レプリケーションのユースケース

ダウンストリーム・リカバリ・アプライアンスはアップストリーム・リカバリ・アプライアンスに依存せずにバックアップを処理するため、バックアップを格納する各データベースに対してまったく異なるポリシーを持つことができます。この設計により、様々なユースケースを構成できます。一般に、レプリケーションのユースケースは、ローカル・リカバリ・アプライアンスが停止または損失した場合にデータベースのバックアップおよびリカバリ操作を維持することです。次に説明するレプリケーション・トポロジでは、これを実現する方法を示します。

一方向

ローカルの保護されたデータベース(DB-a)からのバックアップ・データはアップストリーム・リカバリ・アプライアンス(RA-x)に送信され、RA-xがリモートのダウンストリーム・リカバリ・アプライアンス(RA-y)に転送します。

図rep_oneway.pngの説明
双方向

ローカルの保護されたデータベース(DB-a)からのバックアップ・データはローカルのリカバリ・アプライアンス(RA-x)に送信され、RA-xがリモートのリカバリ・アプライアンス(RA-y)に転送します。逆に、リモート・データベース(DB-d)からのバックアップ・データはRA-yに送信され、RA-yがRA-xに転送します。

双方向レプリケーションは、基本的に、保護されたデータベースの特定のセット(DB-a、DB-b、DB-c)に対するRA-xからRA-yへの一方向レプリケーションであり、保護されたデータベースの別のセット(DB-d、DB-e、DB-f)に対するRA-yからRA-xへの一方向レプリケーションでもあります。

図rep_bidirectional.pngの説明
このケースでは、各リカバリ・アプライアンスがレプリケーション・トポロジのアップストリームとダウンストリーム両方の役割を果たします。すべてのリカバリ・アプライアンスは、一方の保護データベース・セットのプライマリ・バックアップの場所、および他方のセットのセカンダリ・バックアップの場所として使用されます。このように、それぞれのリカバリ・アプライアンスがよく利用され、もう一方のリカバリ・アプライアンスに障害回復サービスを提供します。
ハブアンドスポーク

一方のデータベース・セットのバックアップがローカル・リカバリ・アプライアンスに送信され、別のデータベース・セットのバックアップが別のローカル・リカバリ・アプライアンスに送信されます。これらのローカル・リカバリ・アプライアンスはバックアップを1つのリモート・リカバリ・アプライアンスに転送し、リモート・リカバリ・アプライアンスがバックアップをテープにアーカイブします。

図rep_hubspoke.pngの説明
場所を問わないバックアップ

2つのリカバリ・アプライアンスRA-xとRA-yは相互にレプリケートされ、相互にアップストリームでありダウンストリームです。データベースDB-aおよびDB-bからのバックアップは、それぞれのアップストリーム・リカバリ・アプライアンスであるRA-xおよびRA-yに送信されます。次に、RA-xおよびRA-yは、それぞれのダウンストリーム・リカバリ・アプライアンスであるRA-yおよびRA-xにこれらのバックアップをレプリケートします。データベースDB-aおよびDB-bからのバックアップは、DBからバックアップを直接受信しなかったリカバリ・アプライアンスに対して発生するレプリケーションによって、RA-xまたはRA-yに送信できます。

図rep_backupanywhere.pngの説明
読取り専用レプリケーション

read_onlyレプリケーション・モードは、データベース・バックアップの宛先リカバリ・アプライアンスを元のRA-xから別のRA-yに変更する一方で、RA-xはRA-yから引き続き使用できるようにする際に役立ちます。これにより、RA-xからRA-yに古いバックアップをレプリケートするという時間のかかるネットワーク集中型の作業が必要がなくなります。元のRA-xがRA-yから使用可能な場合、read_onlyモードのレプリケーション・サーバー構成をRA-yの保護ポリシーに追加できます。この保護ポリシーでは、RA-xをダウンストリームとして指定します。ダウンストリームに存在する、ポリシー内のデータベースのすべてのバックアップは、必要な場合にアップストリームから取得できます。保護ポリシーに従って元のRA-x上の古いバックアップが期限切れになると、RA-yはRA-x上のバックアップを必要としなくなります。これにより、RA-xをレプリケーション・トポロジから削除できます。

図rep_readonly.pngの説明
read_onlyレプリケーションの主なユースケースは、元のリカバリ・アプライアンスを廃止したり、保護されたデータベースのワークロードを追加のリカバリ・アプライアンス間でスケール・アウトできるようにしたりするために、新しいリカバリ・アプライアンスをレプリケーション構成に導入することです。これにより、古いバックアップ・ファイルの不要な転送および複製を行わずに、リカバリ・アプライアンス間でバックアップ/リストアを正常に転送できます。
リクエスト・モード・レプリケーション

request_onlyモード・レプリケーションでは、アップストリーム(RA-x)のリカバリ・アプライアンスはプライマリ・データベースのバックアップを受信し、ダウンストリーム(RA-y)はスタンバイ・データベースのバックアップ、REDOログおよびアーカイブ・ログを受信します。計画メンテナンスのためにアップストリームRA-xがオフラインの場合、プライマリ・データベースのREDOログおよびアーカイブ・ログはダウンストリームRA-yにリダイレクトされ、そこでデータベースのリカバリ性を維持するために新しいアーカイブ・ログのバックアップが作成されます。ローカルのアーカイブ・ログ・ディレクトリが一杯になるとデータベースがハングする可能性があるため、REDOログおよびアーカイブ・ログはアップストリーム・データベースから取得する重要なデータです。したがって、DB-a上のRMANで安全に削除できるように、これらはRA-yに転送されます。

コマンドRMAN CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP 1 TIMESでは、REDOがRA-yに送信およびバックアップされた場合、RA-xがローカルのアーカイブ・ログを安全に削除して領域を再利用できるようにします。このポリシーが構成されている場合、コマンドRMAN DELETE ARCHIVELOGを使用して、ローカルのアーカイブ・ログ領域を安全に再利用することもできます。

RA-yはRA-xの停止の影響を受けず、通常どおりスタンバイ・データベースからレベル1のバックアップを受け取ります。RA-yのスタンバイ・バックアップは、プライマリ・データベースのリストアに使用できます。RA-xがオンラインに戻ると、以前にリダイレクトされたすべてのバックアップがダウンストリームRA-yからアップストリームRA-xにレプリケートされ、データベースの完全なリカバリ性が再確立されます。

図rep_request.pngの説明
カスケード・モード・レプリケーション

これらのユースケースのどれでもカスケード・レプリケーションに使用できます。カスケード・レプリケーションでは、アップストリーム・リカバリ・アプライアンスがダウンストリーム・リカバリ・アプライアンスにレプリケートされ、ダウンストリーム・リカバリ・アプライアンスが別のリカバリ・アプライアンスにレプリケートされて、リカバリ・アプライアンスの一方向チェーンが構築されます。

図rep_cascade.pngの説明