Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
WIP: 2PC between binlog and InnoDB
Search
tom--bo
April 13, 2024
1
100
WIP: 2PC between binlog and InnoDB
MySQLアンカンファレンス第3回
tom--bo
April 13, 2024
Tweet
Share
More Decks by tom--bo
See All by tom--bo
SQL SECURITY特性の扱いと作ったパッチ
tombo
1
50
MyRaft論文紹介
tombo
3
830
2PC between Binlog and InnoDB
tombo
1
210
Dive into InnoDB from redo logs
tombo
3
1.2k
MySQLアンカンファレンス01_mysqlredo
tombo
1
560
MySQLアンカンファレンス 開催概要
tombo
0
250
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
The Pragmatic Product Professional
lauravandoore
32
6.3k
Gamification - CAS2011
davidbonilla
80
5.1k
Unsuck your backbone
ammeep
669
57k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
The Language of Interfaces
destraynor
154
24k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Transcript
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
None
None