バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い

バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い

1. 1. 1 バックアップと障害復旧から考える Oracle Database, MySQL, PostgreSQLの違い 2016年7月15日 Japan Oracle User Group 渡部 亮太 現在作成中のため、当日発表までの間に修正される可能性があります
2. 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. 3 What's JPOUG? • オラクルという単語を中心とした共通のコンテキストで話せる みんなが交流するイベントを開催しています • https://jpoug.doorkeeper.jp/ へご登録いただくと 今後のイベント情報をお送りできます
4. 4. 4 【告知】 9月中旬 JPOUGイベントやります！ 仮題 JPOUG in 15 minutes 最大15分のセッションを複数コマ 講演希望者は http://bit.ly/JPOUG16SE からエントリをお願いします！
5. 5. 5 本セミナーについて • バックアップと障害復旧の考え方や手順の違いから、 Oracle Database、MySQL、PostgreSQL これら3つのRDBMSのアー キテクチャや設計思想などを比較してみます • 皆さんの日々の業務の助けになるかはわかりませんが、もしか するとそれぞれのRDBMSに関する理解が深まるかもしれませ ん • ゆるい感じで楽しんでいただければ幸いです • 質問は随時Welcomeです。質疑応答が盛り上がったほうが、 みんなの理解が深まるはず！ • バックアップの取得方法としては、運用中にバックアップを取得する、 いわゆる「ホットバックアップ」を前提とします • Oracle Databaseについては、バックアップにRMANを使用すると仮 定します • MySQLについては、Community Edition、InnoDBを使用している と仮定します
6. 6. 6 Agenda 1. 前提知識：RDBMSのバックアップと復旧について 2. バックアップ周辺の各RDBMS製品アーキテクチャ 3. 一般的なモデルとしてのOracle Databaseのバック アップと復旧 4. バックアップの非一貫性を許容しないMySQL 5. 昔のOracle Databaseにかなり似ている PostgreSQLのバックアップと復旧
7. 7. 7 前提知識：RDBMSの バックアップと復旧について
8. 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. 9 リカバリ機能の重要性 • リカバリ機能がないと、障害発生時にバックアップ取得 時点の状態にしか復旧できない • バックアップ取得時点～障害発生時点の間に実行された 更新はすべて失われる 障害 20:00相当 の状態 23:0020:00 ファイルを コピー 20:00時点の バックアップ バックアップ で上書き 1. バックアップ 2. 障害発生 3. リストア 更 新 20:00～23:00に実行された 更新はすべて失われる
10. 10. 10 トランザクションログがリカバリの肝 • データを更新すると、2種類の ファイルが更新される 1. データファイルの古いデータを新 しいデータで上書き更新 2. トランザクションログファイルに 更新記録を追記書き込み 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. 11 バックアップ周辺の 各RDBMS製品アーキテクチャ
12. 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. 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. 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. 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. 16 一般的なモデルとしての Oracle Databaseの バックアップと復旧
17. 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. 18 RMANによるバックアップの取得 • RMAN： Oracle Databaseに含まれるバックアップ取得 および管理ツール • バックアップの取得例 • 非常に簡単 – データベースを構成するファイルを自動的に認識 – 手順がシンプル。基本的なバックアップであれば、backup databaseコマンドのみでOK $ rman TARGET / Recovery Manager: Release 12.1.0.2.0 - Production on 月 4月 20 13:57:43 2015 ： RMAN> backup database; backupが開始されました(開始時間: 15-04-20) : backupが完了しました(完了時間: 15-04-20) RMAN> Oracle
19. 19. 19 リカバリ処理の目的 • バックアップ取得時点～障害発生直前までにデータベー スに加えられた更新処理を（再）実行する • 一貫性を回復する – データベース起動中に取得したバックアップは一貫性が取れてい ない状態。リカバリ処理により一貫性を回復する 障害 更新 + 一貫性の回復 アーカイブREDO ログファイル REDOに記録 された更新 を適用 ファイルを コピー オンラインREDO ログファイルバックアップ バックアップ で上書き REDOに記録 された更新 を適用 1. バックアップ 2. 障害発生 3. リストア 4. リカバリ 更 新 rman> backup database; rman> restore database; rman> recover database; 一貫性が 取れていない 状態 一貫性が 取れている 状態 ※：UNDOを使用した 更新の取り消しも 実行される Oracle
20. 20. 20 起動中に取得したバックアップの特徴 データファイル 更新済み ブロック 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
21. 21. 21 まとめ バックアップと復旧と一貫性の関係 • Oracle Databaseは起動中にバックアップを取得できる が、バックアップは一貫性が取れていない状態 • 復旧では、バックアップを戻すリストア処理と、バック アップ取得後に実行された更新処理を適用するリカバリ 処理を実行する • リカバリ処理は、一貫性が取れていない状態である起動 中に取得したバックアップを、一貫性が取れた状態にす る機能をもつ • リストアとリカバリを実行することで、障害発生直前の 一貫性が取れた状態に復旧できる Oracle
22. 22. 22 バックアップの非一貫性を許容しない MySQL
23. 23. 23 MySQLのバックアップと復旧の概要 • エクスポートツール mysqldumpを用いて、ある時点に おいて一貫性を持つバックアップを取得する • バイナリログを用いてリカバリを実行すると、ある時点 以降に実行された更新系SQLを再実行することで、障害 発生直前の状態に復旧できる 障害 20:00相当 の状態 更新 23:00相当 の状態 バイナリログ ファイル 20:00 23:0023:00 バイナリログファイル に記録された 更新系SQLを再実行 20:00 データの エクスポート 20:00時点の エクスポート データ データを インポート 1. バックアップ 2. 障害発生 3. リストア 4. リカバリ 更 新 mysqldump mysqlbinlog 要一貫性 MySQL
24. 24. 24 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
25. 25. 25 ログポジションと一貫性の関係 • --single-transactionオプションを指定したmysqldump で、ある時点において一貫性を持つバックアップを取得 できる(InnoDBの読み取り一貫性を使用) • バイナリログを用いたリカバリでは、ある時点以降に実 行された更新系SQLを再実行する • MySQLでは、上記の「ある時点」をバイナリログファイ ルのファイル名とファイル内のログポジションで示す …-bin. …10 …-bin. …11 …-bin. …12 バイナリログ バックアップ に対応した ログ ポジション MySQL
26. 26. 26 バックアップ、復旧におけるログポジション 障害 更新 障害発生 直前の状態 バイナリログファイル に記録された 更新系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
27. 27. 27 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
28. 28. 28 InnoDBログファイルの用途は？ • InnoDBログファイルはmysqldプロセスが異常終了した ときにデータベースの一貫性を回復するために使用され る（クラッシュリカバリ） – バックアップリストア後のリカバリ処理（メディアリカバリ）はバイナリログの役割 更新 + 一貫性の回復 InnoDB ログファイル 20:00 23:00 更新 を適用 1. 通常運用 2. プロセス 障害発生 3. 異常 停止後 4. MySQL起動→クラッシュリカバリ 更 新 mysqld mysqld 障害 一貫性が 取れていない 状態 バイナリ ログファイル InnoDB ログファイル mysqld ※：InnoDB UNDOログを使用した 更新の取り消しも実行される MySQL
29. 29. 29 Oracle Databaseエンジニアが抱きがちな疑問 • mysqldumpに--single-transactionを指定せず、一貫性 の取れていないバックアップを取得したら、復旧できる か？ → リストア・リカバリ処理は問題なく実行できる ただし、最終的に得られるデータはおそらく正しくない • リカバリ時に誤ったバイナリログファイル、ログポジ ションを指定してらどうなるか？ → リカバリ処理そのものではエラーが発生しない ただし、最終的に得られるデータはおそらく正しくない • 論理バックアップの代わりに物理バックアップを取得す ることはできないか？ → MySQL Enterprise Backupをつかえば一貫性のある物 理バックアップを取得できる。 ただし、MySQL Enterprise Editionでないと使用できな い MySQL
30. 30. 30 昔のOracle Databaseにかなり似ている PostgreSQLのバックアップと復旧
31. 31. 31 PostgreSQLのバックアップと復旧の流れ • バックアップモード設定中に、データファイルをコピー することでバックアップ • リストア（バックアップの戻し）後に、リカバリを実行する ことで、障害発生直前の状態に復旧できる 障害 20:00相当 の状態 一貫性の回復 ＋更新 23:00相当 の状態 WALファイル 20:00 23:0023:00 WALファイルに 記録された更新 を適用 20:00 20:00時点の バックアップ バックアップ で上書き 1. バックアップ 2. 障害発生 3. リストア 4. リカバリ 更 新 recovery .conf を配置 して起動 バックアップ モード中に ファイルを コピー PostgreSQL
32. 32. 32 ベースバックアップの取得 • PostgreSQLではリカバリ処理を実行して障害発生直前の 状態に復旧できるバックアップを、ベースバックアップ と呼ぶ • ベースバックアップの取得手順 – 下記手順を一括で実行できるpg_basebackupコマンド(9.1-)もあ る バックアップ 1. バックアップ モードON 2. ベースバックアップ の取得 OSコマンドで ファイルをコピー 3. バックアップ モードOFF SELECT pg_start_backup('label'); SELECT pg_stop_backup(); PostgreSQL
33. 33. 33 ベースバックアップの状態とリカバリ処理 • PostgreSQLのベースバックアップは、Oracle Databae のホットバックアップと同様に、一貫性が取れていない 状態 – バックアップ取得時点で実行中であり、取得後に取り消された更 新SQLの更新が、ファイルが反映されている場合がある – 完了した更新SQLの更新が、まだファイルに反映されていない場 合がある • WALファイルを用いたリカバリ処理において一貫性を回 復する • あわせて、バックアップ取得時点～障害発生直前までに データベースに加えられた更新処理を（再）実行する → リカバリ処理の役割も、Oracle Databaseと同様 PostgreSQL
34. 34. 34 分離ブロック：ホットバックアップ時の課題 • データベース起動中にバックアップを取得 → データファイルの更新とバックアップ処理によるデータ ファイル読み取りが同時に実行される可能性 → ブロックのI/O単位とOSレベルのI/O単位が異なることに起 因して、分離ブロックが発生する可能性がある • 分離ブロックは不正なブロックであるため、リカバリ時に修正 する必要がある 更新された ブロック データファイル データファイル バックアップ （ファイルコピー） 更新前 更新後 分離ブロック PostgreSQL
35. 35. 35 分離ブロック問題への対処 • バックアップモード中で更新済みバッファをデータファイルに書き込 む場合、WALファイルにも更新済みバッファを書き込む → リカバリ時の分離ブロック修正に使用 1. バックアップ モードON 2. バックアップ 取得開始 バックアップ （データファイル のコピー） 3.バックアップ 取得完了 → バックアップ モードOFF すべての更新済バッファ をデータファイルに 一括書き込み （チェックポイント） バックアップモード中に 更新済バッファをデータ ファイルに書き込む場合、 WALファイルにも更新済 みバッファを書き込む x. ユーザー更新処理実行 共有バッファ PostgreSQL
36. 36. 36 Oracle Databaseの分離ブロック対処 • RMANを用いてバックアップした場合、分離ブロックは 発生しない – Oracle Database本体によるデータファイルの更新と競合しない 仕組みが実装されている • RMANが導入される前のOracle Databaseでは PostgreSQLと同様の仕組みで分離ブロックに対処してい た – バックアップモード中は更新済みバッファをオンラインREDOロ グファイルに格納し、リカバリ時に分離ブロックを修正 Oracle
37. 37. 37 おしまい