あなたのデータ、壊れてませんか？ - DBMS毎の保護機能を比べてみる - PostgreSQL Unconference #16 , 8/26 @tzkb

2 最近やっていること • PostgreSQL Conference Japan 2019 “Kubernetesでつくる PostgreSQL as a Service” • NewSQL関連のブログ投稿 “2020年現在のNewSQLについて” “NewSQLコンポーネント詳解” ＋ ＝∞

3 1. データはいつ、どのように壊れるのか 2. PostgreSQL：full_page_writes 3. MySQL：Doublewrite Buffer 4. Oracle：Shadow Lost Write Protect 5. 我々に必要なもの：Atomic Write 6. まとめ アジェンダ

4 データはいつ、どのように壊れるのか 1

5 質問です。あなたのデータ、壊れてませんか？ • Q「そもそもデータって何のこと？DBのレコード？」 A「今回の対象は物理レイヤ。ページであったり、ブロックであったり。」 • Q「いつ、どのように、データは壊れるのか？」 A「何時でも。いつからデータが壊れていないと錯覚していた？」 A「書き込みの失敗、デバイスの破損等（セクタ・ビットの障害など）」 データ破損の回避 書き込み時に 壊さないこと 壊れた際に 検知できること ※今日はこっちがメイン ※チェックサムとか

6 書き込みの失敗ってどういうこと？ • 多くのRDBMSでは先行ログ書込み、その後のCheckpoint時のデータ書き出し （キャッシュ⇒ディスク）で、永続化を行っている。 • つまり、Checkpoint時に低レイヤで障害が発生し、それにDBMSが気付かない で進んでしまった際にデータは壊れる。 共有バッファ メモリ ディスク テーブル ファイル WAL WALバッファ commit時等に シーケンシャルWrite checkpoint時等に ランダムWrite （書き込み時に壊れるケース） • デバイスが書込み応答したけど、 電源断で書けてなかった。 • カーネルが完了の応答したけど、 バグで書けてなかった。 • postgresが書込みエラーをハ ンドリング出来てなかった。 ※澤田さんblogのケース （ほっといて壊れるケース） • セクタやビットの障害。 • 劣化とか宇宙線とか。

7 PostgreSQLのケース 2

8 （PostgreSQL）full_page_writesの概要 • Checkpoint後の最初のWAL書き込みで、ページ全体をWALに書き込む。 • 説明しようと思ったが、、Slideshareの「PostgreSQLのリカバリ超入門」を 読んだ方が分かりやすい。 https://www.slideshare.net/suzuki_hironobu/recovery-11

9 full_page_writesは性能に影響は与えるのか？ • 仕組み上、WALの書き出し量が増える。 • Checkpoint直後にfull_page_writesによる書込みバーストが発生する。 • 対策としては、checkpoint_timeoutを伸ばす。 • デフォルトの5分はおそらく短すぎる（60分に変更した事例あり）。 • 2ndquadrantのblog「On the impact of full-page writes」では、 UUIDによるランダム主キーを利用した場合にページの追加が頻繁に行われ、 full_page_writesによるWAL書き出し量が増えるケースが報告されている。 • B-Treeの仕組み上、シーケンシャルなキー挿入よりもランダムな場合に ページ追加が急速に進むため、パーティショニングで分散を狙うケース等で 注意が必要。

10 MySQLのケース 3

11 （MySQL）Double Write Bufferの概要 • Checkpoint時に最初にDoublewrite Bufferに書き込み、エラーがなければ、 テーブルファイルに書き込む。 • テーブルファイルへの書込み時に障害があれば、バッファからリカバリする。 Doublewrite Buffer Buffer Pool メモリ ディスク テーブル名 .ibd Checkpoint時の流れ ①まずバッファへ 書き出し ②バッファを永続化 （fsync、1度目） ③テーブルファイルへ 書き出し ④データ永続化 （fsync、2度目）

12 Double Write Bufferの性能影響はどうなのか？ • 仕組み上、Checkpoint時の書込み量が増加する。 • 2倍というわけではなく、1.5倍程度の増加という検証結果あり。 • 書込み耐久性の低いメディア（SSD）と相性が悪い。 • IOバウンドなワークロードではトランザクション性能も劣化の可能性あり。 • バッファキャッシュがデータサイズに対して小さいケース。 • Writeの増加がReadと競合し、30-50%の性能劣化となる場合もある。 • 8.0.20以降ではDoublewrite Bufferのファイルが指定できること（以前は システム表領域内）に加えて、パラレル化の改善がなされ、IOバウンドな ワークロードでも劣化度合いが抑えられているようだ。

13 Oracle Databaseのケース 4

14 （Oracle Database）Shadow Lost Write Protect • Oracleでは今回のデータ書き込みの問題をLost Writeと定義。 • Checkpoint時に、Shadow表領域へもSCN(システムコミットNo）を書き込み、 後から検知できるようにしている。 （通常） 表領域 Buffer Cache メモリ ディスク Shadow 表領域 書出し時にSCNを 記録する 通常通りにデータを 書込み • EEのライセンスが必要。 • データの復旧には、 Data Guard を 用いたスタンバイDBが必要。 （ここからは推測） • Shadow表領域への書き出し後に、 通常表領域への書き出すと思われる。 • 「少なくとも2%の領域を余分に使 う」との記載から、Shadow表領域 に書かれるのはSCN＋α(≠データ)と 思われる。

15 我々に必要なもの：Atomic Write 5

16 なぜ、データ書き込みの失敗に気付けないのか？ • まず、一つの原因として、DBとOSのレイヤで扱うページのサイズがずれている。 • さらにOSやファイルシステムのレイヤで、マルチページでAtomic Writeを サポートしていない。 Buffer Pool メモリ ディスク テーブル名 .ibd ４KB ４KB ４KB ４KB ４KB ４KB ４KB ４KB MySQLはページ単位(16KB) でWriteしてるつもり。 OS以下では4KB単位。 マルチページのWriteが Atomicにならないので、 DBLBWで対応している。

17 我々に必要なもの、そして手に入らないもの • DBからAtomic Writeが可能な何か（デバイス、ファイルシステムなど）。 • かつて（今も？）MySQL+Fusion-ioで実現していたもの。 • Atomic Writeを下層レイヤで 実現するか、DBMSが自前で 実現するかというのは過去に も検討されてきた。 例：ZFS、RAWデバイスなど • HWまで含めて一気通貫で最 適化されたDBを作るのはベン ダでも大変。 • PostgreSQLはそうした方向性 ではないので、Atomic Write を実現することは難しいか。 • もしかしたら、Pluggable Storageで？？

18 まとめ  書いたと思ったデータは“壊れている”かもしれない。  それを避けるための機能が各DBMSには実装されている。  オーバヘッドも理解し、破損を防ぐ適切な設定をしよう。  レプリケーション等で破損を修復できるケースもある。 但し、破損の検知が正しくできる前提。  （コミッタの皆さんの顔色を見ながら） PostgreSQLのAtomic Write、欲しいです。

19 Questions? @tzkb @tzkoba