- 新しい順
- 投票が多い順
- コメントが多い順
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.
関連するコンテンツ
AWS公式更新しました 3年前
I know the reader instance has its own CPU and that is separate to the writer instances CPU.