db tech showcase Tokyo 2016で使用した資料ですが、発表後に頂戴したコメントなどを参考に内容を一部修正しています。（大枠の骨子に変更はありません）

1. 1
バックアップと障害復旧から考える
Oracle Database, MySQL,
PostgreSQLの違い
2016年7月15日
Japan Oracle User Group 渡部 亮太

2. 2
自己紹介+所属会社紹介
• 渡部 亮太（わたべ りょうた）
– JPOUG 共同創設者、ボードメンバー
– Oracle ACE
– 著書「プロとしてのOracleアーキテクチャ入門
[第2版]」 「プロとしてのOracle運用管理入門」
– ブログ「コーソルDatabaseエンジニアのBlog」
http://cosol.jp/techdb/
• 株式会社コーソル
– 「CO-Solutions＝共に解決する」の理念のもと、Oracle技術に特
化した事業を展開中。心あるサービスの提供とデータベースエン
ジニアの育成に注力している
– 社員数: 131名 (2016年7月時点)
– ORACLE MASTER Platinum 11g 取得者数 45名
ORACLE MASTER Platinum 12c 取得者数 28名
（現時点でおそらく）取得者数 日本 No.1

3. 3
What's JPOUG?
• オラクルという単語を中心とした共通のコンテキストで話せる
みんなが交流するイベントを開催しています
• https://jpoug.doorkeeper.jp/ へご登録いただくと
今後のイベント情報をお送りできます

4. 4
【告知】 JPOUGイベントやります！
9月12日(月) 19:00-20:30
JPOUG in 15 minutes #1
15分間のショートセッションを5コマ程度
聴講希望
http://bit.ly/in15m1
講演希望
http://bit.ly/JPOUG16SE

5. 5
本セミナーについて
• バックアップと障害復旧の考え方や手順の違いから、 Oracle
Database、MySQL、PostgreSQL これら3つのRDBMSのアー
キテクチャや設計思想などを比較してみます
• 皆さんの日々の業務の助けになるかはわかりませんが、もしか
するとそれぞれのRDBMSに関する理解が深まるかもしれませ
ん
• ゆるい感じで楽しんでいただければ幸いです
• 質問は随時Welcomeです。質疑応答が盛り上がったほうが、
みんなの理解が深まるはず！
• バックアップの取得方法としては、運用中にバックアップを取得する、
いわゆる「ホットバックアップ」を前提とします
• Oracle Databaseについては、バックアップにRMANを使用すると仮
定します
• MySQLについては、Community Edition、InnoDBを使用している
と仮定します

6. 6
Agenda
1. 前提知識：RDBMSのバックアップと復旧について
2. バックアップ周辺の各RDBMS製品アーキテクチャ
3. 一般的なモデルとしてのOracle Databaseのバック
アップと復旧
4. バックアップの非一貫性を許容しないMySQL
5. 昔のOracle Databaseにかなり似ている
PostgreSQLのバックアップと復旧

7. 7
前提知識：RDBMSの
バックアップと復旧について

8. 8
一般的なRDBMSのバックアップと復旧の特徴
• DB起動中にバックアップを取得できる
（ホットバックアップ）
• リストア（バックアップの戻し）後に、リカバリを実行する
ことで、障害発生直前の状態に復旧できる
障害
20:00相当
の状態
トランザクションログ適用
によるデータベースの更新
23:00相当
の状態
トランザクション
ログファイル
20:00 23:0023:00
トランザクションログファイルに
記録された20:00～23:00相当の
更新を適用
20:00
ファイルを
コピー
20:00時点の
バックアップ
バックアップ
で上書き
1. バックアップ 2. 障害発生 3. リストア 4. リカバリ
更
新

9. 9
リカバリ機能の重要性
• リカバリ機能がないと、障害発生時にバックアップ取得
時点の状態にしか復旧できない
• バックアップ取得時点～障害発生時点の間に実行された
更新はすべて失われる
障害
20:00相当
の状態
23:0020:00
ファイルを
コピー
20:00時点の
バックアップ
バックアップ
で上書き
1. バックアップ 2. 障害発生 3. リストア
更
新
20:00～23:00に実行された
更新はすべて失われる

