MySQLアンカンファレンス01_mysqlredo

1. MySQLにおけるRedoログとは？ ダンプツールを作って眺めてみた MySQLアンカンファレンス #001 (2024/02/03) @tom__bo 1
2. ⽬次 • 背景 • 障害回復のための”ログ”についておさらい • MySQL, InnoDBにおける”ログ” • Innodb Redoログのダンプツール紹介 • ログフォーマット • mysqlredoの実⾏例 • まとめ 2
3. 背景 • Cloud NativeなDBで”Log”を活⽤するケースをよく⾒る • MySQL(Innodb)における”Log”ってどうなっているんだっけ？ 左図: Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases 右図: AlloyDB for PostgreSQL under the hood: Intelligent, database-aware storage (⻩緑がlog 紫がmetadata) Amazon Aurora AlloyDB (Google) 3
4. 障害回復のためのログについておさらい • 障害は⼤きく3種類 1. トランザクション障害 • コミットが完了するまでの異常(デッドロックや⾃主的なアボートなど) 2. システム障害 • ハードウェア・ソフトウェアの何らかの理由でプロセスがダウン 3. メディア障害 • ハードディスクの故障などで記憶装置からデータが読めなくなる 4
5. 障害回復のためのログについておさらい • 障害回復は⼤きく3種類 1. トランザクション障害 • コミットが完了するまでの異常(デッドロックや⾃主的なアボートなど) 2. システム障害 • ハードウェア・ソフトウェアの何らかの理由でプロセスがダウン 3. メディア障害 • ハードディスクの故障などで記憶装置からデータが読めなくなる トランザクションによる更新のログ(or ジャーナル) を残すことで対応 5
6. Tx中のシステム障害の例 1 • Commitが完了したらシステム障害後も適⽤済み状態を保証 6
7. Tx中のシステム障害の例2 • システム障害時、Commit前にフラッシュした更新データがあれ ば、その更新はなかったことにする 7
8. Write Ahead Logging(WAL) • トランザクションの更新前後のデータ(before/after image)を ログとして出⼒する • データファイルにフラッシュする前にログを書く • Commit処理の完了の前にログを書く Write Ahead Logging 8
9. Tx中のシステム障害の例1の復旧 • ログ中のTrxメタデータとafter_imageを再実⾏(redo) 9
10. Tx中のシステム障害の例2の復旧 • ログ中のTrxメタデータとbefore_imageで巻き戻し(undo) 10
11. MySQLにおける”ログ”は？ 11
12. MySQLにおける”ログ”はInnoDBの”ログ” • 8.0以降システムテーブル(ibdata1), データディクショナリ (mysql.ibd, 以降DD)がInnoDBで管理されている • https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-transactional- storage.html • https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html • MySQLのシステムデータ(メタデータ)とInnoDBで作成される テーブルはInnoDBのログで障害回復できる • Original MySQLではInnoDB以外のSEはトランザクショナルではない • (MySQL ClusterのNDB SEは未調査) 12
13. MySQLにおける”ログ”はInnoDBの”ログ” • Innodb Redoログ • InnoDBのテーブルはこのredoログだけで障害回復できる • InnoDB Undoログ • 実態はUndoテーブルスペース • “An undo log is a collection of undo log records associated with a single read-write transaction. An undo log record contains information about how to undo the latest change by a transaction to a clustered index record” https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-logs.html 13
14. Innodb_redo_logファイルについて • innodb_log_group_home_dir以下に作成される • 32個のファイルをローテートして利⽤ • 1ファイルのサイズは、Innodb_redo_log_capacity/32 • 8.0.30以前はinnodb_log_file_size 14
15. あれ？Binary log(binlog)は？ • レプリケーションと障害復旧のためのログだが、これは⼀貫性のあ るバックアップからの増分適⽤による復旧⽤ • https://dev.mysql.com/doc/refman/8.0/en/binary-log.html • https://dev.mysql.com/doc/refman/8.0/en/point-in-time-recovery-binlog.html • 内部的にはトランザクションコーディネータがBinlogとInnoDB redo logの2PCを⾏っている • これについては次回以降、解説するかも 15
16. InnoDB Redo Logの中⾝どうなってるの？ 16
17. Redoログをダンプするツールを作った • mysqlredoコマンド (https://github.com/tom--bo/mysqlredo) • MySQLのclientツールとして作成 • 起動時のクラッシュリカバリを⾏うrecv_recovery_begin()関数を改変 • Redoログをパースした結果をデバッグ出⼒の要領で出⼒ 出⼒例 17
18. mysqlredoコマンド • ビルド⽅法 • mkdir bld; cd bld • cmake ... (options) • make mysqlredo … (options) • コマンド説明 • mysqlredo –start-lsn=xxx —stop-lsn=yyy filename • 引数に読みたいredologファイルを指定 • 開始/終了 LSNを—star-lsn, --stop-lsnで指定可能 • -v でverbose output 18
19. Demo or sample 19
20. Innodb_logファイル構造 • 1ファイルは512byteずつの ブロックで構成される • 先頭の4ブロックはヘッダ • 各ブロックにchecksumがある • (ファイルにはないはず。要確認) 20
21. ヘッダブロック • m_start_lsn(8): 開始位置のoffset計算に必要な値 21
22. チェックサムブロック • チェックサムは2ブロックに交互に書き込まれる (ファイル中の先頭ブロック) 22
23. 暗号化ブロック • (未調査) 23
24. データブロック(通常ブロック) • m_hdr_no(4): ブロック番号(lsnから計算) • m_data_len(2): データ⻑(ヘッダを含むデータの終端位置) • m_first_rec_group(2): MTRの開始オフセット (0ならこのブロックで開始したMTRはない) • m_epoch_no(4): ブロック番号(lsnから計算) m_hdr_noの計算 m_epoch_noの計算 24
25. ログレコード • レコードヘッダ • type(1): レコードタイプ • space_id(1~6): スペースID • page_no(1~6): ページ番号 • Payload: typeごとに固有の形式 (図WIP) 25
26. ログタイプ • storage/innobase/include/mtr0types.hのenum mtr_log_tに定義 • 想像以上にMLOG_{N}BYTESが多いので完全理解に苦戦中 26
27. Demo or sample 27
28. まとめ • InnoDB Redoログの中⾝を⾒るツールを作りました • MySQLのビルドができれば簡単に使えるので、遊んでみてください • この過程でわかったRedoログのフォーマットを紹介しました • ログタイプごとの具体的な内容は調査中です • 適⽤先のページやレコードの中⾝もまとめたい 28
29. 気になっていること • 各log typeの中⾝ • Undoテーブルスペースの仕組み • 他のDBのredo, undoログ • MariaDBだとInnoDB Redoログを削減する改良をしているらしい • Redoログの並列化や並列リカバリ技法 29