ロールの自動識別 my $master= my $slave= my $cluster= 0; $master= 1 if $self->show_slaves_via_processlist; $slave = 1 if ($self->instance->show_slave_status && $self->instance->show_slave_status->[0]); $cluster= 1 if defined($self->instance->i_am_group_replication_primary); ### Restore param $self->instance->{_ignore_unsupport_version}= $saved_ignore; ### SHOW SLAVE STATUS condition is advanced more than cluster. if ($slave) { ### Intermidiate-master in a cascaded replication toporogy. return "intermidiate" if $master; return "slave"; } elsif ($cluster) { return "group_replication"; } else { return "master"; } https://github.com/yoku0825/ytkit/blob/0.5.0/lib/Ytkit/ HealthCheck.pm#L217-L249 17/59
ロールの自動識別 4. 1. ～ 3. の辻褄を合わせる 現状、グループレプリケーションを非同期レプリカにするトポロジーはサポートしていない( -- role=group_replication と --role=slave で2回実行すればいいだけだと思う) ‐ role $master $slave $cluster master o x * slave x o * intermidiate o o * group_replication x x o 21/59
コネクション数監視 mysql> SHOW GLOBAL STATUS LIKE 'Threads_connected'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Threads_connected | 3 | +-------------------+-------+ 1 row in set (0.03 sec) mysql> SHOW GLOBAL VARIABLES LIKE 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 151 | +-----------------+-------+ 1 row in set (0.00 sec) 26/59
read_only設定監視 そのまま。 read_only が意図した値になっているかどうか確認する。 role read_only=ON read_only=OFF master 大事故 o slave o 接続先を間違えなければ… intermidiate 大事故 o なんでこんな単純な監視が存在するのかと言うと、「それで痛い目を見たことがあ るから」 31/59
Uptime監視 何のひねりもなく単にUptimeが閾値未満だったらアラートにする ウチは5分間隔のポーリングなので300未満ならCriticalにしている ‐ それ以外の方法(ログ監視とか)で気が付くことがほとんど 1回だけRDSのフェイルオーバーをこれで拾えたので、そういう環境では有効なんだろうなぁ ‐ mysql> SHOW GLOBAL STATUS LIKE 'Uptime'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Uptime | 72615 | +---------------+-------+ 1 row in set (0.08 sec) 34/59
グループレプリケーション状況監視 グループレプリケーションの「遅延」を監視 SHOW SLAVE STATUS の Seconds_Behind_Master のようなシンプルな値ではなく（アレは実は 「算出方法」がシンプルではないけれど）、自分で(SQLで)計算している ‐ 「適用待ちトランザクションキューの数」と「最後にコミットされたトランザクションの時間 差」を計算 ‐ ### How many commits not yet applied. my $trx_lag= $self->instance->replication_group_member_stats->[0]->{count_transactions_re mote_in_applier_queue}; ### How many seconds between "STARTING APPLY" and "COMMITTED ORIGINAL" my $applier_time_lag= $self->instance->replication_applier_status->{group_replication_app lier}->{_diff} // 0; https://github.com/yoku0825/ytkit/blob/0.5.0/lib/Ytkit/ HealthCheck.pm#L773-L804 39/59
グループレプリケーション状況監視 遅延監視ではグループレプリケーションの RECOVERING ステータス(一度グループレ プリケーションから弾き出されたあと、差分同期でグループレプリケーションに追 い付くまでのステータス)も考慮 落ちて上がったあと、延々鳴り続けるのも嫌ですしおすし ‐ ### If node is entering RECOVERING state, mysqlrouter is devide node from load-balancing, ### Group Replication lag is not matter. if ($self->instance->i_am_group_replication_recovering) { ### Change critical threshold to supernum to fall back as WARNING $self->{group_replication_lag_transactions}->{critical}= 2 ** 63 - 1; $self->{group_replication_lag_seconds}->{critical}= 2 ** 63 - 1; } https://github.com/yoku0825/ytkit/blob/0.5.0/lib/Ytkit/ HealthCheck.pm#L773-L804 40/59
後追いできるように情報を残す --dump-detail=/path/to/information.txt と指定すると、ワーニングまたはクリ ティカルになった時点のいくつかの情報を平文テキストで吐き出す $ yt-healthcheck --help .. * --dump_detail=value When result is NOT NAGIOS_OK, output results of "SHOW PROCESSLIST", "SHOW SLAVE STATUS" and "SHOW ENGINE INNODB STATU S"" into specified file .. 45/59
後追いできるように情報を残す --help にあるよりもっと情報を取ってた SHOW FULL PROCESSLIST ‐ SHOW SLAVE STATUS ‐ SHOW ENGINE INNODB STATUS ‐ sys.x$innodb_lock_waits (sysがないバージョンでは似たようなSQLで直接 information_schemaを叩く) ‐ information_schema.innodb_trx ‐ performance_schema.threads ‐ https://github.com/yoku0825/ytkit/blob/0.5.0/lib/Ytkit/ MySQLServer.pm#L1138-L1212 46/59
yoku0825
nori_shinoda
sheep_san_white
eiki
devops_vtj
claudioed
_kensh
kazumax55
asahihidehiko
keiji
imsaku
non97
mixi_engineers
reverentgeek
sonatard
bermonpainter
jennybc
mza
afnizarnur
tmm1
eileencodes
notwaldorf
addyosmani
edds