WIP: binlogとinnodbの2PC @MySQLアンカンファレンス #003 (2024/04/13) tom__bo 

疑問 • 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くらいの頃に整理したのですが、結構変わってました 

状況 • 1年以上前に8.0.27くらいで調べた事があり、その内容をまとめ て発表しようと考えていました。 • 最近バージョンを固定して読んでいる8.0.32で確認したら、 当時のメモでは説明が曖昧かつ、今の実装とずれていました。 • 多少実装が変わっている && おそらく以前の理解が間違ってもいる • 改めて調査していますが、今わかっている内容を話します。 

整理したいこと 1. 2PCの⼤まかな登場⼈物(クラスや関数)と処理の流れ 2. サーバで発番するxidとInnoDBで発番するトランザクションID の紐づけの仕組み、保存先 3. 2PCの仕組みを利⽤したリカバリの処理の流れ 

主要コンポーネント • 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の実装) 

トランザクションコーディネータ(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を利⽤する 

トランザクションコーディネータ • 常に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 

INSERT処理の流れ • BEGIN; INSERT INTO ...; COMMIT;を実⾏し、その時の処理の流れ を整理する • “主要コンポーネント”で説明したServer, Hander, MYSQL_BINLOG, InnoDB, Binlog間の関数呼び出しの流れを⽰す • シーケンス図全体はブログに張りました • https://tombo2.hatenablog.com/entry/2024/04/13/192432 • 画質落とされててみずらい... (⽤意でき次第上げ直します) 

INSERT処理の流れ (BEGIN) • 重要な処理はない • トランザクション情報の初期化は最初の書き込みクエリのとき まで遅延される 

INSERT処理の流れ (INSERT STMT 1) • 重要な処理はない • next_query_id()によるid取得は何度もされる(THD.query_idに設定) • 最初のtable_lockのときにtrans_register_ha()でm_xidにquery_idを設定 

INSERT処理の流れ (INSERT STMT 2) • next_query_id()によるid取得は何度もされる(THD.query_idに設定) • 最初のtable_lockのときにtrans_register_ha()でm_xidにquery_idを設定 

INSERT処理の流れ (COMMIT 1) • next_query_id()によるid取得は何度もされる(THD.query_idに設定) • 最初のtable_lockのときにtrans_register_ha()でm_xidにquery_idを設定 

INSERT処理の流れ (COMMIT 2) 

INSERT処理の 流れ (COMMIT 3) 

リカバリシーケンス(次回) • TBD 

まとめ • 調査も資料間に合いませんでした。 • まとまったところまで調査できたら、次回発表しますm(_ _)m 

No content

No content