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, use racli 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_users 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 either root or any admin user with access to RA2 with a password or SSH key. Required for cloud-based instances, but optional for on-premise.
  • --admin_key specifies the admin user SSH key if the cluster is not accessible using the root 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 the

Task 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