Configure Amazon RDS for Db2 standby replicas for high availability and faster disaster recovery

Amazon Relational Database Service (Amazon RDS) for Db2 offers high availability (HA) through Multi-AZ deployments. When Multi-AZ is enabled, Amazon RDS maintains a redundant, synchronously replicated standby copy of your data within the same AWS Region. Data written to the primary instance is synchronously replicated to the standby instance via block-level storage replication. If the primary instance encounters an issue, Amazon RDS automatically switches to the standby—typically within 60 seconds—providing continued data availability. When automatic failover occurs, your application can remain unaware of what’s happening behind the scenes. The CNAME record for your DB instance will be altered to point to the newly promoted standby. While the endpoint remains the same, you need to re-establish any existing connections to your DB instance. The primary and standby instances are located in different Availability Zones in the same Region, hence the term Multi-AZ. This separation significantly reduces the likelihood that both instances will be affected by the same disruption. Multi-AZ deployments enhance the availability and durability of your RDS DB instances, making them ideal for production workloads.

Several enterprise customers have a crucial requirement to safeguard their production environments against unforeseen disruptions to ensure business continuity. Although Amazon RDS offers a resilient Multi-AZ configuration, it cannot defend against every potential risk, such as natural disasters, malicious events, database corruption, or events that cause a workload to operate in a degraded state. Running out of another Region could be a mitigation strategy. To maintain uninterrupted business operations, it’s essential to devise and validate a comprehensive disaster recovery (DR) plan. Because Multi-AZ is a regional feature, this is where RDS for Db2 standby replicas—a new feature that helps reduce downtime during disaster recovery—becomes important. This feature allows you to maintain a standby replica of your database in a separate AWS Region, providing an additional layer of redundancy beyond the in-region Multi-AZ setup.

In situations where a database in a Region becomes unavailable, you can immediately promote a standby replica in a different Region to resume operations, without having to wait for a database backup to be restored. Together, Multi-AZ deployments and cross-Region standby replicas provide a comprehensive strategy for high availability and disaster recovery—so your Db2 workloads remain resilient, responsive, and ready for mission-critical demands. For more details, refer to Working with replicas for Amazon RDS for Db2.

In this post, we demonstrate how to configure a standby replica for your RDS for Db2 instance. We also discuss best practices for setting up, monitoring, and managing standby replicas.

To use this feature, you can configure your RDS for Db2 instance to maintain a standby replica in another Region. Amazon RDS automatically replicates changes asynchronously from the primary to the standby replica. If the primary instance becomes unavailable, the standby can be promoted to a standalone (act as new primary) instance with a single API call, allowing immediate resumption of read and write operations. This capability significantly reduces downtime during disaster recovery and provides an added layer of resilience for mission-critical workloads.

This cross-Region standby replica capability enables the following:

• Asynchronous data replication to another Region or Availability Zone
• Seamless promotion of standby to primary during disaster recovery
• Recovery Point Objectives (RPO) typically in seconds
• Recovery Time Objectives (RTO) typically in minutes
• Faster disaster recovery compared to traditional backup and restore methods

A standby replica is a physical copy of your primary database and uses IBM Db2’s High Availability Disaster Recovery (HADR) feature for replication across primary and standby replica in SUPERASYNC mode. RDS for Db2 standby replica databases are synchronized with the primary database through log data that is generated on the primary and sent to the standby DB instance. The standby databases constantly roll forward through the logs. The term standby indicates that the replica can’t be used for read or write operations unless it is explicitly promoted to a standalone primary instance.

You can create up to three standby replicas for a DB instance, either within the same Region as the primary or in a different Region. Because standby replicas aren’t operable until promoted, you only need commercial database licenses for 2 vCPUs per replica, regardless of the instance size. Both Db2 Advanced Edition (AE) and Standard Edition (SE) can create replicas in standby for both the Bring Your Own License (BYOL) model and the Db2 license through AWS Marketplace model. Db2 11.5 versions support replica DB instances.

The following table showcases the RPO and RTO metrics that you can attain with various HA and DR capabilities of Amazon RDS for Db2.

Solution overview

The following diagram illustrates the architecture for using an RDS for Db2 standby replica.

In case of a DR situation that demands implementation of failure recovery, you can promote the RDS for Db2 standby replica instance to be the standalone (act as new primary ) instance. The following diagram shows the configuration after replica promotion.

