レプリケーション・トポロジの例
レプリケーション・トポロジは、必要だけ複雑にすることができます。主な変数は、次のとおりです。
-
レプリケーション環境内のリカバリ・アプライアンスの合計数および相互の関係
-
送信レプリケート済バックアップを管理するアップストリーム・リカバリ・アプライアンスの保護ポリシー(CREATE_PROTECTION_POLICY)、および受信レプリケート済バックアップを管理するダウンストリーム・リカバリ・アプライアンスのポリシー -
レプリケーション環境内の各リカバリ・アプライアンスのレプリケーション・サーバー構成(
CREATE_REPLICATION_SERVER) -
レプリケーション・サーバー構成と保護ポリシーとの関連付け(
ADD_REPLICATION_SERVER)
アップストリーム・リカバリ・アプライアンスが複数のダウンストリーム・リカバリ・アプライアンスにレプリケートし、ダウンストリーム・リカバリ・アプライアンスが複数のアップストリーム・リカバリ・アプライアンスからバックアップを受け取るように、レプリケーションをチェーンすることができます。ダウンストリーム・リカバリ・アプライアンスは、自らの保護されたデータベースとレプリケートされたバックアップの両方からバックアップを受け取ることができます。レプリケーション・トポロジ内のすべてのリカバリ・アプライアンスは、アップストリーム・レプリケーション・ロールとダウンストリーム・レプリケーション・ロールを同時に実行できます。
ノート:
リカバリ・アプライアンスがアップストリームとダウンストリームの両方である場合、両方のロールに対して構成する必要があります。
1つのダウンストリーム・リカバリ・アプライアンスへのレプリケーション
図14-2に、reppolicy_us_bronze保護ポリシー(orcl08、orcl09およびorcl10)に関連付けられている3つのデータベースと、reppolicy_us_gold保護ポリシー(orcl11、orcl12およびorcl13)に関連付けられている3つのデータベースを示します。reppolicy_us_goldのみがus_bost_ds_desmというレプリケーション・サーバー構成に関連付けられています。このトポロジでは、アップストリームZDLRA Bostonはreppolicy_us_goldポリシーによって保護されたデータベースのバックアップのみをダウンストリームZDLRA Des Moinesに転送します。
複数のダウンストリーム・リカバリ・アプライアンスへのレプリケーション
保護されたデータベースそれぞれに独自の保護ポリシーがあるため、各ポリシーを異なるレプリケーション・サーバー構成に関連付けることができます。たとえば、図14-3では、reppolicy_us_bronzeポリシーは、reppolicy_us_bronze (orcl08、orcl09およびorcl10)によって保護されたデータベースのバックアップをZDLRA San Franciscoというダウンストリーム・リカバリ・アプライアンスにレプリケートするレプリケーション・サーバー構成us_bost_ds_sfに関連付けられています。reppolicy_us_bronzeポリシーは、reppolicy_us_gold (orcl11、orcl12およびorcl13)によって保護されたデータベースのバックアップをZDLRA Des Moinesというダウンストリーム・リカバリ・アプライアンスにレプリケートするレプリケーション・サーバー構成us_bost_ds_desmに関連付けられています。
ダウンストリーム・リカバリ・アプライアンスでの異なるポリシーを使用したレプリケーション
レプリケーション・スキーマの各ダウンストリーム・リカバリ・アプライアンスでは、保護ポリシーによってディスク・リカバリ・ウィンドウ目標と受け取ったバックアップのテープ保存ポリシーが定義されます。ダウンストリーム構成とアップストリーム構成は完全に独立しています。このため、ダウンストリーム・リカバリ・アプライアンスを長期保存バックアップ・リポジトリとして使用するなど、アップストリーム・リカバリ・アプライアンスよりも多くの記憶域および長いリカバリ・ウィンドウでダウンストリーム・リカバリ・アプライアンスを構成することができます。
図14-4は、アップストリーム・リカバリ・アプライアンスのreppolicy_us_bronzeバックアップが、ZDLRA San Franciscoのreppolicy_ds_bronzeポリシーによって保護されていることを示しています。アップストリーム・リカバリ・アプライアンスのreppolicy_us_bronzeバックアップは、ZDLRA Des Moinesのreppolicy_ds_goldポリシーによって保護されています。
カスケード型レプリケーション
図14-5に、より複雑なトポロジを示します。データベースorcl11、orcl12およびorcl13は、最も遠いアップストリームであるZDLRA Bostonのreppolicy_us_gold保護ポリシーによって保護されています。reppolicy_us_goldポリシーはこれらのデータベースのバックアップを、すぐ下流のZDLRA Des Moinesにレプリケートします。ただし、ZDLRA Des Moinesには、データベースorcl11およびorcl12を保護するreppolicy_ds_gold1とデータベースorcl13のみを保護するreppolicy_ds_gold2の2つの別個の保護ポリシーがあります。
図14-5では、reppolicy_ds_gold2保護ポリシーはレプリケーション・サーバー構成us_desm_ds_laに関連付けられています。その後、ZDLRA Des Moinesはreppolicy_ds_gold2によって保護されている唯一のデータベースorcl13のバックアップを、最も遠いダウンストリーム・リカバリ・アプライアンスであるZDLRA Los Angelesにレプリケートします。ZDLRA Los Angelesにあるorcl13のバックアップは、reppolicy_dds_goldポリシーによって保護されています。3つ以上のリカバリ・アプライアンスがチェーンにリンクされているこの構成を、カスケード型レプリケーションと呼びます。
リカバリ・アプライアンス間の双方向レプリケーション
双方向レプリケーション(場所を問わないバックアップのレプリケーションとも呼ばれる)を使用すると、2つのリカバリ・アプライアンスRA-xおよびRA-yで、同じ(または異なる)保護されたデータベースを相互にレプリケートできます。したがって、どちらのリカバリ・アプライアンスにも、バックアップの完全なセットがあります。
図rep_backupanywhere.pngの説明
2つのリカバリ・アプライアンスRA-xとRA-yは相互にレプリケートされ、相互にアップストリームでありダウンストリームです。保護されたデータベースDB-aおよびDB-bからのバックアップは、それぞれのアップストリーム・リカバリ・アプライアンスであるRA-xおよびRA-yに送信されます。リカバリ・アプライアンス間でバックアップ状態を同期化するために、新しいバックアップが他の(ダウンストリーム)リカバリ・アプライアンスにレプリケートされます。
高可用性/障害回復(HADR)構成でのこの動作の例については、HADRのレプリケーション・モードを参照してください。
レプリケーション・リクエスト専用モード
リクエスト専用モードのレプリケーションは計画メンテナンスに有用であり、データベース・バックアップ、REDOログおよびアーカイブ・ログの量を減らします。これを、メンテナンスの完了時にデータベースの完全なリカバリ性を再確立するためにリカバリ・アプライアンス間で転送する必要があります。
request_onlyモード・レプリケーションでは、アップストリーム(RA-x)のリカバリ・アプライアンスはプライマリ・データベースのバックアップを受信し、ダウンストリーム(RA-y)はスタンバイ・データベースのバックアップ、REDOログおよびアーカイブ・ログを受信します。計画メンテナンスのためにアップストリームRA-xがオフラインの場合、プライマリ・データベースのREDOログおよびアーカイブ・ログはダウンストリームRA-yにリダイレクトされ、そこでデータベースのリカバリ性を維持するために新しいアーカイブ・ログのバックアップが作成されます。
RA-yはRA-xの停止の影響を受けず、通常どおりスタンバイ・データベースからレベル1のバックアップを受け取ります。RA-yのスタンバイ・バックアップは、プライマリ・データベースのリストアに使用できます。RA-xがオンラインに戻ると、以前にリダイレクトされたすべてのバックアップがダウンストリームRA-yからアップストリームRA-xにレプリケートされ、データベースの完全なリカバリ性が再確立されます。
図rep_request.pngの説明
リクエスト・モードは、「実行されていない間に作成できなかったバックアップをリクエストする機能を持つ読取り専用レプリケーション」と考えることができます。リクエスト・モードは、場所を問わないバックアップを有効にしたテクノロジを使用して構築されますが、場所を問わないバックアップではありません。
ローカルのアーカイブ・ログ・ディレクトリが一杯になるとデータベースがハングする可能性があるため、REDOログおよびアーカイブ・ログはアップストリーム・データベースから取得する重要なデータです。したがって、DB-a上のRMANで安全に削除できるように、これらはRA-yに転送されます。
コマンドRMAN CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP 1 TIMESでは、REDOがRA-yに送信およびバックアップされた場合、RA-xがローカルのアーカイブ・ログを安全に削除して領域を再利用できるようにします。このポリシーが構成されている場合、コマンドRMAN DELETE ARCHIVELOGを使用して、ローカルのアーカイブ・ログ領域を安全に再利用することもできます。
リカバリ・アプライアンス間での読取り専用のレプリケーション
read_onlyレプリケーション・モードは、データベース・バックアップの宛先リカバリ・アプライアンスを元の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レプリケーションの重要なユースケースは、ロード・バランシングや古いリカバリ・アプライアンスのデコミッションのために新しいリカバリ・アプライアンスをコミッションする場合など、異なるリカバリ・アプライアンスをデータベース・バックアップの宛先として使用する場合です。これにより、リカバリ・アプライアンス間でバックアップ/リストアを正常に転送できます。
COPYALLレプリケーション
COPYALLモードは保護ポリシーで確立され、文字どおりそのポリシー内のデータベースの既存のすべてのバックアップをダウンストリーム・リカバリ・アプライアンスにレプリケートします。これには、期限切れの可能性があるがアップストリーム・リカバリ・アプライアンスからまだパージされていないバックアップが含まれます。
アップストリーム・リカバリ・アプライアンスでは、バックアップは制御された順序でレプリケートされます。
ダウンストリーム・リカバリ・アプライアンスでは、収集はCOPYALL対応であり、正しく機能します。具体的には、バックアップは正しい順序で収集されます。
バックアップは、COPYALLプロセス中にアップストリームまたはダウンストリームに送信できます。
ダウンストリーム・リカバリ・アプライアンスでは、データベースをCOPYALLの宛先にできるのは1回のみです。
COPYALLモードは、あるリカバリ・アプライアンスから別のリカバリ・アプライアンスへのデータベースの移行または移動の基盤になります。他のレプリケーション・モードでは、データベースを新しいリカバリ・アプライアンスに移行できますが、古いリカバリ・アプライアンスからバックアップ・データを削除する前に、完全なリカバリ・ウィンドウを待機する必要があります。COPYALLモードを使用して、すべてのデータをダウンストリーム・リカバリ・アプライアンスに強制します。