Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

22,378 views

Published on

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

Published in: Software
  • Be the first to comment

バックアップと障害復旧から考える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 【告知】 JPOUGイベントやります! 9月12日(月) 19:00-20:30 JPOUG in 15 minutes #1 15分間のショートセッションを5コマ程度 聴講希望 http://bit.ly/in15m1 講演希望 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種類の ファイルが更新される 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. 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 リカバリ処理の目的 • バックアップ取得時点~障害発生直前までにデータベー スに加えられた更新処理を(再)実行する • 一貫性を回復する – データベース起動中に取得したバックアップは一貫性が取れてい ない状態。リカバリ処理により一貫性を回復する 障害 更新 + 一貫性の回復 アーカイブREDO ログファイル REDOに記録 された更新 を適用 ファイルを コピー オンラインREDO ログファイルバックアップ バックアップ で上書き REDOに記録 された更新 を適用 1. バックアップ 2. 障害発生 3. リストア 4. リカバリ 更 新 rman> backup database; rman> restore database; rman> recover database; 一貫性が 取れていない 状態 一貫性が 取れている 状態 ※:UNDOを使用した 更新の取り消しも 実行される Oracle
  19. 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. 20 まとめ バックアップと復旧と一貫性の関係 • Oracle Databaseは起動中にバックアップを取得できる が、バックアップは一貫性が取れていない状態 • 復旧では、バックアップを戻すリストア処理と、バック アップ取得後に実行された更新処理を適用するリカバリ 処理を実行する • リカバリ処理は、一貫性が取れていない状態である起動 中に取得したバックアップを、一貫性が取れた状態にす る機能をもつ • リストアとリカバリを実行することで、障害発生直前の 一貫性が取れた状態に復旧できる Oracle
  21. 21. 21 バックアップの非一貫性を許容しない MySQL
  22. 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. 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. 24 ログポジションと一貫性の関係 • --single-transactionオプションを指定したmysqldump で、ある時点において一貫性を持つバックアップを取得 できる(InnoDBの読み取り一貫性を使用) • バイナリログを用いたリカバリでは、ある時点以降に実 行された更新系SQLを再実行する • MySQLでは、上記の「ある時点」をバイナリログファイ ルのファイル名とファイル内のログポジションで示す …-bin. …10 …-bin. …11 …-bin. …12 バイナリログ バックアップ に対応した ログ ポジション MySQL
  25. 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. 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. 27 InnoDBログファイルの用途は? • InnoDBログファイルはmysqldプロセスが異常終了した ときにデータベースの一貫性を回復するために使用され る(クラッシュリカバリ) – バックアップリストア後のリカバリ処理(メディアリカバリ)はバイナリログの役割 一貫性の 回復 InnoDB ログファイル 更新 を適用 1. 通常運用 2. プロセス 障害発生 3. 異常 停止後 4. MySQL起動→クラッシュリカバリ 更 新 mysqld mysqld 障害 一貫性が 取れていない 状態 バイナリ ログファイル InnoDB ログファイル mysqld ※:InnoDB UNDOログを使用した 更新の取り消しも実行される MySQL
  28. 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. 29 昔のOracle Databaseにかなり似ている PostgreSQLのバックアップと復旧
  30. 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. 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. 32 ベースバックアップの状態とリカバリ処理 • PostgreSQLのベースバックアップは、Oracle Database のホットバックアップと同様に、一貫性が取れていない 状態 – バックアップ取得時点で実行中であり、取得後に取り消された更 新SQLの更新が、ファイルが反映されている場合がある – 完了した更新SQLの更新が、まだファイルに反映されていない場 合がある • WALファイルを用いたリカバリ処理において一貫性を回 復する • あわせて、バックアップ取得時点~障害発生直前までに データベースに加えられた更新処理を(再)実行する → リカバリ処理の役割も、Oracle Databaseと同様 PostgreSQL
  33. 33. 33 分離ブロック:ホットバックアップ時の課題 • データベース起動中にバックアップを取得 → データファイルの更新とバックアップ処理によるデータ ファイル読み取りが同時に実行される可能性 → ブロックのI/O単位とOSレベルのI/O単位が異なることに起 因して、分離ブロックが発生する可能性がある • 分離ブロックは不正なブロックであるため、リカバリ時に修正 する必要がある 更新された ブロック データファイル バックアップされた データファイル バックアップ (ファイルコピー) 更新前 更新後 分離ブロック PostgreSQL 用途は? 同時実行に よる干渉
  34. 34. 34 分離ブロック問題への対処 • バックアップモード中で更新済みバッファをデータファイルに書き込 む場合、WALファイルにも更新済みバッファを書き込む → リカバリ時の分離ブロック修正に使用 1. バックアップ モードON 2. バックアップ 取得開始 バックアップ (データファイル のコピー) 3.バックアップ 取得完了 → バックアップ モードOFF すべての更新済バッファ をデータファイルに 一括書き込み (チェックポイント) バックアップモード中に 更新済バッファをデータ ファイルに書き込む場合、 WALファイルにも更新済 みバッファを書き込む x. ユーザー更新処理実行 共有バッファ PostgreSQL WAL ファイル
  35. 35. 35 Oracle Databaseの分離ブロック対処 • RMANを用いてバックアップした場合、分離ブロックは 発生しない – Oracle Database本体によるデータファイルの更新と競合しない 仕組みが実装されている • RMANが導入される前のOracle Databaseでは PostgreSQLと同様の仕組みで分離ブロックに対処してい た – バックアップモード中は更新済みバッファをオンラインREDOロ グファイルに格納し、リカバリ時に分離ブロックを修正 Oracle
  36. 36. 36 おしまい Thanks!

×