Read replication scales database reads horizontally by copying changes from a writable primary to one or more read-only replicas. Applications distribute read requests across the primary and replicas while sending writes to the primary. section 10.6.2
Replication is asynchronous, so a replica can lag behind the primary. This improves read throughput when an application performs many more reads than writes, but users may see stale data. section 10.6.2 section 11.5.3
A practical Amazon RDS setup involves:
- Enable automatic backups before creating the replica. section 10.6.2
- Create the replica from the primary database; RDS snapshots the source, launches the new instance, activates replication, and provides a read endpoint. section 10.6.2
- Route read and write requests separately in the application; database replication alone does not make this distinction. section 10.6.2
- Monitor replication lag and increase cache capacity with additional shards or replicas when lag indicates a capacity problem. section 11.5.3 section 11.6
Scaling a WordPress database
For an RDS-backed WordPress site, create a read replica with the AWS CLI and configure application support for replica reads. WordPress does not support read replicas by default; HyperDB can provide that support, but its configuration is tricky. The replica incurs additional charges and can later be promoted to primary when supported. section 10.6.2 section 10.6.2
Use the AWS CLI command to create an RDS read replica from the existing primary instance. section 10.6.2