10. 10
トランザクションログがリカバリの肝
• データを更新すると、2種類の
ファイルが更新される
a. データファイルの古いデータを新
しいデータで上書き更新
b. トランザクションログファイルに
更新記録を追記書き込み
RDBMS
データファイル
UPDATE tab0 SET col1 = 'B'
WHERE col1 = 'A';
UPDATE tab0 SET col1 = 'Y'
WHERE col1 = 'X';
COMMIT;
トランザクション
ログファイル
Y
更新済み
ブロック X→Y
B A→B
トランザクション
ログ
B
Y A→B
X→Y トランザクションログファイルに記録さ
れた更新記録を元にリカバリ処理を実行

11. 11
バックアップ周辺の
各RDBMS製品アーキテクチャ

12. 12
教科書的なRDBMSのアーキテクチャ
データファイル
トランザクション
ログファイル
更新済み
ブロック
X→Y
A→B
トランザクション
ログ
B
Y
A→B
X→Y
YB
A→B
データキャッシュ
RDBMS
インスタンス
UPDATE tab0 SET col1='B' WHERE col1='A';
UPDATE tab0 SET col1='Y' WHERE col1='X';
COMMIT;
・・・
X→Y
データファイルのブロックは
メモリ上にキャッシュされる
更新された
ブロックは
適宜データ
ファイルに
書き込まれる
更新記録（トランザク
ションログ）はトランザ
クションログファイルに
書き込まれる
リカバリ実行時に一連の更新処理を再実行する
ため、バックアップ取得後からの一連のトラン
ザクションログファイルを保管する必要がある

13. 13
Oracle Databaseのアーキテクチャ
データファイル
更新済み
ブロック
B
Y
YB
A→B
データベースバッファキャッシュ
Oracle
インスタンス
UPDATE tab0 SET col1='B' WHERE col1='A';
UPDATE tab0 SET col1='Y' WHERE col1='X';
COMMIT;
X→Y
X→Y
A→B
REDO
ログ
アーカイブ
REDO
ログファイル
オンライン
REDO
ログファイルA→B
X→Y
更新記録（REDOログ）
はオンラインREDOログ
ファイルに循環書き込
みされる
循環書き込みによって
上書きされる前にファ
イル内のREDOログをコ
ピーしてアーカイブ
REDOログを出力する
Oracle

14. 14
PostgreSQLのアーキテクチャ
データファイル
更新済み
ブロック
B
Y
YB
A→B
共有バッファ
PostgreSQL
インスタンス
UPDATE tab0 SET col1='B' WHERE col1='A';
UPDATE tab0 SET col1='Y' WHERE col1='X';
COMMIT;
X→Y
WALログ
ファイル
X→Y
A→B
WAL
ログ
A→B
X→Y
アーカイブ
された
WAL
ログファイル
…010 …011 …012
更新記録（WALログ）を書
き込むWALログファイルは
連番で順次生成される
古いWALログファイルを
別の場所にコピー（アーカ
イブ）する仕組みがある
・・・
PostgreSQL

15. 15
MySQL(InnoDB)のアーキテクチャ
データファイル
バイナリログ
ファイル
更新済み
ブロック
X→Y
A→B
イベント
（更新系SQL)
B
Y
A→B
X→Y
YB
A→B
InnoDBバッファプール
mysqld
プロセス
UPDATE tab0 SET col1='B' WHERE col1='A';
UPDATE tab0 SET col1='Y' WHERE col1='X';
COMMIT;
…-bin.
…10
InnoDB
ログファイル
A→B
X→Y
…-bin.
…11
…-bin.
…12
X→Y
A→B
REDOログ
・・・
X→Y
更新系SQL（イベント）を書
き込むバイナリログファイ
ルは連番で順次生成される
REDOログは
InnoDBログファ
イルに循環書き
込みされる
MySQL

16. 16
一般的なモデルとしての
Oracle Databaseの
バックアップと復旧

