各 MySQL バージョンは、リリース前に多くのプラットフォームでテストされています。 これは、MySQL にバグがないということではありませんが、バグがあってもごく少数であり、見つかることはまれです。 問題が発生した場合は、システムがクラッシュした正確な原因を探すことが常に役に立ちます。問題の修正が迅速に得られる可能性が高まるためです。
まず、問題は mysqld サーバーが停止したことであるかどうか、またはクライアントに関連しているかどうかを判別してください。 mysqld サーバーが稼働している時間を確認するには、mysqladmin version を実行します。 mysqld が停止して再起動された場合は、サーバーのエラーログを確認すると原因が見つかる可能性があります。 セクション5.4.2「エラーログ」 を参照してください。
一部のシステムでは、mysqld が停止した場所のスタックトレースがエラーログに記録されます。 エラーログに書き込まれる変数値は、常に 100% 正しいとは限りません。
予期しないサーバーイグジットの多くは、データファイルまたはインデックスファイルが破損していることが原因です。 MySQL は、各 SQL ステートメントの実行後、クライアントに結果を通知する前に、ディスク上のファイルを write() システムコールを使用して更新します。 (delay_key_write システム変数を有効にして実行している場合、データファイルは書き込まれますがインデックスファイルは書き込まれません。) これは、mysqld がクラッシュしてもデータファイルのコンテンツは安全であることを意味します。フラッシュされていないデータがオペレーティングシステムによってディスクに書き込まれることが保証されているためです。 各 SQL ステートメントのあとに MySQL がすべてのデータをディスクにフラッシュするようにするには、--flush オプションを指定して mysqld を起動します。
これは、通常、次のいずれかが発生していなければ、データが損なわれたテーブルができることはないことを意味します。
MySQL サーバーまたはサーバーのホストが更新中に強制終了された。
更新の途中に mysqld が停止するバグが見つかった。
一部の外部プログラムは、テーブルを適切にロックせずに、mysqld と同時にデータファイルまたはインデックスファイルを操作しています。
適切なファイルシステムのロック (通常は
lockdロックマネージャーによって処理されます) をサポートしていないシステムで同じデータディレクトリを使用して多数の mysqld サーバーを実行しているか、外部ロックを無効にして複数のサーバーを実行している。大きく破損したデータが含まれているクラッシュしたデータファイルまたはインデックスファイルがあり、mysqld が混乱した。
データストレージのコードにバグが見つかった。 可能性は低いですがあり得ることです。 この場合は、修復されたテーブルのコピーに対して
ALTER TABLEを使用することによって、別のエンジンへのストレージエンジンの変更を試みることができます。
何らかのクラッシュが発生している理由を知ることは非常に困難であるため、まず他のユーザーのために機能するものが予期しない終了になるかどうかを確認してみてください。 次のことを試してください。
mysqladmin shutdown を使用して mysqld サーバーを停止し、データディレクトリから myisamchk --silent --force */*.MYI を実行して、すべての
MyISAMテーブルを確認し、mysqld を再起動します。 これにより、クリーンな状態から実行していることが保証されます。 第5章「MySQL サーバーの管理」 を参照してください。一般クエリーログを有効にして (セクション5.4.3「一般クエリーログ」を参照してください) mysqld を起動します。 ログに書き込まれた情報から、特定のクエリーによってサーバーが強制終了したかどうかを判別してください。 すべてのバグの 95% は特定のクエリーに関連しています。 通常、これは、サーバーが再起動される前のログファイルの最後のクエリーのいずれかです。 セクション5.4.3「一般クエリーログ」を参照してください。 クエリーを発行する前にすべてのテーブルを確認しても、特定のクエリーによって MySQL が繰り返し強制終了される場合は、バグとして判別されましたのでバグレポートを送信してください。 セクション1.6「質問またはバグをレポートする方法」を参照してください。
問題を再現するために使用できるテストケースを作成してください。 セクション5.9「MySQL のデバッグ」を参照してください。
fork_big.plスクリプトを試してください。 (ソース配布のtestsディレクトリにあります。)MySQL をデバッグ用に構成すると、何らかの問題がある場合に、考えられるエラーに関する情報を収集しやすくなります。
-DWITH_DEBUG=1オプションを指定して MySQL を再構成し、CMake を実行して再コンパイルします。 セクション5.9「MySQL のデバッグ」を参照してください。オペレーティングシステムに最新のパッチが適用されていることを確認してください。
--skip-external-lockingオプションを使用して mysqld を起動します。 一部のシステムではlockdロックマネージャーが正常に動作しません。--skip-external-lockingオプションは mysqld に外部ロックを使用しないように通知します。 (これは、同じデータディレクトリで 2 つの mysqld サーバーは実行できず、myisamchk を使用する場合は注意する必要があることを意味します。 それでも、テストとしてこのオプションを試すことには価値があります。)mysqld は実行されているが応答しない場合は、mysqladmin -u root processlist を試してください。 mysqld が応答しないように見えても、ハングアップしていないことがあります。 すべての接続が使用されているか、内部ロックの問題である可能性があります。mysqladmin -u root processlist は、通常、これらの場合でも接続を確立することができ、現在の接続数およびそのステータスに関する役に立つ情報が表示されます。
ほかのクエリーを実行しているときに、別のウィンドウで mysqladmin -i 5 status コマンドまたは mysqladmin -i 5 -r status コマンドを実行して統計を生成します。
-
次の手順を試してください。
gdb (または別のデバッガ) から mysqld を起動します。 セクション5.9「MySQL のデバッグ」を参照してください。
テストスクリプトを実行します。
-
もっとも低い 3 つのレベルでバックトレースおよびローカル変数を出力します。 gdb でこれを行うには、mysqld が gdb 内でクラッシュしたときに、次のコマンドを使用します。
backtrace info local up info local up info localgdb で、
info threadsを使用して存在するスレッドを検査し、thread(ここでNNはスレッド ID です) を使用して特定のスレッドに切り替えることもできます。
Perl スクリプトを使用してアプリケーションをシミュレートし、MySQL を強制的に終了または誤動作させてください。
通常のバグレポートを送信します。 セクション1.6「質問またはバグをレポートする方法」を参照してください。 通常より詳しく記述してください。 MySQL は多くのユーザーの環境では動作しているため、クラッシュは問題となっているコンピュータにのみ存在する何かによって発生している可能性があります (たとえば、特定のシステムライブラリに関連するエラー)。
-
動的長の行を含むテーブルで問題があり、
VARCHARカラム (BLOBカラムまたはTEXTカラムではなく) のみを使用している場合は、ALTER TABLEを使用して、すべてのVARCHARをCHARに変更してみてください。 これにより、MySQL が固定長の行を使用するようになります。 固定長の行では若干追加の領域が使用されますが、破損に対してより耐性があります。現在の動的行のコードは数年使用されており、問題はほとんど発生していませんが、動的長の行はその性質のためエラーが発生しやすい傾向があるので、この方法がうまくいくかどうかを試すのは良い考えである可能性があります。
問題を診断する場合は、ハードウェアの障害の可能性を考慮に入れてください。 欠陥のあるハードウェアは、データ破損の原因となることがあります。 ハードウェアをトラブルシューティングする場合は、メモリーおよびディスクのサブシステムに特に注意してください。