Comments
Description
Transcript
第６章 回復管理と高可用性
第６章 回復管理と高可用性 本書に含まれている情報は、正式なIBMのテストを受けていません。また、明記にしろ、暗黙的にしろ、なんらの保証もなしに配布されるものです。 この情報の使用またはこれらの技術の実施は、いずれも、使用先の責任において行われるべきものであり、それらを評価し、実際に使用する環境に統合する 使用先の判断に依存しています。それぞれの項目は、ある特定の状態において正確であることがIBMによって調べられていますが、他のところで同じまたは同 様の結果が得られる保証はありません。これらの技術を自身の環境に適用することを試みる使用先は、自己の責任において行う必要があります。 © Copyright IBM Japan Co., Ltd. 2011 内容 • 回復管理 • 高可用性 2 © 2011 IBM Corporation 内容 － 回復管理 • データベース・リカバリーの概要 • リストアとロールフォワード • 回復に必要なもの • リストアの種類 • ロギング設定 • リストア • リダイレクト・リストア • データベースのリビルド • ロールフォワード • バックアップ・リカバリーの計画 • DB2バックアップの対象とその方法 • バックアップの種類 • • • • オフライン・バックアップ オンライン･バックアップ 表スペース・バックアップ 増分バックアップ • バックアップ・オブジェクトの管理 • 回復履歴ファイル • 回復オブジェクトの自動削除 • その他のバックアップ・リカバリー • オンライン・スプリット・ミラー • db2look 3 © 2011 IBM Corporation ブランク・ページ 4 © 2011 IBM Corporation データベースのリカバリーの概要 1/3 • 一般的なデータベース・サーバーの例 サーバーマシン 更新 ユーザー ア プ リケ ー シ ョン A→ B メモ リー ユ ー テ ィリテ ィー 管理 A→ B 5 デ ィス ク © 2011 IBM Corporation データベースのリカバリーの概要 2/3 • 典型的な障害の例 サーバーのダウン サーバーのダウン アプリケーションの異常終了 アプリケーションの異常終了 サーバーマシン DB2の異常終了 DB2の異常終了 ユーティリティーの異常終了 ユーティリティーの異常終了 更新 ユーザー ア プ リケ ー シ ョン A→ B 更新処理内容の損失 メモリー上のデータの損失 メモ リー ユ ー テ ィリテ ィー 管理 A→ B ディスク上のデータの損失 論理エラー（データの不整合） ユーザーによる誤操作 ユーザーによる誤操作 6 デ ィス ク ディスク障害 ディスク障害 © 2011 IBM Corporation データベースのリカバリーの概要 3/3 • データベースを正しい状態に保つ仕組み 障害の内容 アプリケーションの異常終了 ユーティリティーの異常終了 被害 更新処理内容 の損失 未コミットトランザクションを 取り消す ロールバック サーバーのダウン DB2の異常終了 メモリー上のデータ の損失 論理的回復 コミット済みトランザクション をデータベースに反映させる 破損回復 ディスク障害 ユーザーによる誤操作 回復管理 7 ディスク上のデータ の損失 論理エラー （データの不整合） 整合性のあるデータベース イメージで置き換える トランザクションによる変更を 再度反映させる 物理的回復 バージョン回復 ロールフォワード回復 © 2011 IBM Corporation DB2の物理的回復 バックアップ時点 まで回復 • バージョン回復 障害 BACKUP DATABASE RESTORE DATABASE Backup file バックアップ以降 のある時点 まで回復 • ロールフォワード回復 障害 BACKUP DATABASE RESTORE DATABASE Backup file ROLLFORWARD DATABASE Log files 8 © 2011 IBM Corporation ロールフォワード回復のためのロギング設定 その前に･･･ • ログ・ファイルとは • 全てのデータベースへの更新内容（ログ・レコード）が発生順に記録される ファイル • ログ・レコードは更新されたデータより必ず先にディスクに書かれる（WRITE LOG AHEAD） • ロールバック、破損回復、ロールフォワード回復に使用 • ロールバック • 未コミットの変更データを取り消す • 破損回復 アクティブ・ログ • コミットされた変更をディスクに反映する • 未コミットの変更データを取り消す • ロールフォワード • ログに記録された変更を適用する 9 アーカイブ・ログ © 2011 IBM Corporation ロギング方式とログ･ファイルの状態 • 2種類のロギング方式・・・循環ロギングとアーカイブ・ロギング アクティブ・ログ・ファイル ファイルにこれ以上ログ・レコードが追加できない （上書き再利用） ファイルに含まれる処理内容が すべてコミット済みかつ、全ての 変更データがディスクに書き出さ れた オンライン・アーカイブ・ ログ・ファイル ※ロギングの方式 ログパスから別の場所に コピーされる オフライン・アーカイブ・ ログ・ファイル ：循環ロギング ：アーカイブ・ロギング ：アーカイブ・ロギング（ログ・パスから別の場所にコピー） 10 © 2011 IBM Corporation （参考）ログ・ファイルの動き DB構成パラメーター • 循環ロギング Active Active 0.log Active 1.log 2.log 3.log Full !! 4.log Full !! Full !! LOGPRIMARY LOGSECOND LOGFILSIZ LOGARCHMETH1 LOGARCHMETH2 3 2 1000 OFF OFF SQL0964C ログ・フル・エラー !! • アーカイブ・ロギング DB構成パラメーター アーカイブ DISK 11 0.log 3.log 1.log 2.log LOGPRIMARY LOGSECOND LOGFILSIZ LOGARCHMETH1 LOGARCHMETH2 3 2 1000 DISK:xxx OFF ・・・ © 2011 IBM Corporation ロールフォワード回復のためのロギング設定 • アーカイブ･ロギング方式を使用 • 設定パラメータ（データベース構成パラメーター） • LOGARCHMETH1 • 例： update db cfg for SAMPLE using LOGARCHMETH1=DISK:/arclog • アーカイブ先以下のディレクトリは自動的に作成される • 例：/arclog/db2inst1/SAMPLE/NODE0000/C0000000 LOGARCHMETH1 データベース DISK アクティブ・ ログ db2tapemgr コマンド TSM ミラー・ログ LOGARCHMETH2 テープ VENDOR アーカイブに失敗した場合 FAILARCHPATH 12 TSM:Tivoli Storage Manager © 2011 IBM Corporation バックアップ・リカバリーの計画 • バックアップ・リカバリの計画時には以下の要件を調査する • いつバックアップを取得するか • どこにバックアップを保存するか • バックアップは何世代保存するか • バックアップはどのくらいの頻度で取得するか • どの時点まで回復しないといけないか • 要件に応じてバックアップ･リカバリの方法が異なる • それぞれ任意の組み合わせが可能 13 オフライン？ オンライン？ データベース単位？ 表スペース単位？ フル？ 増分（デルタ）？ © 2011 IBM Corporation DB2 のバックアップの対象とその方法 zOS上の構成ファイル サーバー ¾/etc/services, /var/ifor/nodelock, /var/db2/以下 インスタンス zINSTHOME ・・・ インスタンス・オーナーのホームディレクトリ ¾ UNIXの場合・・・$HOME ¾ Windowsの場合・・・%DB2PATH%¥DB2 データベース ファイル / ディレクトリ単位でのバックアップ zデータベース・パス カタログ表スペース zカタログ表スペースのコンテナー z一時表スペースのコンテナー 一時表スペース ユーザー表スペース zユーザー表スペースのコンテナー BACKUPコマンドによるバックアップ 索引, トリガー, ビュー, etc zLOGPATH/Snnnnnnn.LOG ¾LOGPATHはデータベース構成パラメーターで指定 ログ 14 DB2の機能によるアーカイブ © 2011 IBM Corporation バックアップ・リカバリーの計画 • どこにバックアップを保存するか？ • バックアップ・ファイルは、ディスク（ディレクトリ）、テープ装置、TSM に出力先することができる • 可能であればディスクに出力した方が障害発生の可能性が少ない • その後テープなどに保管することを推奨 • リストア時には、バックアップ・ファイルを一旦テープからディスクにコピーする 必要があることに注意 • バックアップ・ファイルのサイズ • DMSの場合、バックアップされる領域は、使用されているEXTENT • 正確にサイズを見積もることは困難であるが、list tablespaces show detailコマン ドの”最高水準点 (ページ)”を目安にして余裕を持たせる • SMSの場合は、OSコマンドでファイルサイズを確認 • バックアップ・ファイルを圧縮することも可能 • 世代数を多く持つ環境で有効 • データにも依存するが、10～7分の１程度に圧縮される 15 © 2011 IBM Corporation （参考）バックアップ・ファイル • バックアップ・ファイル名と意味 • ファイル名 • DB別名.タイプ.インスタンス名.NODExxxx.CATxxxxx.時刻.順序番号 例）SAMPLE.0.moba.NODE0000.CATN0000.20040113030501.001 • タイプ • 0 : データベース・バックアップ • 3 : 表スペース・バックアップ • 4 : LOADのコピー・ファイル DB TBSP1 LOAD • バックアプ･ファイルの検査コマンド ： db2ckbkp • ディスクやテープ装置上にあるバックアップ・ファイルに対して、 • • • 16 バックアップ・ファイルがリストア可能かどうかを確認する バックアップ・ファイルの情報を表示する バックアップファイルの中にログが含まれているか確認 © 2011 IBM Corporation （参考）db2ckbkp 実行例 • リストア可能検査の例 $ db2ckbkp SAMPLE.0.iwata.NODE0000.CATN0000.20050121114234.001 [1] Buffers processed: ######## Image Verification Complete - successful. • バックアップ・ファイルのヘッダー情報を出力する例 $ db2ckbkp -h SAMPLE.0.moba.NODE0000.CATN0000.20041008013428.001 ===================== MEDIA HEADER REACHED: ===================== Server Database Name Server Database Alias Client Database Alias Timestamp Database Partition Number Instance Sequence Number Release ID Database Seed DB Comment's Codepage (Volume) DB Comment (Volume) DB Comment's Codepage (System) DB Comment (System) Authentication Value Backup Mode Includes Logs Compression ・・・（略）・・・ 17 ------------------ SAMPLE SAMPLE SAMPLE 20041008013428 0 moba 1 A00 92DBF20F 0 0 255 1 1 0 オンライン・バックアップでINCLUDE LOGSオプションを つけてたバックアップの場合 ０：ログ･ファイル含まれてない １：ログ・ファイル含まれている バックアップが圧縮についてのフラグ （０：圧縮していない １：圧縮している） © 2011 IBM Corporation オフライン･バックアップ • オフラインとは • 他のアプリケーションがデータベースから切断されている状態 • オフライン・バックアップの特徴 • リカバリー手順が最も容易となる • データベースに他のアプリケーションが接続していない状態でバックアップ を取得する • データベース全体の場合、ログファイルがなくてもリカバリー可能（バージョ ン回復） • 表スペース単位の場合、ロールフォワード処理が必要となる • QUIESCE DATABASEコマンドを利用するとデータベースをオフライン状態 にできる SQL20157 App quiesce App SQL20157 18 BACKUP オフライン･バックアップ取得 © 2011 IBM Corporation オンライン･バックアップ • バックアップをオンラインで取得可能 • バックアップ操作中に他のアプリケーションがそのデータベースに接続できる • バックアップ取得の前提 • データベースがアーカイブ･ロギングであること • 推奨 • バックアップ･イメージに最小限必要なログを含めること • バックアップ中に発生したログは必ずrollforwardしなくてはいけない バックアップ 取得完了 バックアップ 取得開始 更新処理 アクティブ・ ログ Backup 19 アクティブ・ ログ Backup © 2011 IBM Corporation 表スペース･バックアップ • 表スペース単位で回復可能 • 単独のディスク障害やアプリケーション・エラーから回復する場合に有効 • 個々の表スペースごとにバックアップ、リストア、ロールフォワードを行うことが 可能 • データベース単位のバックアップから、特定の表スペースのみをリストア、ロー ルフォワードすることが可能 • ONLINEオプションでは、他の表スペースを使用中にもリストア、ロールフォワードが可能 • バックアップ取得の前提 • データベースがアーカイブロギングであること TBSP1 • 考慮点 • データベース全体の回復には使用できない • データベース内の整合性を保つための制限事項が多い • 表スペースのリストア後は必ずロールフォワードが必要 • ロールフォワードをPoint in Time で完了するとバックアップ保留 20 © 2011 IBM Corporation 増分バックアップ • 前回取得したバックアップから変更されたデータのみをバックアップする • ページ単位で変更されたかどうかが判断される • バックアップ取得の前提 • 「変更ページの追跡使用可能」であること • データベース構成パラメーター trackmod ＝ YES • 増分バックアップの種類 • 増分（INCREMENTAL） • 最後のフルバックアップから変更されたデータのバックアップ • 差分（DELTA） • 最後のフルバックアップまたはインクリメンタルバックアップから変更された データのバックアップ Sunday Mon Tue Full Wed Thu Fri Sat Sunday Full 増分 バックアップ (Incremental) 21 Sunday Full Mon Tue Wed Thu Fri Sat デルタ バックアップ(Delta) Sunday Full © 2011 IBM Corporation バックアップからの回復 • RECOVER DATABASEコマンド • RESTOREとROLLFOWARDを自動的に実施 • 時間指定のロールフォワードも可能 • バックアップイメージを指定する必要がない • 回復履歴ファイルから自動的に最適なバックアップを選択 • データベース全体のバックアップや増分バックアップからも可能 RECOVER BACKUP DATABASE RESTORE DATABASE Backup file ROLLFORWARD DATABASE Log files 22 © 2011 IBM Corporation リストアの種類 • データベース全体のリストア • リダイレクト・リストア • バックアップ時とは異なる表スペース・コンテナーにリストアしたい場合 • データベースのリビルド • 表スペースのバックアップからデータベースを回復 • ある表スペースのみのリストア DB Backup • 増分バックアップからのリストア delta delta 同じRESTOREコマンドを使用する 種類ごとに指定するオプションが異なる 23 Backup DB TBSP1 © 2011 IBM Corporation リストア • バックアップ・イメージをリストアし、バックアップ取得時のデータベー スを作成する • RESTORE DATABASE コマンド RESTORE DATABASE SAMPLE FROM /backup 障害 BACKUP DATABASE RESTORE DATABASE Backup file 24 © 2011 IBM Corporation リダイレクト・リストア • リストア時に表スペース・コンテナーのレイアウトを変更 • コンテナの追加・変更・削除 • DMS表スペースのコンテナのFILE ⇔ DEVICEの変更が可能 • 変更スクリプトを生成すると、効率的に実施可能 • DMS表スペース ⇔ SMS表スペースの変更は不可能 • 異なるDB名としてリストアし、クローンDBの作成することも可能 オリジナルDB クローンDB DMS DBPATH=/XXX REDIRECT RESTORE LOGPATH=/XXX SMS 25 DMS DBPATH=/YYY LOGPATH=/YYY SMS © 2011 IBM Corporation データベースのリビルド • 表スペースバックアップからのリカバリー • 複数の表スペースバックアップから、データベース全体の復旧が可能 • どのバックアップファイルを使用するかは、DB2が自動的に判断可能 SYSACATSPACE USERSP1 USERSP2 USERSP3 BK1 表スペース・バックアップ 表スペース・バックアップ BK2 Time 表スペース・バックアップ BK3 表スペース・バックアップ BK4 2. 表スペースバックアップ間のログ ファイルを適用して整合性を確保 Log files Table space BK1 backup 26 Crash BK2 BK3 BK4 1. 4つの表スペース・バックアップを元に、 データベースを復旧 © 2011 IBM Corporation ロールフォワード • ログ・ファイルに記録されたトランザクションを適用することによって、 データベースを回復する • ROLLFORWARD DATABASEコマンド • 「ロールフォワード保留中」のデータベースに対して実行 • RESTORE DATABASE 完了後 WITHOUT ROLLING FORWARD オプションを指定する場合を除く ROLLFORWARD DATABASE SAMPLE TO END OF LOGS AND COMPLETE 障害 BACKUP DATABASE RESTORE DATABASE ROLLFORWARD DATABASE Backup file Log files 27 © 2011 IBM Corporation どこまでロールフォワードするか 1.end of backup オンライン バックアップ 取得完了 オンライン バックアップ 取得開始 2. point in time アクティブ・ ログ アクティブ・ ログ アクティブ・ ログ アクティブ・ ログ Backup 3.end of logs Backup アーカイブ・ ログ アーカイブ・ ログ アーカイブ・ ログ アーカイブ・ ログ tape 28 © 2011 IBM Corporation ロールフォワードにおけるログ･ファイルの準備 • 戻す時点に応じてログファイルの準備をする 1. End of Backup バックアップ･ファイルに含まれている • 2. Point in time その時点までのログ • • テープや別ディスクに退避されていれば準備する 3. End of logs 復旧直前までのログ • • テープや別ディスクに退避されていれば準備する 通常運用時 ログパス アーカイブパス オフライン・アーカイブ・ログ オンライン・アーカイブ・ログ DB2 によるコピー（自動） 29 tape テープ等に退避（手動） © 2011 IBM Corporation 例：ロールフォワードに必要なログ （end of logs） アクティブ･ログ・ディレクトリ 18.log 19.log 20.log アーカイブ･ログ・ディレクトリ テープ 15.log 16.log 17.log 10.log 11.log 12.log 13.log 14.log 手動 コピー 一時ディレクトリ（/logtmp） 自動 コピー 10.log 11.log 10.log 11.log 12.log 13.log 14.log オンライン･バックアップ 10.log 11.log DB 1. restore db … logtarget /logtmp Backup 30 2. rollforward db … overflow log path /logtmp … to end of logs © 2011 IBM Corporation （参考）ロールフォワードとログの考慮点 アクティブ･ログ・ディレクトリ 18.log 19.log 20.log アーカイブ･ログ・ディレクトリ テープ 15.log 16.log 17.log 10.log 11.log 12.log 13.log 14.log 一時ディレクトリ（/logtmp） 自動 コピー 10.log 11.log 最低限バックアップ時点の 最低限バックアップ時点の データベースまでは回復可能 データベースまでは回復可能 オンライン･バックアップ 10.log 11.log DB 1. restore db … logtarget /logtmp Backup 31 2. rollforward db … overflow log path /logtmp … to end of backup © 2011 IBM Corporation ブランク・ページ 32 © 2011 IBM Corporation バックアップ・オブジェクトの管理 • 回復履歴ファイル • 回復オブジェクトの自動削除 33 © 2011 IBM Corporation 回復履歴ファイル • 目的 • データベース単位に作成され、リカバリーと管理のさまざまなイベントの記 録を行う • 保存場所 • <データベース・ディレクトリ>/db2rhist.asc • バックアップファイルとしても一つ存在 ： db2rhist.bak • 用途 • 必要なバックアップ・イメージを特定する • データベースに対して実行された特定のユーティリティーの確認 • BACKUP、RESTORE、LOAD、 • DB2が内部的に使用するケース • 確認方法 • LIST HISTORY コマンド 34 © 2011 IBM Corporation 回復履歴ファイルのメンテナンス バックアップ保存期間を過ぎた情報は不要なため、 回復履歴ファイルから情報を削除し、ファイルの容量を節約 • 回復履歴ファイル内の情報を削除する方法 • 有効期限の設定（データベース構成パラメータ） REC_HIS_RETENTN • 何日前のバックアップまで保持するか？ NUM_DB_BACKUPS • 何世代前のバックアップまで保持するか？ • 上記パラメータを満たすと“有効期限切れ”とマークされる • 全データベースのバックアップが実施されると回復履歴ファイルから 必要なくなったデータが削除される • 手動削除 • PRUNE HISTORY コマンド 35 © 2011 IBM Corporation ブランク・ページ 36 © 2011 IBM Corporation 回復オブジェクトの自動削除 • 回復処理に不要となった回復オブジェクトをDB2が自動的に削除する • AUTO_DEL_REC_OBJ=ON で制御（データベース構成パラメータ ） • 対象回復オブジェクト（物理ファイル） • バックアップ・ファイル • ロード・コピー・ファイル • アーカイブ・ログファイル • TSMへのバックアップ取得、自動保守バックアップ機能も対象となる • 削除されるタイミング • NUM_DB_BACKUPS と REC_HIS_RETENTN DB CFG に達していて、 以下のいずれかが実施されたタイミング • 表スペースもしくは全データベースのバックアップが成功したタイミング • and deleteオプションつきのprune historyコマンド • DB2PRUNE_OPTION_DELETE つきの db2Prune API の発行 37 © 2011 IBM Corporation ブランク・ページ 38 © 2011 IBM Corporation その他のバックアップ・リカバリー • オンライン･スプリット・ミラー • db2lookによるDDL保存 39 © 2011 IBM Corporation ブランク・ページ 40 © 2011 IBM Corporation オンライン・スプリット・ミラー • ストレージのコピー機能を使用したバックアップ • • • データベースのクローンを作成し、テスト環境や解析用データベースとして使用可能 障害に備えて、ウォーム･スタンバイのデータベースを作成することが可能 大規模DBにて、 DB2のBackup/Restoreユーティリティーよりも高速にバックアップ/リストアが可能 • Split mirrorとは、バックアップの目的や、データベースのクローンとして再利用可能な、独 立したデータベース・ディスク領域コピーのこと • Split mirrorの作成はストレージ・デバイスのコピー機能を利用 • ストレージ・デバイスで利用可能なハードウェア・ベースの高速コピー機能を使用して、データベース のコピー(Split mirror)を作成することが可能 • DS8000/6000/4000シリーズのFlashCopyなどを利用した、Diskボリュームコピー DBサーバー DB 41 ストレージ機能によって、 短時間でのコピー完了 Copy バックアップ管理・サーバー DB Split mirror © 2011 IBM Corporation （参考）FlashCopyの概念図 DS6000/8000の場合 FlashCopy 実行 ｼｽﾃﾑから見た論理Volume ｺﾋﾟｰ元 ｺﾋﾟｰ先 ｺﾋﾟｰ元 瞬時 ｺﾋﾟｰ先 ｺﾋﾟｰ元 ｺﾋﾟｰ先 ｺﾋﾟｰ元 ｺﾋﾟｰ先 ﾃﾞｰﾀ･ｺﾋﾟｰ開始 対応するESS内のVolume ｺﾋﾟｰ元 ｺﾋﾟｰ先 FlashCopy実行前 ｺﾋﾟｰ元 ｺﾋﾟｰ先 論理コピー：同期確立 この時点でユーザーは利用可能 物理データコピー 処理の実行終了 物理ﾃﾞｰﾀはｺﾋﾟｰ未完了にもかかわらず、 ｼｽﾃﾑからは既にｺﾋﾟｰ完了と見える 42 © 2011 IBM Corporation FlashCopyを用いた自動バックアップ・リカバリ • ACS機能を利用して自動的にFlashCopyによる回復管理が可能 • ACS：Advanced Copy Service （DB2 V9.5～） • バックアップ backup db <dbname> use snapshot • リストア restore db <dbname> use snapshot DBサーバー FlashCopy BACKUP USE SNAPSHOT RESTORE USE SNAPSHOT 43 © 2011 IBM Corporation （参考）FlashCopyを用いた手動バックアップ・リカバリ 1. DB2のI/O停止 3. DB2のI/O再開 1. インスタンス停止 3. インスタンス起動 4. db2inidb 5/6. ロールフォーワード home home 2. FlashCopy論理ｺﾋﾟｰ 4. FlashCopy物理ｺﾋﾟｰ LOG LOG LOG LOG LOG LOG DATA DATA DATA DATA DATA DATA 正Volume (Source) 副Volume (Target) バックアップ手順 1.正Volumeへの書き込みの停止 zset write suspend for database 2.ディスク・ボリュームの論理コピーの実行 3.正Volumeへの書き込みの再開 zset write resume for database 4.ディスク・ボリュームの物理データコピー LOG LOG 2. ｺﾋﾟｰﾊﾞｯｸ 正Volume (Source) DATA DATA 副Volume (Target) リストア手順 1.インスタンスの停止（db2stop） 2.ディスク・ボリュームのコピー・バック 3.インスタンスの起動（db2start） 4.データベースをロールフォワード保留状態にする zdb2inidb データベース名 as mirror 5.必要なログファイルを準備する 6.ロールフォワードを実行する zdb2 rollforward db sample to end of logs and stop 44 © 2011 IBM Corporation db2look • データベース内の定義情報や統計情報を抽出するツール • データベース・オブジェクトの定義情報をバックアップしたい場合に 利用できる • 構成パラメータ、レジストリ変数 • db2look -d DB -f • 表・索引・ビュー等のデータベース・オブジェクトのDDL • db2look -d DB -e • バッファープール、表スペースのDDL • db2look -d DB -l • 権限情報 • db2look -d DB -xd • モジュール・PL/SQLオブジェクト • db2look -d DB –mod • オプションは組み合わせることも可能 本番DB DB object UPDATE db parameter dbm parameter db2set テストDB 45 © 2011 IBM Corporation ブランク・ページ 46 © 2011 IBM Corporation 内容 － 高可用性 • 高可用ソリューション • 災害対策ソリューション • DB2が提供する高可用性・災害対策ソリューション • 高可用性ソリューション • pureScale • 災害対策ソリューション • HADR • Q Replication 47 © 2011 IBM Corporation ブランク・ページ 48 © 2011 IBM Corporation 高可用性ソリューション 製品 HA構成 DB2 HADR, Q Replication DB2 pureScale 構成 1:1 49 対象 小・中規模OLTP 小・中規模OLTP 中・大規模OLTP 特徴 シェアード・ディスク アクティブホットスタンバイ シェアードデータ © 2011 IBM Corporation （参考）HA構成による高可用性ソリューション 方法 長所 短所 クラスター製品の使用 既存のシステムを活用できる コールド・スタンバイである 複数のベンダーからソリューション が提供されている DB2が起動するまでアプリケー ションが一時停止する シェル・スクリプトを使用して統合 DB2 DB2 HACMP/PowerHA DB2製品はそれぞれの サーバーにインストール データベース、表スペース・コンテナ、 ログなどは共有ディスクに配置し、 ノード障害時に引き継ぐ 表スペース ログ ログ 50 © 2011 IBM Corporation 災害対策ソリューション z バックアップ転送遠隔保管型 z z z RPO（データロス） ＢＡＣＫＵＰイメージ 遠隔地保管 データベース・コピー型 z z DB2 BACKUP+TSM PPRC （Metro Mirror / Global Mirror ) ログ･シッピング ログ･シッピング型 ＰＰＲＣ ＧＬＯＢＡＬ MIRROR(非同期） 新機能 z HADR z z 同期・近同期・非同期 Q-REPLICATION z Q-REP 双方向・Peer to Peer ＨＡＤＲ ＰＰＲＣ METRO ＭＩＲＲＯＲ(同期) RTO:リカバリー時間 51 © 2011 IBM Corporation （参考）一般的な災害対策システム 方法 長所 短所 データベース・バックアップの転送 低コスト バックアップ時点から最新時点までのトラン ザクションは回復不能 バックアップ時点までの回復が可能 データベース・バックアップの転送と ログファイルのアーカイブ 低コスト 最後にアーカイブされたログまでの回復が 可能 最後にアーカイブされたログから最新時点 までのトランザクションは回復不能 リカバリー時間が長い（データベースのリス トア＋アーカイブ・ログのロールフォワード） ログに記録されない処理は複製されない ログ ログ 52 ログ ログ © 2011 IBM Corporation （参考）一般的な災害対策システム 方法 長所 短所 スタンバイ・データベースに対する ログ・ファイル・シッピング 本番系に与える影響を最小化 最後のログ・ファイル内のトランザクションを 消失する可能性がある スタンバイ・データベースはロールフォワー ド保留状態のために使用できない ログ ログ スタンバイはプライマリーと同一データベー スである必要がある ログ ログ ログに記録されない処理は複製されない PPRCによるストレージ・レベルの 同期ミラーリング トランザクションの消失がない データベースに対する全ての変更を複 製することが可能 切り替え時間を最小化できる スタンバイが地理的に離れている場合、同 期的なミラーリングがトランザクション・パ フォーマンスに影響を与える 距離の制約がある 高コスト Metro Mirror Global Copy 53 © 2011 IBM Corporation （参考）災害対策における目標設定指標 RTO ： リカバリー時間目標 (時間) • リカバリー時間目標とリカバリー・ポイント目標 障害発生時点 ▼ 時間の流れ RPO 何時までの処理を 戻せるのか RTO 何時になったら 正常状態に戻せるのか RPO ： リカバリー・ポイント目標 · · · Recovery Point Objective 何時までの処理を戻すのか示す指標 障害発生時点からどの位前かを表記 RTO ： リカバリー時間目標 · · · 54 RPO ： リカバリー・ポイント目標 (時間) RPOとRTOの関係 · · · RTO > RPO RPOが長くなると、RTOは対数的に増加 O戻しの処理時間が回復に必要な時間に、 累積加算されるため RPOが短くなると、RTOも短くなる Recovery Time Objective 何時になったら正常状態に戻せるのかを示す指標 障害発生してからどの位時間が経過したかを表記 © 2011 IBM Corporation DB2が提供する高可用性・災害対策ソリューション • 高可用性ソリューション • DB2 pureScale • 高可用性・災害対策ソリューション • HADR • Q Replication 55 © 2011 IBM Corporation ブランク・ページ 56 © 2011 IBM Corporation DB2 pureScale 「ノンストップ」、「スケーラビリティ」、「スピード」を追求した 新しいデータベース・インフラ技術 • ノンストップ • リカバリー処理中の可用性を維持しながら、全体のリカリーを高速に行う • データベース・ノードに障害が発生した際、リカバリーが完了するまで、障害ノードの 更新中(インフライト)のデータだけをロックする • スケーラビリティ • アプリケーションはクラスター環境を意識しない • データブロックを一元管理（Coupling Facility ノード） ノードの台数に関係なくノード間通信量を低減 行の更新がコミットされるときのみブロック・ロックを取得 （同時並行性が向上） • スピード • ノード間通信は直接メモリ間で行われる 57 © 2011 IBM Corporation DB2 pureScale テクノロジー・オーバービュー クライアントはどこにでも接続、 一つのデータベースとして利用 自動的なワークロードバランス クライアント シングル・データベース・ビュー DB2エンジンはそれぞれのコンピューターで稼動 Member Member Member – データベースアクセスの一貫性を提供するように連携 – 2009年出荷時点はAIX 6.1 on p550 or p595限定 Member 統合されたクラスター・サービス(CS) CS CS CS CS – 障害検知, 自動リカバリー, クラスター・ファイルシステム – Tivoli System Automation, GPFS 超高速ノード間通信 Cluster Interconnect – CS Secondary CS Log Log Log Shared Storage Access Database 58 Log Primary RDMAノード間通信を最大限に活用 (Infiniband) (Remote Direct Memory Access) PowerHA pureScale (CF) – 効率的なグローバル・ロッキングとバッファー管理 – セカンダリーへの同期２重化により可用性を確保 データシェアリング・アーキテクチャー – データベースへの共有アクセス – GPFS (General Parallel File System) © 2011 IBM Corporation DB2 pureScale なぜ全面停止にならない？ CFの情報によりリカバリーブロックが全ノードから明確にわかるため、 正常ノードはまったく影響されることなく処理を継続 メンバー1がクラッシュ Member 1 Member 2 Member 3 CF が更新中のブロックを 常に把握 CF x x x x x x I/O 処理を継続 Central Lock Manager x x x x x x CFは、どのノードがダウンしたときにどのブロックにリカバリーが必要なのかを常に意識 59 © 2011 IBM Corporation ブランク・ページ 60 © 2011 IBM Corporation HADR（High Availability Disaster Recovery） • データベース単位の高可用性を実現 • ログ転送を使用したデータベース複製 • プライマリーDBへの更新情報をスタンバイDBに転送し、再生 • 一つのプライマリーDBに対し、一つのスタンバイDBを構築（HADRペア） • 3種類のモードを提供 • 同期（SYNC） • 近似同期(NEARSYNC) • 非同期(ASYNC) • TAKEOVER HADRコマンドによる、高速な引継ぎが可能 • プライマリーに障害が発生した場合、TAKEOVER HADR ... BY FORCE コマンドを使用（強制引継ぎ） HADR プライマリーDB TCP/IP replay スタンバイDB TAKEOVER 61 © 2011 IBM Corporation HADR同期方法 1. 2. 3. 4. 5. クライアントからの接続 1 4 DB2エンジン 3 バッファ プール 2 ログ バッファ 7 代替の接続 (Automatic Client Reroute) プライマリ 5 バッファ TCP層 TCP層 非同期 5 log writer TCP/IP 6 6. 7. データ更新処理を受け取る ログ･バッファに書き込む データ･バッファ上で更新処理 コミットを受け取る ログ・バッファの内容をディスクに書き込むと同時に TCPレイヤーにログ・ページを転送 （→7：非同期） スタンバイのHADRバッファへ書き込む （→6：近同期） ディスクに書き込む (→6：同期) 完了通知をプライマリに返す コミット終了をユーザーへ返す スタンバイ HADR ﾊﾞｯﾌｧ 近同期 log reader log reader ログ ログ DB2エンジン バッファ バッファ プール 5 Replay 5 表 索引 ログ ログ 表 索引 同期 62 © 2011 IBM Corporation DB2 V9.7 FP1 よりアクティブ･スタンバイとして使用可能 • 読み取り専用アプリケーションからのアクセスに使用可能 • レポーティングや負荷分散のために有効活用できる • HADRスタンバイの高可用性や災害対策のための役割を損ねること なく、参照業務をスタンバイ側で実行 • HADRを停止せずにスタンバイ側データベースの参照が可能 • ただし、分離レベルURの参照のみ Read-Only クライアント Read/Writeクライアント ログ Primary Standby ※ スタンバイ側のライセンスは、 フルライセンスが必要となります。 63 © 2011 IBM Corporation ブランク・ページ 64 © 2011 IBM Corporation Q Replication • 表単位で高速に複製可能 • • • • ログから更新データを収集 WebSphere MQのキューを介して更新データを送信 非同期レプリケーション 双方向や1対多のレプリケーションが可能 ターゲット表 ソース Qキャプチャー制御表 INSERT UPDATE DELETE ターゲット Qアプライ制御表 DB2ログ ソース表 WebSphere MQ WebSphere MQ エージェント エージェント エージェント ブラウザ 圧縮 Q APPLY Q CAPTURE 送信キュー 65 受信キュー © 2011 IBM Corporation （参考）Q Replicationの用語 • 制御表 • レプリケーション定義情報が格納されている表 • どの表を複製するか、表のレイアウト、どのMQを使用するかなど • Qキャプチャ • ソース表に対する変更データをログから収集してMQのメッセージに変換し、 キューに送信する • OracleのLogMinerを使用して、Oracleからレプリケーションすることも可能（ただし 単一方向のみサポート） • WebSphere MQ • ソースからターゲットへメッセージを送受信するキューイング機能を提供す る製品 • Qアプライ • MQメッセージからトランザクションを再構築してターゲット表を更新する • 他社DBへのレプリケーションが可能（ただし単一方向のみサポート） 66 © 2011 IBM Corporation 災害対策時のQ Replication構成 • 双方向レプリケーションを実施 セカンダリー DB セカンダリーDB プライマリー DB プライマリーDB log Q Apply Q Capture Q Capture Q Apply Read/ Write アプリケーション（READ/WRITE） 67 log Read/ Write アプリケーション（READ/WRITE） © 2011 IBM Corporation （参考）Q Replicationのレプリケーション･タイプ • データベースの表から表への非同期複製 レプリケーション・タイプ 単方向レプリケーション SOURCE TARGET Peer to Peerレプリケーション TABLE 双方向レプリケーション（Bidir） SOURCE TARGET TABLE TABLE トリガーとソース表へ レプリケーション用の 列を追加する必要がある 災害対策時の構成 68 © 2011 IBM Corporation HADR vs Q Replication 比較のポイント HADR Q Replication レプリケーション対象 データベース 表 スタンバイへのデータの伝搬方法 ログ操作が転送され、 ROLLFORWARDによりセカンダリー DBに適用される DB2のログからコミット済みトランザクション・ データがキャプチャーされ、ターゲット表に適 用される 同期レプリケーションの可能性 可能 不可 非同期レプリケーションの可能性 可能 可能 サポートされるOS Linux、UNIX、Windows Linux、UNIX、Windows、z/OS スタンバイDBへ接続できるか 可能（DB2 V9.7 FP1より、URのみ） 可能 DDLをレプリケーションできるか 可能 不可 プライマリとスタンバイのシステム構成 HW、OS、DB2 UDBのバージョンは プライマリと同じである必要がある HW、OS、DB2 UDBのバージョンはソース・ データベースと同じである必要はない パフォーマンスをモニターするツール db2pd 制御表、レプリケーション･アラート・モニター ネットワーク上のデータの圧縮/暗号化 不可 可能 DPFでの実装は可能か 不可 可能 双方向レプリケーション 不可 可能 2つ以上のサーバーへのレプリケーション 不可 可能 必要ソフトウェア DB2 EE、WSE、ESE DB2 ESE、Homogeneous Replication Feature for DB2 ESE（WebSphere MQ） 69 © 2011 IBM Corporation 参考 • DB2 pureScale • http://www-06.ibm.com/software/jp/data/db2/v9/purescale/ • DB2 HADR • http://www-06.ibm.com/software/jp/data/db2/v9/advantage/hadr.html • Q Replication • http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.swg.im.iis.db.repl.intro. doc/topics/iiyrcintrsqr0.html 70 © 2011 IBM Corporation Let’s go to Lab5!! 71 © 2011 IBM Corporation