17. 17
Oracle Databaseのバックアップと復旧の特徴
• 運用モードがアーカイブログモードであれば、DB起動中
にバックアップを取得できる（ホットバックアップ）
• リストア（バックアップの戻し）後に、リカバリを実行する
ことで、障害発生直前の状態に復旧できる
障害
20:00相当
の状態
更新 +
一貫性の回復
23:00相当
の状態
アーカイブREDO
ログファイル
20:00 23:0023:00
REDOに記録
された更新
を適用
20:00
ファイルを
コピー
オンラインREDO
ログファイル20:00時点の
バックアップ
バックアップ
で上書き
REDOに記録
された更新
を適用
1. バックアップ 2. 障害発生 3. リストア 4. リカバリ
更
新
rman>
backup
database;
rman>
restore
database;
rman>
recover
database;
Oracle

18. 18
リカバリ処理の目的
• バックアップ取得時点～障害発生直前までにデータベー
スに加えられた更新処理を（再）実行する
• 一貫性を回復する
– データベース起動中に取得したバックアップは一貫性が取れてい
ない状態。リカバリ処理により一貫性を回復する
障害
更新 +
一貫性の回復
アーカイブREDO
ログファイル
REDOに記録
された更新
を適用
ファイルを
コピー
オンラインREDO
ログファイルバックアップ
バックアップ
で上書き
REDOに記録
された更新
を適用
1. バックアップ 2. 障害発生 3. リストア 4. リカバリ
更
新
rman>
backup
database;
rman>
restore
database;
rman>
recover
database;
一貫性が
取れていない
状態
一貫性が
取れている
状態
※：UNDOを使用した
更新の取り消しも
実行される
Oracle

19. 19
起動中に取得したバックアップの特徴
データファイル
更新済み
ブロック
B
X
B
B
A→B X→Y
Y
データベースバッファキャッシュ
UPDATE tab0 SET col1='Y' WHERE col1='X';
COMMIT;
UPDATE tab0 SET col1='B' WHERE col1='A';
(COMMIT未実行)
データファイルの
バックアップ
B
X
Bへの変更がファイルに反映さ
れているが、COMMIT未実行
であるため、更新が取り消さ
れ、Aになる可能性がある
COMMIT実行済みで
あるため、Yへの変
更は確定しているが、
ファイルに反映され
ていない
バックアップ
Oracle

20. 20
まとめ バックアップと復旧と一貫性の関係
• Oracle Databaseは起動中にバックアップを取得できる
が、バックアップは一貫性が取れていない状態
• 復旧では、バックアップを戻すリストア処理と、バック
アップ取得後に実行された更新処理を適用するリカバリ
処理を実行する
• リカバリ処理は、一貫性が取れていない状態である起動
中に取得したバックアップを、一貫性が取れた状態にす
る機能をもつ
• リストアとリカバリを実行することで、障害発生直前の
一貫性が取れた状態に復旧できる
Oracle

21. 21
バックアップの非一貫性を許容しない
MySQL

22. 22
MySQLのバックアップと復旧の概要
• エクスポートツール mysqldumpを用いて、ある時点に
おいて一貫性を持つバックアップを取得する
• バイナリログを用いてリカバリを実行すると、ある時点
以降に実行された更新系SQLを再実行することで、障害
発生直前の状態に復旧できる
障害
20:00相当
の状態
更新
23:00相当
の状態
バイナリログ
ファイル
20:00 23:0023:00
バイナリログファイル
に記録された
更新系SQLを再実行
20:00
データの
エクスポート
20:00時点の
エクスポート
データ
データを
インポート
1. バックアップ 2. 障害発生 3. リストア 4. リカバリ
更
新
mysqldump
mysqlbinlog
要一貫性
MySQL

23. 23
UPDATE ...
INSERT ...
DELETE ...
MySQLのバックアップと復旧における一貫性
• MySQLのリカバリ処理には一貫性を回復
する機能がない
– MySQLにおけるリカバリ処理の実体は「更新
系SQLの再実行」
– 当然だが、SQLでできること範囲のことしか
できない。もちろんデータベースの一貫性を
回復することはできない
• ある時点において一貫性を持つバック
アップを取得する必要がある
– リカバリ処理の制限から導かれる帰結
– エクスポートツールmysqldumpを使用する
場合、--single-transactionオプションを指
定してデータをエクスポートする
UPDATE ...
INSERT ...
CREATE TABLE ...
UPDATE ...
INSERT ...
CREATE TABLE ...
バイナリログファイル
データの
エクスポート
mysqldump
--single-
transaction
(ある時点における
一貫性を持つ)
エクスポートデータ
※MySQL Enterprise EditionであればEnterprise backup、3rd Partyツールでは
Percona Xtra Backupをmysqldumpの代替ツールとして使用できるが、一貫性を持つ
バックアップを取得する必要がある点は変わらない
要一貫性
※SQLそのものがバイナリログに記録されるかどうかはbinlog_formatの設定に依存
MySQL

