データベースの運用中には、アプリケーションエラー、データベース接続エラー、データベース権限問題、データベースリソース問題、ネットワーク問題など、さまざまな異常が発生することがよくあります。これらすべてのケースの中で、アプリケーション例外であるにもかかわらず、エラーメッセージにOceanBaseエラーコードが含まれる場合があります。
このようなシナリオで問題の根本原因を迅速に特定し、効率的に解決できるよう支援するために、ここではアプリケーション例外でエラーメッセージにOceanBaseエラーコードが含まれる場合の、明確で実用的なトラブルシューティングプロセスをまとめました。このプロセスは、明確な操作手順を提供し、問題処理の効率を向上させ、業務への影響を可能な限り軽減し、日常の運用保守作業を強力にサポートすることを目的としています。
アプリケーション実行時にエラーが発生し、そのエラーメッセージにOceanBaseエラーコードが含まれる場合の問題トラブルシューティングプロセスは、以下の図のとおりです。
手順の紹介
アプリケーションの実行中に異常が発生し、エラーメッセージにOceanBaseのエラーコード情報が含まれている場合は、この手順に従って問題を調査できます。
まず、OBClientを使用してデータベースに接続した後、問題を手動で再現できるかどうかを判断します：
はいの場合、問題が再現されたら、さらに調査を進めることができます。
いいえの場合、プログラムで設定されたデータソース情報を調査する必要があります。
問題の再現によるトラブルシューティング
OBClientを使用し、2881（SQLポート番号、デフォルトは2881、カスタム設定の場合は実際のポート番号に置き換えてください）でOceanBaseクラスタに接続します。
エラーが発生したSQLを手動で実行し、問題のシナリオを再現します。
以下のステートメントを実行して、trace_idを取得します。
注意
エラーが発生したSQLを実行した直後に、すぐに以下のステートメントを実行する必要があります。そうでないと、クエリされるのはエラーが発生したSQLの
trace_idではありません。MySQLモードOracleモードMySQLモードで
trace_idを取得するステートメントは次のとおりです：obclient> SELECT last_trace_id();Oracleモードで
trace_idを取得するステートメントは以下のとおりです：obclient> SELECT last_trace_id() FROM DUAL;実際にSQLを実行したホスト情報を取得します。
OceanBaseクラスタは通常、複数ノードで構成されています。以下のSQLを使用して、SQLが実際に実行されたノードを取得し、その後ログフィルタリングを行います。
MySQLモードOracleモードMySQLモードで以下のステートメントを実行します：
obclient> SELECT * FROM oceanbase.GV$OB_SQL_AUDIT WHERE trace_id=last_trace_id;ここで、
last_trace_idは前のステップで取得したtrace_idに置き換える必要があります。Oracleモードで以下のステートメントを実行します：
obclient> SELECT * FROM SYS.GV$OB_SQL_AUDIT WHERE trace_id=last_trace_id;ここで、
last_trace_idは前のステップで取得したtrace_idに置き換える必要があります。GV$OB_SQL_AUDITビューのクエリ結果によると、svr_ipに対応するホストが、実際にそのSQLを実行したホストです。取得したホスト情報に基づき、
sshコマンドを使用して対応するホストにログインします。ログが保存されているディレクトリに移動します。
以下では、OceanBaseデータベースのインストールディレクトリを
/home/admin/oceanbaseと仮定します。ログの具体的な保存パスは、実際の環境に準じてください。cd /home/admin/oceanbase/log以下のコマンドを実行して、ログ内の関連情報をフィルタリングします。
grep "${trace_id}" observer.loggrep "${trace_id}" observer.log.xxxここで、
${trace_id}は前の手順で取得したtrace_idに、observer.log.xxxはタイムスタンプ付きのログファイルであり、xxxはSQLエラーが発生した時間に応じて実際のタイムスタンプに置き換える必要があります。ログから提供される情報と、関連するエラーメッセージなどを組み合わせて、問題を分析します。
ログに関する詳細は、ログの概要を参照してください。ログの情報が不明確な場合は、テクニカルサポートにお問い合わせいただき、調査のご協力をお願いいたします。
プログラムが設定するデータソース情報の確認
データソースに基づいてアクセスパスを明確にします。
アクセスパスに含まれる以下の情報の数とアドレスを明確にします。
OBProxyの数とアドレス情報
OBServerホストの数とアドレス情報
OBProxyを経由するかどうかを判断します。
はい、OBProxyを経由する場合は、以下の手順を参照してさらに調査します：
sshコマンドを使用して、対応するOBProxyノードにログインします。cdコマンドを使用して、OBProxyのログディレクトリに移動します。OBProxyのログは、インストールディレクトリの/logディレクトリに保存されています。以下のコマンドを実行して、エラーログをフィルタリングします。
grep "エラーテキスト" obproxy_error.log obproxy_error.log.xxx | grep "エラー発生時刻"フィルタリングされたログエントリに基づいて、エラーが発生したSQLがルーティングされたOBServerノードを特定します。
再度
sshコマンドを使用して、対応するOBServerノードにログインし、調査を続けます。
いいえ、OBProxyを経由しない場合は、以下の手順を参照してさらに調査します：
sshコマンドを使用して、対応するOBServerノードにログインします。ログがあるディレクトリに移動します。
以下では、OceanBaseデータベースのインストールディレクトリを
/home/admin/oceanbaseと仮定します。ログの実際の保存パスは、実際の環境に基づいてください。cd /home/admin/oceanbase/log以下のコマンドを実行して、エラーログをフィルタリングします。
grep "sending error" observer.log observer.log.xxx | grep "エラーコード'フィルタリングされたログからtrace_idを取得し、そのtrace_idを使用してログをさらにフィルタリングします。
grep "trace id" observer.log observer.log.xxxログが提供する情報と関連するエラーメッセージなどを組み合わせて問題を分析します。
ログに関する詳細は、ログの概要を参照してください。ログの情報が不明瞭な場合は、テクニカルサポートにお問い合わせいただき、調査をお手伝いいたします。
典型的なケース
- 普通業務テナントの普通ユーザーがOceanBaseデータベースの2881ポートに直接接続する際に、
ERROR 1040 (08004): Too many connectionsエラーが発生した場合。