In this post, we use a primary RDS for Db2 instance deployed in the US East (N. Virginia) Region (us-east-1). We walk through the steps to configure a standby replica in the US East (Ohio) Region (us-east-2).

Prerequisites

To follow along with this post, you must have the following prerequisites:

• You must have a primary RDS for Db2 instance (for this post, our instance is named rds-db2-primary and is deployed in us-east-1).
• You should use a custom RDS parameter group configured in the target (secondary) Region, which in this case is us-east-2. Refer to Parameter groups for Amazon RDS for more information. The parameter group in a cross-Region standby replica can have different values compared to the primary RDS for Db2 instance. However, in the BYOL license model, customer_id and site_id are still required and must be updated in the parameter group in the secondary Region.
• If your source database is encrypted using an AWS Key Management Service (AWS KMS) multi-Region key, you can use the same key to create the standby replica. If not, you must create a new KMS key in the secondary Region.
• Built-in rdsadmin stored procedures for creating, dropping, restoring, or rolling forward databases must be completed on primary RDS for Db2 DB instance before creating a replica.
• If you have configured multiple databases on the primary instance, keep in mind that after a standby replica is created, you cannot add additional databases on the primary RDS for Db2 instance. To add more databases, you must first remove the standby replica, create additional databases on the primary instance as needed, and then recreate the standby replica. Make sure you have created the necessary databases on the primary RDS for Db2 instance before proceeding. All the databases on primary instances should be in active state.
• You must enable automated backups on the source DB instance.

For more information on prerequisites, refer to Requirements and considerations for RDS for Db2 replicas.

Important considerations for RDS for Db2 replicas

1. RDS for Db2 replicates the local users, but not the master user, to the replicas. You can modify the master user on the replica. For more information, see Modifying an Amazon RDS DB instance.
2. RDS for Db2 replicates database configurations to the replicas.
3. RDS for Db2 doesn’t replicate the following items:
   • Storage access. Be aware of data, such as external tables, that rely on storage access.
   • Non-inline LOBs.
   • Binaries of external stored procedures (in C or Java).
4. Replication doesn’t support the LOAD command. If you run the LOAD command on the source DB instance, the data will be loaded in non-recoverable mode i.e. the data will not be replicated to the Standby replica.
5. When a replica is created in Amazon RDS for Db2, database-level parameter BLOCKNONLOGGED and LOGINDEXBUILD are automatically set to YES on the primary instance. This makes sure all operations and index builds are fully logged for replication. When the standby replica becomes a standalone instance (replica promotion), Amazon RDS sets the value back to NO on primary instance.
6. Replication uses Db2 HADR for all databases on RDS for Db2 primary DB instance.

Create an RDS for Db2 standby replica

To create a standby replica from a source RDS for Db2 DB instance, complete the following steps:

1. On the Amazon RDS console, in the navigation pane, choose Databases.
2. Select the RDS for Db2 DB instance that you want to use as the source for a standby replica.
   
3. On the Actions dropdown menu, choose Create replica.
   
4. For Replica mode, choose Standby.
   
5. For DB instance identifier, enter a name for the read replica.
   
6. For Regions, choose the Region where the standby replica will be launched.
   
7. Choose your instance size and storage type.
8. For Multi-AZ deployment, choose Create a standby instance to create a standby of your replica in another Availability Zone for failover support for the standby replica(optional).
9. Choose the other settings that you want to use.
10. Choose Create replica.

On the Databases page in target region, the standby replica has the role Replica.

You can also verify the replica configuration details on the primary RDS for Db2 instance under the Replication section in the Connectivity & Security tab.

Alternatively, you can create an RDS for Db2 standby replica with the following AWS Command Line Interface (AWS CLI) command:

aws rds create-db-instance-read-replica \
--db-instance-identifier <name of replica instance> \
--source-db-instance-identifier arn:aws:rds:<source DB region>:<accountnumber>:db:rds-db2-primary \
--db-parameter-group-name <name of parameter group in DR region> \
--replica-mode mounted \
--kms-key-id <KMS Key> \
--region <DR region>

Promote the RDS for Db2 standby replica

