レプリケーション・パートナおよびユーザー・アカウントについて

障害回復戦略の一部として、リカバリ・アプライアンスでは他のリカバリ・アプライアンスにバックアップをレプリケートできます。また、テープ・アーカイブをレプリケートされたリカバリ・アプライアンスにオフロードすることで、プライマリ・リカバリ・アプライアンスのリソースを解放できます。レプリケーションは保護ポリシーによって制御されます。すなわち、ポリシーに関連付けられているすべてのデータベースが、初期設定後、完全に自動的にレプリケートされます。

リカバリ・アプライアンス間でレプリケーションするための要件は、すべてのレプリケーションのリカバリ・アプライアンス間で、関連するすべてのデータベースに一意の名前が付けられていることです。

リカバリ・アプライアンス・レプリケーション専用のレプリケーション・ユーザー・アカウントを作成し、組織内の各アップストリーム・アプライアンスには一意のレプリケーション・ユーザー・アカウントを作成する必要があります。

レプリケーション・パートナ

RAパートナを使用すれば、レプリケーションが簡素化されます。レプリケーション・パートナシップは、パートナ間で共通の管理タスクを自動化するRACLIを使用して確立されるため、ヒューマン・エラーの可能性と各システムにリモートでログインする必要性が軽減されます。

RACLIで、2つのリカバリ・アプライアンス間の接続を確立します。

レプリケーション・ユーザー・アカウント

レプリケーション・ユーザーは、マルチテナンシを使用する必要のないadd_db/grant_db_accessまたはregister_tenant_user('repuser name', 1)のいずれかのダウンストリームに定義する必要があります。

Oracleでは、レプリケーション・ユーザー・アカウントの形式はREPUSER_FROM_[ZDLRA_DB_NAMEまたはZDLRA_DB_LOCATION]_TO_[ZDLRA_DB_NAMEまたはZDLRA_DB_LOCATION]にすることをお薦めします。

たとえば、2つのリカバリ・アプライアンスのDB_UNIQUE_NAMEがZDLRA1およびZDLRA2の場合、レプリケーション・ユーザー・アカウントはREPUSER_FROM_ZDLRA1_TO_ZDLRA2およびREPUSER_FROM_ZDLRA2_TO_ZDLRA1のようになります。または、同じ2つのリカバリ・アプライアンスがFlorenceおよびViennaにある場合、レプリケーション・ユーザー・アカウントはREPUSER_FROM_FLORENCE_TO_VIENNAおよびREPUSER_FROM_VIENNA_TO_FLORENCEのようになります。

レプリケーション・ユーザー・アカウントは、racli add db_userと--user_type=replicationを使用して作成されます。レプリケーション・ユーザー・アカウントは、リカバリ・アプライアンスへの接続やバックアップの送信を行うために保護されたデータベースが使用する通常のVPCユーザーとして使用しないでください。

レプリケーションに関連付けられたユーザー・アカウントの重要な区別を次に示します。

RA Partner User

RACLIで使用されるレプリケーション・サーバーの作成、管理、およびヘルスを実行可能な制限付きロールが設定されたオペレーティング・システム・ユーザーです。

1人のパートナ・ユーザーが1つのパートナ・リカバリ・アプライアンスに接続されています。管理ユーザーに基づく制限付き権限があります。

RA Replication User

ダウンストリームのリカバリ・アプライアンスに作成されるデータベース・ユーザーです。この資格証明は、アップストリーム・リカバリ・アプライアンス・レプリケーション・ウォレットに格納されます。

例: rep_user_from_<USDB>_to_<DSDB>

Certificates

アップストリームRAとダウンストリームRA間のTLSセキュア通信に必要です

RA Replication Wallet

すべてのレプリケーション・ユーザー資格証明(ダウンストリーム・リカバリ・アプライアンスの証明書)を格納するウォレットです。

Replication Server

アップストリームからダウンストリームへのレプリケーション・サーバーです。

例: rep_server_from_<USDB>_to_<DSDB>