RACLIを使用したリカバリ・アプライアンス間のレプリケーションの構成

この項では、RA1およびRA2という名前の2つのリカバリ・アプライアンス間にレプリケーションを確立するためのRACLIタスクについて説明します。ほとんどのタスクは、RA1でadmin_userアカウントを使用して実行します。

レプリケーション・ユーザーおよびレプリケーション・ウォレットは、racli create replication_serverおよびracli delete replication_server内で管理されます。リカバリ・アプライアンスのパートナ・ユーザーは、レプリケーション・ユーザー、レプリケーション・ウォレットおよびレプリケーション・サーバー・パラメータを管理します。

ノート:

リカバリ・アプライアンス23.1より前のバージョンおよびDBMS_RAでレプリケーションが確立されていた場合、今後はRACLIコマンドを使用することをお薦めします。RACLIレプリケーションにレプリケーションを変更するには、この項で後述するように、racli add ra_partnerおよびracli enable replication_managementを使用します。

これが完了すると、クライアント・データベースがバックアップをRA1に送信します。レプリケーションの一部として、RA1がこれらのバックアップをRA2にも送信します。

ノート:

この場合のレプリケーション・サーバーはRA1です。作成されるレプリケーション・ユーザーは、RA2用です。

タスク1: レプリケーションに必要なadmin_userユーザー・タイプを作成します。

どちらのリカバリ・アプライアンスにも、できれば同じ名前のadmin_userが必要です。RA1とRA2の両方で、次を実行します: 

racli add admin_user --user_name=REPL_ADMIN_NAME

新しいユーザー(REPL_ADMIN_NAME)がまだ存在していなかった場合は、パスワードの入力を求められます。

ノート:

レプリケーション・ユーザーのパスワード要件は次のとおりです。

  • 合計で15文字以上
  • 1文字以上の小文字
  • 1文字以上の大文字
  • 1つ以上の数字
  • 1つ以上の特殊文字

例: Welcome*123456789

admin_userが作成されたことを確認します。 

racli list admin_user

RA2で新しく作成したadmin_user (REPL_ADMIN_NAME)のuser_name、user_uidおよびuser_gudを後で参照できるように書き留めます。

タスク2: 両方のリカバリ・アプライアンスで、replicationのレプリケーションdb_userを作成します。

このレプリケーションdb_userは、RA1およびRA2の両方のリカバリ・アプライアンスで同じにしてください。この例では、db_userはREP_USER_FROM_DB1_TO_DB2およびREP_USER_FROM_DB2_TO_DB1です。これは、RA1とRA2の両方に対して実行します。 

racli add db_user -user_name=<REPL_VPC_USER> --user_type=replication

このレプリケーションdb_userは、パートナ・ユーザー(admin_user)とは異なります。

タスク3: 2つのリカバリ・アプライアンス間のパートナシップを作成します。

RA1で、RA2の--admin_userの資格証明を使用してパートナ接続を作成します。

ノート:

レプリケーションが双方向の場合、RA2でこのコマンドを実行する必要はなく、以降のracli create replication_serverで--type=bidrectionalを指定してください。 

racli add ra_partner --target_host=<RA2> 
--partner_user=REPL_PARTNER_RA1 --partner_uid=UID 
--admin_user=REPL_ADMIN_NAME --admin_key=VALUE
  • --target_hostには、RA2からの最初のコンピュート・ノードの完全修飾ドメイン名(FQDN)を指定します。
  • --partner_userには、指名されたパートナの名前を指定します。これは、証明書を管理し、SSHキーを渡して双方向の認証および権限を作成するために、制限された権限を持つroot以外のユーザーにしてください。
  • --partner_uidには、パートナ・ユーザーの数値ユーザーID (UID)を指定します。クラウド・システムの場合、UID値は3000未満にする必要があります。
  • rootユーザーを使用してクラスタにアクセスできない場合は、--admin_userに管理ユーザーを指定します。これは、root、またはパスワードまたはSSHキーを使用してRA2にアクセスできる任意のadminユーザーにできます。クラウドベースのインスタンスでは必須ですが、オンプレミスではオプションです。
  • rootユーザーを使用してクラスタにアクセスできない場合は、adminユーザーのSSHキーを--admin_keyに指定します。クラウドベースのインスタンスの場合、または--admin_userが指定されている場合は必須です。

タスク4: レプリケーション・サーバーを作成します。

この操作は、RA1から実行します。RA2のレプリケーション・ユーザーの資格証明情報は、RA1のレプリケーション・ウォレットに格納されます。

