高可用性災害時リカバリー (HADR)
高可用性災害時リカバリー (HADR) は、 部分的なサイト障害と全体的なサイト障害の両方に関する可用性の高い解決方法を提供します。 HADR は、1 次データベース と呼ばれるソース・データベースから、スタンバイ・データベース と呼ばれるターゲット・データベースにデータの変更内容を複製して、データの損失を防ぎます。 HADR は、リモート・スタンバイ・サーバーを最大 3 つサポートします。
部分的なサイト障害は、ハードウェア、ネットワーク、またはソフトウェア (Db2® データベース・システムまたはオペレーティング・システム) の障害によって発生する可能性があります。 HADR を使用しない場合、部分サイト障害では、データベースの入ったデータベース管理システム (DBMS) サーバーを再始動する必要があります。 データベースおよびそれが置かれているサーバーを再始動するのにかかる時間の長さは、予測できません。 データベースが整合した状態に戻って使用可能になるまでに、数分かかることがあります。 HADR を使用すると、スタンバイ・データベースが数秒で処理を引き継ぐことができます。 さらに、自動クライアント・リルートを使用するか、アプリケーションで再試行ロジックを使用することで、 元の 1 次データベースを使用していたクライアントを新しい 1 次データベースにリダイレクトできます。
全サイト障害は、火災などの災害によってサイト全体が破壊される場合に生じ得ます。 ただし、HADR では、1 次データベースとスタンバイ・データベースとの通信に TCP/IP を使用するため、それぞれ別の場所に置くことができます。 例えば、プライマリデータベースがある市区町村の本社にあり、スタンバイ・データベースが他の市区町村の営業所にあるとします。 プライマリー・サイトで災害が生じる場合、リモートのスタンバイ・データベースが、 完全な Db2 機能を備えた 1 次データベースとしてサイトを引き継ぎ、 データの可用性が維持されます。 テイクオーバー操作が発生した後、元のプライマリデータベースをバックアップして、プライマリデータベースのステータスに戻すことができます。この手順はフェイルバックと呼ばれます。 古い 1 次データベースと新しい 1 次データベースを一致させることが可能であれば、フェイルバックを開始できます。 従来プライマリデータベースをスタンバイデータベースとしてHADR設定に再統合した後、データベースの役割を切り替えられます。 この操作により、元のプライマリデータベースを再び プライマリデータベースにすることができます。
- 使用する同期レベル
スタンバイ・データベースは、プライマリデータベースに生成され、スタンバイ・データベースに送信されるログ・データを介して、プライマリデータベースと同期されます。 スタンバイ・データベースは、ログを通じて常にロールフォワードします。 4 つの異なる同期モードから選択できます。 これらのモードは最大保護から最小保護への順で上げると、SYNC, NEARSYNC, ASYNC, and SUPERASYNCになります。
- ピア・ウィンドウの使用
- ピア・ウィンドウ・フィーチャーは、1 次データベースがピア状態で HADR から切断されても、構成された時間の間は 1 次データベースとスタンバイ・データベースを引き続きピア状態にあるかのように動作するよう指定します。 プライマリがピアまたはこの
切断されたピア
状態で障害が発生した場合、スタンバイへのフェイルオーバーはデータ損失なしで発生します。 このフィーチャーにより最高度の保護が提供されます。 - いくつのスタンバイデータベースを展開しますか？
- HADR では、スタンバイ・データベースを 3 つまで使用できます。 複数のスタンバイ・データベースを使うと、単一のテクノロジーで高可用性と災害復旧の両方の目標を達成できます。 詳しくは、 HADR 複数スタンバイ・データベースを参照してください。
- HADR を Db2 pureScale® と結合しますか
Db2 pureScale フィーチャーは、優れた可用性とスケーラビリティーを提供し、高可用性と災害復旧の両方のニーズを満たすために HADR と組み合わせることができるようになりました。 詳しくは、 Db2 pureScale 環境での高可用性災害時リカバリー (HADR)を参照してください。
- スタンバイ・データベースの読み取り
- スタンバイ・データベースの読み取りフィーチャーを使用すれば、スタンバイ・データベースの HA や DR の動作に影響することなく、読み取り専用ワークロードを 1 つ以上のスタンバイに送信できます。 このフィーチャーは、スタンバイの主な役割に影響を与えることなく、1 次のワークロードを削減するのに役立ちます。
スタンバイ・データベースの読み取りを使用可能にしない限り、アプリケーションは、 現行 1 次データベースにしかアクセスできません。 スタンバイ・データベースの読み取りを使用可能にした場合は、読み取り専用アプリケーションをスタンバイにリダイレクトできます。 スタンバイデータベースの接続アプリケーションは、フェイルオーバーが発生した場合でもスタンバイの可用性に影響を与えません。
- 遅延再生
- 遅延再生を使用して、スタンバイ・データベースのログの再生時点が、必ず 1 次データベースの再生時点よりも前になるように指定できます。 プライマリでデータが失われたり破損したりした場合は、時間遅延スタンバイでこのデータを回復できます。
- ローリング更新とローリング・アップグレード
- HADR セットアップを使用すると、停止することなく、データベースに対してさまざまなタイプのアップグレードおよび Db2 フィックスパック更新を行うことができます。 複数のスタンバイ・データベースを使う場合、HADRに提供される保護を維持しながら、アップグレードを実行できます。 詳しくは、 Db2 高可用性災害時リカバリー (HADR) 環境へのローリング更新の適用を参照してください。
| 機能またはフィーチャー | プリンシパル・スタンバイ | 補助スタンバイ | Db2 pureScale 環境のプリンシパル・スタンバイ |
|---|---|---|---|
| 同期モード | すべてのモードがサポートされる | SUPERASYNC モードのみ | すべてのモードがサポートされる |
| スタンバイ・データベースの読み取り | サポートされる | サポートされる | サポートされていない |
| 遅延再生 | サポートされる | サポートされる | サポートされる |
| ログ・スプーリング | サポートされる | サポートされる | サポートされる |
| HADR スタンバイへの自動フェイルオーバーのためのクラスター・マネージャーとしての Tivoli SA MP | サポートされる | サポートされていない | サポートされていない |
| HADR スタンバイへの自動フェイルオーバーのためのクラスター・マネージャーとしてのPacemaker | サポートされる | サポートされていない | サポートされていない |
| ピア・ウィンドウ | サポートされる | サポートされていない | サポートされていない |
| ネットワーク・アドレス変換 (NAT) | サポートされる | サポートされる | サポートされていない |
| 自動クライアント・リルート (ACR) | サポートされる | サポートされる | サポートされる |
| クライアント・アフィニティー | 該当なし | 該当なし | サポートされる |
データベース内のほとんどのデータまたはすべてのデータで保護が必要な場合や、スタンバイ・データベースで自動的に複製する必要がある DDL 操作を実行する場合は、HADR が最善のオプションかもしれません。 ただし、HADR は、Db2 製品ファミリーで提供されている、いくつかのレプリケーション・ソリューションの 1 つに過ぎません。 InfoSphere® Federation Server ソフトウェアおよび Db2 データベース・システムには、高可用性を提供するために一部の構成で使用できる SQL レプリケーションおよび Q レプリケーション・ソリューションが含まれています。 これらのソリューションは、論理的に整合したデータベース表のコピーを、複数の場所で維持するものです。 さらに、列および行のフィルター操作、データ形式変更、表のコピーの更新のサポートなど、 柔軟かつ複雑な機能を提供します。 また、これらのソリューションはパーティション・データベース環境で使用することもできます。
IBM Data Studio バージョン 3.1 以降では、 HADR のセットアップのためにタスク・アシストを使用できます。 タスク・アシスタントは、オプションの設定、タスク実行のために自動生成されたコマンドの確認、およびそれらのコマンドの実行のプロセスをガイドします。 詳しくは、 タスク・アシストを使用したデータベースの管理を参照してください。