Go to the first, previous, next, last section, table of contents.


13 Maintaining a MySQL installation

13.1 テーブルのメンテナンス、クラッシュからの修復のための myisamchk 使用

MyISAM テーブル (.MYI and .MYD) の検査・修復には myisamchk を 使用します。 ISAM テーブル (.ISM and .ISD) の検査・修復には isamchk を 使用します。 「9.4 MySQL table types」節参照.

以下の文は myisamchk について述べていますが、isamchk にもすべて 当てはまります。

myisamchk ユーティリティは、データベースのテーブルの情報を得たり、 チェックしたり、テーブルの修復や最適化に使用します。 以下のセクションでは、 myisamchk の起動方法(オプションの説明も含む)、 テーブルの保守スケジュールのたて方、 myisamchk の色々な機能の使い方を述べます。

もし mysqld--skip-locking で走らせているなら、 (これは Linux など、いくつかのシステムでデフォルトです)、 mysqld があるテーブルを使用しているとき、あなたは同じテーブルに対して myisamchk で確実に検査できません。もし myisamchk 中に、 だれも mysqld を通してそのテーブルをアクセスしないのが確実なら、 テーブルを検査する前に mysqladmin flush-tables を行うべきです。 そうでない場合、テーブルの検査中は mysqld を落とすべきです。 もし mysqld がテーブルを更新中に myisamchk を実行した場合、 テーブルが変更された旨のワーニングがでるでしょう。

もし --skip-locking を使用していないなら、いつでも myisamchk は 使用できます。これを実行している間、全てのテーブルを更新するクライアントは myisamchk が準備できるまで待ちます。

もし myisamchk をテーブルの修復、最適化に使用するなら、その最中に、 mysqld がそのテーブルを絶対に使用しないようにしなければ なりません。これは --skip-locking を使用している場合に起こりえます。 もし mysqld をダウンさせていないなら、最低 myisamchk 実行前に、 mysqladmin flush-tables を実行すべきです。

テーブルの修復と最適化のために、ほとんどの場合、 OPTIMIZE TABLES コマンドが使用できます。しかしこれは myisamchk に比べて、 遅くて確実でもありません。(fatal error発生時の場合)。これは その反面、使用方法が簡単でテーブルのフラッシュを気にかける必要がありません。 「7.9 OPTIMIZE TABLE構文」節参照.

13.2 myisamchk 起動構文

myisamchk は以下のようにして起動します:

shell> myisamchk [options] tbl_name

options に、あなたが myisamchk にさせたいことを指定します。 その説明は後述します。(myisamchk --help と実行すれば、オプションの一覧が取れます)。 オプションがなければ、 myisamchk は単にテーブルを検査するだけです。 より多くの情報を得たい、あるいは、 myisamchk に誤り訂正の行動を取らせる事については、後述します。

tbl_name は検査したいテーブル名です。 もしどこか違うディレクトリにあるデータベースに対して myisamchk を走らせたいなら、 myisamchk にはファイルがどこにあるかわからないので、 ファイルのパスを指定しなければなりません。 実際、 myisamchk はあなたが使用しているファイルがデータベースのディレクトリにあるかどうかは考慮しません; ほかの場所にデータベーステーブルのファイルをコピーし、そのコピーしたファイルに対して 回復操作を実行することができます。

