アプリケーション接続の切断問題のトラブルシューティング

データベースの運用中には、アプリケーションエラー、データベース接続エラー、データベース権限問題、データベースリソース問題、ネットワーク問題など、さまざまな異常が発生することがよくあります。これらすべての状況の中で、アプリケーション接続が切断されるというケースがあります。

このような場合に、問題の根本原因を迅速に特定し、効率的に解決するために、本記事では明確かつ実践的なアプリケーション接続の切断問題のトラブルシューティングプロセスをまとめました。このプロセスでは問題処理の効率化、業務への影響の低減、日常的な運用保守作業を強力にサポートするための具体的な操作手順を提示しています。

アプリケーション接続の切断問題のトラブルシューティングプロセスは、以下の図のとおりです。

手順の概要

アプリケーション接続が切断された場合、この手順に従ってトラブルシューティングが可能です。

まず、ユーザーが使用しているアプリケーションの開発言語を特定する必要があります。

Java言語

アプリケーションの開発言語がJavaであることを確認した場合、Javaアプリケーションのエラーログの内容を確認することで、現在のアプリケーション接続の切断の原因を判断できます。方法は以下のとおりです。

1. エラーログに Communications link failure 例外が含まれていないか確認します。

   • Javaアプリケーションのエラーログに Communications link failure 例外が含まれていない場合、このシナリオを再現します：

     • 再現できた場合、再現後はプログラムコードのデバッグやネットワークパケットキャプチャ分析などで、プログラムコードのエラー原因を分析できます。
     • 再現できない場合、既存の情報とプログラム自体のロジックを組み合わせて、エラー原因を推測してください。

   • Javaアプリケーションのエラーログに Communications link failure 例外が含まれている場合、次の操作を実行します。

2. 例外ログの Caused by 部分に対応する情報を確認します。

   • この部分の情報が出力されていない場合、スタックトレースが不完全であり、原因を判断できません。アプリケーションが完全なスタックトレースを出力してから問題を再現し、分析を続ける必要があります。

   • この部分の情報が出力されている場合、Caused by 部分の出力情報に基づいて、接続切断の原因を判断できます：

     • 内容が Connection reset"、"can not read response from server. Expected to read 4 bytes,read 0 bytes before connection was unexpectedly lost または unexpected end of stream, read XXX bytes from xxx (socket was closed by server) の場合、アプリケーション側の接続が切断されたことを意味します。エラー情報に基づいてさらに原因を判断する必要があります。具体的な判断方法については、本記事の アプリケーション側の接続が切断された場合 を参照してください。

     • 内容が read timed out" または "Connection timed out (Read failed) の場合、スローSQLがアプリケーションで設定された socketTimeout 時間をトリガーし、プログラム側で接続が切断されたことを意味します。この場合、例外SQLがスローSQLに該当するかどうかを判断する必要があります。スローSQLに該当する場合は、状況に応じてSQLを最適化できます。現在スローSQLが存在しない場合は、socketTimeout の調整を検討できます。具体的な調整方法については、データベース接続プールの設定を参照してください。

     • 内容が connect timed out または Connection timed out: connect の場合、TCPハンドシェイクに失敗したことを意味します。アプリケーションがアクセスしようとする宛先アドレスと宛先ポートが到達不能であり、ネットワークが不通であるか、プログラムのIPアドレスやポート設定に誤りがある可能性があります。

     • 内容が Connection refused の場合、接続に失敗したことを意味します。アプリケーションがアクセスしようとする宛先アドレスと宛先ポートは到達可能ですが、何らかのシステムまたはネットワーク上の理由で接続が拒否されました。

C言語

アプリケーションの開発言語がC言語であることを確認した場合、C言語のアプリケーションエラーログの内容を確認することで、現在のアプリケーション接続の切断の原因を判断できます。

• エラー情報が end-of-file on communication channel または Lost connection to MySQL server during query 例外である場合、アプリケーション側の接続が切断されたことを意味するため、エラー情報に基づいてさらに原因を判断する必要があります。具体的な判断方法については、本記事の アプリケーション側の接続が切断された場合 を参照してください。

• エラー情報が reading initial communication packet または reading authorization packet 例外である場合、データベースへの接続に失敗したことを意味します。失敗原因はネットワーク問題またはバックエンドのOceanBaseデータベースサービスの問題のいずれかである可能性があるため、ログ分析を組み合わせる必要や、場合によってはパケットキャプチャによる判断も必要です。

• アプリケーションログに明らかな異常情報がない場合、現在のシナリオを再現してみてください。

  • 再現できた場合、プログラムコードのデバッグやネットワークパケットキャプチャ分析などで、プログラムコードのエラー原因を分析できます。
  • 再現できない場合、既存の情報とプログラム自体のロジックを組み合わせて、エラー原因を推測してみてください。

アプリケーション側の接続が切断された場合

