データ損失を回避しよう 各DBの機能比較

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

7. 7
   PostgreSQLのケース
   2
   

   View Slide

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

   View Slide

9. 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の仕組み上、シーケンシャルなキー挿入よりもランダムな場合に
   ページ追加が急速に進むため、パーティショニングで分散を狙うケース等で
   注意が必要。
   

   View Slide

10. 10
    MySQLのケース
    3
    

    View Slide

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

    View Slide

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

    View Slide

13. 13
    Oracle Databaseのケース
    4
    

    View Slide

14. 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＋α(≠データ)と
    思われる。
    

    View Slide

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

    View Slide

16. 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で対応している。
    

    View Slide

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

    View Slide

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

    View Slide

19. 19
    Questions?
    @tzkb
    @tzkoba
    

    View Slide