发布时间：2022-09-27 00:00   您所在的位置： 网站首页 > 新闻资讯 > 经验杂谈

对备份，只是希望在进入正式话题以前，允许给一部分小提示。

● 在备份上不要拖延，做备份其实并不难。

● 做事不要追求完美，而要追求可恢复。

● 至少相对可接受的数据损失、可接受的宕机時间、数据持续策略以及保险需求要形成文档。

● 对恢复过程要开展练习并形成文档，恢复比备份要重要得多!

● 相对备份作业胜利与否，要开展外部验证，不要依赖于作业自身对你的提示。

下边，让咋们将繁文缛节的形式抛在一边，看一看怎么用复制从服务器做备份。



最先，最显然的事情，是将从服务器自身作为备份。不幸的是，这并不是一个真正的备份。在发生问题时，如丧失了服务器或其一部分、恶意攻击造成的数据破坏、偶然的DROPTABLE，真正的备份可以挽回损失，而复制从服务器相对上述后两个问题所造成的数据损失，却是无能为力的，由于它只是好心地将数据改变复制了过来，从而将数据的破坏或损失也一并复制了过来。

故此，怎么做真正的备份呢?假如只有一台复制从服务器，而且这台服务器也有多余的空间做cron作业等，则在不必数据库服务器的时候，将其停掉，然后备份其数据。相对MYSQL:在MYSQL进程运行的时候，不要复制IINNODB的文件，这样子是无法复制的。假如可以停掉MYSQL，然后将其数据移走，则相对大多数情况，全是最保险的。

假如不想停止服务器，还有一个选择，便是Ktrabackup，一个免费和开源的非阻塞备份程序，用于备份INNODB和KTRADBE的表。假如有MYISAM表，则在复制时会开展锁定。Xtrabackup基于与INNODBI的热备工具一样的原理，但XTRADB开源，且具有一部分额外的特点。

我过去建议人们使用文件系统快照，特别是LVM快照。这些快照也可以创建备份，而又不可能打断数据库的操作。但经过一部分基准测试，我和我的同事都不再推荐这种方法了。LVM的问题是决定性能，而且比咋们过去认为的决定要大得多。其他有快照能力的文件系统，如ZFS，相对比较新，我也不是这方面的专家，故此也就没什么可说的。我的有一些客户使用Solaris和ZFS，尽管很难分离每个变量，或者直接比较性能，但我并不认为性能有明显的好转。ZFS写时复制(copy-on-write)的行为，使得关于数据如何物理组织的考虑变得很复杂了，关于这方面，我还没有足够的時间来熟悉，故此也就无法做出合理的推荐。故此，在我看来，将ZFS用做数据库的文件系统，还仍然没有取得一致意见。故此，在开源领域，我还没有见到基于快照的备份的杀手级解决方案。

关于MYSQLI的，而MYSQL没有这种能力，故此，MYSQL的备份就有点复杂了。好多数据库都有内置的热备能力，假如你的数据库有，就使用它。前面的讨论大部分全是相对MYSQL，可能其他数据库也一样，可以用复制从服务器来做这样子的事:将复制延迟一段時间，如一个小时。这可以使用Maatkitt的mk-slave-delay工具来实现。将延迟的服务器用

做备份”，有下边两个有趣的点:

● 一直地从主服务器中获取更新，但并不应用这些更新，这意味着，比起昨天晚上做的备份(在发生崩溃的时候，备份的数据可能已经过去24小时了)，丧失数据的机会要低得多。在延迟時间到达时，服务器将应用从主服务器中获取的更新。

● 假如发生问题，这种延迟会给你一段缓冲時间。偶然的DROPTABLE，在你的从服务器上会延迟一个小时才会发生，故此，在又对主服务器上的表开展恢复等类似操作时，可以跳过从服务器上DROP，并将从服务器切换为主服务器。这段额外的延迟時间，给了恢复操作相当的选择空间。

将延迟从网站开发服务器用做备份的补充，而不是替代。你仍然必须要做具体的备份!

本文章由新概念互动原创，如没特殊注明，转载请注明来自：http://www.jianzhan0.com/jingyand/72180.html

上一篇：怎么进行网站的真实用户监控(RUM)？

下一篇：怎么将网站关系数据库用于Web的战略战术？