使用亚马逊的EBS进行MySQL热备份

Question

使用Amazons EBS快照功能进行MySql热备份的经验是什么。

我有一个在ec2中运行批处理作业的数据库。我用EBS快照备份。到目前为止，备份看起来一致。但我担心他们“一旦我停止检查就会停止保持稳定”（不确定性原则）。

使用ebs快照备份关系数据库（尤其是mysql）有什么经验？

Answer 1

我一直使用EBS快照来备份我的MySQL数据目录超过一年。它一直很完美。我使用这些快照作为替换（或克隆）MySQL设置的基础从未出现过问题。

最佳做法是使用允许冻结的文件系统格式化EBS卷，例如XFS。这允许您获得一致的快照：将MySQL的内存刷新到磁盘，冻结文件系统，快照，然后解冻。整个过程只需不到10秒钟（但在DB大量使用时可能需要更长时间）。

请参阅Eric Hammond的this article以获取为您完成所有这些操作的脚本。

Answer 2

MySQL因不一致的磁盘状态恢复不良而声名远扬，XFS在快照发生时基本上将IO暂停到文件系统。通常，一旦创建了完整的事务日志条目，数据库就会执行flush（），这表明文件系统基本上是一个检查点。在日志文件系统的情况下，这很重要，并且在大多数情况下，文件系统将恢复到安装后的最后一个有效日记帐分录，这不是100％，但它总比没有好。如果数据库文件位于事务日志之后，则大多数数据库系统使用事务日志文件在恢复时“前滚”，并且数据库引擎将仅向前滚动事务日志的内容。它不会尝试通过部分书面交易前滚。这里的问题是MySQL并不是最好的，所以它绝对是一个问题。我没有找到一个可靠的解决方案，我会想象运行一个镜像，在你执行快照时暂停MySQL然后恢复同步可能会起作用，但我不知道MySQL镜像是否可以应对镜像部分不可用一段时间，然后能够赶上没有完整的重镜，在这种情况下，你可能只是做一个所有数据库的mysqldump，因为它会对数据库产生与运行完整镜像相同的效果。这是我能想到的另一个同时运行的选项 - 将所有数据库的mysqldump运行到备份分区和快照。没有给你运行备份，所以你不能经常这样做，如果你是24/7，mysqldump在数据库运行时会给数据库带来沉重负担，远远不是最佳状态。

其他数据库引擎在这方面要好得多。 PostgreSQL非常擅长从一个不存在的磁盘状态恢复到他们不建议在一个记录的文件系统上运行它。您还可以选择归档事务日志，以便可以从上一次良好的完整备份前滚到存档日志的任何时间点。使用它可以更容易地进行一致的备份。 Oracle将允许您拥有多组事务日志，这些日志可在物理磁盘/ EBS分区之间切换，从而为您提供频繁的窗口以获取一致的快照，并能够向数据库引擎指示您希望执行此操作，而不是翻转回到你这么说。

沿着日志思维，LVM能够在一秒钟内快照整个文件系统。我不知道EBS快照功能是否会利用这一点，尽管您可以手动执行此操作。 LVM比XFS更加繁琐，但过去我曾经遇到过XFS的问题，因为在一个目录中大量的文件都可以使用，其中ext3很好。 LVM也有许多其他好处，绝对值得研究。

Answer 3

我主要关注的是依赖EBS快照进行数据库备份操作。快照在磁盘上以非常低的级别运行，并且无论写入应用程序的状态如何，都会拍摄图像。从理论上讲，您的备份映像可能处于事务中间或某些事情，如果时间到了，这将使恢复有点尴尬。

Answer 4

我建议使用LVM作为DB文件系统的抽象层。因为这将获得本地快照的好处，就像热备份一样。 LVM快照的好处是可以在EBS上获得类似的结果，并且可以在任何机器上使用它（不仅仅是基于亚马逊）。

另外一个优点是，LVM可以使用热调整大小，特别好，当您需要最少的停机时间并且需要动态扩展磁盘空间时（不推荐，但在特定情况下可能）< / p>

Answer 5

你可能会考虑使用Amazon RDS来管理你的数据库 - 它就像一个标准的MySQL服务器一样，然后你可以责怪亚马逊崩溃（它不会）。此外，他们会定期为您备份和修补服务器。我把我的Wordpress和vBulletin安装完了，花了大概一个小时。

只是我的2¢！