狠狠撸

PostgreSQLのリカバリ超入門
Version 2.0
See also http://www.interdb.jp/pg/
2015.3.09
鈴木啓修

2014/5/31 29回jpug_study 鈴木啓修＠interdb.jp 2
改訂履歴
●
2014.5.31 ver1.1
●
2015.3.09 ver2.0 LSNの説明追加+ FPW(Full-Page-Writes)の説明を修正

目的
●
リカバリの原理を25分?30分で紹介
– リカバリ(recovery)=サーバクラッシュ後の復旧プロセス
– 物理バックアップと密接な関係
種本(ネタ元)
こちら　
講師
●
勉強会主催者の一人、種本の著者

i. データベースとテーブル
ii. データ操作
iii. WAL(Write Ahead Logging)
iv. CHECKPOINT
v.Full-Page-Writes
vi. オンラインバックアップ

/
$PG_DATA/
base/
1/
(template0)
12891/
(templete1)
12896/
(postgres)
16384/
(sampledb)
18740
(sampletbl)
Database Cluster
pg_xlog/ global/ .......
postgresql.conf
i. データベースとテーブル

/
$PG_DATA/
base/
1/
(template0)
12891/
(templete1)
12896/
(postgres)
16384/
(sampledb)
18740
(sampletbl)
Database Cluster
postgresql.conf
データベースとテーブル

/
$PG_DATA/
base/
1/
(template0)
12891/
(templete1)
12896/
(postgres)
16384/
(sampledb)
18740
(sampletbl)
Database Cluster
postgresql.conf
データベースとテーブル
XLogRecPtr TimeLineID pd_lower
pd_special
pd_pagesize_
version
pd_prune
_xid
１
Tuple 1

8192[byte]
XLogRecPtr TimeLineID pd_lower pd_upper
pd_special
pd_pagesize_
version
pd_prune
_xid
１
Tuple 1
Heap Tuples
(record data)
Header Info
Line Pointer
TABLE = FILE
1行のデータ

8192[byte]
pd_special
pd_pagesize_
version
pd_prune
_xid
１ 2
Tuple 1
Tuple 2
INSERT
PostgreSQLはデータを追加していきます。

8192[byte]
pd_special
pd_pagesize_
version
pd_prune
_xid
１ 2
Tuple 1 AAAAAAAAAAAAABBBBBBBBBBBB
Tuple 2 BBB
INSERT
sampledb=# SELECT *
FROM sampletbl;
id | data
----+------------
1 | AAAAAAAAAA
2 | BBBBBBBBBB
(2 rows)

8192[byte]
pd_special
pd_pagesize_
version
pd_prune
_xid
１ 2
Tuple 1 AAAAAAAAAAAAABBBBBBBBBBBB
Tuple 2 BBB
INSERT
$ od -c data/base/16384/18740
0000000 0 0 0 0 324 V 022 002 001 0 0 0 0 260 037
0000020 0 004 0 0 0 0 330 237 N 0 260 237 N 0
*
0017660 4 * 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0017700 002 0 002 0 002 t 030 0 002 0 0 0 027 B B B
0017720 B B B B B B B 0 3 * 0 0 0 0 0 0
0017740 0 0 0 0 0 0 0 0 001 0 002 0 002 t 030 0
0017760 001 0 0 0 027 A A A A A A A A A A 0
0020000
sampledb=# SELECT *
FROM sampletbl;
id | data
----+------------
1 | AAAAAAAAAA
2 | BBBBBBBBBB
(2 rows)

8192[byte]
pd_special
pd_pagesize_
version
pd_prune
_xid
１ 2
Tuple 1
Tuple 2
3
Tuple 3
UPDATE
PostgreSQLはUPDATEでも追加します
MVCC (多版型同時実行制御)の一種

