MySQLは、Oracleに次ぐDB Engine Webサイトによると、世界で2番目に有名なデータベースです。 MySQLを有名にしているのは、おそらくそれが非常に高速で信頼性が高く、柔軟なデータベース管理システムだからです。 MySQLは、ClusterControlでサポートされているデータベースの1つでもあります。 ClusterControlを使用すると、さまざまなことを簡単に展開、スケーリング、監視、実行できます。
今日はそれらについては説明しませんが、MySQLの一般的なエラーの1つと考えられるトラブルシューティングのヒントについて説明します。チケットを操作しているときに、エラーレポートやログを確認するときに、「通信パケットの読み取り中にエラーが発生しました」という行が頻繁に表示されました。このエラーに関連するブログをお客様だけでなく、他の読者にも書いていただければ幸いです。もう待つ必要はありません。もっとダイビングする時が来ました！
MySQLクライアント/サーバープロトコル
まず、MySQLがクライアントとサーバー間で通信する方法を理解する必要があります。クライアントとサーバーの両方が、コネクタ、MySQLプロキシ、およびマスターとスレーブのレプリケーションサーバー間の通信によって実装されるMySQLプロトコルを使用しています。 MySQLプロトコルは、SSLを介した透過的な暗号化、透過的な圧縮、接続フェーズ、およびコマンドフェーズなどの機能をサポートします。
整数と文字列はどちらも、MySQLプロトコル全体で使用される基本的なデータ型です。 MySQLクライアントとサーバーが相互に通信したり、データを送信したりする場合は常に、データを最大サイズ16MBのパケットに分割し、すべてのチャンクにパケットヘッダーを付加します。各パケットの中には、データ型（整数/文字列）がその役割を果たす場所であるペイロードがあります。
CLIENT_PROTOCOL_41が有効になっていることを考慮すると、クライアントがサーバーに送信するほとんどすべてのコマンドに対して、サーバーは次のパケットのいずれかを応答として応答します。
| OK_Packet | これは、成功したすべてのコマンドのシグナルです。 |
| ERR_Packet | |
| EOF_Packet | |
通常、接続の問題には、通信エラーまたは接続の中止の2種類があります。これらの接続の問題のいずれかが発生した場合は常に、次の情報源がトラブルシューティングと分析の開始点として適しています。
-
エラーログ
-
一般的なクエリログ
-
Aborted_xxxおよびConnection_errors_xxxステータス変数
-
ホストキャッシュ
接続エラーが発生した場合、エラーに応じて、ステータス変数のAborted_clientsまたはAborted_connectsのステータスカウンターがインクリメントされます。 MySQLのドキュメントからわかるように、Aborted_clientsは、接続を適切に閉じずにクライアントが停止したために中止された接続の数を意味します。 Aborted_connectsの場合、MySQLサーバーへの接続に失敗した回数を意味します。
--log-warningsオプションを指定してMySQLサーバーを起動した場合、エラーログに次のメッセージの例が表示される可能性があります。お気づきのように、メッセージは接続の中止に関連していることを明確に示しているため、Aborted_connectsステータスカウンターはステータス変数でインクリメントされます：
[警告]dbへの接続154669を中止しました：'wordpress' user：'wpuser' host：'hostname'（通信パケットの読み取り中にエラーが発生しました）
通常、次の理由により、接続の試行が失敗する可能性があります。これに気付いたときは、権限のない人がデータベースを侵害しようとしていることを示している可能性があり、できるだけ早くデータベースを確認することをお勧めします。
-
クライアントにはデータベースにアクセスする権限がありません。
-
間違ったクレデンシャルが使用されました。
-
誤った情報を持つ接続パケット。
-
connect_timeoutが接続するための制限に達したため。
Aborted_clientsのステータス変数は、クライアントが接続できたが、接続が切断されたり、不適切な方法で終了したりした場合に、サーバーによって増分されます。それに加えて、サーバーは中止された接続メッセージをエラーログに記録します。このタイプのエラーの場合、通常、次の理由が原因である可能性があります。
-
クライアントは、終了する前に接続を適切に閉じません（mysql_close（）を呼び出さない）。
> -
クライアントがwait_timeoutまたはinteractive_timeout秒を超えました。
-
クライアントプログラムまたはアプリケーションがデータ転送の途中で突然終了しました。
前述の理由に加えて、接続の中止とクライアントの中止の両方の問題のその他の考えられる理由は、次のいずれかに関連している可能性があります。
-
TCP/IP構成が混乱しています。
-
変数の値が、max_allowed_packetに対して小さすぎます。
-
クエリのメモリ割り当てが不十分です。
-
イーサネット、スイッチ、ケーブルなどのハードウェアの故障
-
スレッドライブラリの問題。
-
転送がバースト-一時停止-バースト-一時停止モードになるデュプレックスシンドロームの問題（イーサネットプロトコルを使用している場合） Linuxの場合、半二重と全二重の両方）。
これで、MySQL接続エラーの原因となる多くの可能性を学びました。私たちの経験に基づくと、ほとんどの場合、この問題はファイアウォールまたはネットワークの問題に関連しています。このような問題を診断するのは簡単ではないと言っても過言ではありません。それでも、このエラーを解決するには、次の解決策が役立つ場合があります。
-
アプリケーションが接続を閉じるためにwait_timeoutに依存している場合は、アプリケーションロジックを変更して接続を閉じる価値があります。操作の終了時に適切に閉じられます。
-
max_allowed_packetの値が許容範囲内にあることを確認して、クライアントが以下に関連するエラーを受け取らないようにします。 「パケットが大きすぎます」。
-
DNSが原因である可能性のある接続遅延の問題については、skip-name-があるかどうかを確認する価値があります。解決が有効になっています。
-
PHPアプリケーションまたはその他のプログラミングを使用している場合は、中断しないようにするのが最善です。通常max_execution_timeに設定される接続。
-
netstatからのTIME_WAIT通知がたくさんあることに気付いた場合は、接続が適切に管理されていることを確認する価値があります。アプリケーション終了。
-
Linuxを使用していて、問題がネットワークに起因していると思われる場合は、ネットワークインターフェイスを確認することをお勧めします。 ifconfig-aコマンドを使用して、MySQLサーバーの出力にエラーがないか調べます。
-
ClusterControlユーザーの場合、クラスター->セキュリティ->監査ログから監査ログを有効にできます。この機能を有効にすると、原因のクエリを絞り込むのに役立ちます。
-
tcpdumpやWiresharkなどのネットワークツールは、MySQLの潜在的なネットワークの問題、タイムアウト、およびリソースの問題を特定するのに役立ちます。
-
特にイーサネット、ハブ、スイッチ、ケーブルなどの障害のあるデバイスがないことを確認して、ハードウェアを定期的にチェックしますなど。常に接続が良好であることを確認するために、障害のあるアプライアンスを交換する価値があります。
MySQL接続パケットの問題につながる可能性のある理由はたくさんあります。この問題が発生するたびに、それは間違いなくビジネスと日常業務に影響を与えます。このタイプの問題は診断が容易ではなく、ほとんどの場合、ネットワークまたはファイアウォールが原因ですが、問題を修正するために以前に提案されたすべての手順を考慮する価値があります。このブログ投稿が、特にこの問題に直面したときに、何らかの形で役立つことを心から願っています。