FLUSH PRIVILEGESやFLUSH TABLESはバイナリーログに書かれるのでgtid_executedに記録されるよ

や、まあ、バイナリーログに吐かれるのはマニュアルに書いてあってそうなんだけれども、GTID振られるのは失念してた。

一つだけマニュアルが誤解を招く表現。

デフォルトでは、サーバーは 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 は呼ばれない（ので、コイツらはロギングされることはない）


簡単なところなので、コードを読むにはなかなか面白かった。

mikasafabric for MySQLのビルド

mikasafabric for MySQL が何なのかについては こちら

取り敢えずビルド方法のメモ。雑に。

#!/bin/bash

version="0.1.1"
dirname="mikasafabric-${version}"

rm -rf ~/rpmbuild
mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

if [ -d ~/$dirname ] ; then
  rm -rf ~/$dirname
fi
git clone https://github.com/gmo-media/mikasafabric.git ~/$dirname
cd ~/$dirname
git checkout ${version}
cd $OLDPWD

tar czf ~/rpmbuild/SOURCES/${dirname}.tar.gz $dirname
rpmbuild -bb ~/$dirname/mikasafabric.spec

ビルドにはpython-develとrpm-buildが必要。実際にmikasafabricを動かすにはmysql-connector-pythonが必要。CentOS 7.2とCentOS 6.7くらいでビルドして動作できる。実際に本番で動いているのはCentOS 7.2。

バージョンはセマンティックバージョニングじゃ ない 。Groongaに似てるかも。
機能が1つ増える、バグが1つFIXされると末尾の数字が増える。 `yum install ~/rpmbuild/RPMS/noarch/mikasafabric-*.rpm` で上書きインストールできて便利だからというだけの理由。


GitHub Pagesでyumリポジトリー作りたい。