8192[byte]
pd_special
pd_pagesize_
version
pd_prune
_xid
１ 2
Tuple 1 AAAAAAAAAAAA
Tuple 2 BBB
3
Tuple 3 CCCCCCC
BBBBBBBBB
CCCCCC
UPDATE
PostgreSQLはUPDATEでも追加します
MVCC (多版型同時実行制御)の一種
sampledb=# UPDATE sampletbl
SET data='CCCCCCCCCC'
WHERE id = 1;
sampledb=# SELECT *
FROM sampletbl;
id | data
----+------------
2 | BBBBBBBBBB
1 | CCCCCCCCC
(2 rows)

8192[byte]
pd_special
pd_pagesize_
version
pd_prune
_xid
１ 2
Tuple 1
Tuple 2
3
Tuple 3
データが増えたら
8192[byte]
pd_special
pd_pagesize_
version
pd_prune
_xid
１
Tuple 4
ブロック追加

ここまでのまとめ
●
1テーブル　＝　1ファイル
●
ファイルは8[kbyte]単位
足りなくなったら8[kbyte]づつ追加
●
データをどんどん、追加していく
INSERTだけでなく、　UPDATEも

ii. データ操作
ブロック (block)
or
ページ (page)

データ操作
begin;
UPDATE ...;
(共有)メモリに読み込んで操作する
ページ (page)
ブロック (block)
or
ページ (page)

データ操作
begin;
UPDATE ...;
commit;

データ操作
begin;
...;
commit;
HDDに書き込むのは高コストなので
なるべく
メモリ上で操作

データ操作
begin;
...;
commit;
なるべく

データ操作
OS or Postgres
クラッシュ
なるべく

OS or Postgres
クラッシュ
データ操作
まずい！
更新データが消えた
Orz

iii. WAL (Write Ahead Logging)
耐障害性を高める
先に変化分だけHDDに書いて(logging)
ページ本体は後からHDDに書く

WAL (Write Ahead Logging)
●
論理的に超長いファイルを想定
WAL つづく

●
●
物理的には16[Mbyte]のファイルの集合
WAL
1つのWALセグメント
16[Mbyte]
16[Mbyte]
つづく

●
●
WAL
16[Mbyte]
16[Mbyte]
つづく
単調増加の番地(LSN=Log Sequential Number)がある

●
●
●
差分データをWALセグメントに書く
WAL
16[Mbyte]
16[Mbyte]
つづく

●
●
●
差分データをWALセグメントに書く
差分データ≒ (追加したデータ) ≒ (基本情報)+(更新データ)
基本情報＝誤り訂正符号, INSERTかUPDATEかなど
WAL
16[Mbyte]
16[Mbyte]
つづく

$PG_DATA/
base/
1/
(template0)
12891/
(templete1)
12896/
(postgres)
16384/
(sampledb)
18740
WAL
順次書き込む
WALセグメントの実体はここ↓
# ls -la
total 131084
drwx------ 3 postgres postgres 4096 Apr 23 19:16 .
drwx------ 16 postgres postgres 4096 Apr 21 03:30 ..
-rw------- 1 postgres postgres 16777216 Apr 26 12:41 00000001000000000000000C
-rw------- 1 postgres postgres 16777216 Apr 23 19:02 00000001000000000000000D
-rw------- 1 postgres postgres 16777216 Apr 23 19:03 00000001000000000000000E
-rw------- 1 postgres postgres 16777216 Apr 23 19:03 00000001000000000000000F
-rw------- 1 postgres postgres 16777216 Apr 23 19:05 000000010000000000000010
drwx------ 2 postgres postgres 4096 Apr 23 19:16 archive_status

FAQ: HDD上のWALに書いたら
遅いんじゃないの？
HDDに分散して配置された
8[kbyte]のblockを書く

WAL
16[Mbyte]のWALセグメントに
必要な分だけ、シーケンシャルに書く

頑健性と性能を総合評価
WAL

WAL
SSDとかRAIDとか
FileSystemのブロックサイズとか
面倒な話は忘れるように

ということで

データ操作
(WALあり)
WAL
begin;
UPDATE ...;
LSN_1
これから書き込む
番地はLSN_1
LSN_0
LSN_0

