Promoting a read replica to be a standalone DB instance

Implementing failure recovery – You can use read replica promotion as a data recovery scheme if the primary DB instance fails. This approach complements synchronous replication, automatic failure detection, and failover.

If you are aware of the ramifications and limitations of asynchronous replication and you still want to use read replica promotion for data recovery, you can. To do this, first create a read replica and then monitor the primary DB instance for failures. In the event of a failure, do the following:

Upgrading storage configuration – If your source DB instance isn't on the preferred storage configuration, you can create a read replica of the instance and upgrade the storage file system configuration. This option migrates the file system of the read replica to the preferred configuration. You can then promote the read replica to a standalone instance.

You can use this option to overcome the scaling limitations on storage and file size for older 32-bit file systems. For more information, see Upgrading the storage file system for a DB instance.

This option is only available if your source DB instance is not on the latest storage configuration, or if you're modifying the DB instance class within the same request.

Sharding – Sharding embodies the "share-nothing" architecture and essentially involves breaking a large database into several smaller databases. One common way to split a database is splitting tables that are not joined in the same query onto different hosts. Another method is duplicating a table across multiple hosts and then using a hashing algorithm to determine which host receives a given update. You can create read replicas corresponding to each of your shards (smaller databases) and promote them when you decide to convert them into standalone shards. You can then carve out the key space (if you are splitting rows) or distribution of tables for each of the shards depending on your requirements.

Performing DDL operations (MySQL and MariaDB only) – DDL operations, such as creating or rebuilding indexes, can take time and impose a significant performance penalty on your DB instance. You can perform these operations on a MySQL or MariaDB read replica once the read replica is in sync with its primary DB instance. Then you can promote the read replica and direct your applications to use the promoted instance.

The standalone DB instance retains the option group and the parameter group of the pre-promotion read replica.

You can create read replicas from the standalone DB instance and perform point-in-time restore operations.

You can't use the DB instance as a replication target because it is no longer a read replica.

Review your backup strategy:

Stop any transactions from being written to the primary DB instance, and then wait for RDS to apply all updates to the read replica.

Database updates occur on the read replica after they have occurred on the primary DB instance. Replication lag can vary significantly. Use the Replica Lag metric to determine when all updates have been made to the read replica.

(MySQL and MariaDB only) To make changes to a MySQL or MariaDB read replica before you promote it, set the read_only parameter to 0 in the DB parameter group for the read replica. You can then perform all needed DDL operations, such as creating indexes, on the read replica. Actions taken on the read replica don't affect the performance of the primary DB instance.