1.备份mysql数据，常用方法如下。很多人可能不知道备份时的数据一致性。1、直接将整个数据目录下的所有文件复制到新机器上。优点是简单快捷，只需要复制即可；缺点也很明显，整个备份过程中新机完全不可用，无法释放源数据文件中碎片造成的空间浪费，也无法回收扩容后的文件。innodb表空间。2、使用xtrabackup进行热备份。优点是在备份过程中可以继续提供服务；缺点与第一种方法类似，目标分区无法释放源数据文件中碎片造成的空间浪费，也无法回收扩展的InnoDB表空间。3.使用官方的mysqldump逻辑重做。优点是可以在整个备份过程中提供服务，最重要的一点是可以解决碎片的浪费。以上几种方法相信大家都很熟悉，就不详细介绍了。下面主要讲解mysqldump备份时如何保持数据的一致性。mysqldump对不同类型的存储引擎有不同的内部实现。它主要针对两类存储引擎：支持事务的存储引擎（如InnoDB）和不支持事务的存储引擎（如MyISAM）。下面看看这两个存储引擎的实现：1.对于支持事务的引擎如InnoDB，参数是在备份的时候加上--single-transaction保证数据的一致性--single-transaction实际上做了下面两个操作：①。一开始设置session的事务隔离级别成为可重复读；②、然后开始一个事务（执行bigin），当备份完数据（同点）时结束事务（执行commit）。可以理解为innodb引擎增加了这个参数，在备份开始的时候就已经确定了要备份的数据，备份过程中提交的事务是不可见的，不会备份。2.对于不支持事务的引擎，比如MyISAM，只能通过锁表来保证数据的一致性。这里有三种情况：①．导出整个数据库：添加--lock-all-tables参数，会在备份开始时启动全局读锁（executeflushtableswithreadlock）时，其他session可以读但不能更新数据，并且数据在备份过程中没有变化，所以最终数据必须完全一致；②、导出单个库：添加--lock-tables参数，备份开始时会锁定该库的所有表，其他session可以读取但不能更新该库的所有表，该库的数据为持续的;③、导出单表：添加--lock-tables参数，备份开始时会锁定该表，其他表不受影响，本表数据保持一致。以上仅说明不同引擎添加的参数只是为了保持数据一致，但是备份过程中业务并没有停止，随时可能写入新的数据，目的是为了让我们知道备份的是什么数据在备份的时候，或者直到那个指针（binarylog），我们可以加上--master-data参数，备份的sql文件会记录备份的指针，我们可以通过binarylog恢复指针之后的数据更新.#mysqldump-uroot-p--single-transaction--master-data--flush-log--databasetest>test.sql-->--flush-log表示备份开始后的所有变化都切到下一个binarylog在备份的test.sql文件的前几行可以看到备份时记录的二进制日志信息#vimtest.sql--CHANGEMASTERTOMASTER_LOG_FILE='mysql-bin.000004',MASTER_LOG_POS=436263492;----CurrentDatabase:`test`.....#mysqlbinlog--start-position=436263492mysql-bin.000004>00004.sql-->完全恢复后，我们可以通过后续的二进制日志进行恢复。另外说明为什么mysqldump备份是锁表可以保持数据一致性：注意：1、在时间t1，使用mysqldump启动非锁表备份；2、先导出表a，总共耗时5分钟，因为没有表锁，表b在5分钟内插入了10行数据；3、t2时刻，a表导出完成，开始b表导出；4、导出表b用了10分钟。在导出b表的过程中，a表和b表没有数据变化；5、时间点t3，b表导出完成，所有备份完成；6.然后备机从时间点t1的binlog位置开始申请binlog，***备机b表数据比主机多10行，数据不一致.从这个图可以看出，如果MyISAM等不支持事务的存储引擎在备份过程中没有锁表，那么在备份开始时，不同表对应的binlog和pos是不一致的。此时，所有表都从备份开始的点开始应用。Binlog，很有可能会出现数据不一致的情况（除了备份过程中所有表都没有数据更新）。
