全スレーブが同時にレプリケーションを停止する問題事象

全スレーブが同時に「unknown error reading log event on the master」というエラーでレプリケーションを停止する問題事象についての、問題の詳細と対策など

Transcript

1. 全スレーブが同時にレプリケーションを停止する 問題事象のご説明 Kentoku SHIBA
2. - show slave statusで「Got fatal error 1236 from master when reading data from binary log: 'unknown error reading log event on the master; the first event 'binlog.004215' at 8610479, the last event read from './binlog.004226' at 154, the last byte read from './binlog.004226' at 154.'」が出力される エラーが発生し、レプリケーションが停止する。 - start slaveを実行すると、少しpositionが進み、再度同じエラーで レプリケーションが停止する。 - マスタ側のバイナリログローテート後にstart slaveすると復旧する。 - HWエラーなし、disk fullでもない。 問題事象
3. パニックにならないでください！ 詳細を説明します。 問題事象
4. スレーブからのバイナリログ転送要求 マスタ スレーブ バイナリログ 要求 最新のバイナリログについてはMYSQL_BIN_LOG::binlog_end_posを 参照して、バイナリログをスレーブに送信する。 バイナリログ 送信 MYSQL_BIN_LOG ::binlog_end_pos
5. COMMIT時の挙動 マスタ ＦＬＵＳＨステージ SYNC_BINLOG=1の場合、FLUSHステージで書きこんだ更新の終端位置 をTHD::m_trans_end_pos に保持し、SYNCステージで MYSQL_BIN_LOG::binlog_end_pos に書き込む。 ＣＯＭＭＩＴステージ THD:: m_trans_end_pos ＳＹＮＣステージ MYSQL_BIN_LOG ::binlog_end_pos
6. - FLUSHステージ 各トランザクションで保持している更新内容を、バイナリログに 書き込む。（物理的な書き込みはここでは保証されない） - SYNCステージ バイナリログの書き込みを、物理的に保証する。 - COMMITステージ ストレージエンジン側で更新を確定する。 （それまでは、PREPAREという状態） 各ステージは、並列で実行可能で、あるトランザクションがCOMMIT、 次のトランザクションがSYNC、その次のトランザクションがFLUSHと いうように、それぞれのトランザクションが同時に異なるステージで 処理されているということがある。 COMMIT時の各ステージの概要
7. 問題発生契機 マスタ ＦＬＵＳＨステージ SYNCステージでMYSQL_BIN_LOG::binlog_end_pos に書き込む前に、バ イナリログのローテートが行われると問題が発生する。 ＣＯＭＭＩＴステージ THD:: m_trans_end_pos ＳＹＮＣステージ MYSQL_BIN_LOG ::binlog_end_pos バイナリログローテート 今COMMITステージにいるトランザクション もしくは Flush (binary) logs によって 実行される
8. - バイナリログ自体は壊れておらず、読み込み可能位置のみが 誤っているため、レプリケーション再開後実際に書き込まれた部 分は読み込まれ、まだ書き込まれていない位置に達すると再度エ ラーになる。 - バイナリログが再度切り替わると、 MYSQL_BIN_LOG::binlog_end_pos新しいファイル用にリセット されるため、この時に再度問題発生契機に該当することがなけれ ば、問題は収束する。 - トランザクションをサポートするテーブルに対する更新の場合は、 MYSQL_BIN_LOG::m_prep_xidsがインクリメントされることによ り、COMMIT_STAGEでのストレージエンジン側のCOMMITが完 了するまでローテートが待たされるため、この問題事象は発生し ない。 問題発生後の挙動
9. 前提条件 - MySQL 5.7 もしくは MySQL 8.0 （Percona Serverなども含まれます。Amazon RDS? Aurora? ソースコードがないのでわかりません。MariaDBは含まれません） - SYNC_BINLOG=1 - バイナリログを出力している 以下の操作を実行した際にバイナリログがローテートする。 （FLUSH BINARY LOGSでローテートした場合も含む） - XAトランザクションをサポートしていないテーブル（MyISAM、 MEMORYなど）に対する更新 - DDLの実行（MySQL 8.0のアトミックDDLを除く） （CREATE TABLE … SELECT … は、アトミックDDLに含まれない） - ANALYZE TABLEなどのコマンドの実行 問題の発生条件の詳細
10. MySQL 5.7、MySQL 8.0共通 ANALYZE TABLE, REPAIR TABLE, OPTIMIZE TABLE, FLUSH TABLES, FLUSH PRIVILEGES, FLUSH ENGINE LOGS, FLUSH ERROR LOGS, FLUSH GENERAL LOGS, FLUSH HOSTS, FLUSH OPTIMIZER_COSTS, FLUSH RELAY LOGS, FLUSH SLOW LOGS, FLUSH SLOW LOGS, FLUSH STATUS, FLUSH USER_RESOURCES, ALTER INSTANCE, CREATE TABLE ... SELECT ... MySQL 5.7、MySQL 8.0共通(アトミックDDL非サポートテーブル) CREATE TABLE, DROP TABLE, ALTER TABLE, RENAME TABLE, TRUNCATE, CREATE INDEX, DROP INDEX MySQL 5.7、MySQL 8.0共通(XAトランザクション非サポートテーブル) INSERT, UPDATE, DELETE, REPLACE, LOAD DATA 問題の発生条件となる操作の詳細（その１）
11. MySQL 5.7 CREATE USER, DROP USER, RENAME USER, ALTER USER, SET PASSWORD, GRANT, REVOKE (ALL), CREATE DATABASE, DROP DATABASE, ALTER DATABASE, CREATE VIEW, DROP VIEW, CREATE TABLESPACE, DROP TABLESPACE, ALTER TABLESPACE, CREATE FUNCTION, DROP FUNCTION, ALTER FUNCTION, CREATE PROCEDURE, DROP PROCEDURE, ALTER PROCEDURE, CREATE TRIGGER, DROP TRIGGER, CREATE EVENT, DROP EVENT, ALTER EVENT, FLUSH DES_KEY_FILE, FLUSH QUERY CACHE 問題の発生条件となる操作の詳細（その２）
12. 以下のいずれかの対応が可能（他の対応が可能な場合もある） ①FLUSH BINARY LOGSで、バイナリログを手動で切り替え、 スレーブでSTART SLAVE (IO_THREAD)を実行する。 同じエラーとなった場合は、再度FLUSH BINARY LOGS、 START SLAVEを行う。 ②スレーブで、エラーがなくなるまでSTART SLAVE (IO_THREAD) を実行する。 問題発生後もしくは発生を回避するための対応
13. 以下のいずれかの対応が可能（他の対応が可能な場合もある） ③マスタ障害時のデータ不整合を考慮に入れた上で、 SYNC_BINLOGを1以外の値に設定する。 ④通常運用時は問題が発生しないことがあらかじめ分かっている 場合、メンテナンスでDDLなどを実行する前に、 FLUSH BINARY LOGSを実行し、DDL実行時の バイナリログローテートの可能性を小さくする。 問題発生後もしくは発生を回避するための対応
14. MySQL 5.7 5.7.25で修正済 MySQL 8.0 8.0.14で修正済 現在の修正状況