リカバリ・アプライアンス・レプリケーションの概要

図14-1の例では、保護されたデータベースがあるリカバリ・アプライアンスにバックアップを送信し、そのリカバリ・アプライアンスが別のリカバリ・アプライアンスにバックアップを転送します。このトポロジを一方向リカバリ・アプライアンス・レプリケーションと呼びます。1つめのリカバリ・アプライアンスはアップストリーム・リカバリ・アプライアンスで、2つめはダウンストリーム・リカバリ・アプライアンスです。

図14-1 単純なレプリケーション・トポロジ

「図14-1 単純なレプリケーション・トポロジ」の説明

その他のレプリケーション・トポロジの例に示されているように、その他の多くのレプリケーション・シナリオが考えられます。

レプリケーションの保護ポリシー

保護されたデータベースのレプリケーションが行われるのは、次の条件が満たされる場合です。

アップストリーム・リカバリ・アプライアンスで、レプリケーション・サーバー構成によってダウンストリーム・リカバリ・アプライアンスとして動作するリカバリ・アプライアンスが指定されていること(CREATE_REPLICATION_SERVER)。
アップストリーム・リカバリ・アプライアンスで、保護ポリシーがレプリケーション・サーバー構成に関連付けられていること(ADD_REPLICATION_SERVER)。
アップストリーム・リカバリ・アプライアンスで、レプリケーション・サーバー構成に関連付けられている保護ポリシーに保護されたデータベースが割り当てられていること(ADD_DB)。
ダウンストリームのリカバリ・アプライアンスで、保護ポリシー(CREATE_PROTECTION_POLICY)の作成、ポリシーへのデータベースの追加(ADD_DB)、データベースへのレプリケーション・アクセス権の付与(GRANT_DB)を、設定全体の最初に実行してください。

デフォルトでは、ADD_REPLICATION_SERVERを実行した後に、ポリシー内の各データベースの最新の完全バックアップがレプリケートされます。COPYALL_BACKUPがTRUEに設定されている場合、すべてのバックアップ(完全、増分、アーカイブ・ログ)がレプリケートされます。このレプリケーション・モードは、あるアプライアンスから別のアプライアンスにバックアップを移行する際に使用できます。その後は、アップストリームのリカバリ・アプライアンスが新しいバックアップを受け取るたびに、それらをレプリケートします。

リカバリ・アプライアンスでのバックアップのレプリケート方法: 基本プロセス

保護されたデータベースを永久的増分ポリシーを使用してリカバリ・アプライアンスにバックアップすると想定します。保護されたデータベースが、レプリケーションが構成されたリカバリ・アプライアンスにバックアップを送信すると、次の基本ステップが行われます。

アップストリーム・リカバリ・アプライアンスはバックアップを収集し、レプリケーション・サーバー構成に関連付けられているかどうか保護ポリシーを確認します。
保護ポリシーのレプリケーション・サーバー構成が存在する場合、アップストリーム・リカバリ・アプライアンスはバックアップをレプリケートします。レプリケーション・プロセスは次のとおりです。
- メタデータ・レコードを作成して、レプリケートされたレコードを追跡
  
  ノート:
  
  リアルタイムREDOトランスポートが有効である場合、受信したREDO変更はリカバリ・アプライアンスによってリアルタイムではレプリケートされません。アーカイブREDOログのバックアップが作成されると、リカバリ・アプライアンスは、このバックアップをデータ・ファイルのバックアップとともにレプリケートします。
- 指定された各ダウンストリーム・リカバリ・アプライアンスにネットワークを介してデータ・ブロックを転送
ダウンストリーム・リカバリ・アプライアンスはバックアップを収集して、仮想バックアップを作成します。

ノート:

ダウンストリームの収集フェーズは、ステップ1で説明した収集フェーズと同じです。このため、ダウンストリーム・リカバリ・アプライアンスもバックアップをレプリケートするように構成されている場合、アップストリーム・リカバリ・アプライアンスのロールを負い、バックアップをすぐ下流のリカバリ・アプライアンスにバックアップします。
その後間もなく、アップストリーム・リカバリ・アプライアンスはダウンストリーム・リカバリ・アプライアンスに調整リクエストを送信し、今度はダウンストリーム・リカバリ・アプライアンスがバックアップに関するメタデータをアップストリーム・リカバリ・アプライアンスに送信します。

リカバリ・アプライアンス・レプリケーションでは、調整はリカバリ・アプライアンスがすぐ下流のリカバリ・アプライアンスからメタデータを受信するプロセスです。

このため、バックアップがレプリケートされた後は、アップストリームおよびダウンストリーム・リカバリ・カタログの両方が保護されたデータベースのバックアップのレコードを所持します。

アーカイブされたバックアップのミラーリング

アーカイブされたバックアップのミラーリング(SBTミラーリング)を使用すると、レプリケーション・パートナとして構成されたダウンストリームのリカバリ・アプライアンスが、アップストリームのリカバリ・アプライアンスがテープ、クラウドまたはサード・パーティのストレージに作成した、外部格納のバックアップにアクセスできます。

リモートのリカバリ・アプライアンスに外部ストレージがもともと設定されていなかった場合でも、ローカルSBTライブラリが同じ外部ストレージにアクセスするように、RACLIまたはシステム管理者によって構成されます。

RA 23.1より前は、ダウンストリームのリカバリ・アプライアンスに、アップストリームのリカバリ・アプライアンスのバックアップおよびカタログ・レコードのコピーがありますが、外部ストレージにアーカイブされたバックアップに関する情報やアクセス権はありませんでした。RA 23.1以降では、アーカイブされたバックアップのミラーリングを使用すると、ソースのレプリケートされたリカバリ・アプライアンスからリモートのリカバリ・アプライアンスに、このバックアップに関する詳細が取得されます。

