一つだけマニュアルが誤解を招く表現。
デフォルトでは、サーバーは FLUSH ステートメントをバイナリログに書き込み、それらがレプリケーションスレーブにレプリケートされるようにします。ロギングを抑制するには、オプションの NO_WRITE_TO_BINLOG キーワード、またはそのエイリアス LOCAL を指定します。
注記
FLUSH LOGS、FLUSH TABLES WITH READ LOCK (テーブルリスト付き、またはなし)、および FLUSH TABLES tbl_name ... FOR EXPORT は、スレーブにレプリケートされると問題が発生するため、どのような場合でもバイナリログに書き込まれません。
MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.7.6.3 FLUSH 構文
FLUSH LOGSのうちロギングされないのは「バイナリーログをフラッシュする」時だけで、追加引数なしのFLUSH LOGSとFLUSH BINARY LOGSだけがバイナリーロギングされない。
https://github.com/mysql/mysql-server/blob/mysql-5.6.32/sql/sql_reload.cc#L156-L170
それ以外のFLUSH SLOW LOGSやFLUSH ENGINE LOGS, FLUSH PRIVILEGES, WITH READ LOCKなしのFLUSH TABLESはしっかりバイナリーロギングされてスレーブでも実行される。迂闊にFLUSH TABLESとかマスターでやると、スレーブでも実行されてクエリーキャッシュが吹っ飛ばされるとか、マスターとスレーブの mysql.user がズレてる状態でFLUSH PRIVILEGESがレプリカされると地獄が見えるなとか思いますたん。
FLUSH TABLES WITH READ LOCK とFLUSH TABLES .. FOR EXPORT はそれぞれ違う関数を通り、それらの関数の後に write_bin_log は呼ばれない(ので、コイツらはロギングされることはない)
簡単なところなので、コードを読むにはなかなか面白かった。
0 件のコメント :
コメントを投稿