24. 24
ログポジションと一貫性の関係
• --single-transactionオプションを指定したmysqldump
で、ある時点において一貫性を持つバックアップを取得
できる(InnoDBの読み取り一貫性を使用)
• バイナリログを用いたリカバリでは、ある時点以降に実
行された更新系SQLを再実行する
• MySQLでは、上記の「ある時点」をバイナリログファイ
ルのファイル名とファイル内のログポジションで示す
…-bin.
…10
…-bin.
…11
…-bin.
…12
バイナリログ
バックアップ
に対応した
ログ
ポジション
MySQL

25. 25
バックアップ、復旧におけるログポジション
障害
更新
障害発生
直前の状態
バイナリログファイル
に記録された
更新系SQLを再実行
データを
インポート
1. バックアップ 2. 障害発生 3. リストア 4. リカバリ
更新
mysqldump
--single-transaction
mysqlbinlog
--start-position <バックアッ
プに対応したログポジション>
…-bin.…12
…-bin.…13
…-bin.…14 | mysql
…-bin.
…10
…-bin.
…11
…-bin.
…12
バイナリログ
バックアップ
に対応した
ログ
ポジション
…-bin.
…10
…-bin.
…11
…-bin.
…12
バイナリログ
…-bin.
…13
…-bin.
…14
ログポジションに
対応する時点での
一貫性を持つ
バックアップ
取得時点の
状態
（一貫性あり）
※：リカバリ時のログポジション指定および運用をシンプル
にするため、バックアップ取得と同時にバイナリログを切り
替えるのが一般的な運用
→ リカバリで指定するログポジションがファイルの先頭にな
る
エクスポート
データ
MySQL

26. 26
InnoDBログファイルの用途は？
データファイル
バイナリログ
ファイル
更新済み
ブロック
X→Y
A→B
イベント
（更新系SQL)
B
Y
A→B
X→Y
YB
A→B
InnoDBバッファプール
mysqld
プロセス
UPDATE tab0 SET col1='B' WHERE col1='A';
UPDATE tab0 SET col1='Y' WHERE col1='X';
COMMIT;
…-bin.
…10
InnoDB
ログファイル
A→B
X→Y
…-bin.
…11
…-bin.
…12
X→Y
A→B
REDOログ
・・・
X→Y
MySQL
用途は？

27. 27
InnoDBログファイルの用途は？
• InnoDBログファイルはmysqldプロセスが異常終了した
ときにデータベースの一貫性を回復するために使用され
る（クラッシュリカバリ）
– バックアップリストア後のリカバリ処理（メディアリカバリ）はバイナリログの役割
一貫性の
回復
InnoDB
ログファイル
更新
を適用
1. 通常運用 2. プロセス
障害発生
3. 異常
停止後
4. MySQL起動→クラッシュリカバリ
更
新
mysqld mysqld
障害
一貫性が
取れていない
状態
バイナリ
ログファイル
InnoDB
ログファイル
mysqld
※：InnoDB UNDOログを使用した
更新の取り消しも実行される
MySQL

28. 28
Oracle Databaseエンジニアが抱きがちな疑問
• mysqldumpに--single-transactionを指定せず、一貫性の取れ
ていないバックアップを取得したら、復旧できるか？
→ リストア・リカバリ処理は問題なく実行できる
ただし、最終的に得られるデータはおそらく正しくない
• リカバリ時に誤ったバイナリログファイル、ログポジションを
指定したらどうなるか？
→ リカバリ処理そのものではエラーが発生しない
ただし、最終的に得られるデータはおそらく正しくない
• 論理バックアップの代わりに物理バックアップを取得すること
はできないか？
→ MySQL Enterprise BackupまたはPercona Xtra Backupを
つかえば一貫性のある物理バックアップを取得できる。
ただし、 MySQL Enterprise Backup はMySQL Enterprise Edition
でないと使用できないこと、 Percona Xtra Backupは3rd Partyツー
ルであることに注意
MySQL

