このセクションの説明では、MyISAM テーブル (拡張子 .MYI および .MYD) に対し myisamchk を使用する方法について説明します。
さらに、CHECK TABLE および REPAIR TABLE ステートメントを使用して、MyISAM テーブルをチェックして修復することもできます。 セクション13.7.3.2「CHECK TABLE ステートメント」およびセクション13.7.3.5「REPAIR TABLE ステートメント」を参照してください。
破損したテーブルの兆候として、予期せずに中止するクエリーや次のような観察可能なエラーが含まれます。
ファイル
tbl_name.MYInnn)。予期しないファイルの終わり
レコードファイルがクラッシュしました
テーブルハンドラからエラー
nnnを取得します
エラーの詳細を取得するには、perror nnn を実行します。ここで、nnn はエラー番号です。 次の例は、perror を使用して、テーブルの問題を示すもっとも一般的なエラー番号の意味を見つける方法を示しています。
shell> perror 126 127 132 134 135 136 141 144 145
MySQL error code 126 = Index file is crashed
MySQL error code 127 = Record-file is crashed
MySQL error code 132 = Old database file
MySQL error code 134 = Record was already deleted (or record file crashed)
MySQL error code 135 = No more room in record file
MySQL error code 136 = No more room in index file
MySQL error code 141 = Duplicate unique key or constraint on write or update
MySQL error code 144 = Table is crashed and last repair failed
MySQL error code 145 = Table was marked as crashed and should be repaired
エラー 135 (レコードファイルに空きがない) およびエラー 136 (インデックスファイルに空きがない) は、単純な修復で修正できるエラーではありません。 この場合、ALTER TABLE を使用して、MAX_ROWS および AVG_ROW_LENGTH テーブルオプションの値を増やす必要があります。
ALTER TABLE tbl_name MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;
現在のテーブルオプション値が不明な場合は、SHOW CREATE TABLE を使用します。
その他のエラーの場合は、テーブルを修復する必要があります。myisamchk は通常発生するほとんどの問題を検出し、修正できます。
修復プロセスには、ここで説明する 3 つのステージが含まれます。 始める前に、場所をデータベースディレクトリに変更し、テーブルファイルの権限をチェックしてください。 Unix では、mysqld を実行するユーザーによって (およびチェックするファイルにアクセスする必要があるため、チェックするユーザーにも)、それらが読み取り可能であることを確認します。 ファイルを変更する必要があることが分かったら、それらに書き込みできる必要もあります。
このセクションでは、テーブルチェックが失敗した (セクション7.6.2「MyISAM テーブルのエラーのチェック方法」 で説明しているものなど) 場合、または myisamchk が提供する拡張機能を使用する場合について説明します。
テーブル保守に使用される myisamchk オプションについては、セクション4.6.4「myisamchk — MyISAM テーブルメンテナンスユーティリティー」で説明しています。myisamchk には、パフォーマンスを向上できるメモリー割り当てを制御するために設定できる変数もあります。 セクション4.6.4.6「myisamchk メモリー使用量」を参照してください。
コマンド行からテーブルを修復する場合は、まず mysqld サーバーを停止する必要があります。 リモートサーバーで mysqladmin shutdown を実行すると、mysqladmin が戻ったあとに、すべてのステートメント処理が停止し、すべてのインデックス変更がディスクにフラッシュされるまで、しばらくの間 mysqld サーバーがまだ使用できることに注意してください。
ステージ 1: テーブルのチェック
myisamchk *.MYI または時間があれば myisamchk -e *.MYI を実行します。 -s (サイレント) オプションを使用すると、不要な情報を抑制します。
mysqld サーバーが停止している場合は、--update-state オプションを使用して、myisamchk にテーブルを「チェック済み」とマークするように指示してください。
myisamchk がエラーを報告しているテーブルだけを修復する必要があります。 そのようなテーブルの場合、ステージ 2 に進みます。
チェック時に、予期しないエラー (out of memory エラーなど) を受け取った場合、または myisamchk がクラッシュした場合、ステージ 3 へ進みます。
ステージ 2: 簡単で安全な修復
まず myisamchk -r -q tbl_name を試します (-r -q は「クイックリカバリモード」を意味します)。 これは、データファイルにアクセスせずに、インデックスファイルを修復しようとします。 データファイルに、必要なすべてのものが含まれ、削除リンクがデータファイル内の正しい場所を指している場合、これは機能するはずであり、テーブルが修正されます。 次のテーブルの修復を開始します。 そうでない場合は、次の手順を使用します。
続行する前に、データファイルのバックアップを作成します。
myisamchk -r
tbl_nameを使用します (-rは「リカバリモード」を意味します)。 これによって、正しくない行と削除された行がデータファイルから削除され、インデックスファイルが再構築されます。先述のステップが失敗した場合、myisamchk --safe-recover
tbl_nameを使用します。 安全なリカバリモードでは、通常のリカバリモードで扱われないわずかなケースを処理する古いリカバリ方法を使用します (ただし遅くなります)。
修復操作を大幅に高速化する場合、sort_buffer_size および key_buffer_size 変数の値をそれぞれ、myisamchk の実行時に使用可能なメモリーの約 25% に設定してください。
修復時に、予期しないエラー (out of memory エラーなど) を受け取った場合、または myisamchk がクラッシュした場合、ステージ 3 へ進みます。
ステージ 3: 困難な修復
このステージに到達するのは、インデックスファイル内の最初の 16K バイトのブロックが破損しているか、誤った情報が含まれている場合、またはインデックスファイルが失われている場合に限られるはずです。 この場合、新しいインデックスファイルを作成する必要があります。 次のように実行します。
データファイルを安全な場所に移動します。
-
テーブル記述ファイルを使用して、新しい (空の) データファイルとインデックスファイルを作成します。
shell> mysql db_namemysql> SET autocommit=1; mysql> TRUNCATE TABLE tbl_name; mysql> quit 古いデータファイルを新しく作成したデータファイルにコピーします。 (古いファイルを新しいファイルに単に移動しないでください。 何か異常があった場合に備えて、コピーを保持する必要があります。)
レプリケーションを使用している場合、それにはファイルシステム操作が含まれ、これらは MySQL によって記録されないため、上記の手順を実行する前に、それを停止してください。
ステージ 2 に戻ります。myisamchk -r -q が機能するはずです。 (これは無限ループにならないはずです。)
手順全体を自動的に実行する REPAIR TABLE SQL ステートメントを使用することもできます。 tbl_name USE_FRMREPAIR TABLE を使用すると、サーバーがすべての作業を実行するため、ユーティリティーとサーバー間の不要なやり取りの可能性もなくなります。 セクション13.7.3.5「REPAIR TABLE ステートメント」を参照してください。