In situations where the primary DB instance becomes unavailable, you can promote the standby replica to a standalone instance and resume read and write operations. When a standby replica promotion is initiated, RDS applies any pending transactions from archive logs, transitions the standby replica to an active state, and enables read/write capabilities on the promoted instance. It’s crucial to understand that this process involves asynchronous data replication from the primary database to standby replica. Consequently, there may be data loss depending on the replication lag between the primary database and the standby replica. To minimize potential data discrepancies, we strongly recommend reviewing the replication lag, as described in the best practices section of this blog post, before initiating a replica promotion.By carefully monitoring this lag and understanding its implications, you can make informed decisions during disaster recovery scenarios, facilitating the best possible data consistency in your promoted standby instance.To promote a RDS for Db2 standby replica

1. On the Amazon RDS console, in the navigation pane, choose Databases.
2. Choose the source RDS for Db2 DB instance.
3. Select your standby replica.
4. On the Actions dropdown menu, choose Promote.

Alternatively, you can use the following AWS CLI command:

aws rds promote-read-replica \
--db-instance-identifier <name of the replica instance> \
--region <DR region>

Connect to the RDS for Db2 standby replica after promotion:

db2 catalog TCPIP node <node_name> remote <dns_name> server <port>
db2 catalog database <database_name> as <dbalias-name> at node <node_name> 
db2 connect to <database_name> user <master_username> using <master_password>

Best practices

Consider the following best practices when implementing this solution:

• It is generally recommended to configure the RDS for Db2 standby replica with the same instance type and size as the primary instance to avoid performance issues or replication lag. However, you also have the flexibility to choose a different instance type and size for the standby replica to optimize infrastructure costs.
• The RDS for Db2 standby replica version must be equal to or higher than the primary instance version. When performing a manual minor version upgrade, you must upgrade the replica instance before upgrading the primary instance.
• We recommend monitoring the replication lag in Amazon CloudWatch by viewing the Amazon RDS ReplicaLag metric. For more information about replication lag time, see Monitoring read replication and Amazon CloudWatch metrics for Amazon RDS. The ReplicaLag metric is the maximum lag of databases that have fallen behind, in seconds. For more information on monitoring and troubleshooting replication issues, refer to Troubleshooting RDS for Db2 replication issues.

You can set CloudWatch alarms to receive notifications when the ReplicaLag exceeds a defined threshold, based on your business requirements.

• If your primary RDS for Db2 instance is configured with Multi-AZ and automated backups are enabled, you can also enable these settings on the standby replica. This makes sure the standby maintains the same configuration as the primary instance, allowing for a smooth and quick transition in the event of a DR scenario. After promotion, you can connect to the promoted instance without needing to configure these settings separately.
• Use the same or compatible DB parameter groups and option groups for both primary and standby instances to avoid unexpected behavior during promotion.
• You can create and restore backups of an RDS for Db2 replica instance. RDS for Db2 standby replicas support both automatic backups and manual snapshots. RDS for Db2 replicas don’t have automated backups turned on by default. Turn on automated backups by setting the backup retention period to a positive non-zero value. Enabling automated backups on an RDS for Db2 standby replica makes sure it can be promoted with full recovery capabilities, including point-in-time restore. This is important for disaster recovery, compliance, and a seamless transition to a standalone instance if needed. For more information, refer to Working with RDS for Db2 replica backups.
• To implement automation in traffic routing without changing your application endpoint, refer to Orchestrate disaster recovery automation using Amazon Route 53 ARC and AWS Step Functions.

Clean up

To delete the RDS for Db2 Standby replica.

1. On the Amazon RDS console, in the navigation pane, choose Databases.
2. Choose the source RDS for Db2 DB instance.
3. Select your standby replica.
4. On the Actions dropdown menu, choose Delete.

To delete your RDS for Db2 standby replica, use the following AWS CLI command:

aws rds delete-db-instance --db-instance-identifier <replicaname> \
--skip-final-snapshot | --no-skip-final-snapshot \
--final-db-snapshot-identifier <value> \
--delete-automated-backups | --no-delete-automated-backups \
--region <region>

Conclusion

Configuring cross-Region standby replicas for RDS for Db2 enhances both availability and disaster recovery readiness.By following best practices around setup and encryption, you can achieve a smooth failover experience. With this setup, you can maintain business continuity with minimal disruption during unexpected events.

Try out this solution for your own use case and share your feedback in the comments.

About the Authors