AWS Database Blog

Managed Oracle Data Guard Switchover with Amazon RDS for Oracle

Amazon Relational Database Service (Amazon RDS) for Oracle now supports a fully managed, switchover-based role transition for Oracle Database replicas using Oracle Data Guard. You can initiate a switchover to a replica that is mounted or open read-only and the replicas can reside within an Availability Zone of a Region, across an Availability Zones of a Region, or across Regions. Amazon RDS provides complete automation of switchover from the primary database to the replica to minimize downtime during planned maintenance.

In this post, we discuss the use cases of the Data Guard switchover on Amazon RDS for Oracle and show how database administrators (DBAs) and database architects can perform a managed switchover to enable role reversal between RDS for Oracle primary database and its replica.

Amazon RDS for Oracle switchover

Amazon RDS for Oracle supports the creation of Oracle Data Guard replicas. For more information, refer to Managed disaster recovery and managed reader farm with Amazon RDS for Oracle using Oracle Active Data Guard. It fully manages the configuration of Oracle Data Guard, and asynchronously replicates data over secured network connections between a primary DB instance and its replicas. To check the requirements for creating an Oracle replica, refer to Replica requirements for Oracle.

The Data Guard switchover is a planned event where the original primary database transitions to a standby role, while the original replica transitions to the primary role. This feature allows putting the new replica in the same state (mounted or read-only) as the original replica. It reverses the direction of replication from the new primary database to the new replica (old primary database), maintaining your replication configuration with zero data loss and providing data consistency. It also updates configuration of other replicas that aren’t part of switchover to re-establish replication with the new primary database by resuming the log shipping from the new primary to the replica and restarting the redo apply on the replica. The Amazon RDS for Oracle Data Guard switchover supports repeated role reversals, allowing your new replica to return to its original primary role.

The following diagram depicts an example Oracle Data Guard setup with orcl1 as the primary database instance and orcl2 as the replica with asynchronous replication before Data Guard switchover.

The following diagram depicts an example Oracle Data Guard setup with orcl2 as the primary database instance and orcl1 as the replica with asynchronous replication after completion of Data Guard switchover.

Supported Oracle Database versions

Oracle Data Guard switchover is supported for Oracle Database 19c.

Supported AWS Regions

Oracle Data Guard switchover is available in all commercial Regions that support RDS for Oracle replica instances. For more information, visit Region availability.

AWS pricing considerations

The RDS for Oracle Data Guard switchover feature doesn’t cost anything extra to you over the cost of having read or mounted replicas. See Amazon RDS for Oracle pricing for more information.

Oracle licensing options

You should make sure that you’re compliant with Oracle Data Guard licensing to establish read or mounted replicas for your RDS for Oracle database. Configurations with Amazon RDS for Oracle Data Guard read-only DB replicas require Oracle Database Enterprise Edition (EE) and Oracle Active Data Guard licenses. The mounted replicas on Amazon RDS for Oracle require the Oracle Database Enterprise Edition (EE) license (includes Oracle Data Guard redo apply). For more information, see Licensing Information.

Use cases

Just as it’s important to test restoration of data from backups, being able to conduct recovery drills in a cost-effective manner can help give confidence that you can meet your objectives and customer expectations should you need to call upon a recovery. The following are common use cases of Data Guard switchover on an RDS for Oracle database:

  • Perform disaster recovery readiness for applications using on-demand or scheduled disaster recovery drills with planned downtime. For scheduled disaster recovery drills both primary and replica should be in sync for switching roles with Data Guard switchover.
  • Plan regular maintenance activities from one Region to another Region or different database configurations to switch write traffic. Some of the examples of regular planned maintenance activities include modifying instance types, changing database parameter configurations, and increasing storage size.
  • Expand to a global audience as an application grows and its user base becomes more geographically dispersed and changing database traffic patterns. As part of this process, you may need switchover your database to reduce latencies on write traffic to different Regions.

Promoting RDS for Oracle replicas vs. Data Guard switchover

Many AWS customers use RDS for Oracle mounted or read-only replicas for their disaster recovery solutions. Until today, with RDS for Oracle read and mounted replicas, in order to perform a disaster recovery drill, you needed to promote the replica as a new standalone database and then create a new replica to maintain the replication configuration. Managed Oracle Data Guard Switchover enhances the customer experience by simply reversing the roles of the databases without having to recreate the replicas.

You can initiate the switchover for a target standby database by issuing the appropriate AWS Command Line Interface (AWS CLI) command or from the Amazon RDS console. Amazon RDS for Oracle reverses the primary and standby roles in your replication configuration. The managed Data Guard switchover on Amazon RDS for Oracle eliminates the need to rebuild replicas after promotion to a new standalone primary database, as described in the previous section. Oracle Data Guard maintains transactional consistency during a switchover and therefore data validation between the new primary and standby replica isn’t required after a switchover.

Solution overview

The following figure shows an RDS for Oracle Multi-AZ primary database with in-Region and cross-Region replicas in Region 1 and Region 2. The switchover is initiated across Regions, between the RDS for Oracle primary database in Region 1 and the replica in Region 2. The automated backup feature of Amazon RDS for Oracle backs up your databases and archives redo logs securely in Amazon Simple Storage Service (Amazon S3) for a user-specified retention period.

Amazon RDS Multi-AZ maintains a redundant and consistent standby copy of your data using synchronous storage replication. The Amazon RDS Multi-AZ deployment option enables you to run mission-critical workloads with high availability in the same Region and have built-in automated failover from your primary database to a synchronously replicated secondary database in case of a failure. The standby in a Multi-AZ setup on Amazon RDS for Oracle has no read access, while the primary is available for read/writes.

