CodeParkRead replicas take most of the read load off the primary database. A read replica is a copy of the database that receives every change from the primary (the main database). The application sends reads to the replicas. All writes still go to the primary.
With 90% reads, you spread those reads over several replicas, so the primary has much less work. Replicas can also act as standby candidates for failover: if the primary dies, a replica can take its place.
The new problems:
- Replication lag. Replication is usually asynchronous: the primary does not wait for replicas to copy a write. So a replica can return old (stale) data.
- Read-your-writes breaks. A user saves a change, then reads from a replica that has not received it yet. The fix is to send that user's reads to the primary for a short time after they write.
- Two connection targets. The application must manage one connection for writes and another for reads.
- No help for writes. Replicas do nothing for write throughput. If writes become the bottleneck, you need caching of hot data, batching, or partitioning.
Before you add replicas, check whether indexes and a cache would solve the problem more cheaply.
- Writes go to the primary, and reads are spread over the replicas.
- Asynchronous replication means a replica can return stale data.
- Read-your-writes needs special routing, such as reading from the primary right after a write.
- Read replicas do not scale writes.
- Try indexes and caching first, because they are cheaper.
Read more