29. 29
昔のOracle Databaseにかなり似ている
PostgreSQLのバックアップと復旧

30. 30
PostgreSQLのバックアップと復旧の流れ
• バックアップモード設定中に、データファイルをコピー
することでバックアップ
• リストア（バックアップの戻し）後に、リカバリを実行する
ことで、障害発生直前の状態に復旧できる
障害
20:00相当
の状態
一貫性の回復
＋更新
23:00相当
の状態
WALファイル
20:00 23:0023:00
WALファイルに
記録された更新
を適用
20:00
20:00時点の
バックアップ
バックアップ
で上書き
1. バックアップ 2. 障害発生 3. リストア 4. リカバリ
更
新
recovery
.conf
を配置
して起動
バックアップ
モード中に
ファイルを
コピー
PostgreSQL

31. 31
ベースバックアップの取得
• PostgreSQLではリカバリ処理を実行して障害発生直前の
状態に復旧できるバックアップを、ベースバックアップ
と呼ぶ
• ベースバックアップの取得手順
– 下記手順を一括で実行できるpg_basebackupコマンド(9.1-)、
pg_rman(非標準ツール)もある
バックアップ
1. バックアップ
モードON
2. ベースバックアップ
の取得
OSコマンドで
ファイルをコピー
3. バックアップ
モードOFF
SELECT
pg_start_backup('label');
SELECT
pg_stop_backup();
PostgreSQL

32. 32
ベースバックアップの状態とリカバリ処理
• PostgreSQLのベースバックアップは、Oracle Database
のホットバックアップと同様に、一貫性が取れていない
状態
– バックアップ取得時点で実行中であり、取得後に取り消された更
新SQLの更新が、ファイルが反映されている場合がある
– 完了した更新SQLの更新が、まだファイルに反映されていない場
合がある
• WALファイルを用いたリカバリ処理において一貫性を回
復する
• あわせて、バックアップ取得時点～障害発生直前までに
データベースに加えられた更新処理を（再）実行する
→ リカバリ処理の役割も、Oracle Databaseと同様
PostgreSQL

33. 33
分離ブロック：ホットバックアップ時の課題
• データベース起動中にバックアップを取得
→ データファイルの更新とバックアップ処理によるデータ
ファイル読み取りが同時に実行される可能性
→ ブロックのI/O単位とOSレベルのI/O単位が異なることに起
因して、分離ブロックが発生する可能性がある
• 分離ブロックは不正なブロックであるため、リカバリ時に修正
する必要がある
更新された
ブロック
データファイル バックアップされた
データファイル
バックアップ
（ファイルコピー）
更新前
更新後
分離ブロック
PostgreSQL
用途は？
同時実行に
よる干渉

34. 34
分離ブロック問題への対処
• バックアップモード中で更新済みバッファをデータファイルに書き込
む場合、WALファイルにも更新済みバッファを書き込む
→ リカバリ時の分離ブロック修正に使用
1. バックアップ
モードON
2. バックアップ
取得開始
バックアップ
（データファイル
のコピー）
3.バックアップ
取得完了
→ バックアップ
モードOFF
すべての更新済バッファ
をデータファイルに
一括書き込み
（チェックポイント）
バックアップモード中に
更新済バッファをデータ
ファイルに書き込む場合、
WALファイルにも更新済
みバッファを書き込む
x. ユーザー更新処理実行
共有バッファ
PostgreSQL
WAL
ファイル

35. 35
Oracle Databaseの分離ブロック対処
• RMANを用いてバックアップした場合、分離ブロックは
発生しない
– Oracle Database本体によるデータファイルの更新と競合しない
仕組みが実装されている
• RMANが導入される前のOracle Databaseでは
PostgreSQLと同様の仕組みで分離ブロックに対処してい
た
– バックアップモード中は更新済みバッファをオンラインREDOロ
グファイルに格納し、リカバリ時に分離ブロックを修正
Oracle

36. 36
おしまい
Thanks!