在 AWS RDS 上执行 MASTER-MASTER 复制时，我应该担心和注意哪些时间延迟注意事项

Posted 2023-03-04

【中文标题】在 AWS RDS 上执行 MASTER-MASTER 复制时，我应该担心和注意哪些时间延迟注意事项

【英文标题】：What are the Time-Delay considerations, I should be worried about and take care while performing MASTER-MASTER Replication on AWS RDS

【发布时间】：2020-05-22 07:08:53

【问题描述】：

我正在尝试通过执行automated Vertical Scaling 以完美的零停机时间来实现成本优化。

仅供参考：我的应用程序是 LAMP 堆栈，在大约 200 个用户的峰值负载时，重写入 IOPS 接近 8000。

但是，使用上述链接进行自动缩放时，会在多可用区切换期间引入 30-50 秒的停机时间。为了避免这种情况，我们尝试在使用上述脚本中的步骤之前设置 Master-Master Replication。

我正在使用this link 设置主-主复制。

简要介绍一下我正在尝试做的事情。

从 M1 创建只读副本 停止副本 从只读副本创建快照 从 Sanpshot 创建 DB(M2) 将 M2 设置为 M1 的从站。 将 M1 设置为 M2 的从站。 Master-Master 已设置

根据我的要求进行其他步骤：

删除副本和快照 执行应用切换到 M2 垂直刻度/保持M1 执行应用程序切换到 M1 DB 已正确扩展 删除 M2。

【问题讨论】：

我不确定我是否理解您的想法。您希望通过对实例大小进行复杂的自动缩放来处理预期的峰值流量，从而节省成本，预计成本节省 50%，但是您希望通过将实例数量加倍来避免这种大小切换带来的停机时间（从而将成本设置回原来的水平）并且必须引入 master/master（RDS 不支持这种方式，并且 master/master 以引入数据丢失和损坏而闻名）才能使其工作？

所有这些设置将在一小时内被删除。所以本质上，我们支付高峰使用时间 + 1 小时。发布 RDS 减少，从而节省成本。 @ydaetskcoR

这绝对是一个疯狂的复杂性，即使它完美地工作，它所花费的工程时间也将超过它所节省的时间。它可能不会。在这种情况下，它会花费你最重要的东西——数据。我强烈建议不要这样做。

我通常只会将您的数据库大小保持在需要的大小，除非您即将发生重大的、不规则的扩展事件（您正在运行 Superbowl 广告/在黑色星期五）。如果您需要动态扩展，请使用只读副本来承担读取负载、在其他地方缓存（例如 Redis）、切换到 Aurora，甚至可以使用 Aurora 无服务器或非关系型、可扩展性更高的数据库，例如 DynamoDB。

我的应用在 LAMP 堆栈上，日负载约为 2000 名用户。上午 11 点左右约 200 名用户的峰值负载。想法是在清晨扩大规模，然后根据 CPU util 或基于时间的时间每天缩小规模。

【参考方案1】：

在开始之前，我建议

使用慢日志来识别“最差”的查询，然后尝试加快它们的速度和/或避免它们。 找出写入和读取 IOP 之间存在如此不平衡的原因。 实施副本以卸载任何与写入无关的读取。

无论如何，使用Master-Master，所有写入仍在两台服务器上完成。那就是 写 IOP 可能不会提高！

【讨论】：

使用慢日志来识别“最差”的查询，然后尝试加快和/或避免它们。 ：已经识别了它们，其他工程师团队已将它们从 15 分钟缩短到 30 秒。弄清楚为什么在写入和读取 IOP 之间存在这种不平衡：应用程序更新繁重，基于每个关键的用户操作，活动都会被记录下来。让它写得很重。实施副本以卸载任何与写入无关的读取：这将如何降低 IOPS？ @rick-james