# Working with replicas for Amazon RDS for Db2
RDS for Db2 supports creating replica databases to provide read scaling and disaster recovery capabilities. You can create replicas in two modes: read-only replicas for offloading read workloads, and standby replicas for cross-region disaster recovery. RDS for Db2 uses IBM Db2 High Availability Disaster Recovery (HADR) technology for replication. For more information, see [High availability disaster recovery (HADR)](https://www.ibm.com/docs/en/db2/11.5?topic=server-high-availability-disaster-recovery-hadr) in the IBM Db2 documentation.
A *Db2 replica* database is a physical copy of your primary database. A Db2 replica in read-only mode is called a *read replica*. A Db2 replica in standby mode is called a *standby replica*. Db2 doesn't permit 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. For more information, see [Promoting a read replica to be a standalone DB instance](USER_ReadRepl.Promote.md).
For a summary of the features and behaviors of RDS for Db2 replicas, see [Differences between read replicas for DB engines](USER_ReadRepl.Overview.Differences.md).
## Read-only and standby replicas
When creating or modifying a Db2 replica, you can place it in either of the following modes:
**Read-only**
This is the default. HADR transmits and applies changes from the source database to all read replica databases. For read-only replicas, the Db2 environment variable `DB2_HADR_ROS` is set to `ON`. The isolation level for read queries on the replica database is `Uncommitted Read`. For more information, see [ Isolation level on the active standby database](https://www.ibm.com/docs/en/db2/11.5?topic=standby-isolation-level-active-database) in the IBM Db2 documentation.
For general information about read replicas that applies to all DB engines, see [Working with DB instance read replicas](USER_ReadRepl.md). For more information about Db2 HADR, see [High availability disaster recovery (HADR)](https://www.ibm.com/docs/en/db2/11.5?topic=server-high-availability-disaster-recovery-hadr) in the IBM Db2 documentation.
**Standby**
For standby replicas, the Db2 environment variable `DB2_HADR_ROS` is set to `OFF` so that the replica databases don'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. You can create a combination of read-only and standby DB replicas for the same source DB instance. After you create a replica, you can change the replica mode. for more information, see [Modifying the RDS for Db2 replica mode](db2-replicas-changing-replica-mode.md).
Before creating replicas, make sure that you meet all requirements. For more information, see [Requirements and considerations for RDS for Db2 replicas](db2-read-replicas.limitations.md).
## 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. For more information, see [Stored procedures for databases for RDS for Db2](db2-sp-managing-databases.md).
## 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 AWS Region and to cross-Region DB instances.
For information about setting archive log retention hours, see [rdsadmin.set\$1archive\$1log\$1retention](db2-sp-managing-databases.md#db2-sp-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.
# Requirements and considerations for RDS for Db2 replicas
Db2 replica requirements fall into several categories: licensing and versioning, backup and restore considerations, replication behavior, and general operational considerations. Before creating a Db2 replica, familiarize yourself with the following requirements and considerations.
## Version and licensing requirements for RDS for Db2 replicas
Before you create an RDS for Db2 replica, review the following information about versions and licensing models:
+ **Supported versions** – All Db2 11.5 versions support replica DB instances.
Source and replica DB instances must use the same major version. Db2 replicas support minor version upgrades but not major version upgrades. For information about upgrading DB instances, see [Upgrading a DB instance engine version](USER_UpgradeDBInstance.Upgrading.md).
**Note**
When upgrading a source DB instance, all replicas are automatically upgraded to maintain version compatibility.
+ **Valid licensing models and replica modes** – Both Db2 Advanced Edition (AE) and Standard Edition (SE) can create replicas in read-only or standby mode for both the Bring Your Own License (BYOL) model and the Db2 license through AWS Marketplace model.
+ **Custom parameter group** – You must specify a custom parameter group for the replica.
For replicas that use the BYOL model, this custom parameter group must include your IBM Site ID and IBM Customer ID. For more information, see [IBM IDs for bring your own license (BYOL) for Db2](db2-licensing.md#db2-prereqs-ibm-info). You can specify this custom parameter group for the replica by using the AWS Management Console, the AWS CLI , or the RDS API.
+ **vCPU count** varies by replica mode and licensing model:
+ **Standby replicas** always use two vCPUs regardless of DB instance size.
+ **BYOL model** – AWS License Manager configurations show that RDS for Db2 DB instances use two vCPUs.
+ **Db2 license through AWS Marketplace model** – Bills reflect license costs for two vCPUs.
+ **Read-only replicas** use the same vCPU count as the DB instance size.
+ **BYOL model** – AWS License Manager configurations show that RDS for Db2 DB instances use the same number of vCPUs that match the DB instance size.
+ **Db2 license through AWS Marketplace model** – Bills reflect license costs for the same number of vCPUs that match the DB instance size.
## Backup and restore considerations for RDS for Db2 replicas
Replica backups have different behavior than primary database backups. Consider the following backup and restore requirements:
+ To create snapshots of RDS for Db2 replicas or turn on automatic backups, make sure to set the backup retention period manually. Automatic backups aren't turned on by default.
+ When you restore a replica backup, you restore to the database time, not the time that the backup was taken. The database time refers to the latest applied transaction time of the data in the backup. The difference is significant because a replica can lag behind the primary database for minutes or hours. When there are multiple databases, RDS for Db2 uses the earliest database time.
To find the difference, run the AWS CLI [describe-db-snapshots](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-snapshots.html) command or call the RDS API [DescribeDBSnapshots](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBSnapshots.html) operation. Compare the `SnapshotDatabaseTime` value to the `OriginalSnapshotCreateTime` value. The `SnapshotDatabaseTime` value is the database time of the replica backup. The `OriginalSnapshotCreateTime` value is the latest applied transaction on the primary database.
For more information about backups and restoring backups, see [Working with RDS for Db2 replica backups](db2-read-replicas.backups.md).
## Replication considerations for RDS for Db2 replicas
Db2 replicas use HADR technology with specific limitations and behaviors. Review the following replication considerations:
+ Replication uses Db2 HADR for all databases on the RDS for Db2 DB instance.
+ Replication doesn't support the `LOAD` command. If you run the `LOAD` command from the source DB instance, you will receive inconsistent data.
+ 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 that are not logged.
+ Binaries of external stored procedures (in C or Java).
+ For standby replicas, RDS for Db2 replicates the following items:
+ Local users, except master users
+ Database configuration parameters
+ For read-only replicas, RDS for Db2 replicates the following items:
+ Local users, except master users
+ SID group mappings
## Miscellaneous considerations for RDS for Db2 replicas
Additional operational considerations apply to Db2 replicas. Review the following items:
+ RDS for Db2 replicates database configurations to the replicas. When RDS for Db2 promotes a replica, it deactivates and activates each database.
+ RDS for Db2 replicates the local users, but not the master user, and SID group mappings to the replicas. You can modify the master user on the replica. For more information, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md).
+ All databases must be in an active state. For information about activating databases, see [Stored procedures for databases for RDS for Db2](db2-sp-managing-databases.md).
+ All stored procedures for creating, dropping, restoring, or rolling forward databases must be completed before creating a replica. For information about these stored procedures, see [Stored procedures for databases for RDS for Db2](db2-sp-managing-databases.md).
+ When the replica is created, Amazon RDS sets the database-level parameter `blocknonlogged` for all databases on the source DB instance to `YES`. When the source replica becomes a standalone instance again, Amazon RDS sets the value back to `NO`. For more information, see [blocknonlogged - Block creation of tables that allow non-logged activity configuration parameter](https://www.ibm.com/docs/en/db2/11.1?topic=dcp-blocknonlogged-block-creation-tables-that-allow-non-logged-activity) in the IBM Db2 documentation.
+ When the replica is created, Amazon RDS sets the database-level parameter `logindexbuild` for all databases on the source DB instance to `YES`. When the source replica becomes a standalone instance again, Amazon RDS sets the value back to `NO`. For more information, see [logindexbuild - Log index pages created configuration parameter](https://www.ibm.com/docs/en/db2/11.1?topic=parameters-logindexbuild-log-index-pages-created) in the IBM Db2 documentation.
# Preparing to create an RDS for Db2 replica
Before creating an RDS for Db2 replica, you must complete the following tasks for successful replication. These tasks help prevent common issues and ensure optimal performance.
## Task 1: Enable automatic backups
Before a DB instance can serve as a source DB instance, you must enable automatic backups on the source DB instance. This is a prerequisite for all replica creation operations. To learn how to perform this procedure, see [Enabling automated backups](USER_WorkingWithAutomatedBackups.Enabling.md).
For information about backups specific to Db2 replicas, see [Working with RDS for Db2 replica backups](db2-read-replicas.backups.md).
## Task 2: Plan compute and storage resources
Ensure that the source DB instance and its replicas are sized properly, in terms of compute and storage, to suit their operational load. If a replica reaches compute, network, or storage resource capacity, the replica stops receiving or applying changes from its source. For information about monitoring replica performance and resource utilization, see [Monitoring read replication](USER_ReadRepl.Monitoring.md).
RDS for Db2 doesn't intervene to mitigate high replica lag between a source DB instance and its replicas. If you experience high replica lag, see [Monitoring Db2 replication lag](db2-troubleshooting-replicas.md#db2-troubleshooting-replicas-lag) for troubleshooting guidance.
You can modify the storage and CPU resources of a replica independently from its source and other replicas. For more information, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md).
## Task 3: Prepare databases
Before creating a replica, confirm that your databases are ready based on the following points:
+ The DB instance contains all databases that you want present on the DB instance. After replica creation, you can't create, drop, or native restore a database on the DB instance. Any calls to the [rdsadmin.create\$1database](db2-sp-managing-databases.md#db2-sp-create-database), [rdsadmin.drop\$1database](db2-sp-managing-databases.md#db2-sp-drop-database), or [rdsadmin.restore\$1database](db2-sp-managing-databases.md#db2-sp-restore-database) stored procedures fail.
+ All databases on the DB instance are in an active state. If any database is in an inactive state, replica creation will fail. For information about activating databases, see [Stored procedures for databases for RDS for Db2](db2-sp-managing-databases.md).
## Next steps
After completing all the preparation tasks, you are ready to create a Db2 replica.
+ To create a read-only replica, see [Creating a read replica](USER_ReadRepl.Create.md).
+ To create a standby replica, see [Creating a standby Db2 replica](db2-read-replicas.creating-in-standby-mode.md).
# Creating an RDS for Db2 replica in standby mode
By default, Db2 replicas are created in read-only mode. You can create a replica in standby mode for disaster recovery purposes. Standby replicas don't accept user connections but provide faster failover capabilities for cross-Region scenarios.
Before creating a standby replica, make sure that you have completed the preparation tasks. For more information, see [Preparing to create an RDS for Db2 replica](db2-read-replicas.Configuration.md). After creating a standby replica, you can change the replica mode. For more information, see [Modifying the RDS for Db2 replica mode](db2-replicas-changing-replica-mode.md).
You can create a standby replica using the AWS Management Console, the AWS CLI, or the RDS API. For information about creating a read-only replica, see [Creating a read replica](USER_ReadRepl.Create.md).
## Console
**To create a standby replica from a source RDS for Db2 DB instance**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the RDS for Db2 DB instance that you want to use as the source for a standby replica.
1. For **Actions**, choose **Create replica**.
1. For **Replica mode**, choose **Standby**.
1. Choose the settings that you want to use. For **DB instance identifier**, enter a name for the standby replica. Adjust other settings as needed.
1. For **Regions**, choose the AWS Region where the standby replica will be launched.
1. Choose your instance size and storage type. We recommend that you use the same DB instance class and storage type as the source DB instance for the standby replica.
1. 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.
1. Choose the other settings that you want to use.
1. Choose **Create replica**.
In the **Databases** page, the standby replica has the role **Replica**.
## AWS CLI
To create a Db2 replica in standby mode, use the AWS CLI command [create-db-instance-read-replica](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance-read-replica.html) with `--replica-mode` set to `mounted`.
**Example**
For Linux, macOS, or Unix:
```
aws rds create-db-instance-read-replica \
--db-instance-identifier my_standby_replica \
--source-db-instance-identifier my_db_instance \
--replica-mode mounted
```
For Windows:
```
aws rds create-db-instance-read-replica ^
--db-instance-identifier my_standby_replica ^
--source-db-instance-identifier my_db_instance ^
--replica-mode mounted
```
## RDS API
To create a Db2 replica in standby mode, specify `ReplicaMode=mounted` in the RDS API operation [CreateDBInstanceReadReplica](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstanceReadReplica.html).
# Modifying the RDS for Db2 replica mode
You can change the replica mode of an existing Db2 replica between read-only and standby modes. This flexibility allows you to adapt your replica configuration based on changing requirements for read workloads or disaster recovery needs.
You might want to change replica modes in the following scenarios:
+ **Read-only to standby** – When you no longer need read capacity but want to maintain disaster recovery capabilities
+ **Standby to read-only** – When you need to add read capacity for reporting or analytics workloads
Before changing replica modes, make sure the following conditions are met:
+ The replica is in an available state.
+ No active maintenance operations are running on the replica.
+ You have the necessary permissions to modify the DB instance.
The change operation can take a few minutes. During the operation, the DB instance status changes to **modifying**. For more information about status changes, see [Viewing Amazon RDSDB instance status](accessing-monitoring.md#Overview.DBInstance.Status). When you change from read-only to standby mode, the replica disconnects all active connections.
**Important**
Because changing replica modes temporarily interrupts service, plan the change during a maintenance window to minimize impact on your applications.
You can modify the replica mode using the AWS Management Console, the AWS CLI, or the RDS API.
## Console
**To change the replica mode of a Db2 replica**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the replica database that you want to modify.
1. Choose **Modify**.
1. For **Replica mode**, choose the desired mode:
+ **Read-only** – For read workloads
+ **Standby** – For disaster recovery
1. Choose the other settings that you want to change.
1. Choose **Continue**.
1. For **Scheduling of modifications**, choose **Apply immediately**.
1. Choose **Modify DB instance**.
1. After the modification completes, verify the replica mode change in the **Databases** page. The replica status should show as **Available** when the change is complete.
## AWS CLI
To change a Db2 replica from read-only mode to standby mode, set `--replica-mode` to `mounted` in the AWS CLI command [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html). To change a Db2 replica from standby mode to read-only mode, set `--replica-mode` to `open-read-only`.
The following example changes a replica from read-only to standby mode:
**Example**
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my_db2_replica \
--replica-mode mounted
```
For Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my_db2_replica ^
--replica-mode mounted
```
The following example changes a replica from standby to read-only mode:
**Example**
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my_db2_replica \
--replica-mode open-read-only
```
For Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my_db2_replica ^
--replica-mode open-read-only
```
## RDS API
To change a Db2 replica from read-only mode to standby mode, set `ReplicaMode=mounted` in [ModifyDBInstance](AmazonRDS/latest/APIReference/API_ModifyDBInstance.html). To change a Db2 replica from standby mode to read-only mode, set `ReplicaMode=open-read-only`.
The following is an example API call to change the replica mode from read-only to standby:
```
{
"DBInstanceIdentifier": "my_db2_replica",
"ReplicaMode": "mounted",
"ApplyImmediately": true
}
```
The following is an example API call to change the replica mode from standby to read-only:
```
{
"DBInstanceIdentifier": "my_db2_replica",
"ReplicaMode": "open-read-only",
"ApplyImmediately": true
}
```
For information about the differences between replica modes, see [Working with replicas for Amazon RDS for Db2](db2-replication.md). For troubleshooting replica issues, see [Troubleshooting RDS for Db2 replication issues](db2-troubleshooting-replicas.md).
# Working with RDS for Db2 replica backups
You can create and restore backups of an RDS for Db2 replica just like a primary database. However, there are important differences in how replica backups work, particularly regarding restore timing and backup retention settings.
RDS for Db2 supports both automatic backups and manual snapshots for replicas. RDS for Db2 doesn't support point-in-time restore. For information about RDS backups, see [Backing up, restoring, and exporting data](CHAP_CommonTasks.BackupRestore.md).
## Key differences for replica backups
Replica backups differ from primary database backups in several important ways:
+ Automatic backups aren't enabled by default for replicas.
+ Restore operations use database time rather than backup creation time.
+ Replica lag can affect the actual data restored. For information about monitoring replica lag, see [Monitoring Db2 replication lag](db2-troubleshooting-replicas.md#db2-troubleshooting-replicas-lag).
## Enabling automatic backups for RDS for Db2 replicas
Unlike primary databases, RDS for Db2 replicas don't have automated backups enabled by default. You must manually configure the backup retention period to enable automatic backups. Enable automated backups by setting the backup retention period to a positive nonzero value.
### Console
**To enable automatic backups immediately**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**, and then choose the DB instance that you want to modify.
1. Choose **Modify**.
1. For **Backup retention period**, choose a positive nonzero value, for example three days.
1. Choose **Continue**.
1. Choose **Apply immediately**.
1. Choose **Modify DB instance** to save your changes and enable automated backups.
### AWS CLI
To enable automated backups, use the AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) command.
Include the following parameters:
+ `--db-instance-identifier`
+ `--backup-retention-period`
+ `--apply-immediately` or `--no-apply-immediately`
The following example enables automated backups by setting the backup retention period to three days. The changes are applied immediately.
**Example**
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my_db_instance \
--backup-retention-period 3 \
--apply-immediately
```
For Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier my_db_instance ^
--backup-retention-period 3 ^
--apply-immediately
```
### RDS API
To enable automated backups, use the RDS API [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) operation with the following required parameters:
+ `DBInstanceIdentifier`
+ `BackupRetentionPeriod`
## Restoring an RDS for Db2 replica backup
You can restore an RDS for Db2 replica backup the same way that you can restore a backup of the primary database. For more information, see [Restoring to a DB instance](USER_RestoreFromSnapshot.md).
The most important consideration when restoring replica backups is understanding the difference between database time and backup creation time, especially when replica lag is present.
You can monitor replication lag and ensure that your backups contain the expected data. For information about the ReplicaLag metric, see [Amazon CloudWatch metrics for Amazon RDS](rds-metrics.md).
### Understanding timing differences
When you restore a replica backup, you must determine the point in time to which you are restoring. The database time refers to the latest applied transaction time of the data in the backup. When you restore a replica backup, you restore to the database time, not the time when the backup completed. The difference is significant because a replica can lag behind the primary database by minutes or hours. Thus, the database time of a replica backup might be much earlier than the snapshot creation time.
To find the difference between database time and creation time, run the AWS CLI [describe-db-snapshots](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-snapshots.html) command or call the RDS API [DescribeDBSnapshots](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBSnapshots.html) operation. Compare the `SnapshotDatabaseTime` value and the `OriginalSnapshotCreateTime` value. The `SnapshotDatabaseTime` value is the earliest database time among all the databases of the replica backup. The `OriginalSnapshotCreateTime` value is the latest applied transaction on the primary database. Note that replication lags could be different for multiple databases, and the database time could be in between these two times.
The following AWS CLI example shows the difference between the two times:
For Linux, macOS, or Unix:
```
aws rds describe-db-snapshots \
--db-instance-identifier my_db2_replica \
--db-snapshot-identifier my_replica_snapshot
```
For Windows:
```
aws rds describe-db-snapshots ^
--db-instance-identifier my_db2_replica ^
--db-snapshot-identifier my_replica_snapshot
```
This command produces output similar to the following example.
```
{
"DBSnapshots": [
{
"DBSnapshotIdentifier": "my_replica_snapshot",
"DBInstanceIdentifier": "my_db2_replica",
"SnapshotDatabaseTime": "2022-07-26T17:49:44Z",
...
"OriginalSnapshotCreateTime": "2021-07-26T19:49:44Z"
}
]
}
```
# Troubleshooting RDS for Db2 replication issues
This topic describes common RDS for Db2 replication issues and provides troubleshooting guidance for both read-only and standby replicas. In addition to reviewing the following troubleshooting information, make sure that you followed the [requirements and considerations](db2-read-replicas.limitations.md), and completed the [preparation steps](db2-read-replicas.Configuration.md) before creating Db2 replicas.
## Replica creation failures
Replica creation can fail for several reasons:
+ **Inactive databases** – All databases on the source DB instance must be active before creating replicas.
For information about activating databases, see [Stored procedures for databases for RDS for Db2](db2-sp-managing-databases.md).
+ **Missing automatic backups** – The source DB instance must have automatic backups enabled.
For information about enabling backups, see [Enabling automatic backups for RDS for Db2 replicas](db2-read-replicas.backups.md#db2-read-replicas.backups.turning-on).
+ **Parameter group issues** – Custom parameter groups are required for replicas. For BYOL licensing, the parameter group must include the IBM Site ID and IBM Customer ID.
For more information, see [IBM IDs for bring your own license (BYOL) for Db2](db2-licensing.md#db2-prereqs-ibm-info).
## Monitoring Db2 replication lag
To monitor replication lag in Amazon CloudWatch, view the Amazon RDS `ReplicaLag` metric. For more information about replication lag time, see [Monitoring read replication](USER_ReadRepl.Monitoring.md) and [Amazon CloudWatch metrics for Amazon RDS](rds-metrics.md). For information about setting up CloudWatch alarms for replica lag, see [Monitoring Amazon RDS metrics with Amazon CloudWatch](monitoring-cloudwatch.md).
For a read-only replica, if the lag time is too long, query the `MON_GET_HADR` table for the status of the replica DB instance.
For a standby replica, if the lag time is too long, query the `MON_GET_HADR` table for the status of the source DB instance. Don't query the replica DB instance because replica DB instances don't accept user connections.
Common causes of high replication lag include the following reasons:
+ Insufficient compute resources on the replica
+ Network connectivity issues between the source and the replica
+ High write activity on the source database
+ Storage performance limitations on the replica
If high replication lag persists, consider scaling your replica resources. For more information, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md).
## Db2 replication errors
Db2 replication can be in an error state for a number of reasons. Perform the following actions:
+ Monitor events and the DB instance state to make sure that the DB instance is replicating.
For more information, see [Working with Amazon RDS event notification](USER_Events.md).
+ Check the diagnostic logs for the Db2 replica in the Amazon RDS console. In the logs, look for errors in HADR messages. Compare the log sequence number to the primary sequence number.
For information about accessing and interpreting Db2 diagnostic logs, see [Amazon RDS for Db2 database log files](USER_LogAccess.Concepts.Db2.md). For information about Db2 HADR configuration and troubleshooting, see [Working with replicas for Amazon RDS for Db2](db2-replication.md).
If replication errors persist, you might need to recreate the replica.
## Connection issues
If you can't connect to your replica, review the following information about the replica modes:
+ **Standby replicas** – They don't accept user connections by design. Use read-only replicas for read workloads.
+ **Read-only replicas** – Check your security group settings, network ACLs, and parameter group configurations.
For more information, see [Control traffic to your AWS resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) in the *Amazon VPC User Guide*, [Control subnet traffic with network access control lists](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) in the *Amazon VPC User Guide*, and [Parameter groups for Amazon RDS](USER_WorkingWithParamGroups.md).
## Performance issues
If replica performance is poor, review the following suggestions:
+ Ensure the replica has adequate compute and storage resources.
+ Monitor the `ReplicaLag` metric in Amazon CloudWatch.
+ Consider scaling up the replica DB instance class.
For information about modifying resources or instance classes, see [Modifying an Amazon RDS DB instance](Overview.DBInstance.Modifying.md).
For information monitoring replication lag, see [Monitoring replication lag](USER_ReadRepl.Monitoring.md#USER_ReadRepl.Monitoring.Lag) and [Amazon CloudWatch metrics for Amazon RDS](rds-metrics.md). For information about setting up CloudWatch alarms for replica lag, see [Monitoring Amazon RDS metrics with Amazon CloudWatch](monitoring-cloudwatch.md).