myisamchk 使用
Starting with MySQL 3.23.13, you can check tables MyISAM with the
CHECK TABLE command. 「7.11 CHECK TABLE 構文」節参照. You can repair tables
with the REPAIR TABLE command. 「7.12 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.10 OPTIMIZE 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
myisamchk は以下のオプションを持ちます:
-a, --analyze
-#, --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 テーブルハンドラーに最初の # インデックスだけを更新するように指示します。
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, --no-symlinks
myisamchk はシンボリックリンクが指し示すテーブルも修復します。
-q, --quick
-r と共に使用され、修復を早く行います。
通常、オリジナルのデータファイルは検査されません；
二回 -q を指定すると、強制的にオリジナルのデータファイルも使用します。
-r, --recover
-r, you
should then try -o. (Note that in the unlikely case that -r
fails, the data file is still intact).
-o, --safe-recover
-r よりも遅いですが、 -r が扱えないものも扱えます。
Normally one should always first repair with
-r and only if this fails use -o.
-O var=option, --set-variable var=option
-s, --silent
-s を指定すると(-ss)、myisamchk は
ほとんど出力をしなくなります。
-S, --sort-index
-R index_num, --sort-records=index_num
SELECT, ORDER BY オペレーションを速くします。
(この操作の最初のソートは非常に遅くなるかもしれません！)
テーブルのインデックスの番号をみつけるには SHOW INDEX を使用しますが、
これは myisamchk がテーブルのインデックスを見つけるのと同じ順序で行います。
インデックス番号は 1 から始まります。
-u, --unpack
pack_isam でパックされたテーブルをアンパックします。
-U, --update-status
--fast
option, but you shouldn't use this if option if the mysqld server is
using the table and you are running mysqld with
--skip-locking.
-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
key_buffer_size is only used when you check the table with -e or
repair it with -o.
sort_buffer_size is used when you repair the table with -r.
If you want a faster repair, set the above variables to about 1/4 of your available memory. You can set both variables to big values as only one of the above buffers will be used at at time.
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
問題が発生するまで待つより、定期的にテーブルを検査する方がよりよい考えです。
保守目的には、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 を
信頼することになります。
テーブルから詳細/統計を得るためには、次の方法を使用します。後でさらに詳細な情 報をいくつか説明します。
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-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 でテーブルを再配置できます。
「15.6.3 テーブルの最適化」節参照.
Recordblocks
Deleteblocks
Recorddata
Deleted data
Lost space
Linkdata
Linkdataは
そのポインタの全ての合計です。
テーブルが pack_isam で圧縮されているなら、myisamchk -d は
それぞれのテーブルコラムに関する追加情報を出力します。
「14.7 MySQL の圧縮された読み込み専用テーブルジェネレータ ( myisampack ・ pack_isam )」節. を参照してください。
この情報例と説明記述の意味があります。
myisamchk for crash recoveryMySQL がデータ格納に使用するファイル形式は、 広範囲にわたってテストされました。が、データベースのテーブルが 破壊されるかもしれない外的状況があります:
mysqld プロセスが書き込み再中に killed された場合
本節では、MySQL のデータの扱い方、検査の方法を述べます。 もしテーブルがたくさんダメになるのであれば、 あなたは、この理由を見つけるよう試みるべきです! 「H.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 を走らせる前にバックアップを
少なくともとるべきです。
テーブルをチェックするには,以下のコマンドを使用してください:
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 にいくらかの
統計情報を出させるようにします。
テーブル破壊の兆しとして、クエリが予期せず中断したり、以下のようなエラーが出たりします：
これらの場合、あなたは自分のテーブルを修理しなければなりません。
myisamchk はほとんどの問題を見つけ出し修正します。
修復過程は以下で記述する最大4つの段階を踏みます。
これを始める前に、あなたはデータベースディレクトリに cd して
テーブルファイルのパーミッションを確認すべきです。
これらファイルは mysqld を実行しているUnixユーザーが読み込み可能
であるようにしてください(検査のするのにあなたにファイルのアクセス権も必要)。
もしファイルの変更をする必要があるならば、ファイルへの書き込み許可も必要です。
If you are using MySQL 3.23.16 and above you can (and should) use the
CHECK and REPAIR commands to check and repair MyISAM
tables. 「7.11 CHECK TABLE 構文」節参照. 「7.12 REPAIR TABLE 構文」節参照.
The manual section about table maintenence includes the options to
isamchk/myisamchk. 「15.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> DELETE FROM tbl_name; mysql> quit
Stage 2 に戻ってください。 myisamchk -r -q は既に動作します。
(これは無限ループにはなりません).
Stage 4: とても難しい修復
これは、ディスクリプタファイル(.frm)もクラッシュした場合にだけ発生します。 これは発生することはありません。なぜならディスクリプタファイルは テーブルが生成された後に書かれることはないからです。
myisamchk -r で開始すべきです。
断片化されたレコードの結合と、
レコードの削除と更新から生じる無駄なスペースの排除、
これら行うには、修復モード(recovery mode)で myisamchk を実行します：
shell> myisamchk -r tbl_name
SQL OPTIMIZE TABLE でも同様にテーブルを最適化できます。
OPTIMIZE TABLE は簡単ですが、 myisamchk の方が速いです。
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 see 「15.2 myisamchk 起動構文」節.
MySQL をログファイルとともに使用する場合、 あなたは、時々古いログファイルを リムーブ/バックアップ し、 MySQL に新しいファイルにログを取るように指示したいと思うことでしょう。 「21.3 更新ログ」節参照.
Redhat Linux においては、mysql-log-rotate スクリプトを
これに使用できます。 もし RPM ディストリビューションの MySQL を
インストールしたなら、このスクリプトは自動でインストールされているはずです。
他のシステムでは、自分自身で短いスクリプトをインストールします。
cron でログファイルを扱うようにします。
mysqladmin flush-logs コマンドか FLUSH LOGS SQL文で、
MySQL に新しいログファイルを使用させることが出来ます。
もしあなたが MySQL 3.21 を使用しているなら、
mysqladmin refresh を使用しなくてはなりません。
上記のコマンドは、以下のように動作します：
--log) が使用されているならば、このログファイルを
一度閉じてから再び開きます。
(`mysql.log' がデフォルトのログファイル).
--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.