- Newest
- Most votes
- Most comments
Read replica in RDS is realized based on the replication function of MySQL. This is achieved by transferring the binary log of the write instance to the reader instance and reproducing it on the reader instance.
In other words, since the read instance exists separately, including the disk, it is not considered to affect the write instance.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.ReadReplicas.html
Great. This was my research but great to get confirmation. Thanks for the time.
Agreed that queries on the read replica will not impact the primary database server, however there is a small risk that if your queries on the read replica max out the CPU that the replication process will slow down in writing updates to the read replica and replication lag will increase (the amount of time the replica is behind the primary database).
If you're using MySQL, have you considered migrating to Amazon Aurora MySQL compatible? Aurora separates the compute and the storage, and the primary and read replica's all reference the same underlying logical storage, so you don't have the issue of heavy reads on a read replica increasing replication latency. See: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html
Also, Aurora includes an optional feature (Parallel Query) that speeds up analytical queries by pushing down some of the query processing to the storage layer. See: https://aws.amazon.com/rds/aurora/parallel-query/.
Because of these things, your may benefit significantly by migrating to Aurora.
We are in fact using Aurora so this is extra good news. Thanks for the time and information.
Relevant content
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated 3 years ago
I know the reader instance has its own CPU and that is separate to the writer instances CPU.