关于备份，我只是希望在进入正式话题之前能给大家一些提示。 不要拖延备份，这并不难。 做事不追求完美，而追求可恢复性。 至少记录可接受的数据丢失、可接受的停机时间、数据持久性策略和安全要求。 练习并记录恢复过程。恢复比备份重要得多！ 对于备份作业的成功，请执行外部验证，不要依赖作业本身来提示您。接下来，让我们抛开繁文缛节，看看如何使用**从服务器进行备份。首先，最明显的事情就是使用服务器本身作为备份。不幸的是，这不是真正的备份。当出现问题时，例如服务器或其部分丢失、恶意攻击造成的数据损坏、意外DROPTABLE等，真正的备份可以恢复损失，但上面提到的最后两个问题造成的数据丢失从从服务器是无能为力的，因为它只是善意地防止数据更改，从而也防止数据损坏或丢失。那么，如何进行真正的备份呢？如果只有一台从服务器，并且这台服务器还有额外的空间用于cron作业等，那么在数据库服务器不使用时将其停止，然后备份其数据。对于MYSQL:当MYSQL进程运行时，不要**IINNODB文件，就不会**。如果您可以停止MYSQL，然后移动其数据，那么在大多数情况下这是最安全的。如果您不想停止服务器，另一个选择是Ktrabackup，这是一个免费开源的非阻塞备份程序，用于备份INNODB 和KTRADBE 表。如果有MYISAM表，**时就会被锁。 Xtrabackup 与INNODBI 的热备份工具基于相同的原理，但XTRADB 是开源的，并且具有一些附加功能。我过去建议人们使用文件系统快照，特别是LVM 快照。这些快照还可以在不中断数据库操作的情况下创建备份。但经过一些基准测试后，我和我的同事不再推荐这种方法。 LVM 的问题在于它影响性能，而且它对性能的影响比我们以前想象的要大得多。其他具有快照功能的文件系统（例如ZFS）相对较新，而且我不是它们的专家，因此对它们没有太多可说的。我有客户使用Solaris 和ZFS，虽然很难隔离变量或直接比较性能，但我认为性能没有显着改进。 ZFS 的写时复制行为使有关数据物理组织方式的考虑变得复杂。我还没有足够的时间来熟悉这方面，所以无法做出合理的决定。推荐。因此，在我看来，对于使用ZFS作为数据库文件系统目前还没有达成共识。因此，在开源世界中，我还没有看到基于快照的备份的杀手级解决方案。关于MYSQLI，MYSQL没有这个能力，所以MYSQL备份有点复杂。许多数据库都内置热备功能，如果您有的话，请使用它。前面讨论的大部分都是关于MYSQL的，其他数据库可能也是一样的。你可以使用**从服务器做这样的事情：来延迟**一段时间，比如一个小时。这可以使用Maatkitt 的mk-slave-delay 工具来实现。使用延迟服务器作为“备份”有两个有趣的事情： 它不断从主服务器获取更新，但不应用它们，这意味着与昨晚制作的备份相比（在发生崩溃时） ）到那时，备份的数据可能已经是24小时前的了），数据丢失的几率要低得多。

当达到延迟时间时，服务器将应用从主服务器获得的更新。 如果出现问题，这种延迟可以为您提供缓冲。从属服务器上偶尔会发生DROPTABLE，延迟一小时。因此，在主服务器上恢复表等类似操作时，可以跳过从服务器上的DROP，将从服务器切换为主服务器。服务器。这种额外的延迟时间为恢复操作提供了相当多的选择。使用网络服务器的延迟作为备份的补充，而不是替代。您仍然需要进行实际备份！