Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Cd891a89dfec6ca7bd278b5f5bd87c90?s=47 tzkoba
August 26, 2020

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

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

August 26, 2020
Tweet

Transcript

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

  2. 2 最近やっていること • PostgreSQL Conference Japan 2019 “Kubernetesでつくる PostgreSQL as

    a Service” • NewSQL関連のブログ投稿 “2020年現在のNewSQLについて” “NewSQLコンポーネント詳解” + =∞
  3. 3 1. データはいつ、どのように壊れるのか 2. PostgreSQL:full_page_writes 3. MySQL:Doublewrite Buffer 4. Oracle:Shadow

    Lost Write Protect 5. 我々に必要なもの:Atomic Write 6. まとめ アジェンダ
  4. 4 データはいつ、どのように壊れるのか 1

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

    書き込み時に 壊さないこと 壊れた際に 検知できること ※今日はこっちがメイン ※チェックサムとか
  6. 6 書き込みの失敗ってどういうこと? • 多くのRDBMSでは先行ログ書込み、その後のCheckpoint時のデータ書き出し (キャッシュ⇒ディスク)で、永続化を行っている。 • つまり、Checkpoint時に低レイヤで障害が発生し、それにDBMSが気付かない で進んでしまった際にデータは壊れる。 共有バッファ メモリ

    ディスク テーブル ファイル WAL WALバッファ commit時等に シーケンシャルWrite checkpoint時等に ランダムWrite (書き込み時に壊れるケース) • デバイスが書込み応答したけど、 電源断で書けてなかった。 • カーネルが完了の応答したけど、 バグで書けてなかった。 • postgresが書込みエラーをハ ンドリング出来てなかった。 ※澤田さんblogのケース (ほっといて壊れるケース) • セクタやビットの障害。 • 劣化とか宇宙線とか。
  7. 7 PostgreSQLのケース 2

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

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

  11. 11 (MySQL)Double Write Bufferの概要 • Checkpoint時に最初にDoublewrite Bufferに書き込み、エラーがなければ、 テーブルファイルに書き込む。 • テーブルファイルへの書込み時に障害があれば、バッファからリカバリする。

    Doublewrite Buffer Buffer Pool メモリ ディスク テーブル名 .ibd Checkpoint時の流れ ①まずバッファへ 書き出し ②バッファを永続化 (fsync、1度目) ③テーブルファイルへ 書き出し ④データ永続化 (fsync、2度目)
  12. 12 Double Write Bufferの性能影響はどうなのか? • 仕組み上、Checkpoint時の書込み量が増加する。 • 2倍というわけではなく、1.5倍程度の増加という検証結果あり。 • 書込み耐久性の低いメディア(SSD)と相性が悪い。

    • IOバウンドなワークロードではトランザクション性能も劣化の可能性あり。 • バッファキャッシュがデータサイズに対して小さいケース。 • Writeの増加がReadと競合し、30-50%の性能劣化となる場合もある。 • 8.0.20以降ではDoublewrite Bufferのファイルが指定できること(以前は システム表領域内)に加えて、パラレル化の改善がなされ、IOバウンドな ワークロードでも劣化度合いが抑えられているようだ。
  13. 13 Oracle Databaseのケース 4

  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+α(≠データ)と 思われる。
  15. 15 我々に必要なもの:Atomic Write 5

  16. 16 なぜ、データ書き込みの失敗に気付けないのか? • まず、一つの原因として、DBとOSのレイヤで扱うページのサイズがずれている。 • さらにOSやファイルシステムのレイヤで、マルチページでAtomic Writeを サポートしていない。 Buffer Pool

    メモリ ディスク テーブル名 .ibd 4KB 4KB 4KB 4KB 4KB 4KB 4KB 4KB MySQLはページ単位(16KB) でWriteしてるつもり。 OS以下では4KB単位。 マルチページのWriteが Atomicにならないので、 DBLBWで対応している。
  17. 17 我々に必要なもの、そして手に入らないもの • DBからAtomic Writeが可能な何か(デバイス、ファイルシステムなど)。 • かつて(今も?)MySQL+Fusion-ioで実現していたもの。 • Atomic Writeを下層レイヤで

    実現するか、DBMSが自前で 実現するかというのは過去に も検討されてきた。 例:ZFS、RAWデバイスなど • HWまで含めて一気通貫で最 適化されたDBを作るのはベン ダでも大変。 • PostgreSQLはそうした方向性 ではないので、Atomic Write を実現することは難しいか。 • もしかしたら、Pluggable Storageで??
  18. 18 まとめ  書いたと思ったデータは“壊れている”かもしれない。  それを避けるための機能が各DBMSには実装されている。  オーバヘッドも理解し、破損を防ぐ適切な設定をしよう。  レプリケーション等で破損を修復できるケースもある。

    但し、破損の検知が正しくできる前提。  (コミッタの皆さんの顔色を見ながら) PostgreSQLのAtomic Write、欲しいです。
  19. 19 Questions? @tzkb @tzkoba