9/9(金) Database Lounge Tokyo #2にて使用した資料です。 db tech showaseの資料に若干の修正、スライドの追加をしています。

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

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

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起動中にバックアップを取得できる
（ホットバックアップ）
• リストア（バックアップの戻し）後に、リカバリを実行する
ことで、障害発生直前の状態に復旧できる
障害
00:00相当
の状態
トランザクションログ適用
によるデータベースの更新
12:00相当
の状態
トランザクション
ログファイル
00:00 12:0012:00
トランザクションログファイルに
記録された00:00～12:00相当の
更新を適用
00:00
ファイルを
コピー
00:00時点の
バックアップ
バックアップ
で上書き
1. バックアップ 2. 障害発生 3. リストア 4. リカバリ
更
新

9. 9
リカバリ機能の重要性
• リカバリ機能がないと、障害発生時にバックアップ取得
時点の状態にしか復旧できない
• バックアップ取得時点～障害発生時点の間に実行された
更新はすべて失われる
障害
00:00相当
の状態
12:0000:00
ファイルを
コピー
00:00時点の
バックアップ
バックアップ
で上書き
1. バックアップ 2. 障害発生 3. リストア
更
新
00:00～12: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起動中
にバックアップを取得できる（ホットバックアップ）
• リストア（バックアップの戻し）後に、リカバリを実行する
ことで、障害発生直前の状態に復旧できる
障害
00:00相当
の状態
更新 +
一貫性の回復
12:00相当
の状態
アーカイブREDO
ログファイル
00:00 12:0012:00
REDOに記録
された更新
を適用
00:00
ファイルを
コピー
オンラインREDO
ログファイル00: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を再実行することで、障害
発生直前の状態に復旧できる
障害
12:00相当
の状態
更新
12:00相当
の状態
バイナリログ
ファイル
00:00 12:0012:00
バイナリログファイル
に記録された
更新系SQLを再実行
00:00
データの
エクスポート
00: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のバックアップと復旧の流れ
• バックアップモード設定中に、データファイルをコピー
することでバックアップ
• リストア（バックアップの戻し）後に、リカバリを実行する
ことで、障害発生直前の状態に復旧できる
障害
00:00相当
の状態
一貫性の回復
＋更新
12:00相当
の状態
WALファイル
00:00 12:0012:00
WALファイルに
記録された更新
を適用
00:00
00: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!

37. 37
追加スライド

38. 38
増分バックアップ
• 前回のバックアップ以降に更新されたブロックのみを
バックアップする
更新された
ブロックのみ
をバックアップ
２. 差分増分
バックアップ
3. 差分増分
バックアップ
Oracle
更新された
ブロックのみ
をバックアップ
全体を
バックアップ
1.全体
バックアップ
4. 全体
バックアップ
更新された
ブロックのみ
をバックアップ
5. 差分増分
バックアップ
全体を
バックアップ
更
新

39. 39
増分バックアップを用いた復旧
Oracle
２. 差分増分
バックアップ
3. 差分増分
バックアップ
1.全体
バックアップ
更
新
更
新
更新
オンライン/アーカイブ
REDOログファイル
REDOに記録
された更新
を適用
障害

40. 40
増分更新バックアップによる復旧時間の短縮
Oracle
２. 差分増分
バックアップ
3. 差分増分
バックアップ
1.全体
バックアップ
更
新 更新
オンライン/アーカイブ
REDOログファイル
REDOに記録
された更新
を適用
障害