myisamchk コマンドラインには、複数のテーブル名が指定できます。 また、インデックスファイル名(`.MYI' 接尾語のついたファイル)も指定でき、 さらに `*.MYI' とすれば、ディレクトリ内の全てのテーブルが指定できます。 例えば、現在のカレントディレクトリがデーターベースディレクトリならば、 そのディレクトリ内の全てのテーブルは、以下のようにして検査できます:

shell> myisamchk *.MYI

データベースディレクトリに入っていない場合、 パスを指定することにより全てのテーブルが検査できます:

shell> myisamchk /path/to/database_dir/*.MYI

MySQL データディレクトリのパスにワイルドカードを使用することにより、 データベースの全てのテーブルも検査できます:

shell> myisamchk /path/to/datadir/*/*.MYI

myisamchk は以下のオプションを持ちます:

-a, --analyze
キーの分布(配置)を分析します。 これは MySQL のいくつかの結合を速くします。
-#, --debug=debug_options
デバッグログの出力。 debug_options はよく 'd:t:o,filename' とされます。
-d, --description
テーブルに関するいくらかの情報を表示します
-e, --extend-check
テーブルを非常に徹底的に検査します。 極端な場合にだけで必要とされます。 通常 myisamchk は、このオプションなしで全てのエラーを見つけるはずです。
-f, --force
古い一時的なファイルを上書きします。 myisamchk-r なしで走らせてテーブルを検査しているときに、 -f を使用するならば、 myisamchk はチャックでエラーが出たテーブルに対して、 自動的に -r を伴って、検査を再開します。
--help
ヘルプを表示して終了。
-i, --information
検査されたテーブルの統計情報を表示。
-k #, --keys-used=#
-r と共に使用します。 NISAM テーブルハンドラーに最初の # インデックスだけを更新するように指示します。 より高い番号のインデックスは非アクティブにします。 これはインサートを速くします! 非アクティブになったインデックスは、myisamchk -r を使用すれば再びアクティブになります。
-l, --no-symlinks
修復時にシンボリックリンクを追いません。 通常、myisamchk はシンボリックリンクが指し示すテーブルも修復します。
-q, --quick
-r と共に使用され、修復を早く行います。 通常、オリジナルのデータファイルは検査されません; 二回 -q を指定すると、強制的にオリジナルのデータファイルも使用します。
-r, --recover
修復モード。 一意のキーを除いた、一意でないキーのほとんどを修正できます。
-o, --safe-recover
修復モード。 古い修復方法を使用します; これは -r よりも遅いですが、 -r が扱えないものも扱えます。
-O var=option, --set-variable var=option
変数に値を入れます。可能な変数は後述します。
-s, --silent
静粛モード。 エラーのみを出力します。 二度 -s を指定すると(-ss)、myisamchk は ほとんど出力をしなくなります。
-S, --sort-index
インデックスブロックのソート。 これは、アプリケーションでの ``read-next'' を速くします。
-R index_num, --sort-records=index_num
インデックスに従ってソート。 これはあなたのデータをよりよく配置し、このインデックスへの SELECT, ORDER BY オペレーションを速くします。 (この操作の最初のソートは非常に遅くなるかもしれません!) テーブルのインデックスの番号をみつけるには SHOW INDEX を使用しますが、 これは myisamchk がテーブルのインデックスを見つけるのと同じ順序で行います。 インデックス番号は 1 から始まります。
-u, --unpack
pack_isam でパックされたテーブルをアンパックします。
-v, --verbose
冗長モード。より多く情報を出力します。 -d-e オプションと共に使用できます。 -v を複数指定すると(-vv, -vvv)、もっと出力が多くなります!
-V, --version
myisamchk バージョンを表示して終了。
-w, --wait
テーブルがロックされていたら待ちます。

--set-variable (-O) オプションで可能な変数:

key_buffer_size       current value: 16776192
read_buffer_size      current value: 262136
write_buffer_size     current value: 262136
sort_buffer_size      current value: 2097144
sort_key_blocks       current value: 16
decode_bits           current value: 9

13.3 myisamchk メモリ使用

myisamchk を走らす上でメモリーの配分は重要です。 myisamchk-O オプションで定義した以上のメモリは使用しません。 とても大きなファイルのたいして myisamchk をかけたいなら、 メモリーをどれくらい使用するかを最初に決めなくてはなりません。 デフォルトは固定で約 3M だけを使用します。大きな値を使用することで、 myisamchk をより速く動作できます。 例えば、32MBytesのRAMがあるなら、以下のように指定できます (他のオプションも指定して):

shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...

-O sort=16M の使用は多くの場合おそらく十分でしょう。

しかし、myisamchkTMPDIR 内に一時ファイルを使用します。 TMPDIR がメモリファイルシステムを指している場合は、簡単に out of memory エラーを得るでしょう。 If this happens, set TMPDIR to point at some directory with more space and restart myisamchk

13.4 テーブルの保守体制の設定

問題が発生するまで待つより、定期的にテーブルを検査する方がよりよい考えです。 保守目的には、myisamchk -s でテーブルを検査するのがよいでしょう。 -s オプションはサイレントモードなので、エラーが起きた場合にだけメッセージを出力します。

サーバーを開始するときにテーブルを検査するのもよい考えです。 例えば、更新最中にマシンがリブートされたなら、全てのテーブルに関して その影響がないか検査する必要があります。(これは``expected crashed table''です) リブート後にもし古い `.pid' ファイル(プロセスID) があるならば、 24時間以内に変更されたテーブルに対して myisamchk を走らせて検査させるように、 safe_mysqld にテストを追加しても構いません。 (`.pid' ファイルは mysqld 起動時に作られ、通常修了時に消されます。 スタート時に `.pid' ファイルが存在するなら mysqld が異常終了したことを示します。)

