Working with replicas for Amazon RDS for Db2
To configure replication between RDS for Db2 DB instances, you can create replica databases. For a summary of the differences between RDS for Db2 replicas and other DB engines, see Differences between read replicas for DB engines.
A Db2 replica database is a physical copy of your primary database.
A Db2 replica in standby mode is called a standby replica. Db2 doesn't
permit reads or writes in a replica, but you can promote a replica to make it writable. The
promoted replica has the replicated data to the point when the request was made to promote
it. RDS for Db2 uses Db2 High Availability Disaster Recover (HADR) for replication. For more
information, see High availability disaster recovery (HADR)
Standby replicas
When creating or modifying a Db2 replica, you can place it in standby mode. For
standby replicas, the Db2 environment variable DB2_HADR_ROS is set to
OFF so that the replica database doesn't accept user connections. The
primary use for standby replicas is cross-Region disaster recovery.
A standby replica can't serve a read-only workload. The standby replica doesn't have any archive logs.
You can create up to three replicas from one source DB instance.
Database activations
Db2 HADR is configured at the database level. After you create replicas, HADR is set
for all Db2 databases, including rdsadmin, which RDS fully manages. Before
you create Db2 replicas, you must explicitly activate all databases. Otherwise, creation
of replicas fails and Amazon RDS emits an event. After a DB instance has one or more
replicas, you can't activate or deactivate any databases on the DB instance by using the
rdsadmin.activate_database or rdsadmin.deactivate_database
stored procedures. However, you can call the rdsadmin.reactivate_database
stored procedure to reactivate databases. For more information, see Stored procedures for databases for
RDS for Db2.
HADR configurations
You can see all HADR configurations for a database by connecting to the database and
then running db2 get db cfg.
Archive log retention
Amazon RDS purges logs from a primary DB instance after the following conditions have been met:
-
The logs are at least two hours old.
-
The setting for archive log retention hours has passed.
-
The archive logs were successfully replicated to all replica DB instances. This condition applies both to DB instances in the same Amazon Web Services Region and to cross-Region DB instances.
For information about setting archive log retention hours, see rdsadmin.set_archive_log_retention.
Amazon RDS checks and cleans up each database individually. If a database loses the HADR connection or if information about the connection isn't available, then Amazon RDS skips the database and doesn't purge the archive logs.
Outages during Db2 replication
When you create a replica, Amazon RDS takes a DB snapshot of your source DB instance and begins replication. When the DB snapshot operation begins, the source DB instance experiences a very brief I/O suspension. The I/O suspension typically lasts about one second. However, if the source DB instance is a Multi-AZ deployment, then the source DB instance doesn't experience any I/O suspension. This is because with Multi-AZ deployments, the snapshot is taken from the secondary DB instance.
The DB snapshot becomes the Db2 replica. Amazon RDS sets the necessary parameters and permissions for the source database and replica without any service interruption. Similarly, if you delete a replica, no outage occurs.