Upgrade to Pro — share decks privately, control downloads, hide ads and more …

突然全てのスレーブのレプリケーションがunknown error reading log ev...

Kentoku SHIBA
September 20, 2018

突然全てのスレーブのレプリケーションがunknown error reading log event on the masterというエラーで停止したら。おまけで、Spider Storage Engineを少し。

MySQL 5.7、8.0には、ごく稀なケースで突然全てのスレーブが"unknown error reading log event on the master;"というエラーで停止することがあることが確認されました。一見非常に重大な問題が発生したようにも見えてしまいますが、問題発生のメカニズムと対処方法を理解していればそれほど慌てる問題ではありません。このセッションでは、この問題の説明とメカニズムの解説、解消方法をご説明させて頂きます。
と、Spiderストレージエンジンを少しご紹介させて頂きます。

Kentoku SHIBA

September 20, 2018
Tweet

More Decks by Kentoku SHIBA

Other Decks in Technology

Transcript

  1. 突然全てのスレーブのレプリケーションが unknown error reading log event on the master; というエラーで停止したら。

    おまけで、Spider Storage Engineを少し。 スパイラルアーム合同会社 Kentoku SHIBA
  2. SPIDER (MySQL/MariaDB) SPIDER (MySQL/MariaDB) Spiderで何ができるようになるのか? DB1 (MySQL/MariaDB) 1.リクエスト 2. 問い合わせを実行

    3.レスポンス AP SPIDER (MySQL/MariaDB) アプリケーションは、1つのデータベースに接続するだけで、 大量のデータベースを意識せずに利用できる。 AP AP AP AP DB2 (MySQL/MariaDB) DB3 (MySQL/MariaDB)
  3. - 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でもない。 問題事象
  4. - FLUSHステージ 各トランザクションで保持している更新内容を、バイナリログに 書き込む。(物理的な書き込みはここでは保証されない) - SYNCステージ バイナリログの書き込みを、物理的に保証する。 - COMMITステージ ストレージエンジン側で更新を確定する。

    (それまでは、PREPAREという状態) 各ステージは、並列で実行可能で、あるトランザクションがCOMMIT、 次のトランザクションがSYNC、その次のトランザクションがFLUSHと いうように、それぞれのトランザクションが同時に異なるステージで 処理されているということがある。 COMMIT時の各ステージの概要
  5. - バイナリログ自体は壊れておらず、読み込み可能位置のみが 誤っているため、レプリケーション再開後実際に書き込まれた部 分は読み込まれ、まだ書き込まれていない位置に達すると再度エ ラーになる。 - バイナリログが再度切り替わると、 MYSQL_BIN_LOG::binlog_end_pos新しいファイル用にリセット されるため、この時に再度問題発生契機に該当することがなけれ ば、問題は収束する。

    - トランザクションをサポートするテーブルに対する更新の場合は、 MYSQL_BIN_LOG::m_prep_xidsがインクリメントされることによ り、COMMIT_STAGEでのストレージエンジン側のCOMMITが完 了するまでローテートが待たされるため、この問題事象は発生し ない。 問題発生後の挙動
  6. 前提条件 - 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などのコマンドの実行 問題の発生条件の詳細
  7. 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 問題の発生条件となる操作の詳細(その1)
  8. 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 問題の発生条件となる操作の詳細(その2)
  9. http://spiderse.com Kentoku SHIBA (kentokushiba [at] gmail [dot] com) Any Questions?

    You can see me later! Come to visit me!! ご清聴ありがとうございました!