Copy-to-tapeおよびarchived-to-cloudのバックアップ・レコードは、レプリケーション・ペアのリカバリ・アプライアンス・カタログ間でミラーリングされるため、どちらのリカバリ・アプライアンスも、リストア操作に必要なテープやクラウドのバックアップにアクセスできます。これは、各リカバリ・アプライアンスに同じSBTライブラリ名を設定して、テープやクラウド用に構成されたSBTライブラリにsbt_mirroring=>'TRUE'を設定することで有効になります。

ノート:

有効化する前に、両方のリカバリ・アプライアンスが同じ外部ストレージを指していることを確認する必要があります。

ローカルSBTライブラリは、SBTライブラリ・マッピングを使用して、レプリケートされたバックアップ・ピースとリンクされています。これにより、外部に格納されているレプリケーション・バックアップ・ピースを、リストア操作用にローカルで使用できるようになります。

CREATE_SBT_LIBRARYおよびUPDATE_SBT_LIBRARYは、新しい列sbt_mirrorが指定されたライブラリ・メタデータ(SBT_LIB_DESC)を指定するのに役立ちます。ライブラリにミラーリングのマークが付いていても、対応するパートナがもう一方のリカバリ・アプライアンスにない場合は、調整(reconcile)時にライブラリ情報の交換が行われず、すべてが以前と同様に続行されます。

要件

名前が同じで、パートナのリカバリ・アプライアンスと同じ外部ストレージにアクセスするリモートSBTライブラリを、リモートのリカバリ・アプライアンスのSBTライブラリに設定します。
リカバリ・アプライアンスのレプリケート・ペア間で、同じライブラリ名を使用します。リカバリ・アプライアンスのライブラリ名は常に一意であるため、この一意性およびライブラリ・タイプとレプリケーション・ペアの詳細が、リカバリ・アプライアンス間でSBTライブラリをマップするのに役立ちます。ライブラリ・タイプには、T (テープ)またはC (クラウド)を指定できます。
SBTミラーは、自動化しなくてもAPIで設定できます。リカバリ・アプライアンス間の移行シナリオの場合、RACLIよる移行では、宛先のリカバリ・アプライアンスで必要なすべての構成の設定が、SBTライブラリも含めて自動化されます。
この自動化レイヤーでは、設定を実行する前に、ペアになっているリカバリ・アプライアンスでライブラリ名の競合があるかどうかも確認する必要があります。

SBTミラーリングの使用

パートナのリカバリ・アプライアンス間のすべてのメタデータのマッピングは、reconcileを介して行われます。これにより、レプリケートするパートナのリカバリ・アプライアンス間でカタログ・メタデータが同期され、アップストリームのリカバリ・アプライアンスがダウンストリームのバックアップ・メタデータにアクセスできるようになります。

ミラーリングを設定しても、すぐには有効になりません。調整(reconcile)や(最終的に暗黙の調整(reconcile)を開始する)次のバックアップにより、変更が実施されます。

ユーザーが、sbt_mirrorをYESに設定してCREATE_SBT_LIBRARYまたはUPDATE_SBT_LIBRARYをコールします。これにより、必要な設定の自動化が呼び出されます。
トリガーされた自動化では、レプリケートするように関連付けられているリカバリ・アプライアンスが参照され、前述のライブラリ名とタイプの指定を使用してSBTライブラリの作成が開始されます。
この自動化により、ペアになっているリカバリ・アプライアンスに、同じ名前のSBTライブラリが存在しないことが確認されます。
この自動化レイヤーにより、パートナのリカバリ・アプライアンスに(sbt_mirrorをYESに設定された)新しいSBTライブラリが作成されます。このライブラリは、この自動化を開始したリカバリ・アプライアンスと同じ外部ストレージの場所に(同じライブラリ名のままで)アクセスできます。

RMANがレプリケーション環境でバックアップをリストアする方法

保護されたデータベースをリストアする場合、一般にRMANは当初バックアップを送信した同じリカバリ・アプライアンスにAS CATALOGを接続します。たとえば、図14-2では、RMANがorcl11をリストアする必要がある場合、RMANはアップストリーム・リカバリ・アプライアンス上のカタログに接続します。

バックアップがレプリケーション・スキーマの任意のリカバリ・アプライアンスにある場合、アップストリーム・リカバリ・アプライアンスは他のリカバリ・アプライアンスからバックアップを取得してリストアできます。たとえば図14-2では、RMANがorcl11をリストアする必要がある場合、アップストリームのバックアップがパージされていて、ダウンストリームのリカバリ・アプライアンスでバックアップがまだ使用可能な場合は、それらのバックアップがアップストリームのリカバリ・アプライアンスに転送され、その後データベースに転送されます。

必要に応じて、RMANはダウンストリーム・リカバリ・アプライアンスから直接バックアップをリストアすることもできます。RMANはAS CATALOGをダウンストリーム・リカバリ・アプライアンスに接続してから、バックアップをリストアします。たとえば、図14-2で、RMANがprod3をリストアする必要があるが、アップストリーム・リカバリ・アプライアンスが一時的にアクセス不可である場合、RMANはダウンストリーム・リカバリ・アプライアンス上のカタログに直接接続して、保護されたデータベース・ホストに直接バックアップをリストアできます。

ノート:

Oracle Enterprise Manager Cloud Control (Cloud Control)またはコマンドラインを使用している場合、ダウンストリーム・リカバリ・アプライアンスからバックアップをリストアするには追加構成が必要です。『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。