アプリケーション側の接続が切断されたと判断された場合、ログ情報に conn id の識別子が含まれているか、異常発生時に実行されたSQLが出力されていないかを確認します。どちらもない場合は、診断に必要な重要な情報が欠けているため、アプリケーション側に連絡してより多くの情報を取得する必要があります。ログ情報に上記のいずれかの情報が出力されている場合は、現在のプログラムで設定されているデータソース情報を明確にし、以下の手順に従って処理を進めます。

1. データソースに基づいてアクセスパスを特定します。アクセスパスには、以下の情報を含むアドレスの数が含まれます。

   • OBProxyの数とアドレス情報

   • OBServerホストの数とアドレス情報

2. 現在のアクセスパスを確認し、アプリケーションがOBProxyを経由しているかどうかを確認します。

   • アプリケーションがOBProxyを経由してデータベースに接続する場合

     1. ssh コマンドを使用して、対応するOBProxyノードにログインします。

     2. ps コマンドを実行して、obproxyプロセスの起動時間を確認します。

     3. 異常発生時にアプリケーションが再起動したかどうかを確認します。

        もし再起動した場合、これはOBProxyの再起動が原因で異常が発生したことを意味します。

        再起動していない場合は、次の手順に進みます。

     4. 再起動していない場合は、cd コマンドを使用して、OBProxyのログディレクトリに移動します。OBProxyのログは、インストールディレクトリの /log ディレクトリに保存されています。

     5. conn_id があるかどうかを確認します。なければ、異常に関連するSQLテキストがあるかどうかを確認します。どちらもない場合は、アプリケーション側に連絡して、より多くの情報を取得する必要があります。

        • conn_id がある場合は、その conn_id を以下のコマンドに代入して実行し、異常発生時のobproxyログをフィルタリングします。

          grep "xxxxxx" obproxy.log
          

          xxxxx は実際の conn_id 情報に置き換える必要があります。

        • 異常に関連するSQLテキストがある場合は、SQLテキストの一部の文字を以下のコマンドに代入して実行し、異常発生時のobproxyログをフィルタリングします。

          grep "エラーテキスト" obproxy.log.xxxx | grep "エラー発生時刻"
          

          grep "エラーテキスト" obproxy_error.log.xxxx | grep "エラー発生時刻"
          

     6. フィルタリングされたログエントリに基づいて、異常発生時のobproxyの trace_id を特定します。

     7. trace_id を以下のコマンドに代入して実行し、異常発生時のobproxyログをフィルタリングします。

        grep "xxxxxx" obproxy.log.xxxx | grep "エラー発生時刻"
        

        xxxxx は実際の trace_id 情報に置き換える必要があります。

     8. obproxyログの出力に基づいて、接続切断の状況を判断します。

        • obproxyが積極的に接続を切断した場合、フィルタリングされたログに基づいて切断原因を分析し、必要に応じてobproxyのソースコードと組み合わせて分析します。

        • 接続がobserverによって切断され、アプリケーションの接続が切断された場合、obproxyログエントリに基づいて、切断時の接続OBServerノードおよびobserverのsession_idを特定し、以下の アプリケーションがSSHを使用して対応するOBServerノードに直接ログインする の内容を参照して、次の診断分析を行います。

        • アプリケーションサーバーとobproxyの間のネットワーク機器（例：F5、SLB、その他のネットワーク機器など）によって接続が切断された場合、アプリケーションとobproxyの間のネットワーク機器のトラブルシューティングを行う必要があります。

   • アプリケーションがSSHを使用して対応するOBServerノードに直接ログインする場合

     1. ssh コマンドを使用して、対応するOBServerノードにログインします。

     2. ps コマンドを実行して、observerプロセスの起動時間を確認します。

     3. 異常発生時にアプリケーションが再起動したかどうかを確認します。

        もし再起動した場合、これはOBServerノードの再起動が原因で異常が発生したことを意味します。

        再起動していない場合は、次の手順に進みます。

     4. 再起動していない場合は、cd コマンドを使用して、ログがあるディレクトリに移動します。

        以下では、OceanBaseデータベースのインストールディレクトリが /home/admin/oceanbase である場合を例に説明します。ログの具体的な保存パスは、実際の環境に基づいてください。

        cd /home/admin/oceanbase/log
        

     5. 以下のコマンドを実行して、session id に関連するログをフィルタリングします。

        grep "observer session id" observer.log
        

        grep "observer session id" observer.log.xxx
        

     6. フィルタリングされたログに基づいて、接続状況を判断します。

        • 接続がobserverによって積極的に切断された場合、フィルタリングされたログに基づいて切断原因を分析し、必要に応じてobserverのソースコードと組み合わせて分析します。
        • 接続がobproxyとobserverの間のネットワーク機器によって切断された場合、obproxyとobserverの間のネットワーク機器の使用状況のトラブルシューティングを行う必要があります。

一般的なケース

関連ドキュメント

• サーバー接続の切断問題のトラブルシューティング方法

• OceanBaseデータベースとアプリケーション間の通信TCP原理