WIP: 2PC between binlog and InnoDB

MySQLアンカンファレンス第3回

1. WIP: binlogとinnodbの2PC @MySQLアンカンファレンス #003 (2024/04/13) tom__bo
2. 疑問 • redoログばかり⾒ていたけど、binlogとの関係は？ • ファイルが違うので、binlogでコミットされていて、innodb(redo log)でコ ミットされていない事はありえる • => どうやら2 Phase Commit (2PC)しているらしい • https://www.slideshare.net/takanorisejima/binary-log-2pc-group-commit • by @ts4thさん • 5.7.12時点の主要なクラスや関数を列挙しながら説明がされている • => 8.0.32での実装を調査してみた(今回の内容) • 以前8.0.28くらいの頃に整理したのですが、結構変わってました
3. 状況 • 1年以上前に8.0.27くらいで調べた事があり、その内容をまとめ て発表しようと考えていました。 • 最近バージョンを固定して読んでいる8.0.32で確認したら、 当時のメモでは説明が曖昧かつ、今の実装とずれていました。 • 多少実装が変わっている && おそらく以前の理解が間違ってもいる • 改めて調査していますが、今わかっている内容を話します。
4. 整理したいこと 1. 2PCの⼤まかな登場⼈物(クラスや関数)と処理の流れ 2. サーバで発番するxidとInnoDBで発番するトランザクションID の紐づけの仕組み、保存先 3. 2PCの仕組みを利⽤したリカバリの処理の流れ
5. 主要コンポーネント • Server (sqlレイヤ。クエリを受け取って実⾏する部分) • TC_LOG (トランザクションコーディネータ) • 2PC実装の抽象クラス • サブクラスにTC_LOG_DUMMY, TC_LOG_MMAP, MYSQL_BIN_LOGがある • 今回はMYSQL_BIN_LOGだけに注⽬ • Handler (ハンドラー実装) • ha_innobase (InnoDBの実装、Handler経由で呼ばれる) • binlog (MYSQL_BIN_LOGクラス以外のbinlogの実装)
6. トランザクションコーディネータ(tc_log) • Serverはトランザクション処理が正しく処理されるようにトラ ンザクションコーディネータを使う。3つの異なる実装がある。 (コードコメント意訳) • https://github.com/mysql/mysql-server/blob/mysql- 8.0.32/sql/tc_log.h#L133 • 3つの実装(TC_LOGのサブクラス) • TC_LOG_DUMMY: 何もしない • TC_LOG_MMAP: メモリ上の構造で処理する (?) • MYSQL_BIN_LOG: transaction cordinationにbinlogを利⽤する
7. トランザクションコーディネータ • 常に3つのサブクラスすべてをインスタンス化している • TC_LOG_DUMMY, TC_LOG_MMAP • https://github.com/mysql/mysql-server/blob/mysql- 8.0.32/sql/tc_log.cc#L735-L736 • MYSQL_BINLOG • https://github.com/mysql/mysql-server/blob/mysql- 8.0.32/sql/binlog.cc#L177
8. INSERT処理の流れ • BEGIN; INSERT INTO ...; COMMIT;を実⾏し、その時の処理の流れ を整理する • “主要コンポーネント”で説明したServer, Hander, MYSQL_BINLOG, InnoDB, Binlog間の関数呼び出しの流れを⽰す • シーケンス図全体はブログに張りました • https://tombo2.hatenablog.com/entry/2024/04/13/192432 • 画質落とされててみずらい... (⽤意でき次第上げ直します)
9. INSERT処理の流れ (BEGIN) • 重要な処理はない • トランザクション情報の初期化は最初の書き込みクエリのとき まで遅延される
10. INSERT処理の流れ (INSERT STMT 1) • 重要な処理はない • next_query_id()によるid取得は何度もされる(THD.query_idに設定) • 最初のtable_lockのときにtrans_register_ha()でm_xidにquery_idを設定
11. INSERT処理の流れ (INSERT STMT 2) • next_query_id()によるid取得は何度もされる(THD.query_idに設定) • 最初のtable_lockのときにtrans_register_ha()でm_xidにquery_idを設定
12. INSERT処理の流れ (COMMIT 1) • next_query_id()によるid取得は何度もされる(THD.query_idに設定) • 最初のtable_lockのときにtrans_register_ha()でm_xidにquery_idを設定
13. INSERT処理の流れ (COMMIT 2)
14. INSERT処理の 流れ (COMMIT 3)
15. リカバリシーケンス(次回) • TBD
16. まとめ • 調査も資料間に合いませんでした。 • まとまったところまで調査できたら、次回発表しますm(_ _)m