突然全てのスレーブのレプリケーションが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ストレージエンジンを少しご紹介させて頂きます。

Transcript

1. 突然全てのスレーブのレプリケーションが unknown error reading log event on the master; というエラーで停止したら。 おまけで、Spider Storage Engineを少し。 スパイラルアーム合同会社 Kentoku SHIBA
2. Spiderで何ができるようになるのか?
3. SPIDER （MySQL/MariaDB） SPIDER （MySQL/MariaDB） Spiderで何ができるようになるのか？ DB1 （MySQL/MariaDB） 1.リクエスト 2. 問い合わせを実行 3.レスポンス AP SPIDER （MySQL/MariaDB） アプリケーションは、１つのデータベースに接続するだけで、 大量のデータベースを意識せずに利用できる。 AP AP AP AP DB2 （MySQL/MariaDB） DB3 （MySQL/MariaDB）
4. Spiderはどんなところで使われているか?
5. Spiderはどんなところで使われているか? Galaxy Semiconductor データ品質分析基盤として、Spiderが 利用されている。 ３つのSpiderノード、４つのデータノードで 3か月あたり、2000億レコードを扱っている。
6. Spiderはどんなところで使われているか? Tencent Games オンラインゲームの基盤としてSpiderが 利用されている。 ３96のSpiderノード、2800のデータノードで 100TBのデータを扱っている。
7. Spiderストレージエンジンとは？
8. Spiderストレージエンジンとは? Spiderストレージエンジンは、 MariaDB/MySQLのプラグインであり、 データベースのシャーデングやプロキシを 実現するソリューションです。 テーブル作成する際にEngineにSpiderと 書くことで、Spiderテーブルを作成して 利用します。
9. Spiderストレージエンジンとは? Spiderテーブルは他のサーバにある MariaDB/MySQL/OracleDBのテーブルを あたかもそのデータベースにあるテーブルの ように利用することを可能にします。 また、複数サーバに分散されたテーブルを １つのテーブルとして利用することも 可能にします。（データベースシャーディング）
10. Spiderストレージエンジンとは? SpiderはMariaDB 10.0系から 標準でバンドルされております。 また、MariaDB 10.3系からは Spiderの全機能が制限なく 使えるようになったことに加え、 MariaDB社からサポートを 受けられるようになりました。
11. 突然全てのスレーブのレプリケーションが unknown error reading log event on the master; というエラーで停止する現象について
12. - 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でもない。 問題事象
13. 突然起こるとパニックになりそうな 内容ですが、あらかじめ問題を 理解しておくと、問題が起こっても 落ち着いて対応が可能です。 詳細を説明します。 問題事象
14. スレーブからのバイナリログ転送要求 マスタ スレーブ バイナリログ 要求 最新のバイナリログについてはMYSQL_BIN_LOG::binlog_end_posを 参照して、バイナリログをスレーブに送信する。 バイナリログ 送信 MYSQL_BIN_LOG ::binlog_end_pos
15. 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
16. - FLUSHステージ 各トランザクションで保持している更新内容を、バイナリログに 書き込む。（物理的な書き込みはここでは保証されない） - SYNCステージ バイナリログの書き込みを、物理的に保証する。 - COMMITステージ ストレージエンジン側で更新を確定する。 （それまでは、PREPAREという状態） 各ステージは、並列で実行可能で、あるトランザクションがCOMMIT、 次のトランザクションがSYNC、その次のトランザクションがFLUSHと いうように、それぞれのトランザクションが同時に異なるステージで 処理されているということがある。 COMMIT時の各ステージの概要
17. 問題発生契機 マスタ ＦＬＵＳＨステージ SYNCステージでMYSQL_BIN_LOG::binlog_end_pos に書き込む前に、バ イナリログのローテートが行われると問題が発生する。 ＣＯＭＭＩＴステージ THD:: m_trans_end_pos ＳＹＮＣステージ MYSQL_BIN_LOG ::binlog_end_pos バイナリログローテート 今COMMITステージにいるトランザクション もしくは Flush (binary) logs によって 実行される
18. - バイナリログ自体は壊れておらず、読み込み可能位置のみが 誤っているため、レプリケーション再開後実際に書き込まれた部 分は読み込まれ、まだ書き込まれていない位置に達すると再度エ ラーになる。 - バイナリログが再度切り替わると、 MYSQL_BIN_LOG::binlog_end_pos新しいファイル用にリセット されるため、この時に再度問題発生契機に該当することがなけれ ば、問題は収束する。 - トランザクションをサポートするテーブルに対する更新の場合は、 MYSQL_BIN_LOG::m_prep_xidsがインクリメントされることによ り、COMMIT_STAGEでのストレージエンジン側のCOMMITが完 了するまでローテートが待たされるため、この問題事象は発生し ない。 問題発生後の挙動
19. 前提条件 - 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などのコマンドの実行 問題の発生条件の詳細
20. 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 問題の発生条件となる操作の詳細（その１）
21. 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 問題の発生条件となる操作の詳細（その２）
22. 以下のいずれかの対応が可能（他の対応が可能な場合もある） ①FLUSH BINARY LOGSで、バイナリログを手動で切り替え、 スレーブでSTART SLAVE (IO_THREAD)を実行する。 同じエラーとなった場合は、再度FLUSH BINARY LOGS、 START SLAVEを行う。 ②スレーブで、エラーがなくなるまでSTART SLAVE (IO_THREAD) を実行する。 問題発生後もしくは発生を回避するための対応
23. 以下のいずれかの対応が可能（他の対応が可能な場合もある） ③マスタ障害時のデータ不整合を考慮に入れた上で、 SYNC_BINLOGを1以外の値に設定する。 ④通常運用時は問題が発生しないことがあらかじめ分かっている 場合、メンテナンスでDDLなどを実行する前に、 FLUSH BINARY LOGSを実行し、DDL実行時の バイナリログローテートの可能性を小さくする。 問題発生後もしくは発生を回避するための対応
24. MySQL 5.7 5.7.25で修正済 MySQL 8.0 8.0.14で修正済 現在の修正状況
25. 今回の件で見えてくる オープンソースを使うことのメリット
26. 問題に対して、妥協しないという選択肢がある。 ・多くの場合、開発元が問題を再現できないと対応してはもらえず、 その場合ワークアラウンドで対応するのは一般的。 ・ただし、サービスが大きくなった場合、例えそのために費用が かかっても、サポートを受けることに加えて、問題に妥協しない 選択肢があることに大きなメリットがあることがある。 ・その時に、それができるエンジニアに依頼することもできるし、 そもそもそういったことができるエンジニアを雇用しておく選択もある。 オープンソースを使うことのメリット
27. http://spiderse.com Kentoku SHIBA (kentokushiba [at] gmail [dot] com) Any Questions? You can see me later! Come to visit me!! ご清聴ありがとうございました!