您使用 Amazon EBS 快照功能进行 MySql 热备份的经验是什么?
我有一个在 ec2 中运行批处理作业的数据库。我用 EBS 快照备份。到目前为止,备份看起来是一致的。但我担心他们“一旦我停止检查就会停止一致”(不确定性原则)。
您在使用 ebs 快照备份关系数据库(尤其是 mysql)方面有何经验?
您使用 Amazon EBS 快照功能进行 MySql 热备份的经验是什么?
我有一个在 ec2 中运行批处理作业的数据库。我用 EBS 快照备份。到目前为止,备份看起来是一致的。但我担心他们“一旦我停止检查就会停止一致”(不确定性原则)。
您在使用 ebs 快照备份关系数据库(尤其是 mysql)方面有何经验?
一年多来,我一直在使用 EBS 快照备份我的 MySQL 数据目录。它一直在完美地工作。使用这些快照作为替换(或克隆)MySQL 设置的基础,我从来没有遇到过问题。
最佳实践是使用允许冻结的文件系统(例如 XFS)格式化 EBS 卷。这允许您获得一致的快照:将 MySQL 的内存刷新到磁盘,冻结文件系统,快照,然后解冻。整个过程需要不到 10 秒的时间(但当数据库大量使用时可能需要更长的时间)。
请参阅Eric Hammond 的这篇文章,了解为您完成所有这些工作的脚本。
MySQL 以从不一致的磁盘状态中恢复不佳而闻名,XFS 本质上是在快照发生时暂停对文件系统的 IO。通常,一旦创建了完整的事务日志条目,数据库就会执行 flush(),这实际上表明了文件系统的检查点。在日志文件系统的情况下,这很重要,并且在大多数情况下,一旦挂载,文件系统将恢复到最后一个有效的日志条目,这不是 100%,但总比没有好。如果数据库文件在事务日志之后,大多数数据库系统使用事务日志文件在恢复时“前滚”,并且数据库引擎只会在给定事务日志内容的情况下前滚。它不会尝试通过部分写入的事务前滚。这里的问题是 MySQL 在实现这一点方面并不是最好的,所以它绝对是一个问题。我还没有找到一个可靠的解决方案,我想运行一个镜像,在你做快照的同时暂停 MySQL,然后恢复同步可能会起作用,但我不知道 MySQL 镜像是否可以处理部分不可用的镜像一段时间,然后能够在没有完整重新镜像的情况下赶上,在这种情况下,您不妨只对所有数据库进行 mysqldump,因为它对数据库的影响与运行完整镜像大致相同。这是我能想到的另一个运行时选项——将所有数据库的 mysqldump 运行到备份分区并对其进行快照。不给你运行备份,所以你不能经常这样做,如果你是 24/7,
其他数据库引擎在这方面要好得多。PostgreSQL 非常擅长从不稳定的磁盘状态恢复到他们根本不建议在日志文件系统上运行它的地步。您还可以选择归档事务日志,这样您就可以从最后一个良好的完整备份前滚到归档日志存在的任何时间点。使用它进行一致的备份要容易得多。Oracle 将允许您拥有在物理磁盘/EBS 分区之间切换的多组事务日志,从而为您提供频繁的窗口来拍摄一致的快照,并能够向数据库引擎指示您希望这样做,而不是翻转回来,直到你这么说。
按照日志的思路,LVM 通常可以在一秒钟内对整个文件系统进行快照。我不知道 EBS 快照功能是否会利用这一点,尽管您可以手动执行此操作。LVM 比 XFS 稍微复杂一些,但我过去曾遇到过 XFS 的问题,因为它在一个 ext3 很好的单个目录中处理大量文件。LVM 还有很多其他好处,无论哪种方式都绝对值得研究。
我建议使用 LVM 作为数据库文件系统的抽象层。因为这将获得本地快照的好处,就像热备份一样。LVM 快照的好处是可以实现与 EBS 相似的结果,并且可以在任何机器上使用它(不仅仅是基于亚马逊的)。
另一个优点是 LVM 可以使用热调整大小,当您需要最少的停机时间并且需要动态扩展磁盘空间时特别好(不推荐,但在特定情况下可能)
我主要关心的是依赖 EBS 快照在它们运行的级别进行数据库备份。快照在磁盘上的一个非常低的级别上运行并拍摄图像,而不管应用程序写入它的状态如何。从理论上讲,您的备份映像可能处于事务或其他事情的中间,如果到了那个时候,这会使恢复变得有些尴尬。
您可能会考虑使用Amazon RDS来管理您的数据库——它就像标准的 MySQL 服务器一样工作,然后如果它崩溃(它不会),您可以责怪 Amazon。此外,他们会定期为您备份和修补服务器。我移动了我的 Wordpress 和 vBulletin 安装,大概花了一个小时。
只是我的2美分!