Configuring Replication between Recovery Appliances Using RACLI
This section describes the RACLI tasks for establishing replication between two Recovery Appliances, named RA1 and RA2. Most of the tasks are performed on RA1 with an admin_user
account.
The replication user and replication wallet are managed within racli create replication_server
and racli delete replication_server
. The Recovery Appliance partner user manages the replication user, replication wallet, and replication server parameters.
Note:
If the replication was established with a version earlier than Recovery Appliance 23.1 and DBMS_RA, the recommendation is to use the RACLI commands going forward. To change replication to RACLI replication, useracli add ra_partner
and racli enable replication_management
as provided later in this section.
Upon completion of this, the client database sends its backups to RA1. RA1 as part of replication sends those backups to RA2 as well.
Note:
The replication server in this case is RA1. The replication user that is created is for RA2.
Task 1: Create the admin_user
user types needed for replication.
Both Recovery Appliances require an admin_user
, preferably named the same. On both RA1 and RA2, run:
racli add admin_user --user_name=REPL_ADMIN_NAME
If the new user (REPL_ADMIN_NAME
) did not already exist, you are prompted for a password.
Note:
The replication user has the following password requirements.
- At least 15 characters in total
- At least 1 lower case letter
- At least 1 upper case letter
- At least 1 number
- At least 1 special character
For example: Welcome*123456789
Verify that the admin_user
was created.
racli list admin_user
Make a note for later the user_name
, user_uid
, and user_gud
of the newly creaded admin_user
(REPL_ADMIN_NAME
) on RA2.
Task 2: Create a replication db_user
for replication
on both Recovery Appliances.
This replication db_user
for should be the same for both Recovery Appliances, RA1 and RA2. In this example, the db_user
s are REP_USER_FROM_DB1_TO_DB2
and REP_USER_FROM_DB2_TO_DB1
. This is performed on both RA1 and RA2.
racli add db_user -user_name=<REPL_VPC_USER> --user_type=replication
This replication db_user
is different from the partner user (admin_user
).
Task 3: Create a partnership between two Recovery Appliances.
On RA1, create the partner connection with RA2 --admin_user
credentials.
Note:
If replication is two-way, the command does not need to be run on RA2 and later racli create replication_server
should specify --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
specifies the fully qualified domain name (FQDN) of the first compute node from RA2.--partner_user
specifies the designated partner's name. This should be a non-root user with limited privileges to manage certificates and pass the SSH key for building two-way authentication and authority.--partner_uid
specifies the numeric user id (UID) for the partner user. The UID value needs to be less than 3000 for cloud system.--admin_user
specifies the administrative user if the cluster is not accessible using the root user. It can be eitherroot
or anyadmin
user with access to RA2 with a password or SSH key. Required for cloud-based instances, but optional for on-premise.--admin_key
specifies theadmin
user SSH key if the cluster is not accessible using theroot
user. Required for cloud-based instances or when an--admin_user
is specified.
Task 4: Create a replication server.
This operation is run from RA1. The credential information for the RA2 replication user is put into the replication wallet for RA1.
Note:
This racli create replication_server
command has a password prompt for the replication user. It creates a replication wallet if one did not exist. You do not need to create a replication user and replication wallet separately.
racli create replication_server --target_host=PATH2TARGET
--type=bidirectional [--certificates=YOURLIST]
--target_host
specifies full path to the first node of the target Recovery Appliance to be paired.--type=bidirectional
specifies two-way replication.--certificates=cert1,cert2,cert3...
specifies one or more certificates with their full paths. If RA1 and RA2 share the same trusted certificate, then only one trusted certificate is needed.
The command racli list listener
provides information on whether TCP or TCPS is used.
Example 1: Two-way replication.
racli create replication_server --target_host=<RA2> --backup_anywhere
–certificates=/raacfs/raadmin/cert/raCA.pem
Example 2: One-way replication with TLS enabled on only the downstream Recovery Appliance. Copy the trusted certificate to RA1 from RA2
scp root@RA2:<TRUSTED CERT FROM RA2> /tmp/<CERTNAME>.pem
racli create replication_server --target_host=<RA2> – certificates=/tmp/<CERTNAME>.pem
Example 2: Two-way replication with TLS enabled on only the downstream Recovery Appliance. Copy the trusted certificate to RA1 from RA2
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
Note:
After this task, replication is managed completely through RACLI commands include theTask 5: Create protection policy.
If a suitable protection policy does not exist, you can create one appropriate for the replication.
racli create protection_policy --protection_policy_name=YOUR_POLICY
--storage_location_name=<YOURLOC> --recovery_window_goal=11day --autotune_reserved_space=YES
Refer to racli create protection_policy
for other appropriate arguments.
Task 6: Add protected databases.
If the database has not been assigned a protection policy by other means (DBMS_RA API or Enterprise Manager Cloud Control), then issue a command similar to.
racli add protected_db --db_unique_name=<yourDB>
--protection_policy_name=<YOUR_POLICY> --reserved_space-10G
Task 7: Grant protected database access to replication user on both ZDLRAs
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
Task 8: Grant protected database access.
Determine the replication user names created in earlier steps.
racli list db_user
With the appropriate replication user name, grant access.
racli grant db_access --db_unique_name=<yourDB> --username=REPL_ADMIN_NAME
Task 9: Add replication server
This command is run on both RA1 and 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
The RACLI commands for replication server management are:
racli add replication_server
racli delete replication_server
racli list replication_server
racli remove replication_server
racli status replication_server
racli update replication_server
The RACLI commands for replication user management are:
racli add replication_user
racli alter replication_user
[for changing the password]racli list replication_user
racli remove replication_user
The RACLI commands for replication wallet management are:
racli add replication_wallet
racli alter replication_wallet
racli list replication_wallet
racli remove replication_wallet