Aurora副本的大小是否需要与源数据库的大小匹配？

Question

【以下的问题经过翻译处理】 客户的问题：

我们目前使用以下规格的Aurora：

主实例：db.r4.16xlarge

副本a：db.r4.8xlarge

副本b：db.r4.8xlarge

副本c：db.r4.8xlarge

副本d：db.r4.16xlarge<--故障转移

在这个文档链接中，我们看到了以下段落：

“为了使复制正常运作，每个只读副本应该拥有与源DB实例相同的计算和存储资源。如果您扩展了源DB实例，您也应该扩展只读副本。”

然而，我们在Aurora文档中没有找到类似的说明。

关于Aurora MySQL的主/副本规格，是否有任何指导？它们是否需要相同的实例规格？

**更新**
客户的后续问题：

当故障转移发生（即主实例故障，且最高优先级的故障转移副本得到提升）时，是否只会产生性能影响？还是在正常复制期间也会产生影响？

Answer

【以下的回答经过翻译处理】 客户的后续问题更新：当故障转移发生（即主节点故障，最高的故障转移副本被提升），是否只会产生性能影响？ 在正常复制过程中是否会产生影响？

回答：

由于Amazon Aurora副本与同一AWS区域中的主要实例共享相同的数据卷，因此几乎没有复制延迟。我们通常观察到10毫秒左右的滞后时间。
参见

按设计，复制是异步的。因此，副本滞后取决于数据库更改的速率。也就是说，如果数据库进行了大量写操作的时期，您可能会看到副本滞后有所增加。因为我们必须将相同的日志更改（重做日志）发送到读取副本以更新缓存。如果有太多的更改，您可能会看到比预期的滞后。这不取决于您为读取副本使用哪个实例类。

Re-Invent视频：

现在，通过为读副本使用较小的实例类：

1.）您可能会看到很多查询会执行物理读取（读取IOPS会增加），而不是逻辑读取。
2.）当故障转移发生在读取副本上时，您可能会看到性能受到影响，因为它资源（CPU，内存等）较少。

Relevanter Inhalt