Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
データ損失を回避しよう 各DBの機能比較
tzkoba
August 26, 2020
Technology
3
820
データ損失を回避しよう 各DBの機能比較
tzkoba
August 26, 2020
Tweet
Share
More Decks by tzkoba
See All by tzkoba
The State of Distibuted Database In Japan
tzkoba
0
170
#CloudNativeDB NewSQLへの誘い
tzkoba
4
2.4k
Cloud Native時代のデータベース
tzkoba
12
12k
2020年DBプラットフォーム (超個人的)5大ニュース
tzkoba
0
750
PostgreSQLプラットフォームの徹底比較(コンテナからクラウドまで)
tzkoba
3
5k
Kubernetesでストレージ?そもそも何に使えるの?
tzkoba
0
740
昨今のデータデバイス(アーカイブ編)
tzkoba
2
1.1k
理解して拡げる分散システムの基礎知識
tzkoba
19
8k
NewSQL その成り立ちとモチベーション
tzkoba
13
5.2k
Other Decks in Technology
See All in Technology
OpsJAWS Meetup21 システム運用アンチパターンのすすめ
yoshiiryo1
0
1.5k
SlackBotで あらゆる業務を自動化。問い合わせ〜DevOpsまで #CODT2022
kogatakanori
0
880
DOM Invader - prototype pollution対応の衝撃 - / DOM Invader - prototype pollution
okuken
0
150
Swift Regex Builder
kumamotone
1
100
DeepL の用語集が(いつのまにか)日本語に対応してたので試してみた
irokawah0
0
160
UIKitのアップデート #WWDC22
akatsuki174
4
330
PUTとPOSTどっち使う?
hankehly
0
260
紙にまつわる苦しみを機能化してきた カミナシの歴史
kaminashi
0
1.2k
Oracle Cloud Infrastructure:2022年6月度サービス・アップデート
oracle4engineer
PRO
0
140
oakのミドルウェアを書くときの技のらしきもの
toranoana
0
130
Introduction To Technical Writing
olawanle_joel
0
100
リファインメントは楽しいかね?
kitamu_mu
1
440
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
19
1.2k
No one is an island. Learnings from fostering a developers community.
thoeni
9
1.3k
Art Directing for the Web. Five minutes with CSS Template Areas
malarkey
196
9.4k
Why Our Code Smells
bkeepers
PRO
324
55k
BBQ
matthewcrist
74
7.9k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
226
15k
KATA
mclloyd
7
8.7k
The Illustrated Children's Guide to Kubernetes
chrisshort
15
36k
Side Projects
sachag
450
37k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
172
8.4k
How New CSS Is Changing Everything About Graphic Design on the Web
jensimmons
213
11k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
19
1.4k
Transcript
あなたのデータ、壊れてませんか? - 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 4KB 4KB 4KB 4KB 4KB 4KB 4KB 4KB 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