MySQL Clusterを試す！第1回

行ベースレプリケーション

　MySQLにはマスター／スレーブ型のレプリケーション機能があります。MySQLでサポートしているのは非同期型のレプリケーションで、マスターサーバーで実行されたSQLステートメントをスレーブサーバーへ転送し、スレーブで再実行することでデータを一貫に保つという手法を用いています。

　これはステートメントベースレプリケーション（SBR）と呼ばれています。SBRではその仕組み上、根本的な問題があります。例えばUUID()という関数がありますが、マスターとスレーブでUUID()を実行するとそれぞれ違う結果になってしまいます。

　その結果、マスターとスレーブにはデータの不整合が生じてしまいます。この問題を解決するには、スレーブへ伝達する情報をステートメントではなく、実際にテーブルへ書き込まれた内容、つまり行そのものにする必要があります。それを実装したのが行ベースレプリケーション（RBR：Row Based Replication）です。

　MySQL 5.1では、UUID()のようにレプリケーションができない記述をステートメントが含む時だけ、自動的にSBRからRBRへ切り替えるMIXEDモードがデフォルトになっています。

　これは性能と正確さのバランスをとった結果です。RBRは変更を正確に伝達できる変わり、マスターからスレーブへのデータの転送量が増えてしまいます。SBRの場合、一度に100行を更新するUPDATEステートメントが実行された場合でも、転送するデータは1つのステートメントだけ済みますが、それに対してRBRの場合は100行分のデータを転送しなければなりません。これは大きな違いです。従って、よほどのことがない限りMIXEDモードから変更することはないでしょう。

　レプリケーションのフォーマットを変更するには--binlog-format=オプションを使用します。typeに指定できる値は、STATEMENT、MIXED、ROWの3種類です。明示的に切り替える場合には、このオプションを使って変更するといいでしょう。

　MySQL 5.1では性能を犠牲にすることなく安定性が向上するため、より使いやすいものとなるでしょう。まだレプリケーションを使われたことがないという方がいらっしゃれば、ぜひこの機会にMIXEDモードが使えるMySQL 5.1をお試しください。

ログテーブル

　MySQL 5.0までは、ログはすべてファイルへ書き込む仕様でしたが、MySQl 5.1では一般クエリログとスロークエリログをテーブルへ書き込むことができるようになりました。テーブルへの書き込みはファイルへ書き込むよりも処理が重いのですが、SQLを使ってログの検査ができるという利点があります。ログの出力先となるテーブル名はそれぞれmysql.general_logとmysql.slow_logで、ストレージエンジンにはCSVを利用しています。テーブル定義はDESCコマンドで調べてみてください。

　これらのテーブルに対して、SELECTステートメントを実行することで内容を参照することができます。WHERE句でユーザーや日時を限定することで、ファイルをテキストエディターなどで閲覧する場合と比べて効率的に調査することが可能です。

　MySQL 5.1では一般クエリログとスロークエリログのON/OFFを動的に切り替えられるようになっています。また、出力先をファイルとテーブルのどちらにするかも動的に変更可能です。スロークエリログをテーブルへ一時的に出力するには以下のステートメントを実行します。

mysql> SET GLOBAL log_output=FILE;
mysql> SET GLOBAL slow_log=ON;

　一般クエリログはアプリケーションのデバッグには非常に役立ちますが、非常に肥大化しますし、ログの書き込みにかかるオーバーヘッドも無視できません。そのため、アプリケーションのデバッグをする時以外にはあまり使う機会はないでしょう。スロークエリログは時間がかかったクエリやインデックスを使用しなかったクエリを記録します。クエリが順調に実行されている間は一切負荷はありませんので、常にONにしておくことをおすすめします。