yt-healthcheckが使っている、そのMySQLがマスターなのかスレーブなのかを判定する方法

Yoku-san no ToolKIT の yt-healthcheck はデフォルトでは「接続先のMySQLがマスターなのかスレーブなのか mikasafabricなのか 」によって監視項目を切り替える。

—role によって明示的に “master” なり “slave” なりを押し込むこともできるけれど、デフォルトは “auto” で、 yt-healthcheck 自身が勝手にマスターかスレーブかあるいは中間マスター(カスケード構成の2段目、子スレーブ(孫スレーブの親))かを判定する。

https://github.com/yoku0825/ytkit/blob/0.2.1/lib/Ytkit/HealthCheck.pm#L181-L207

判定ロジックはこんな感じ。

• SHOW PROCESSLIST に Binlog Dump または Binlog GTID Dump がいれば、スレーブがつなぎにきているから $master フラグを立てる
• SHOW SLAVE STATUS の出力結果があれば親がいるから $slave フラグを立てる

で、こう。

	$slave = true	$slave = false
$master = true	中間マスター	マスター
$master = false	スレーブ	レプリケーション構成を組んでいない(監視の扱いとしてはマスター)

案外たったこれだけのことで正しくマスタースレーブを判定できるので、案外オススメ。 SHOW SLAVE STATUS には GRANT REPLICATION CLIENT が、 SHOW PROCESSLIST には GRANT PROCESS が必要（そうでないと「自分と同じアカウント以外」が SHOW PROCESSLIST に出て来なくてBinlog Dumpスレッドを検出できない）

ProxySQLとか「read_only=OFFならマスター」みたいな判定をしているやつもあるけど、アレはあてにならない（フェイルオーバーに失敗したら2台以上がread_only=OFFになるのは目に見えてるので）し、だいたい「スレーブがread_only=OFFでした」みたいなのも監視したかったのでそれはできなかった。

ただし $master フラグが立っていないMySQLに mysqlbinlog -R --stop-never とかでつなぎにいくと、フラグが立っちゃって監視がおかしくなる(スレーブは read_only= ON, マスターや中間マスターは read_only= OFF でない場合にWARNやCRITICALを吐くようにしているから)

これはもうこういうものだと思ってやっている。

いつの日になるかわからないけど、 SELECT * FROM performance_schema.replication_group_members の結果が空でなければ「グループレプリケーション」という判定も入れる気がする。必要になったら。

​