どうやらMySQLの起動時かクラインアントからの新規接続をトリガーにしている模様。
-----------------------------------------------------------------------------
アプリケーションログ
ソース:MySQL イベントID:100
Changed limits: max_open_files: 2048 max_connections: 800
table_cache: 619
For more information, see Help and Support Center at http://www.mysql.com.
-----------------------------------------------------------------------------
早速調査開始。
どうやらWindows版のMySQLはmax_open_fileの既定値が2048で固定されていて、
しかも変更が出来ないらしい。max_open_fileは以下の計算式で求める事が出来る。
(max_connectionsとtable_chacheはmy.iniで設定可能)
max_open_file = (10 + max_connections + table_cache) * 2
計算した所、確かに2048を上回っている。
でもtable_cacheの値がなんか変？ログの619という端数はどこから？
再び調査開始。
どうやらmax_open_fileの既定値を超えた場合、table_cacheの値が再計算されるよう。
再計算した結果、619という値になったとの事。table_cacheは以下の計算式で求める。
table_cache = (max_open_file - 10 - max_connections) * 2
計算したら確かに619になりました。
つまり、ログの警告の文の意味は以下になる。
「max_open_fileを計算したら既定値の2048を上回ってました。なのでtable_cacheの
値を再計算して、その結果をtable_cacheとして再設定します」
my.iniで設定した値ではなく、実際のtable_cacheは619で動いていた訳ね。納得。
どうせ再設定されるなら初めから設定してしてしまおうとmy.iniを編集して再起動。
で、当然イベントログにも警告文も出なくなりました。
今回のシステムは書き込みはほぼなしなのでI/Oパフォーマンスは気にしなくてよい。
なのでtable_chacheの値はそれほど重要じゃないって事で一件落着。
以上。
0
1それぞれの説明は以下。
①. エラーログ
②. 一般クエリログ
③. バイナリログ
④. スロークエリログ
①. エラーログについて
エラーログファイルでは、mysqld の起動時刻と停止時刻、
および実行中に発生したエラーに関する情報を記録しています。
②. 一般クエリログについて
サーバはこのログに、クライアント接続や切断の情報を書き込み、
そのときのクライアントからの SQL ステートメントも記録します。
③. バイナリログについて
バイナリ ログの内容には更新データのステートメント、
レコードに一致しない場合の DELETE などで更新済みのステートメントがあります。
④. スロークエリログについて
スロー クエリ ログの内容は、long_query_time 秒より
実行に時間がかかる SQL ステートメントすべてが入ります。
(要するに時間のかかるクエリ)
通常使うのは①だけで、差分バックアップやレプリケーションを行っている場合は③も。
②と④についてはデバッグ時や性能の最適化を行うときだけ使用する感じ。
設定方法下記見れば分かります。
My SQL5.1 リファレンスマニュアル
今更感が拭えない記事ですがとりあえず覚え書き。
今回はmysqldumpを使ってバックアップリストアについて。
ちなみにバイナリログは取得しないので差分は取りません。
mysqldumpはDB構造からデータまで全てをSQL文でダンプしてくれます。
なのでリストアはそれを読むだけでOK。
お手軽なうえ簡単なのでよく使われているバックアップ方式だと思います。
早速mysqldumpしてみます。よく使われるオプション付です。
mysqldump -u root -pパスワード 対象DB --opt -F > ダンプ出力先
以上。
なんてお手軽なのでしょうか。(ちなみに-pとパスワードの間はスペースなし)
オプションの説明は以下。
--opt
--quick --add-drop-table --add-locks --extended-insert --lock-tables と同じ。
-F, --flush-logs
ダンプする前に、MySQL のログファイルをフラッシュします。
--add-locks
テーブルのダンプの前に LOCK TABLES 文を追加し、テーブルのダンプ後に
UNLOCK TABLE 文を追加( リストア時に速くなる)。
--add-drop-table
テーブル作成の前にテーブルを削除する
-e, --extended-insert
新しいマルチライン INSERT 構文を使用します。
(これはあとで挿入する際、よりコンパクトかつ速くなります。)
-l, --lock-tables
ダンプを開始する前に全てのテーブルをロックする。.
-q, --quick
クエリをバッファにためない。
簡単に説明するとダンプ時の読み込みを出来るだけ早くしてます。
後は-Fでフラッシュされたログファイルをバックアップ先へコピーして終了。
これらをタスクスケジューラで回すだけでも充分バックアップが取れます。
では次にリストアしてみましょう。
mysql -u root -ppassword 対象DB < ダンプファイル
以上。
なんてお手軽なのでしょうか。
(対象DBを指定しているので分かると思いますがDB自体は先に作成しておく必要あり)
但し、差分バックアップではないので障害時に復旧できるのはバックアップ取得時点まで。
差分バックアップについてはまたの機会に。
InnoDBでテーブル作ると二つのファイルが出来る。
table名.frmってやつとテーブルスペースのファイル(デフォルトではibdata1という名前)
まずこれらが何を意味すかと言うと、
table名.frm テーブル構造のデータ
ibdata1 レコードデータやインデックスデータ
つまり、table名.frmはカラム構造などを、実際のデータはibdata1にある訳ですね。
ではこれらの格納位置を変更するにはどうするか？
設定はmy.iniで簡単に出来ます。
以下二つのパラメータを変更
(両方ともSERVER SECTION配下にある)
datadir="格納パス"
innodb_data_home_dir="格納パス"
ちなみに上のがtable名.frmファイルで下のがデータファイルのパラメータ。
編集後、一旦MySQLをシャットダウン。
でこの後、必ず今まで使用していた格納場所からデータのコピーをする事。
特にsystem系のDBをコピーし忘れるとMySQLが立ち上がりません。
既存のデータがある場所は、ibdataはコンフィグレーションウィザードで指定したInnoDBの格納場所で、frmファイルはMySQLのインストールフォルダのdata配下に存在している。
これらを全て新ディレクトリにコピーし終えたらMySQLを立ち上げる。
以上で格納位置の変更が可能。