データ操作
(WALあり)
WAL
begin;
UPDATE ...;
LSN_1
LSN_0
LSN_0
直前に書き込んだ
番地LSN_0は
headerに保存

データ操作
(WALあり)
WAL
begin;
UPDATE ...;
LSN_1
LSN_0
LSN_0
直前に書き込んだ
番地LSN_0は
headerに保存
理由はすぐに説明するので
ここでは”そういうもの”と...

データ操作
(WALあり)
WAL
begin;
UPDATE ...;
commit;
同期書き込み
commit時に
LSN_0
LSN_0
LSN_1

データ操作
(WALあり)
WAL
begin;
UPDATE ...;
commit;
LSN_0からLSN_1に書き換え
LSN_0
LSN_1
LSN_1

データ操作
(WALあり)
WAL
begin;
...
LSN_1 < LSN_2
LSN_0
LSN_1 LSN_1

データ操作
(WALあり)
WAL
begin;
...
commit;
同期書き込み
commit時に
LSN_1
LSN_0
LSN_1 LSN_2
LSN_2

データ操作
(WALあり)
WAL
begin;
...
commit;
同期書き込み
LSN_1 LSN_2
LSN_0
LSN_1 LSN_2LSN_1 LSN_3
LSN_3

データ操作
(WALあり)
WAL
begin;
...
commit;
同期書き込み
LSN_1 LSN_2 LSN_3
LSN_0
LSN_0 LSN_2 LSN_3 LSN_4

データ操作
(WALあり)
WAL
OS or Postgres
クラッシュ
LSN_0

リカバリ
サーバを再起動
WAL
LSN_0

リカバリ
リカバリ-フェーズ
WAL
LSN_0
LSN_0

リカバリ
WAL
LSN_0
LSN_0
ページのLSN(LSN_0)と
WALデータのLSN(LSN_1)を比較

リカバリ
WAL
LSN_0
LSN_1
ページのLSN(LSN_0) < WALデータのLSN(LSN_1)
なのでREDOする

リカバリ
WAL
LSN_0
LSN_1
ページのLSN < WALデータのLSN　　ならばREDO
ページのLSN >= WALデータのLSN　　ならば何もしない

リカバリ
WAL
LSN_0
LSN_1 LSN_1
LSN_1 < LSN_2なのでREDO

リカバリ
WAL
LSN_0
LSN_1 LSN_2
そして

リカバリ
WAL
LSN_0
LSN_1 LSN_2 LSN_3
そして

リカバリ
WAL
LSN_0
そして

リカバリ完了
稼働-フェーズへ
WAL
LSN_4
LSN_4

リカバリ完了
WAL
トランザクションの実行記録なので
Transaction LOG
再実行してリカバリするから
REDO LOG

ちょっと待てよ?

Question.
”どこから”
リカバリを
始めるんだ？

Answer.
CHECKPOINTの
開始点から
(REDO point)

iv. CHECKPOINT
周期的にメモリ上のデータをHDDに書き込む

CHECKPOINT
そもそも
メモリ上の(更新された)ページは
周期的に
HDDに書き込まなければ
ならない

CHECKPOINT
●
周期的(default:5min)にメモリ上の(更新された)ペー
ジをHDDに書き込む
●
CHECKPOINTの開始直後の位置=REDO point

CHECKPOINT
●
●
CHECKPOINTが完了すれば
(少なくとも)REDO point以前のデータはHDDに反映されてる。
→ REDO point以前のことは気にしなくてよい

CHECKPOINT
●
●
CHECKPOINTが完了すれば
(少なくとも)REDO point以前のデータはHDDに反映されてる。
→ REDO point以前のことは気にしなくてよい
●
Fuzzy CHECKPOINT
●
LOCK不要
– CHECKPOINT実行中も更新可能

Fuzzy CHECKPOINT
WAL
begin;
UPDATE ...;
commit;
同期書き込み
LSN_1
LSN_0
LSN_1

Fuzzy CHECKPOINT
WAL
CHECKPOINT
開始
LSN_1
LSN_0
LSN_1

