2003-04-17

* mysql: バイナリログとレプリケーション
会社で、昨日、レプリケーションの挙動について調べたような気がする。
- レプリケーションは、マスター側DBのバイナリログにそって、
スレーヴ側DBが反映される。
- 従って、マスター側DBの古くなったバイナリログを、
不要だからと考えて圧縮したり移動したり削除したりすると、
もし、まだスレーヴで反映されていない部分のバイナリログが
あった場合に、スレーヴ側でエラーが発生する。
- マスター側DBで
RESET MASTER;
というSQLを実行すると、溜まっていたバイナリログが全て消されて、
実行した段階から、バイナリログをまた蓄積し直していく。
これは要するに、RESET MASTER直前のマスター側DBを手動で、
スレーヴ側に反映させておくべき必要がある仕組みの様子。
- スレーヴ側DBで直接UPDATE文等、変更を行うSQLは、実行可能。
これは、互いにスレーヴしあうような構造を可能にする為に、
変更可能になっている様子（変更の禁止は、mysql内アカウントの
変更権限設定ででもやっとけ、という方針の様子）。
今のmysqlが、互いにスレーヴしあう構造を完全にサポートしているかどうかは、
過去に調べた時は怪しげだったような記憶があるが、
今は完全にサポートしているかもしれない（未調査）。
- 例えば、スレーヴ側でDROP TABLE等をしてから、マスター側で
INSERT等を実行すると、当然エラーになる。エラーは、エラーログに
記録され、そして、そのまま、レプリケーションはそこで中断されてしまう。
これは、かなり致命的なような気がしないでもない。
大規模なシステムでは、万が一のDB間不整合が起こらないとは限らないので、
レプリケーション時には、レプリケーション状態の監視を行った方が
良いような気がする。
レプリケーション状態の取得は、次のSQL文を実行し、
SHOW SLAVE STATUS;
Slave_Runningのカラムを見れば分かる。
- 現段階では、レプリケーションでは、
mysql内乱数取得関数、
mysql内変数、
は、サポートされてない、らしい。使うと不整合の元。
テンポラリテーブルはサポートされてた気がする。
- 後は忘れた