Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

7.445 visualizaciones

Publicado el

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

Publicado en: Tecnología
  • Sé el primero en comentar

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

  1. 1. 1 バックアップと障害復旧から考える Oracle Database, MySQL, PostgreSQLの違い 2016年9月9日 Japan Oracle User Group 渡部 亮太
  2. 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. 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起動中にバックアップを取得できる (ホットバックアップ) • リストア(バックアップの戻し)後に、リカバリを実行する ことで、障害発生直前の状態に復旧できる 障害 00:00相当 の状態 トランザクションログ適用 によるデータベースの更新 12:00相当 の状態 トランザクション ログファイル 00:00 12:0012:00 トランザクションログファイルに 記録された00:00~12:00相当の 更新を適用 00:00 ファイルを コピー 00:00時点の バックアップ バックアップ で上書き 1. バックアップ 2. 障害発生 3. リストア 4. リカバリ 更 新
  9. 9. 9 リカバリ機能の重要性 • リカバリ機能がないと、障害発生時にバックアップ取得 時点の状態にしか復旧できない • バックアップ取得時点~障害発生時点の間に実行された 更新はすべて失われる 障害 00:00相当 の状態 12:0000:00 ファイルを コピー 00:00時点の バックアップ バックアップ で上書き 1. バックアップ 2. 障害発生 3. リストア 更 新 00:00~12: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起動中 にバックアップを取得できる(ホットバックアップ) • リストア(バックアップの戻し)後に、リカバリを実行する ことで、障害発生直前の状態に復旧できる 障害 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. 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を再実行することで、障害 発生直前の状態に復旧できる 障害 12:00相当 の状態 更新 12:00相当 の状態 バイナリログ ファイル 00:00 12:0012:00 バイナリログファイル に記録された 更新系SQLを再実行 00:00 データの エクスポート 00: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のバックアップと復旧の流れ • バックアップモード設定中に、データファイルをコピー することでバックアップ • リストア(バックアップの戻し)後に、リカバリを実行する ことで、障害発生直前の状態に復旧できる 障害 00:00相当 の状態 一貫性の回復 +更新 12:00相当 の状態 WALファイル 00:00 12:0012:00 WALファイルに 記録された更新 を適用 00:00 00: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!
  37. 37. 37 追加スライド
  38. 38. 38 増分バックアップ • 前回のバックアップ以降に更新されたブロックのみを バックアップする 更新された ブロックのみ をバックアップ 2. 差分増分 バックアップ 3. 差分増分 バックアップ Oracle 更新された ブロックのみ をバックアップ 全体を バックアップ 1.全体 バックアップ 4. 全体 バックアップ 更新された ブロックのみ をバックアップ 5. 差分増分 バックアップ 全体を バックアップ 更 新
  39. 39. 39 増分バックアップを用いた復旧 Oracle 2. 差分増分 バックアップ 3. 差分増分 バックアップ 1.全体 バックアップ 更 新 更 新 更新 オンライン/アーカイブ REDOログファイル REDOに記録 された更新 を適用 障害
  40. 40. 40 増分更新バックアップによる復旧時間の短縮 Oracle 2. 差分増分 バックアップ 3. 差分増分 バックアップ 1.全体 バックアップ 更 新 更新 オンライン/アーカイブ REDOログファイル REDOに記録 された更新 を適用 障害

×