Fuzzy CHECKPOINT
WAL
REDO point
CHECKPOINT開始直後
のWALの書き込み位置
CHECKPOINT
開始
LSN_1
LSN_0
LSN_1

Fuzzy CHECKPOINT
WAL
REDO point
CHECKPOINT
開始
ちょっとややこしいやり方でちょっとややこしいやり方で
HDDHDDののpg_controlpg_control
に記録。に記録。
今回は説明略今回は説明略
詳細は種本で詳細は種本で (^_^;(^_^;
ちょっとややこしいやり方でちょっとややこしいやり方で
HDDHDDののpg_controlpg_control
に記録。に記録。
今回は説明略今回は説明略
詳細は種本で詳細は種本で (^_^;(^_^;LSN_1
LSN_0
LSN_1

Fuzzy CHECKPOINT
WAL
REDO point
CHECKPOINT完了までに
(更新された)ページを必ずHDDに書き込む
CHECKPOINT
開始
何時、書き込まれるかは分からない
LSN_1
LSN_0
LSN_1
LSN_1

Fuzzy CHECKPOINT
WAL
CHECKPOINT
実行中
OR
LSN_1
LSN_1 LSN_2
LSN_2
LSN_1 LSN_2

Fuzzy CHECKPOINT
WAL
CHECKPOINT
完了
OR OR
CHECKPOINT実行中も
更新可能
LSN_1
LSN_1
LSN_2
LSN_2 LSN_3
LSN_3
LSN_1 LSN_2 LSN_3

Fuzzy CHECKPOINT
WAL
CHECKPOINT
完了
OR OR
CHECKPOINT実行中も
更新可能
LSN_1
LSN_1
LSN_2
LSN_2 LSN_3
LSN_3
LSN_1 LSN_2 LSN_3
そのかわり
どのタイミングで
HDDに書き込まれるか
分からない

Fuzzy CHECKPOINT
WAL
OR OR
LSN_1
LSN_1
LSN_2
LSN_2 LSN_3
LSN_3
LSN_1 LSN_2 LSN_3
LSN_4
LSN_4

Fuzzy CHECKPOINT
WAL
OR OR
LSN_1 LSN_2 LSN_3
LSN_1 LSN_2 LSN_3
LSN_4
LSN_4OS or Postgres
クラッシュ

リカバリ
WAL
リカバリは
REDO point
から
OR OR
LSN_1 LSN_2 LSN_3

リカバリ
WAL
リカバリは
REDO point
から
OR OR
? ページの状態は
直前のCHECKPOINTの
タイミング次第
LSN_1 LSN_2 LSN_3

リカバリ
WAL
リカバリは
REDO point
から
ページの状態は
直前のCHECKPOINTの
タイミング次第
今回はLSN_2　のときに
書き込まれたと仮定
LSN_2
LSN_2

リカバリ
WAL
リカバリは
REDO point
から
LSN_2 LSN_2

リカバリ
WAL
リカバリは
REDO point
から
LSN_2 LSN_2
LSNが同じなので
REDOしない

リカバリ
WAL
LSN_2 LSN_2
LSNが同じなので
REDOしない
REDOしたらマズい！
(普通の)WALデータの
REDO操作は
“ベキ等でない”から

リカバリ
WAL
LSN_2 LSN_2 LSN2 < LSN_3
なので
REDOする
LSN_2

リカバリ
WAL
LSN_2 LSN2 < LSN_3
なので
REDOする
LSN_2 LSN_2

リカバリ
WAL
LSN_2 LSN2 < LSN_3
なので
REDOする
そして
LSN_3書き換え
LSN_2 LSN_3

リカバリ
WAL
LSN_2
同様に
REDOして
LSN書き換え
LSN_2 LSN_3 LSN_4

リカバリ完了
WAL
LSN_4

リカバリ完了
WAL
(原理的には)
CHECKPOINT間の変更分だけ
書き込めるWALセグメントがあればよい

ちょいと脇道へ
初見時は
vi.オンラインバックアップ
まで飛ばしてもOK

v. Full-Page-Writes
●
WALでリカバリ可能
●
全ページ正常で、常に完璧にREDOできることが前提

v. Full-Page-Writes
●
●
– もしもページが壊れたら？

v. Full-Page-Writes
●
●
●
こんなこともあろうかと

v. Full-Page-Writes
●
●
●
こんなこともあろうかと Full-Page-Writes

v. Full-Page-Writes
●
●
●
●
Full-Page-Writes：
– Checkpoint直後は(差分でなく)ページ全体をWALに
書き込む

v. Full-Page-Writes
●
●
●
●
Full-Page-Writes：
書き込む
– PostgreSQLはデフォルトで有効

v. Full-Page-Writes
●
●
●
●
Full-Page-Writes：
書き込む
– PostgreSQLはデフォルトで有効
●
実例で機能を確認！

Full-Page-Writes
WAL
begin;
UPDATE ...;
commit;
同期書き込み
LSN_1
LSN_0
LSN_1
Full-Page-Writesの威力を示すため、
クリティカルなトラブルを起こしてみる

Full-Page-Writes
WAL
CHECKPOINT
開始
LSN_1
LSN_0
LSN_1

Full-Page-Writes
WAL
CHECKPOINT
実行中
OR
LSN_1
LSN_1 LSN_2
LSN_2
LSN_1 LSN_2

Full-Page-Writes
WAL
CHECKPOINT
実行中
OR
LSN_1
LSN_1 LSN_2
LSN_2
LSN_1 LSN_2
Checkpoint直後は
ページデータ全体
を書き込む

Full-Page-Writes
WAL
CHECKPOINT
実行中
OR
LSN_1
LSN_1 LSN_2
LSN_2
LSN_1 LSN_2
Checkpoint直後は
ページデータ全体
を書き込む
バックアップブロック
(BackupBlock)
と呼びます

Full-Page-Writes
WAL
CHECKPOINT
実行中
OR
LSN_1
LSN_1 LSN_2
LSN_2
LSN_1 LSN_2
OR
LSN_3
LSN_3
LSN_3

Full-Page-Writes
WAL
OR
LSN_1
LSN_1 LSN_2
LSN_2
LSN_1 LSN_2
OR
LSN_3
LSN_3
LSN_3
LSN_4
LSN_4

Full-Page-Writes
WAL
LSN_1
LSN_1 LSN_2
LSN_2
LSN_3
LSN_3 LSN_4
LSN_4
LSN_4
BackgroundWriterが
このページを....
Full-Page-Writesの威力を示すため

Full-Page-Writes
WAL
BackgroundWriterが
このページを
書いてる最中に
クラッシュ！！！
OS or Postgres
クラッシュ

Full-Page-Writes
WAL
BackgroundWriterが
このページを
書いてる最中に
クラッシュ！！！
OS or Postgres
クラッシュ
データ書き込み中にクラッシュ
したので、
データがおかしい orz

こんな状態でリカバリーできるの？

できるんです

リカバリ
WAL
リカバリは
REDO point
から

リカバリ
WAL
バックアップブロックだから
LSNに関わらず上書きする

リカバリ
WAL
LSN_2
データロストした
ページが直ったぞ！！！

リカバリ
WAL
LSN_2
データロストした
ページが直ったぞ！！！
Full-Page-Writes
スゲー

リカバリ完了
あとは、粛々とリカバリを続ける也
WAL
LSN_3 LSN_4
LSN_4
LSN_2

というわけで、
Full-Page-Writesで
(各checkpoint直後に)バックアップブロックを
書き込んでおけば
かなり頑健になる

さて、
最後のトピック
vi. オンラインバックアップについて

CHECKPOINTを実行しておけば

WALを使って
リカバリできる
(HDDが正常であれば)

HDD上に最新データがなくても
WALを使って
リカバリできる
(HDDが正常であれば)

もしかして？

うまいことやれば、
オンラインバックアップ
できる？
稼働中に
データを
バックアップ

はい、できます。
稼働中に
データを
バックアップ

PostgreSQLはLockなしで
オンラインバックアップできます(論理も物理も)。
稼働中に
データを
バックアップ
論理：INSERT文のリスト, CSV, etc..
物理：ファイルそのもの

v. オンラインバックアップ
WAL
DBMSを稼働したまま
物理バックアップをつくる

(1) CHECKPOINTから始める
WAL
開始
最初に
CHECKPOINT
実行
backup_label
CHECKPOINTの情報などが書き込まれている。
後からREDOpointを知るために使う。

(2) テーブルファイルをCOPY
WAL
開始
テーブルファイルを
コピー
最初に
CHECKPOINT
実行
コピーに時間がかかっても大丈夫
backup_label

FILE COPY
0:00
0:00
0:00
0:00copy
実際のデータベースには
多数のテーブル(FILE)があり、巨大なものもある。

FILE COPY
1:00
1:00
1:00
1:00
0:00
copyに1時間

FILE COPY
1:01
1:01
1:01
1:00
0:00
1:01今、copy終了

FILE COPY
1:01
1:01
1:01
1:00
0:00
1:01
時間差
Snapshot
じゃないけど
OK

(3) COPY中もデータ操作可能
WAL
開始
テーブルファイルを
コピー
(backup_labelも)
最初に
CHECKPOINT
実行
コピーに時間がかかっても大丈夫
OR OR OR
backup_label
backup_label

(4) 最後に WALをCOPY
WAL
WAL
WALを
コピー
OR OR OR
backup_label

(4) 最後に WALをCOPY
WAL
WAL
WALを
コピー
OR OR OR
backup_label
注意：pg_xlog/以下のWALセグメントは短時間で消されるので、
　アーカイブログ(Archiving Logging)の設定をして
　別のディレクトリに保存し、それらもCOPYしませう

バックアップデータからDB起動
初期状態
WAL
OR OR OR
backup_label

WAL
?
OR OR OR

WAL
?

リカバリ-フェーズ完了 → 稼働！
稼働-フェーズ
WAL
?

まとめ
リカバリの原理は単純にして巧妙
WALにREDOログ(CHECKPOINT直後はページ)を書く
– もう、ジムグレイのトランザクション本：9?11章がスラスラ分かる！はず
実際に使うには
利点だけでなく、短所や限界も把握しませう

Appendix 1

今回、省略したこと
WALの書き込みタイミングは3種類
1. COMMITと同時（今回説明）
2. 大量更新でWALバッファがあふれたとき
3. 周期的にWAL writerが書き込む
変更されたページ(dirtyページ)の書き込みタイミングは3種類
1. CHECKPOINT(今回説明)
① CHECKPOINTERが周期的に実行(今回説明)
② CHECKPOINTコマンド実行時
③ WALバッファへの書き込みがcheckpoint_segmentsを超えたとき
④ pg_start_backup()関数実行時
⑤ PostgreSQL正常終了時
2. 共有メモリが一杯で、ページを入れ替えるとき
3. バックグランドライタが少しづつ書き込む

Appendix 2

1: 更新がなかったら？
WAL
これはどうなる？

1: 更新がなかったら？
WAL
CHECKPOINT

2: CHECKPOINTが失敗したら?
WAL
CHECKPOINT
実行中
OS or Postgres
クラッシュ

一つ前のREDO pointからリカバリ
WAL
CHECKPOINT
失敗
OS or Postgres
クラッシュ
CHECKPOINT
成功
?
OROR

WAL
CHECKPOINT
成功
CHECKPOINT
失敗
?

狠狠撸

笔辞蝉迟驳谤别厂蚕尝のリカバリ超入门(もしくは奥础尝、颁贬贰颁碍笔翱滨狈罢、オンラインバックアップの仕组み)

More Related Content

笔辞蝉迟驳谤别厂蚕尝のリカバリ超入门(もしくは奥础尝、颁贬贰颁碍笔翱滨狈罢、オンラインバックアップの仕组み)