This chapter covers what you should know about maintaining a MySQL distribution. You will learn how to care for your tables on a regular basis, and what to do when disaster strikes.
myisamchk 使用
Starting with MySQL Version 3.23.13, you can check MyISAM tables with the
CHECK TABLE command. 「7.12 CHECK TABLE 構文」節参照. You can repair tables
with the REPAIR TABLE command. 「7.16 REPAIR TABLE 構文」節参照.
MyISAM テーブル (.MYI and .MYD) の検査・修復には myisamchk を
使用します。
ISAM テーブル (.ISM and .ISD) の検査・修復には isamchk を
使用します。
「8 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.11 OPTIMIZE TABLE構文」節参照.
Even that the repair in myisamchk is quite secure, it's always a
good idea to make a backup BEFORE doing a repair (or anything that could
make a lot of changes to a table)
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
The recommended way to quickly check all tables is:
myisamchk --silent --fast /path/to/datadir/*/*.MYI isamchk --silent /path/to/datadir/*/*.ISM
If you want to check all tables and repair all tables that are corrupted, you can use the following line:
myisamchk --silent --force --fast --update-state -O key_buffer=64M -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.MYI isamchk --silent --force -O key_buffer=64M -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.ISM
The above assumes that you have more than 64 M free.
Note that if you get an error like:
myisamchk: warning: 1 clients is using or hasn't closed the table properly
This means that you are trying to check a table that has been updated by the another program (like the mysqld server) that hasn't yet closed the file or that has died without closing the file properly.
If you mysqld is running, you must force a sync/close of all
tables with FLUSH TABLES and ensure that no one is using the
tables while you are running myisamchk. In MySQL Version 3.23
the easiest way to avoid this problem is to use CHECK TABLE
instead of myisamchk to check tables.
myisamchk supports the following options.
-# か --debug=debug_options
debug_options はよく 'd:t:o,filename' とされます。
-? か --help
-O var=option か --set-variable var=option
myisamchk --help で確認できます:
| key_buffer_size | 523264 |
| read_buffer_size | 262136 |
| write_buffer_size | 262136 |
| sort_buffer_size | 2097144 |
| sort_key_blocks | 16 |
| decode_bits | 9 |
sort_buffer_size is used when the keys are repaired by sorting
keys, which is the normal case when you use --recover.
key_buffer_size is used when you are checking the table with
--extended-check or when the keys are repaired by inserting key
row by row in to the table (like when doing normal inserts). Repairing
through the key buffer is used in the following cases:
--safe-recover.
FULLTEXT index.
CHAR, VARCHAR or TEXT keys as the
sort needs to store the whole keys during sorting. If you have lots
of temporary space and you can force myisamchk to repair by sorting
you can use the --sort-recover option.
-s か --silent
-s を指定すると(-ss)、myisamchk は
ほとんど出力をしなくなります。
-v か --verbose
-d と -e オプションと共に使用できます。
-v を複数指定すると(-vv, -vvv)、もっと出力が多くなります！
-V か --version
myisamchk バージョンを表示して終了。
-w か --wait
mysqld
on the table with --skip-locking, the table is can only be locked
by another myisamchk command.
-c or --check
myisamchk にオプションを
与えていない時のデフォルトです。
他の全てのオプションをこのオプションを上書きします。
-e, --extend-check
myisamchk や myisamchk --medium-check は、
このオプションなしで全てのエラーを見つけるはずです。
多くのメモリがマシンにあるなら、--extended-check を使用する際には
key_buffer_size の値を多く増やします。
-F or --fast
-C or --check-only-changed
-f, --force
myisamchk を -r なしで走らせてテーブルを検査しているときに、
-f を使用するならば、
myisamchk はチャックでエラーが出たテーブルに対して、
自動的に -r を伴って、検査を再開します。
-i, --information
-m or --medium-check
-U or --update-status
--check-only-changed option, but you shouldn't use this
option, but you shouldn't use this if option if the mysqld server is
using the table and you are running mysqld with
use locking (like mysqld --skip-locking).
--skip-locking.
-T or --read-only
myisamchk
to check a table that is in use by some other application that doesn't
use locking (like mysqld --skip-locking)
以下のオプションは myisamchk を -r か -o オプションで
実行した場合に使用できます:
-D # or --data-file-length=#
-e or --extend-check
-f or --force
table_name.TMD) instead of aborting.
-k #, --keys-used=#
-r と共に使用します。
NISAM テーブルハンドラーに最初の # インデックスだけを更新するように指示します。
If you are using MyISAM tells which keys to use, where each
binary bit stands for one key (First key is bit 0).
これはインサートを速くします！
非アクティブになったインデックスは、myisamchk -r を使用すれば再びアクティブになります。
-l or --no-symlinks
myisamchk はシンボリックリンクが指し示すテーブルも修復します。
-r or --recover
-r, you
should then try -o. (Note that in the unlikely case that -r
fails, the data file is still intact.)
If you have lots of memory, you should increase the size of
sort_buffer_size!
-o or --safe-recover
-r よりも遅いですが、 -r が扱えないものも扱えます。
Normally one should always first repair with
-r, and only if this fails use -o.
If you have lots of memory, you should increase the size of
key_buffer_size!
-n or --sort-recover
myisamchk to use sorting to resolve the keys even if the
temporary files should be very big. This will not have any effect if you have
fulltext keys in the table.
--character-sets-dir=...
--set-character-set=name
-t or --tmpdir=path
myisamchk は
TMPDIR 環境変数の値をこのパスとします。
-q or --quick
-q to force myisamchk to modify the original datafile in case
of duplicate keys
-u or --unpack
myisampack でパックされたテーブルファイルをアンパックします。
Other actions that myisamchk can do, besides repair and check tables:
-a, --analyze
myisamchk --describe --verbose table_name' or using SHOW KEYS in
MySQL.
-d, --description
-A or --set-auto-increment[=value]
-S or --sort-index
-R or --sort-records=#
SELECT, ORDER BY オペレーションを速くします。
(この操作の最初のソートは非常に遅くなるかもしれません！)
テーブルのインデックスの番号をみつけるには SHOW INDEX を使用しますが、
これは myisamchk がテーブルのインデックスを見つけるのと同じ順序で行います。
インデックス番号は 1 から始まります。
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 の使用は多くの場合おそらく十分でしょう。
しかし、myisamchk は TMPDIR 内に一時ファイルを使用します。
TMPDIR がメモリファイルシステムを指している場合は、簡単に out of
memory エラーを得るでしょう。
If this happens, set TMPDIR to point at some directory
with more space and restart myisamchk.
When repairing, myisamchk will also need a lot of disk space:
--quick, as in this
case only the index file will be re-created. This space is needed on the
same disk as the original record file!
--recover or --sort-recover
(but not when using --safe-recover, you will need space for a
sort buffer for:
(largest_key + row_pointer_length)*number_of_rows * 2.
You can check the length of the keys and the row_pointer_length with
myisamchk -dv table.
This space is allocated on the temporary disk (specified by TMPDIR or
--tmpdir=#).
If you have a problem with disk space during repair, you can try to use
--safe-recover instead of --recover.
Starting with MySQL Version 3.23.13, you can check MyISAM
tables with the CHECK TABLE command. 「7.12 CHECK TABLE 構文」節参照. You can
repair tables with the REPAIR TABLE command. 「7.16 REPAIR TABLE 構文」節参照.
問題が発生するまで待つより、定期的にテーブルを検査する方がよりよい考えです。
保守目的には、myisamchk -s でテーブルを検査するのがよいでしょう。
-s オプション(short for --silent) はサイレントモードなので、
エラーが起きた場合にだけメッセージを出力します。
サーバーを開始するときにテーブルを検査するのもよい考えです。
例えば、更新最中にマシンがリブートされたなら、全てのテーブルに関して
その影響がないか検査する必要があります。（これは``expected crashed table''です）
リブート後にもし古い `.pid' ファイル(プロセスID) があるならば、
24時間以内に変更されたテーブルに対して myisamchk を走らせて検査させるように、
safe_mysqld にテストを追加しても構いません。
(`.pid' ファイルは mysqld 起動時に作られ、通常修了時に消されます。
スタート時に `.pid' ファイルが存在するなら mysqld が異常終了したことを示します。)
良いテストは、`.pid' ファイルの作成時間以降に変更された 全てのテーブルを検査するテストです。
通常のシステム運用中にもテーブルを検査すべきです。
MySQL AB では、週に一度、 cron を使用して重要なテーブルを検査しています。
`crontab' ファイルには以下のように記述します：
35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI
これは壊れたテーブルの情報を出力しますので、必要とあらば検査、修復が行えるわけです。
予想外の事故で壊れたテーブル(ハードウェアのトラブルが原因で崩壊)を除き、 2,3年間、テーブルは壊れたことはありません(これは本当に本当です)。 ので、一週間に一度のチェックでも十分です。
24時間以内に変更された全てのテーブルに対して、
myisamchk -s を毎晩実行する事を勧めます。
そうすれば、あなたは我々と同じぐらいに MySQL を
信頼することになります。
Normally you don't need to maintain MySQL tables that much. If
you are changing tables with dynamic size rows (tables with VARCHAR,
BLOB or TEXT columns) or have tables with many deleted rows
you may want to from time to time (once a month?) defragment/reclaim space
from the tables.
You can do this by using OPTIMIZE TABLE on the tables in question or
if you can take the mysqld server down for a while do:
isamchk -r --silent --sort-index -O sort_buffer_size=16M */*.ISM myisamchk -r --silent --sort-index -O sort_buffer_size=16M */*.MYI
テーブルから詳細/統計を得るためには、次の方法を使用します。後でさらに詳細な情 報をいくつか説明します。
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 と似ているが、何を行っているかを表示します。
MyISAM file: company.MYI
Record format: Fixed length
Data records: 1403698 Deleted blocks: 0
Recordlength: 226
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-version
Creation time
Recover time
Data records
Deleted blocks
Datafile: Parts
Data records と同じです。
Deleted data
Datafile pointer
Keyfile pointer
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
packed, stripped か empty オプションを持ちます。
Root
Blocksize
Rec/key
myisamchk -a で更新されます。これ
が全く更新されない場合はデフォルト値の 30 が与えられます。
Keyblocks used
myisamchk で再配置
されるため、値はとても高くなります (理論的な最大にとても近くなります)。
Packed
CHAR/VARCHAR/DECIMAL キーでだけ使用できます。名前の
ような長い文字列では、これは使用領域を顕著に減らします。上の三番目の例では4番目
のキーが10文字長で、領域の60%の減少を得ます。
Max levels
Records
M.recordlength
Packed
Packed は示します。
Recordspace used
Empty space
Blocks/Record
myisamchk でテーブルを再配置できます。
「16.4.3 テーブルの最適化」節参照.
Recordblocks
Deleteblocks
Recorddata
Deleted data
Lost space
Linkdata
Linkdataは
そのポインタの全ての合計です。
テーブルが pack_isam で圧縮されているなら、myisamchk -d は
それぞれのテーブルコラムに関する追加情報を出力します。
「15.12 MySQL の圧縮された読み込み専用テーブルジェネレータ ( myisampack ・ pack_isam )」節. を参照してください。
この情報例と説明記述の意味があります。
myisamchk 使用MySQL がデータ格納に使用するファイル形式は、 広範囲にわたってテストされました。が、データベースのテーブルが 破壊されるかもしれない外的状況があります:
mysqld プロセスが書き込み再中に killed された場合
本節では、MySQL のデータの扱い方、検査の方法を述べます。 もしテーブルがたくさんダメになるのであれば、 あなたは、この理由を見つけるよう試みるべきです! 「I.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 を走らせる前にバックアップを
少なくともとるべきです。
MyISAM テーブルをチェックするには,以下のコマンドを使用してください:
myisamchk tbl_name
myisamchk を走らすか、-s or --silent オプションをつけます。
myisamchk -m tbl_name
myisamchk -e tbl_name
-e は ``extended check'' の意)。
全てのキーについて、それらがさす行が正しいかを確認するために、
読み込みチェックを行います。
これはたくさんのキーがある大きなテーブルでは、凄く時間がかかります。
myisamchk は通常、最初のエラーが見つかった時点で止まります。
もしより情報が得たいなら、--verbose (-v) オプションを加えます。
これは myisamchk をエラーが20個出るまで動作させ続けます。
普通に使用する場合は、myisamchk だけで十分です。(テーブル名以外の引数は一切無し)
myisamchk -e -i tbl_name
-i オプションは myisamchk にいくらかの
統計情報を出させるようにします。
In the following section we only talk about using myisamchk on
MyISAM tables (extensions .MYI and .MYD). If you
are using ISAM tables (extensions .ISM and .ISD),
you should use isamchk instead.
Starting with MySQL Version 3.23.14, you can repair MyISAM
tables with the REPAIR TABLE command. 「7.16 REPAIR TABLE 構文」節参照.
テーブル破壊の兆しとして、クエリが予期せず中断したり、以下のようなエラーが出たりします：
perror ###. Here
is the most common errors that indicates a problem with the table:
shell> perror 126 127 132 134 135 136 141 144 145 126 = Index file is crashed / Wrong file format 127 = Record-file is crashed 132 = Old database file 134 = Record was already deleted (or record file crashed) 135 = No more room in record file 136 = No more room in index file 141 = Duplicate unique key or constraint on write or update 144 = Table is crashed and last repair failed 145 = Table was marked as crashed and should be repairedNote that error 135, no more room in record file, is not an error that can be fixed by a simple repair. In this case you have to do:
ALTER TABLE table MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;
この他の場合、あなたは自分のテーブルを修理しなければなりません。
myisamchk はほとんどの問題を見つけ出し修正します。
修復過程は以下で記述する最大4つの段階を踏みます。
これを始める前に、あなたはデータベースディレクトリに cd して
テーブルファイルのパーミッションを確認すべきです。
これらファイルは mysqld を実行している UNIX ユーザーが読み込み可能
であるようにしてください(検査のするのにあなたにファイルのアクセス権も必要)。
もしファイルの変更をする必要があるならば、ファイルへの書き込み許可も必要です。
If you are using MySQL Version 3.23.16 and above, you can (and
should) use the CHECK and REPAIR commands to check and repair
MyISAM tables. 「7.12 CHECK TABLE 構文」節参照. 「7.16 REPAIR TABLE 構文」節参照.
The manual section about table maintenance includes the options to
isamchk/myisamchk. 「16.1 テーブルのメンテナンス、クラッシュからの修復のための myisamchk 使用」節参照.
The following section is for the cases where the above command fails or
if you want to use the extended features that isamchk/myisamchk provides.
If you are going to repair a table from the command line, you must first
take down the mysqld server. Note that when you do
mysqladmin shutdown on a remote server, the mysqld server
will still be alive for a while after mysqladmin returns, until
all queries are stopped and all keys have been flushed to disk.
Stage 1: テーブルをチェックする
myisamchk *.MYI (時間がかかってもよいなら myisamchk -e *.MYI)
を実行します。
-s (silent) オプションは不要な情報の出力をおさえます。
If the mysqld server is done you should use the --update option to tell
myisamchk to mark the table as 'checked'.
myisamchk がエラーを返した場合にだけ、テーブルを修復する必要があります。
この場合、Stage 2 へ進みます。
チェック時に奇妙なエラー(out of memory エラーのような) が起きた場合、
あるいは myisamchk が落ちた場合、Stage 3 に進んでください。
Stage 2: 簡単で安全な修復
まず最初に myisamchk -r -q tbl_name を試みてください
(-r -q は ``quick recovery mode''の意)。
これはデータファイルに触れないでインデックスファイルの修理を試みます。
もしデータファイルが全てとデータファイル中の正しい場所での削除リンクポイントを
含んでいるなら、これは動作してテーブルを修復します。
成功後、次のテーブルの修復に進んでください。
失敗した場合は、以下の手順で試みてください：
myisamchk -r tbl_name を使用します(-r は ``recovery mode''の意)。
これは不正なレコードと削除されたレコードをデータファイルから消去し、
インデックスファイル(.MYI)を再構築します。
myisamchk --safe-recover tbl_name を使用して下さい。
Safe recovery モードは古い方法を使用して修復します。
これは普通の修復モードでは行わない操作をいくつかもっています。(遅いですが)
チェックまたは修復時に、メモリ不足のような妙なエラーがでた場合、または
myisamchk がクラッシュした場合は、Stage 3 に進んでください。
Stage 3: 難しい修復
インデックスファイル(.MYI)の最初の 16K ブロックが破壊された場合、 または不正な情報を含む場合、またはインデックスファイルがない場合にだけ、 本修復段階を経ます。 この場合、新しいインデックスファイルファイルを作成する必要があります。 次のようにしてください:
shell> mysql db_name mysql> SET AUTOCOMMIT=1; mysql> TRUNCATE TABLE table_name; mysql> quitIf your SQL version doesn't have
TRUNCATE TABLE, use DELETE FROM
table_name instead.
Stage 2 に戻ってください。 myisamchk -r -q は既に動作します。
(これは無限ループにはなりません).
Stage 4: とても難しい修復
これは、ディスクリプタファイル(.frm)もクラッシュした場合にだけ発生します。 これは発生することはありません。なぜならディスクリプタファイルは テーブルが生成された後に書かれることはないからです。
myisamchk -r で開始すべきです。
断片化されたレコードの結合と、
レコードの削除と更新から生じる無駄なスペースの排除、
これら行うには、修復モード(recovery mode)で myisamchk を実行します：
shell> myisamchk -r tbl_name
SQL OPTIMIZE TABLE でも同様にテーブルを最適化できます。
OPTIMIZE TABLE does a repair of the table, a key
analyzes and also sorts the index tree to give faster key lookups.
There is also no possibility of unwanted interaction between a utility
and the server, because the server does all the work when you use
OPTIMIZE TABLE. 「7.11 OPTIMIZE TABLE構文」節参照.
myisamchk には、あなたがテーブルの性能を向上させるのに使用することができる
他の多くのオプションがあります:
-S, --sort-index
-R index_num, --sort-records=index_num
SELECT , ORDER BY 操作を速くします。
(最初にこれを実行してソートするときは時間がとてもかかります！)
テーブルのインデックス番号を見つけるために、 SHOW INDEX を使用します。
これは myisamchk が行うのと同様の順でテーブルのインデックスを表示します。
インデックス番号は 1 から開始されます。
-a, --analyze
For a full description of the option. 「16.1.1 myisamchk 起動構文」節参照.
MySQL has a lot of log files which make it easy to see what is
going. 「23 The MySQL log files」節参照. One must however from time to time clean up
after MysQL to ensure that the logs don't take up too much disk
space.
MySQL をログファイルとともに使用する場合、 あなたは、時々古いログファイルを リムーブ/バックアップ し、 MySQL に新しいファイルにログを取るように指示したいと思うことでしょう。 「22.2 データベースのバックアップ」節参照.
Redhat Linux においては、mysql-log-rotate スクリプトを
これに使用できます。 もし RPM ディストリビューションの MySQL を
インストールしたなら、このスクリプトは自動でインストールされているはずです。
Note that you should be careful with this if you are using
the log for replication!
他のシステムでは、自分自身で短いスクリプトをインストールします。
cron でログファイルを扱うようにします。
mysqladmin flush-logs コマンドか FLUSH LOGS SQL文で、
MySQL に新しいログファイルを使用させることが出来ます。
もしあなたが MySQL Version 3.21 を使用しているなら、
mysqladmin refresh を使用しなくてはなりません。
上記のコマンドは、以下のように動作します：
--log) or slow query logging
(--log-slow-queries) is used, closes and reopens the log file.
(`mysql.log' and ``hostname`-slow.log' as default).
--log-update) を使用しているなら、
更新ログを閉じ、新しいログファイルを開きます。そのさい、
ログファイルについている番号は増えます。
もし更新ログだけを使用しているなら、あなたは、ログを 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.