Amazon RDS 备份/快照实际上是如何工作的？

我是一个亚马逊 RDS 客户，每天都会经历亚马逊 RDS 写延迟峰值，大致相当于备份窗口。我还将看到快照结束时的峰值(例如: 运行快照需要1小时，在最后5分钟，写入延迟峰值)。我正在运行一个多 AZ m1.large 部署。

Stack 上有人能解释一下 Amazon RDS 备份是如何工作的吗？我读过亚马逊的 RDS 文档，就我所知，亚马逊的 RDS 并没有按照规范行事。具体来说，这些备份/快照操作应该会影响到我的副本，因此不会导致任何停机/性能损失，至少我是这么认为的。

我可以把我的问题浓缩成六个问题:

在快照和备份期间技术上发生了什么，它们有什么不同？(如果你回答了这个问题，请告诉我你是否能够凭经验证实你的答案，或者只是引用我的文件)。
在多 AZ 部署的备份窗口期间是否会出现写入延迟峰值？
在多 AZ 部署的快照结束时是否预期写入延迟激增？
如果我不是多 AZ，我的写延迟峰值会更高吗？
从架构上讲，如果我在两个 m1.large EC2实例上运行我自己的数据库，我是否能够避免这些写延迟峰值？
有没有什么配置我可以使用，以避免这些写延迟峰值，同时仍然托管我的数据库与 RDS，或我有效地在亚马逊的怜悯？

附加问题: 在哪里以及如何托管 mysql 数据库？

我可以说，除了这些日常写延迟问题之外，我一般对 RDS 感到满意。我喜欢内置的数据库监控，它的设置和运行相当简单。

谢谢！

amazon RDS write latency

28461

小开

最佳答案

We also run several RDS instances, in addition to MySQL on some machines that we manage ourselves. I can't comment specifically, as I'm not an Amazon engineer, but several things I've learned that might explain what you're seeing:

Although Amazon does not share the backend details 100%, we strongly suspect that they are using their EBS system to back RDS databases.
This article helps explain EBS limitations and snapshot functionality http://blog.rightscale.com/2008/08/20/amazon-ebs-explained/ Again, while it's not explicit, it would make sense for Amazon to be using this infrastructure to provide RDS services.
Typically, a MySQL backup, in contrast to a snapshot, involves using a tool like mysqldump to create a file of SQL statements that will then reproduce the database. The database does not need to be frozen to do this. With an EBS backend, the best practice is to freeze the database (pause all transactions) while you are snapshotting to avoid data corruption.
The spikes you're seeing at the ends of the backup window. If replication is paused by Amazon during the snapshot of your replica, the replica would then need to "catch up" on transactions when the snapshot was complete. This would cause a latency spike.
Replication across a multi-AZ deployment is inherently slower then a single AZ deployment. The price you pay for better redundancy.