我们的大多数客户使用MySQL。虽然他们中的多数进行了备份，但是这当中存在许多错误，也从未进行过测试。

为什么会发生这样的问题，如何发生的？有很多种可能，所以我们先来看一下备份MySQL的好方法和坏方法的区别。

从 库 - 很多人认为备份从库是个不错的办法。但是即便他们正确地（实际上未必）备份了MySQL数据库，这也不是个好注意。为什么？因为从数据库的数据经常会与主 数据库相不一致。为什么？很多原因，其中包含MySQL本身的问题，也有可能是一些SQL语句没有被从数据库正确的复制（看到过日志里面的Warning 信息吧？）。或者复制由于某种错误类似死锁和超时而停止，然后被不正确地重新启动或跳过。又或者在系统运行中的某个时刻(也许是多年以前)曾有认识不足的 skip操作或配置修改，从而导致了数据的不一致。

基本上，你不应该相信从库数据是正确无误的，因此应该避免在从库上备份数据库，除非主库非常繁忙或者出于其他原因不能处理性能或有关备份锁定的问题。即便是这种情况，您依然应该使用类似Percona的复制检查工具来检查同步工作从而确认从库数据是否正确无误。

锁 问题 – 我们接手的多数客户过去使用了难于备份的MyISAM表（一个糟糕的主意，参考其他博客）。 对于MyISAM来说唯一好的备份办法就是在备份期间锁住整个数据库，通常是几分钟甚至几小时，事实上造成了网站长时间内的功能不正常。 这个问题可以通过使用InnoDB引擎来避免，但有些客户采用了其他方法：如使用mysqlbackup在一个非锁模式下进行备份，又或者使用或不使用快 照来直接备份文件，等等。 这些其他的方法都没用，因为数据可能被损坏或者不一致。

MyISAM/InnoDB 引擎混合使用问题。很多客户同时使用MySAM和InnDB表，他们尝试使用标准的InnoDB single transaction单事务模式进行数据备份，但是对于MyISAM数据表来说这是一个错误的方法（直到他们恢复数据的时候，才会发现）。有时会更糟， 很多客户不知道他们使用的是MyISAM数据引擎，开发人员在没有检查默认数据引擎的情况下创建了很多MyISAM表，并且毫不知情。 在5.1或更早的MySQL版本中，默认引擎就是MyISAM。我们的监控系统会发现这种情况，但是多数客户对此并不清楚还在备份不一致的数据。

正 确的方式 – 正确的做法是仔细规划和选择备份选项，主要基于是否存在MyISAM表。首先，尽可能备份主库。其次，如果全是InnoDB表，使用single transaction模式或者LVM快照方式进行备份，并且确认不存在MyISAM表(系统自带的mysql库不算)。第三，如果存在MyISAM表， 那么使用Percona工具检测主从数据库的一致性，此时如有需要可备份从库。

备份MySQL数据库不容易做到完美，它需要优秀的知识、工具和监控。长久以来，我们一直致力于这些问题，以确保客户数据的安全性和可靠性。