良いテストは、`.pid' ファイルの作成時間以降に変更された 全てのテーブルを検査するテストです。

通常のシステム運用中にもテーブルを検査すべきです。 TcX では、週に一度、 cron を使用して重要なテーブルを検査しています。 `crontab' ファイルには以下のように記述します:

35 0 * * 0 /path/to/myisamchk -s /path/to/datadir/*/*.MYI

これは壊れたテーブルの情報を出力しますので、必要とあらば検査、修復が行えるわけです。

予想外の事故で壊れたテーブル(ハードウェアのトラブルが原因で崩壊)を除き、 2,3年間、テーブルは壊れたことはありません(これは本当に本当です)。 ので、一週間に一度のチェックでも十分です。

24時間以内に変更された全てのテーブルに対して、 myisamchk -s を毎晩実行する事を勧めます。 そうすれば、あなたは我々と同じぐらいに MySQL を 信頼することになります。

13.5 テーブル情報取得

テーブルから詳細/統計を得るためには、次の方法を使用します。後でさらに詳細な情 報をいくつか説明します。

myisamchk -d tbl_name
myisamchk を ``describe mode'' で実行し、テーブルの説明記述を作ります。 --skip-locking を指定して MySQL サーバーを起動した場合、 myisamchk は myisamchk 実行中に更新されたテーブルについてエラーを報告します. しかし myisamchk は describe mode ではテーブルを変えないので、 データを破壊する危険性はありません。
myisamchk -d -v tbl_name
myisamchk がしていることに関する、より多くの情報を作り出すには、 -v をつけて冗長モードで走らせるようにします。
myisamchk -eis tbl_name
テーブルから最も重要な情報だけを示します。 テーブル全体を読まなければならないので、遅いです。
myisamchk -eiv tbl_name
-eis と似ているが、何を行っているかを表示します。

myisamchk -d 出力の例:

ISAM file:     company.MYI
Data records:           1403698  Deleted blocks:         0
Recordlength:               226
Record format: Fixed length

table description:
Key Start Len Index   Type
1   2     8   unique  double
2   15    10  multip. text packed stripped
3   219   8   multip. double
4   63    10  multip. text packed stripped
5   167   2   multip. unsigned short
6   177   4   multip. unsigned long
7   155   4   multip. text
8   138   4   multip. unsigned long
9   177   4   multip. unsigned long
    193   1           text

myisamchk -d -v 出力の例:

ISAM file:     company.MYI
Isam-version:  2
Creation time: 1996-08-28 11:44:22
Recover time:  1997-01-12 18:35:29
Data records:           1403698  Deleted blocks:              0
Datafile: Parts:        1403698  Deleted data:                0
Datafilepointer (bytes):      3  Keyfile pointer (bytes):     3
Max datafile length: 3791650815  Max keyfile length: 4294967294
Recordlength:               226
Record format: Fixed length

table description:
Key Start Len Index   Type                      Root Blocksize Rec/key
1   2     8   unique  double                15845376      1024       1
2   15    10  multip. text packed stripped  25062400      1024       2
3   219   8   multip. double                40907776      1024      73
4   63    10  multip. text packed stripped  48097280      1024       5
5   167   2   multip. unsigned short        55200768      1024    4840
6   177   4   multip. unsigned long         65145856      1024    1346
7   155   4   multip. text                  75090944      1024    4995
8   138   4   multip. unsigned long         85036032      1024      87
9   177   4   multip. unsigned long         96481280      1024     178
    193   1           text

myisamchk -eis 出力の例:

Checking ISAM file: company.MYI
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:  98%  Packed:   17%

Records:          1403698    M.recordlength:     226   Packed:             0%
Recordspace used:     100%   Empty space:          0%  Blocks/Record:   1.00
Recordblocks:     1403698    Deleteblocks:         0
Recorddata:     317235748    Deleted data:         0
Lost space:             0    Linkdata:             0

User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966

myisamchk -eiv 出力の例:

Checking ISAM file: company.MYI
Data records: 1403698   Deleted blocks:       0
- check file-size
- check delete-chain
index  1:
index  2:
index  3:
index  4:
index  5:
index  6:
index  7:
index  8:
index  9:
No recordlinks
- check index reference
- check data record references index: 1
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 2
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
- check data record references index: 3
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
- check data record references index: 5
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 6
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 7
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 8
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 9
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
Total:    Keyblocks used:   9%  Packed:   17%

- check records and index references
[LOTS OF ROW NUMBERS DELETED]

Records:          1403698    M.recordlength:     226   Packed:             0%
Recordspace used:     100%   Empty space:          0%  Blocks/Record:   1.00
Recordblocks:     1403698    Deleteblocks:         0
Recorddata:     317235748    Deleted data:         0
Lost space:             0    Linkdata:             0

User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, Involuntary context switches 122798

上で使用されたテーブルのデータファイルサイズをここに示します:

-rw-rw-r--   1 monty    tcx     317235748 Jan 12 17:30 company.ISD
-rw-rw-r--   1 davida   tcx      96482304 Jan 12 18:35 company.ISM
-rw-rw-r--   1 monty    tcx     317235748 Jan 12 17:30 company.MYD
-rw-rw-r--   1 davida   tcx      96482304 Jan 12 18:35 company.MYI

myisamchk が生成する情報の説明を以下に示します。 ``keyfile'' はインデックスファイルです。 ``Record'' と ``row'' は同義です。

ISAM file
ISAM (index) ファイルの名前
Isam-version
ISAM 形式のバージョン。現在は常に 2 。
Creation time
データファイルが生成された時。
Recover time
インデックス/データファイルが最後に再構築された時。
Data records
レコード/行の数。
Deleted blocks
予約された領域をまだ持っている削除ブロック数。 このスペースを最小にするために自分のテーブルを最適化することができます。 「13.6.3 テーブルの最適化」節参照.
Datafile: Parts
動的なレコード形式にいくつのデータブロックがあるかを表示します。 分割なしで最適化されたテーブルでは Data records と同じです。
Deleted data
改善されていない削除データのバイト数。 このスペースを最小にするために自分のテーブルを最適化することができます。 「13.6.3 テーブルの最適化」節参照.
Datafile pointer
データファイルポインタの大きさ(バイト数)。これは普通 2, 3, 4 または 5 バ イトです。多くのテーブルは 2 バイトで管理されますが、これはまだ MySQL から制御できません。固定テーブルではこれはレコードアドレ スです。動的テーブルではこれはバイトアドレスです。
Keyfile pointer
データファイルポインタのバイト数。これは普通 1, 2 または 3 バイトです。 多くのテーブルは 2 バイトで管理されますが、これは MySQL では自動的に 計算されます。これは常にブロックアドレスです。
Max datafile length
テーブルのデータファイル (.MYD ファイル) が獲得できる長さ (バイト数)。
Max keyfile length
テーブルのキーファイル (.MYI ファイル) が獲得できる長さ (バイト数)。
Recordlength
各レコード/行が使用する領域の大きさ(バイト数)。
Record format
各テーブルの行が持つ形式。この例では Fixed length を使用します。 他の値で可能な物は圧縮パックします。
table description
テーブル内の全てのキーのリスト。各キーについて、いくつかの低レベル情報が提供さ れます:
Key
このキー番号。
Start
このインデックス部が開始するレコード/行内の位置。
Len
インデックス部の長さ。パックされた数値では、これは常に項目の完全な長さになります。 文字型においては、文字型の項目の頭の部分にインデックスがつく事になりますので、 インデックス項目の最大長さよりもこの値は短くなるでしょう。
Index
unique or multip. (multiple). このインデックス内では1つの値が複数 回存在し得ます。
Type
このインデックス部が持つデータ型。 これは NISAM データ型で、 packed, strippedempty オプションを持ちます。
Root
ルートインデックスブロックのアドレス。
Blocksize
各インデックスブロックのサイズ。これはデフォルトでは 1024 ですが、コンパ イル時に変更できます。
Rec/key
これはオプティマイザによって使用される統計値です。このキーの値ごとのレコー ド数を知らせます。ユニークキーは常に1の値を持ちます。これはテーブルがロードさ れた(または大きく変更された)後に myisamchk -a で更新されます。これ が全く更新されない場合はデフォルト値の 30 が与えられます。
上の最初の例では、9番目のキーは2つの部分をもったマルチパートキーです。
Keyblocks used
使用されたキーブロックのパーセンテージ。このテーブルは myisamchk で再配置 されるため、値はとても高くなります (理論的な最大にとても近くなります)。
Packed
MySQL は一般の接尾辞でキーのパックを試みます。これは CHAR/VARCHAR/DECIMAL キーでだけ使用できます。名前の ような長い文字列では、これは使用領域を顕著に減らします。上の三番目の例では4番目 のキーが10文字長で、領域の60%の減少を得ます。
Max levels
このキーの Btree の深さ。長いキーを持つ大きなテーブルは高い値を得ます。
Records
テーブルが持っている行数。
M.recordlength
平均の行長。固定テーブルでは、これはレコード長です。
Packed
MySQL は文字列の最後から空白を除きます。これによって節約された パーセンテージを Packed は示します。
Recordspace used
データファイルが使用されたパーセンテージ。
Empty space
データファイルが使用されていないパーセンテージ。
Blocks/Record
レコード毎のブロック数 (i.e., 断片化レコードの構成数)。 これは固定形式テーブルでは常に1です。この値は可能な限 り 1.0 に留まります。これが大きすぎる場合は、myisamchk でテーブルを再配置できます。 「13.6.3 テーブルの最適化」節参照.
Recordblocks
使用されたブロック (links) 数。固定型式ではこれはレコード数と同じです。
Deleteblocks
削除されたブロック (links) 数。
Recorddata
データファイル中にある実際のユーザデータのバイト数。
Deleted data
データファイル中にある削除された(unused)データのバイト数。
Lost space
レコードがより短い長さに更新された場合、いくつかの領域が失われます。これ はそのような消失の全ての合計です。in bytes.
Linkdata
動的形式の使用時、ブロックはポインタ(4~7バイト)にリンクされます。Linkdataは そのポインタの全ての合計です。

テーブルが pack_isam で圧縮されているなら、myisamchk -d は それぞれのテーブルコラムに関する追加情報を出力します。 「12.5 MySQL の圧縮された読み込み専用テーブルジェネレータ ( myisampackpack_isam )」節. を参照してください。 この情報例と説明記述の意味があります。

13.6 Using myisamchk for crash recovery

MySQL がデータ格納に使用するファイル形式は、 広範囲にわたってテストされました。が、データベースのテーブルが 破壊されるかもしれない外的状況があります:

本節では、MySQL のデータの扱い方、検査の方法を述べます。 もしテーブルがたくさんダメになるのであれば、 あなたは、この理由を見つけるよう試みるべきです! 「G.1 MySQL server のデバッグ」節参照.

破壊からの修復をする場合、”データベース内のそれぞれのテーブル tbl_name は、 データベースディレクトリ内にある三つのファイルに一致する”、これを理解する事は とても重要です:

File Purpose
`tbl_name.frm' Table definition (form) file
`tbl_name.MYD' Data file
`tbl_name.MYI' Index file

これら三つのファイルは様々な方法で破壊を受ける事がありますが、 この場合最も問題が起こりやすいのは、データファイルとインデックスファイルです。

myisamchk`.MYD' ファイル(データ)のコピーを一行一行おこないます。 この修理過程の最後に、古い `.MYD' ファイルを消し、新しいファイルをオリジナルの名前に変更します。 もし --quick オプションを使用したなら、myisamchk`.MYD' ファイルの一時ファイルを作りません。そのかわり、`.MYD' ファイル が正しいと仮定して新しいインデックスファイルだけを作ります。 この時 `.MYD' ファイルはいじりません。 この場合、myisamchk は自動で `.MYD' ファイルの間違いを検出して 修復を中止するので、安全です。

myisamchk に二つ --quick オプションを指定することもできます。 この場合、myisamchk はいくつかのエラー(キーの重複とか)では中止はしません。 かわりに `.MYD' ファイルを変更します。

通常の修理を実行するためにディスクのスペースの空きが少ししか無い場合に限って、 --quick の二回指定が役に立ちます。 この場合,あなたは myisamchk を走らせる前にバックアップを 少なくともとるべきです。

13.6.1 テーブルのエラーチェック方法

テーブルをチェックするには,以下のコマンドを使用してください:

myisamchk tbl_name
これはすべての誤りの99.99%を見つけます。 これが見つけることができない物は、データファイルの破壊だけです (これは非常にまれ)。もしテーブルをチェックしたいなら、オプションなしで myisamchk を走らすか、-s or --silent オプションをつけます。
myisamchk -e tbl_name
これは全てのデータを完璧に徹底的にチェックします。 (-e は ``extended check'' の意)。 全てのキーについて、それらがさす行が正しいかを確認するために、 読み込みチェックを行います。 これはたくさんのキーがある大きなテーブルでは、凄く時間がかかります。 myisamchk は通常、最初のエラーが見つかった時点で止まります。 もしより情報が得たいなら、--verbose (-v) オプションを加えます。 これは myisamchk をエラーが20個出るまで動作させ続けます。 普通に使用する場合は、myisamchk だけで十分です。(テーブル名以外の引数は一切無し)
myisamchk -e -i tbl_name
前のコマンドと似ていますが、 -i オプションは myisamchk にいくらかの 統計情報を出させるようにします。

13.6.2 テーブルの修復方法

テーブル破壊の兆しとして、クエリが予期せず中断したり、以下のようなエラーが出たりします:

これらの場合、あなたは自分のテーブルを修理しなければなりません。 myisamchk はほとんどの問題を見つけ出し修正します。

修復過程は以下で記述する最大4つの段階を踏みます。 これを始める前に、あなたはデータベースディレクトリに cd して テーブルファイルのパーミッションを確認すべきです。 これらファイルは mysqld を実行しているUnixユーザーが読み込み可能 であるようにしてください(検査のするのにあなたにファイルのアクセス権も必要)。 もしファイルの変更をする必要があるならば、ファイルへの書き込み許可も必要です。

Stage 1: テーブルをチェックする

myisamchk *.MYI (時間がかかってもよいなら myisamchk -e *.MYI) を実行します。 -s (silent) オプションは不要な情報の出力をおさえます。

myisamchk がエラーを返した場合にだけ、テーブルを修復する必要があります。 この場合、Stage 2 へ進みます。

チェック時に奇妙なエラー(out of memory エラーのような) が起きた場合、 あるいは myisamchk が落ちた場合、Stage 3 に進んでください。

Stage 2: 簡単で安全な修復

まず最初に myisamchk -r -q tbl_name を試みてください (-r -q は ``quick recovery mode''の意)。 これはデータファイルに触れないでインデックスファイルの修理を試みます。 もしデータファイルが全てとデータファイル中の正しい場所での削除リンクポイントを 含んでいるなら、これは動作してテーブルを修復します。 成功後、次のテーブルの修復に進んでください。 失敗した場合は、以下の手順で試みてください:

  1. 続ける前にデータファイルをバックアップしてください。
  2. myisamchk -r tbl_name を使用します(-r は ``recovery mode''の意)。 これは不正なレコードと削除されたレコードをデータファイルから消去し、 インデックスファイル(.MYI)を再構築します。
  3. 上記が失敗した場合、myisamchk --safe-recover tbl_name を使用して下さい。 Safe recovery モードは古い方法を使用して修復します。 これは普通の修復モードでは行わない操作をいくつかもっています。(遅いですが)

チェックまたは修復時に、メモリ不足のような妙なエラーがでた場合、または myisamchk がクラッシュした場合は、Stage 3 に進んでください。

Stage 3: 難しい修復

インデックスファイル(.MYI)の最初の 16K ブロックが破壊された場合、 または不正な情報を含む場合、またはインデックスファイルがない場合にだけ、 本修復段階を経ます。 この場合、新しいインデックスファイルファイルを作成する必要があります。 次のようにしてください:

  1. データファイル .MYD ファイルをどこか安全場所に移動します。
  2. 新しい空のデータとインデックスファイルを作るために、 テーブルディスクリプタファイルを使用します:
    shell> mysql db_name
    mysql> DELETE FROM tbl_name;
    mysql> quit
    
  3. 古いデータファイルを新しく作ったデータファイルにコピーします。 (古いデータファイルを move してはいけません;なんら頭の問題が起きます)

Stage 2 に戻ってください。 myisamchk -r -q は既に動作します。 (これは無限ループにはなりません).

Stage 4: とても難しい修復

これは、ディスクリプタファイル(.frm)もクラッシュした場合にだけ発生します。 これは発生することはありません。なぜならディスクリプタファイルは テーブルが生成された後に書かれることはないからです。

  1. ディスクリプタファイルをバックアップからリストアして、Stage 3 に戻ってください。 インデックスファイルのリストアもできます。そして Stage 2 に戻ってください。 後者の場合、myisamchk -r で開始すべきです。
  2. バックアップを持っていなくても、テーブルがどのように作成されたかを正確に知って いれば、他のデータベース内にテーブルのコピーを生成します。 新しいデータファイルを削除し、先ほど作ったデータベースの中の ディスクリプタファイルとインデックスファイルを、壊れたデータベース内に 移動します。これは新しいディスクリプタファイルとインデックスファイルを 与えることになりますが、データファイルはそのまま残っています。 Stage 2 に進み、インデックスファイルの修復を行ってください。

13.6.3 テーブルの最適化

断片化されたレコードの結合と、 レコードの削除と更新から生じる無駄なスペースの排除、 これら行うには、修復モード(recovery mode)で myisamchk を実行します:

shell> myisamchk -r tbl_name

SQL OPTIMIZE TABLE でも同様にテーブルを最適化できます。 OPTIMIZE TABLE は簡単ですが、 myisamchk の方が速いです。

myisamchk には、あなたがテーブルの性能を向上させるのに使用することができる 他の多くのオプションがあります:

-S, --sort-index
インデックスツリーブロックのソート。降順にソートします。 これはシーク(seek)を最適化し、キーを使用したテーブルの走査(scan)を速くします。
-R index_num, --sort-records=index_num
インデックスによるソート。これはあなたのデータをより良く配置し、 このインデックスを使用した SELECT , ORDER BY 操作を速くします。 (最初にこれを実行してソートするときは時間がとてもかかります!) テーブルのインデックス番号を見つけるために、 SHOW INDEX を使用します。 これは myisamchk が行うのと同様の順でテーブルのインデックスを表示します。 インデックス番号は 1 から開始されます。
-a, --analyze
テーブル内のキー配置の分析。 このテーブルからレコードを取得する際に、 結合(join)のパフォーマンスを向上させます。

For a full description of the option see 「13.2 myisamchk 起動構文」節.

13.7 Log file maintenance

MySQL をログファイルとともに使用する場合、 あなたは、時々古いログファイルを リムーブ/バックアップ し、 MySQL に新しいファイルにログを取るように指示したいと思うことでしょう。 「9.2 更新ログ」節参照.

Redhat Linux においては、mysql-log-rotate スクリプトを これに使用できます。 もし RPM ディストリビューションの MySQL を インストールしたなら、このスクリプトは自動でインストールされているはずです。

他のシステムでは、自分自身で短いスクリプトをインストールします。 cron でログファイルを扱うようにします。

mysqladmin flush-logs コマンドか FLUSH LOGS SQL文で、 MySQL に新しいログファイルを使用させることが出来ます。 もしあなたが MySQL 3.21 を使用しているなら、 mysqladmin refresh を使用しなくてはなりません。

上記のコマンドは、以下のように動作します:

もし更新ログだけを使用しているなら、あなたは、ログを flush するだけでよくて、 その時、バックアップのため古い更新ログファイルを移動します。 もし普通のログを使っていれば、あなたは以下のようにすることができます:

shell> cd mysql-data-directory
shell> mv mysql.log mysql.old
shell> mysqladmin flush-tables

こうしておいて、`mysql.old' をバックアップし削除します。.


Go to the first, previous, next, last section, table of contents.