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

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

このような場合において、問題の根本原因を迅速に特定し、効率的に解決できるよう支援するために、本記事では明確で実用的なアプリケーション接続切断問題のトラブルシューティングプロセスをまとめました。このプロセスは、明確な操作手順を提供し、問題処理の効率を向上させ、業務への影響を可能な限り軽減することを目的としており、日常的な運用保守作業を強力にサポートします。

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

手順の概要

アプリケーションの接続が切断された場合、この手順に従って問題を調査できます。

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

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の間のネットワーク機器の使用状況を調査する必要があります。

代表的なユースケース