ノート:

このracli create replication_serverコマンドでは、レプリケーション・ユーザーのパスワード・プロンプトが表示されます。レプリケーション・ウォレットが存在しない場合は作成されます。レプリケーション・ユーザーとレプリケーション・ウォレットを個別に作成する必要はありません。 

racli create replication_server --target_host=PATH2TARGET 
--type=bidirectional [--certificates=YOURLIST]
  • --target_hostには、ペアにするターゲット・リカバリ・アプライアンスの最初のノードへのフルパスを指定します。
  • --type=bidirectionalで、双方向レプリケーションを指定します。
  • --certificates=cert1,cert2,cert3...には、1つ以上の証明書をフルパスで指定します。RA1とRA2が同じ信頼できる証明書を共有する場合は、信頼できる証明書が1つのみ必要です。

racli list listenerコマンドは、TCPまたはTCPSのどちらが使用されているかに関する情報を表示します。

例1: 双方向レプリケーション。

racli create replication_server --target_host=<RA2> --backup_anywhere
  –certificates=/raacfs/raadmin/cert/raCA.pem

例2: ダウンストリームのリカバリ・アプライアンスでのみTLSが有効になっている一方向レプリケーション。信頼できる証明書をRA2からRA1にコピーします 

scp root@RA2:<TRUSTED CERT FROM RA2> /tmp/<CERTNAME>.pem

racli create replication_server --target_host=<RA2> – certificates=/tmp/<CERTNAME>.pem

例2: ダウンストリームのリカバリ・アプライアンスでのみTLSが有効になっている双方向レプリケーション。信頼できる証明書をRA2からRA1にコピーします 

scp root@RA2:<TRUSTED CERT FROM RA2> /tmp/<CERTNAME>.pem

racli create replication_server --target_host=<RA2> --type=backup_anywhere
--certificates=/tmp/<CERTNAME>.pem,/raacfs/raadmin/cert/<raCA>.pem

ノート:

このタスクの後、レプリケーションはRACLIコマンドを使用して完全に管理されます

タスク5: 保護ポリシーを作成します。

適切な保護ポリシーが存在しない場合は、レプリケーションに適したポリシーを作成できます。

racli create protection_policy --protection_policy_name=YOUR_POLICY 
--storage_location_name=<YOURLOC> --recovery_window_goal=11day --autotune_reserved_space=YES

その他の適切な引数については、racli create protection_policyを参照してください。

タスク6: 保護されたデータベースを追加します。

他の方法(DBMS_RA APIまたはEnterprise Manager Cloud Control)で保護ポリシーがデータベースに割り当てられていない場合は、次のようなコマンドを発行します。

racli add protected_db --db_unique_name=<yourDB>  
--protection_policy_name=<YOUR_POLICY> --reserved_space-10G

タスク7: 両方のZDLRAのレプリケーション・ユーザーに、保護されたデータベース・アクセス権を付与します 

racli grant db_access --db_unique_name=test_db --tenant_identifier=1111 -username=REP_USER_FROM_DB1_TO_DB2 
racli grant db_access --db_unique_name=test_db --tenant_identifier=1111 -username=REP_USER_FROM_DB2_TO_DB1

タスク8: 保護されたデータベース・アクセスを付与します。

前のステップで作成したレプリケーション・ユーザー名を特定します。

racli list db_user

適切なレプリケーション・ユーザー名を使用して、アクセス権を付与します。

racli grant db_access --db_unique_name=<yourDB> --username=REPL_ADMIN_NAME

タスク9: レプリケーション・サーバーを追加します

このコマンドは、RA1とRA2の両方で実行します。

racli add replication_server --replication_server_name=<REPL> --protection_policy_name=YOUR_POLICY
--replication_user_name=rep_user_from_DB1_to_DB2
--ra_partner_user=REPL_PARTNER_RA1

レプリケーション・サーバー管理用のRACLIコマンドは次のとおりです:

  • racli add replication_server
  • racli delete replication_server
  • racli list replication_server
  • racli remove replication_server
  • racli status replication_server
  • racli update replication_server

レプリケーション・ユーザー管理用のRACLIコマンドは次のとおりです:

  • racli add replication_user
  • racli alter replication_user [パスワードの変更用]
  • racli list replication_user
  • racli remove replication_user

レプリケーション・ウォレット管理用のRACLIコマンドは次のとおりです:

  • racli add replication_wallet
  • racli alter replication_wallet
  • racli list replication_wallet
  • racli remove replication_wallet