

# Working with Oracle replicas for RDS Custom for Oracle
Working with RDS Custom for Oracle replicas

**Note**  
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).

You can create Oracle replicas for RDS Custom for Oracle DB instances that run Oracle Enterprise Edition. Both container databases (CDBs) and non-CDBs are supported. Standard Edition 2 doesn't support Oracle Data Guard. 

Creating an RDS Custom for Oracle replica is similar to creating an RDS for Oracle replica, but with important differences. For general information about creating and managing Oracle replicas, see [Working with DB instance read replicas](USER_ReadRepl.md) and [Working with read replicas for Amazon RDS for Oracle](oracle-read-replicas.md).

**Topics**
+ [

## Overview of RDS Custom for Oracle replication
](#custom-rr.overview)
+ [

# Guidelines and limitations for RDS Custom for Oracle replication
](custom-rr.reqs-limitations.md)
+ [

# Promoting an RDS Custom for Oracle replica to a standalone DB instance
](custom-rr.promoting.md)
+ [

# Configuring a VPN tunnel between RDS Custom for Oracle primary and replica instances
](cfo-standby-vpn-tunnel.md)

## Overview of RDS Custom for Oracle replication


The architecture of RDS Custom for Oracle replication is analogous to RDS for Oracle replication. A primary DB instance replicates asynchronously to one or more Oracle replicas.

![\[RDS Custom for Oracle supports Oracle replicas\]](http://docs.amazonaws.cn/en_us/AmazonRDS/latest/UserGuide/images/read-replica-custom-oracle.png)


### Maximum number of replicas


As with RDS for Oracle, you can create up to five managed Oracle replicas of your RDS Custom for Oracle primary DB instance. You can also create your own manually configured (external) Oracle replicas. External replicas don't count toward your DB instance limit. They also lie outside the RDS Custom support perimeter. For more information about the support perimeter, see [RDS Custom support perimeter](custom-concept.md#custom-troubleshooting.support-perimeter).

### Replica naming convention


Oracle replica names are based on the database unique name. The format is `DB_UNIQUE_NAME_X`, with letters appended sequentially. For example, if your database unique name is `ORCL`, the first two replicas are named `ORCL_A` and `ORCL_B`. The first six letters, A–F, are reserved for RDS Custom. RDS Custom copies database parameters from your primary DB instance to the replicas. For more information, see [DB\$1UNIQUE\$1NAME](https://docs.oracle.com/database/121/REFRN/GUID-3547C937-5DDA-49FF-A9F9-14FF306545D8.htm#REFRN10242) in the Oracle documentation.

### Replica backup retention


By default, RDS Custom Oracle replicas use the same backup retention period as your primary DB instance. You can modify the backup retention period to 1–35 days. RDS Custom supports backing up, restoring, and point-in-time recovery (PITR). For more information about backing up and restoring RDS Custom DB instances, see [Backing up and restoring an Amazon RDS Custom for Oracle DB instance](custom-backup.md).

**Note**  
While creating a Oracle replica, RDS Custom temporarily pauses the cleanup of redo log files. In this way, RDS Custom ensures that it can apply these logs to the new Oracle replica after it becomes available.

### Replica promotion


You can promote managed Oracle replicas in RDS Custom for Oracle using the console, `promote-read-replica` Amazon CLI command, or `PromoteReadReplica` API. If you delete your primary DB instance, and all replicas are healthy, RDS Custom for Oracle promotes your managed replicas to standalone instances automatically. If a replica has paused automation or is outside the support perimeter, you must fix the replica before RDS Custom can promote it automatically. You can only promote external Oracle replicas manually.

# Guidelines and limitations for RDS Custom for Oracle replication
Guidelines and limitations for replication

**Note**  
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).

When you create RDS Custom for Oracle replicas, not all RDS Oracle replica options are supported.

**Topics**
+ [

## General guidelines for RDS Custom for Oracle replication
](#custom-rr.guidelines)
+ [

## General limitations for RDS Custom for Oracle replication
](#custom-rr.limitations)
+ [

## Networking requirements and limitations for RDS Custom for Oracle replication
](#custom-rr.network)
+ [

## External replica limitations for RDS Custom for Oracle
](#custom-rr.external-replica-reqs)

## General guidelines for RDS Custom for Oracle replication


When working with RDS Custom for Oracle, follow these guidelines:
+ You can use RDS Custom for Oracle replication only in Oracle Enterprise Edition. Standard Edition 2 isn't supported.
+ We strongly recommend that you implement a VPN tunnel to encrypt communication between your primary and standby instances. For more information, see [Configuring a VPN tunnel between RDS Custom for Oracle primary and replica instances](cfo-standby-vpn-tunnel.md).
+ Don't modify the `RDS_DATAGUARD` user. This user is reserved for RDS Custom for Oracle automation. Modifying this user can result in undesired outcomes, such as an inability to create Oracle replicas for your RDS Custom for Oracle DB instance.
+ Don't change the replication user password. It is required to administer the Oracle Data Guard configuration on the RDS Custom host. If you change the password, RDS Custom for Oracle might put your Oracle replica outside the support perimeter. For more information, see [RDS Custom support perimeter](custom-concept.md#custom-troubleshooting.support-perimeter).

  The password is stored in Amazon Secrets Manager, tagged with the DB resource ID. Each Oracle replica has its own secret in Secrets Manager. The secret uses either of the following naming formats.

  ```
  do-not-delete-rds-custom-db-DB_resource_id-uuid-dg
  rds-custom!oracle-do-not-delete-DB_resource_id-uuid-dg
  ```
+ Don't change the `DB_UNIQUE_NAME` for the primary DB instance. Changing the name causes any restore operation to become stuck.
+ Don't specify the clause `STANDBYS=NONE` in a `CREATE PLUGGABLE DATABASE` command in an RDS Custom CDB. This way, if a failover occurs, your standby CDB contains all PDBs.

## General limitations for RDS Custom for Oracle replication


RDS Custom for Oracle replicas have the following limitations:
+ You can't create RDS Custom for Oracle replicas in read-only mode. However, you can manually change the mode of mounted replicas to read-only, and from read-only to mounted. For more information, see the documentation for the [create-db-instance-read-replica](https://docs.amazonaws.cn/cli/latest/reference/rds/create-db-instance-read-replica.html) Amazon CLI command.
+ You can't create cross-Region RDS Custom for Oracle replicas.
+ You can't change the value of the Oracle Data Guard `CommunicationTimeout` parameter. This parameter is set to 15 seconds for RDS Custom for Oracle DB instances.

## Networking requirements and limitations for RDS Custom for Oracle replication


Make sure that your network configuration supports RDS Custom for Oracle replicas. Consider the following:
+ Make sure to enable port 1140 for both inbound and outbound communication within your virtual private cloud (VPC) for the primary DB instance and all of its replicas. This is required for Oracle Data Guard communication between read replicas.
+ RDS Custom for Oracle validates the network while creating a Oracle replica. If the primary DB instance and the new replica can't connect over the network, RDS Custom for Oracle doesn't create the replica and places it in the `INCOMPATIBLE_NETWORK` state.
+ For external Oracle replicas, such as those you create on Amazon EC2 or on-premises, use another port and listener for Oracle Data Guard replication. Trying to use port 1140 could cause conflicts with RDS Custom automation.
+ The `/rdsdbdata/config/tnsnames.ora` file contains network service names mapped to listener protocol addresses. Note the following requirements and recommendations:
  + Entries in `tnsnames.ora` prefixed with `rds_custom_` are reserved for RDS Custom when handling Oracle replica operations.

    When creating manual entries in `tnsnames.ora`, don't use this prefix.
  + In some cases, you might want to switch over or fail over manually, or use failover technologies such as Fast-Start Failover (FSFO). If so, make sure to manually synchronize `tnsnames.ora` entries from the primary DB instance to all of the standby instances. This recommendation applies to both Oracle replicas managed by RDS Custom and to external Oracle replicas.

    RDS Custom automation updates `tnsnames.ora` entries on only the primary DB instance. Make sure also to synchronize when you add or remove a Oracle replica.

    If you don't synchronize the `tnsnames.ora` files and switch over or fail over manually, Oracle Data Guard on the primary DB instance might not be able to communicate with the Oracle replicas.

## External replica limitations for RDS Custom for Oracle


 RDS Custom for Oracle external replicas, which include on-premises replicas, have the following limitations:
+ RDS Custom for Oracle doesn't detect instance role changes upon manual failover, such as FSFO, for external Oracle replicas.

  RDS Custom for Oracle does detect changes for managed replicas. The role change is noted in the event log. You can also see the new state by using the [describe-db-instances](https://docs.amazonaws.cn/cli/latest/reference/rds/describe-db-instances.html) Amazon CLI command.
+ RDS Custom for Oracle doesn't detect high replication lag for external Oracle replicas.

  RDS Custom for Oracle does detect lag for managed replicas. High replication lag produces the `Replication has stopped` event. You can also see the replication status by using the [describe-db-instances](https://docs.amazonaws.cn/cli/latest/reference/rds/describe-db-instances.html) Amazon CLI command, but there might be a delay for it to be updated.
+ RDS Custom for Oracle doesn't promote external Oracle replicas automatically if you delete your primary DB instance. 

  The automatic promotion feature is available only for managed Oracle replicas. For information about promoting Oracle replicas manually, see the white paper [Enabling high availability with Data Guard on Amazon RDS Custom for Oracle](https://d1.awsstatic.com/whitepapers/enabling-high-availability-with-data-guard-on-amazon-rds-custom-for-oracle.pdf).

# Promoting an RDS Custom for Oracle replica to a standalone DB instance
Promoting a replica

**Note**  
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).

Just as with RDS for Oracle, you can promote an RDS Custom for Oracle replica to a standalone DB instance. When you promote a Oracle replica, RDS Custom for Oracle reboots the DB instance before it becomes available. For more information about promoting Oracle replicas, see [Promoting a read replica to be a standalone DB instance](USER_ReadRepl.Promote.md).

When promoting a replica, note the following guidelines:
+ Don't initiate a failover while RDS Custom for Oracle is promoting your replica. Otherwise, the promotion workflow could become stuck.
+ Don't switch over your primary DB instance while RDS Custom for Oracle is promoting your Oracle replica. Otherwise, the promotion workflow could become stuck.
+ Don't shut down your primary DB instance while RDS Custom for Oracle is promoting your Oracle replica. Otherwise, the promotion workflow could become stuck.
+ Don't try to restart replication with your newly promoted DB instance as a target. After RDS Custom for Oracle promotes your Oracle replica, it becomes a standalone DB instance and no longer has the replica role.

Note the following limitations for RDS Custom for Oracle replica promotion:
+ You can't promote a replica while RDS Custom for Oracle is backing it up.
+ You can't change the backup retention period to `0` when you promote your Oracle replica.
+ You can't promote your replica when it isn't in a healthy state.

  If you issue `delete-db-instance` on the primary DB instance, RDS Custom for Oracle validates that each managed Oracle replica is healthy and available for promotion. A replica might be ineligible for promotion because automation is paused or it is outside the support perimeter. In such cases, RDS Custom for Oracle publishes an event explaining the issue so that you can repair your Oracle replica manually.

The following steps show the general process for promoting a Oracle replica to a DB instance:

1. Stop any transactions from being written to the primary DB instance. 

1. Wait for RDS Custom for Oracle to apply all updates to your Oracle replica.

1. Promote your Oracle replica by choosing the **Promote** option on the Amazon RDS console, the Amazon CLI command [https://docs.amazonaws.cn/cli/latest/reference/rds/promote-read-replica.html](https://docs.amazonaws.cn/cli/latest/reference/rds/promote-read-replica.html), or the [https://docs.amazonaws.cn/AmazonRDS/latest/APIReference/API_PromoteReadReplica.html](https://docs.amazonaws.cn/AmazonRDS/latest/APIReference/API_PromoteReadReplica.html) Amazon RDS API operation.

Promoting a Oracle replica takes a few minutes to complete. During the process, RDS Custom for Oracle stops replication and reboots your replica. When the reboot completes, the Oracle replica is available as a standalone DB instance. For information about troubleshooting replica promotion, see [Troubleshooting replica promotion for RDS Custom for Oracle](custom-troubleshooting.md#custom-troubleshooting-promote).

## Console


**To promote an RDS Custom for Oracle replica to a standalone DB instance**

1. Sign in to the Amazon Web Services Management Console and open the Amazon RDS console at [https://console.amazonaws.cn/rds/](https://console.amazonaws.cn/rds/).

1. In the Amazon RDS console, choose **Databases**.

   The **Databases** pane appears. Each Oracle replica shows **Replica** in the **Role** column.

1. Choose the RDS Custom for Oracle replica that you want to promote.

1. For **Actions**, choose **Promote**.

1. On the **Promote Oracle replica** page, enter the backup retention period and the backup window for the newly promoted DB instance. You can't set this value to **0**.

1. When the settings are as you want them, choose **Promote Oracle replica**.

## Amazon CLI


To promote your RDS Custom for Oracle replica to a standalone DB instance, use the Amazon CLI [https://docs.amazonaws.cn/cli/latest/reference/rds/promote-read-replica.html](https://docs.amazonaws.cn/cli/latest/reference/rds/promote-read-replica.html) command.

**Example**  
For Linux, macOS, or Unix:  

```
aws rds promote-read-replica \
--db-instance-identifier my-custom-read-replica \
--backup-retention-period 2 \
--preferred-backup-window 23:00-24:00
```
For Windows:  

```
aws rds promote-read-replica ^
--db-instance-identifier my-custom-read-replica ^
--backup-retention-period 2 ^
--preferred-backup-window 23:00-24:00
```

## RDS API


To promote your RDS Custom for Oracle replica to be a standalone DB instance, call the Amazon RDS API [https://docs.amazonaws.cn/AmazonRDS/latest/APIReference/API_PromoteReadReplica.html](https://docs.amazonaws.cn/AmazonRDS/latest/APIReference/API_PromoteReadReplica.html) operation with the required parameter `DBInstanceIdentifier`.

# Configuring a VPN tunnel between RDS Custom for Oracle primary and replica instances
Configuring a VPN tunnel between a primary and replica

**Note**  
End of support notice: On March 31, 2027, Amazon will end support for Amazon RDS Custom for Oracle. After March 31, 2027, you will no longer be able to access the RDS Custom for Oracle console or RDS Custom for Oracle resources. For more information, see [RDS Custom for Oracle end of support](RDS-Custom-for-Oracle-end-of-support.md).

A VPN tunnel is an encrypted connection between two or more devices over a network. To ensure the highest level of security for your Oracle Data Guard instances in RDS Custom for Oracle, we strongly recommend that you implement a VPN tunnel to encrypt communication between your primary and standby instances. The tunnel serves as a safeguard for sensitive data as it travels the network between instances. While this configuration is optional, we recommend it as a best practice to achieve data security and regulatory compliance. 

Make sure you meet the following prerequisites:
+ You have root access to the primary and standby hosts.
+ You have the technical expertise to run the `ipsec` command.

**To configure a VPN tunnel between a primary and replica in RDS Custom for Oracle**

1. Add the security groups for both the primary instance and standby instance to the allow list using the following rules:

   ```
   ACTION FLOW SOURCE PROTO PORT
   
   ALLOW ingress this-SG 50 (ESP) all (N/A)
   ALLOW egress this-SG 50 (ESP) all (N/A)
   
   ALLOW ingress this-SG 17 (UDP) 500 (IKE)
   ALLOW egress this-SG 17 (UDP) 500 (IKE)
   ```

1. Switch to the root user.

   ```
   $ sudo su – root
   ```

1. Run the following commands on both the primary instance and the standby instance to initialize the Network Security Services (NSS) database under the user `root`.

   ```
   ipsec initnss --nssdir /etc/ipsec.d
   ```

1. Generate RSA keys as follows:

   1. On the primary instance, generate the keys using either of the following `ipsec` commands, depending on your OS version.

      ```
      ipsec newhostkey --nssdir /etc/ipsec.d       ## for Oracle Linux Version 8
      ipsec newhostkey --output /etc/ipsec.secrets ## for Oracle Linux version 7.9
      ```

   1. Obtain the public key, which you need to create the configuration. In the following example, the primary instance is `left` because in `ipsec` parlance, `left` refers to the device you are currently configuring, and `right` refers to the device at the other end of the tunnel.

      ```
      ipsec showhostkey --left --ckaid ckaid-returned-in-last-statement
      ```

   1. On the standby instance, generate keys for the standby instance. 

      ```
      ipsec newhostkey --nssdir /etc/ipsec.d       ## for Oracle Linux Version 8
      ipsec newhostkey --output /etc/ipsec.secrets ## for Oracle Linux version 7.9
      ```

   1. Obtain the public key for the standby instance, which you need to create the configuration. In the following example, the standby instance is `right` because it refers to the device at the other end of the tunnel.

      ```
      ipsec showhostkey --right --ckaid ckaid-returned-in-last-statement
      ```

1. Based on the RSA keys that you obtained, generate the configuration. The configuration is identical for both the primary instance and the standby instance. You can find the primary instance IPv4 address and standby instance IPv4 address in the Amazon console.

   On both the primary instance and the standby instance, save the following configuration to the file `/etc/ipsec.d/custom-fb-tunnel.conf`.

   ```
   conn custom-db-tunnel
    type=transport
    auto=add
    authby=rsasig
    left=IPV4-for-primary 
    leftrsasigkey=RSA-key-generated-on-primary
    right=IPV4-for-standby
    rightrsasigkey=RSA-key-generated-on-standby
   ```

1. On both the primary instance and the standby instance, start the `ipsec` daemon on both hosts.

   ```
   ipsec setup start
   ```

1. Start the tunnel on either the primary instance or the standby instance. The output should look similar to the following.

   ```
   [root@ip-172-31-6-81 ~]# ipsec auto --up custom-db-tunnel
   181 "custom-db-tunnel" #1: initiating IKEv2 connection
   181 "custom-db-tunnel" #1: sent IKE_SA_INIT request to 172.31.32.196:500
   182 "custom-db-tunnel" #1: sent IKE_AUTH request {cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=DH19}
   003 "custom-db-tunnel" #1: initiator established IKE SA; authenticated peer '3584-bit PKCS#1 1.5 RSA with SHA1' signature using preloaded certificate '172.31.32.196'
   004 "custom-db-tunnel" #2: initiator established Child SA using #1; IPsec transport [172.31.6.81-172.31.6.81:0-65535 0] -> [172.31.32.196-172.31.32.196:0-65535 0] {ESP/ESN=>0xda9c4815 <0xb742ca42 xfrm=AES_GCM_16_256-NONE DPD=passive}
   [root@ip-172-31-6-81 ~]#
   ```