Switchover on Amazon RDS for Oracle is performed using the Oracle Data Guard broker, which validates the primary and replica to be ready for switchover. During the Data Guard switchover on Amazon RDS for Oracle, the original primary database stops processing write requests and new transactions are blocked. It also interrupts replication for all replicas in your read replica configuration. The unapplied redo changes are shipped and applied to the standby database for data consistency between the primary and replica. After the switchover, the new primary database is restarted in read/write mode and the new replica is started in the previous replication configuration (read-only or mounted mode). We go into the steps to initiate the switchover in more detail later in this post.

The following figure depicts role transition after the switchover with the new primary database on Amazon RDS for Oracle in Region 2 and the new replica in the Multi-AZ configuration in Region 1. After the switchover, other bystander replicas that aren’t part of the switchover are reconfigured to continue asynchronous replication from the new primary database.

After the Oracle Data Guard switchover is complete, you reconnect your application to the new primary database. The addition of TNS aliases with both endpoints of the RDS for Oracle primary instance and replica can help simplify application connection reconfiguration after the switchover.

Disaster recovery objectives

Recovery Time Objective (RTO) is the maximum acceptable delay between the interruption of service and restoration of service. This determines what is considered an acceptable window of time when the service is unavailable.

During a planned Data Guard switchover on RDS for Oracle, ensures that all transactions are applied to both the primary and the replica ensuring data consistency. The RTO for completing the Data Guard switchover on an RDS for Oracle database is typically in minutes, but may vary based on replication lag between the primary and the replica at the time of the switchover. Common causes for replication lag are a high amount of transaction activity at the source DB instance, which may result in generating a large number of archive logs on the source DB instance. This results in a delay in shipping the archive logs to the replica due to network latencies.

Prerequisites

Make sure you have the following prerequisites:

  • Automated backups must be enabled on the original replica. The automated backups configuration from your primary will be copied and run on the new primary when the switchover is complete.
  • It’s a best practice to have the same parameter group and option group on all RDS for Oracle primary and replica databases.
  • Switchover is a planned on-demand event, so choose an RDS for Oracle replica with minimal replica lag for a switchover. Validate the result of switchover_status from v$database to be TO PRIMARY or SESSIONS ACTIVE before initiating the switchover on the RDS for Oracle replica. See the following code:
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; 
(Confirm result is TO PRIMARY or SESSIONS ACTIVE)

Initiate the Data Guard switchover using the AWS CLI

To initiate a switchover using the AWS CLI, run the command rds switchover-read-replica in the Region of the original replica. Specify the following option:

aws rds switchover-read-replica --db-instance-identifier <orig-standby>

The <orig-standby> value is the instance ID of the original replica. After the switchover, this database becomes the new primary database.

The following example uses the AWS CLI command to switch over the original replica named orcl2 and original primary database named orcl1:

aws rds switchover-read-replica --db-instance-identifier orcl2

The following code is our sample output:

{
"DBInstance": {
"DBInstanceIdentifier": "orcl2",
"DBInstanceClass": "db.r5.xlarge",
"Engine": "oracle-ee",
"DBInstanceStatus": "available",
"MasterUsername": "netuser",
"DBName": "ORCL",
………..
"StatusInfos": [
{
"StatusType": "read replication",
"Normal": true,
"Status": "replicating"
}
],
……….
}

After the successful switchover, the Data Guard broker changes the role of the orcl2 database instance to the new primary and is open for read/write operations, resuming log shipping and redo apply to all the replicas in the configuration. It also switches the role of the orcl1 database to the new replica in the previous replication configuration.

Monitoring

To check the status of your instances, use the AWS CLI command describe-db-instances. The following command checks the status of the DB instance orcl2. This database was a replica before the switchover, but is the new primary database after the switchover.

aws rds describe-db-instances --db-instance-identifier orcl2

We get the following sample output:

{
    "DBInstances": [
        {
            "DBInstanceIdentifier": "orcl2",
            "DBInstanceClass": "db.r5.xlarge",
            "Engine": "oracle-ee",
            "DBInstanceStatus": "available",
……….
}

To confirm that the switchover completed successfully, query open_mode in V$DATABASE view. Check that the value for the new primary database is READ WRITE.

SQL> SELECT OPEN_MODE FROM V$DATABASE;

We get the following output:

OPEN_MODE
--------------------
READ WRITE

To look for switchover-related events, use the AWS CLI command describe-events. The following example looks for events on the orcl2 instance:

aws rds describe-events --source-identifier orcl2 --source-type db-instance

We get the following output:

{
    "Events": [
        {
            "SourceIdentifier": "orcl2",
            "SourceType": "db-instance",
            "Message": "The Switchover to the read replica started.",
            "EventCategories": [
                "read replica"
            ],
			……………
        },
        {
            "SourceIdentifier": "orcl2",
            "SourceType": "db-instance",
            "Message": "The Switchover to the read replica finished successfully.",
            ………….
}

Conclusion

In this post, we demonstrated how to perform a managed switchover using Data Guard to enable role reversal between an RDS for Oracle primary database and replica. With managed Oracle Data Guard switchover, you’re able to quickly design solutions on Amazon RDS for Oracle to perform periodic role reversals to minimize downtime during planned maintenance.

We welcome your feedback. Share your experience and any questions in the comments.

About the Authors

Nethravathi Muddarajaiah is a Senior Database Specialist Solutions Architect. She works with large Enterprises, ISVs and DNB customers to rearchitect their data platforms to build innovative, resilient, and cost-effective solutions on AWS.

Sachin Vaidya is a Database Specialist Solutions Architect. He works with AWS customers to provide guidance and technical assistance on database projects, helping them improve the value of their solutions when using AWS.