Mysqldump用于备份，不得不提两个关键的参数：
--single-transaction：在开始备份前，执行start transaction命令，以此来获取一致性备份，该参数仅对innodb存储引擎有效。
--master-data=2：主要用于记录一致性备份的位点。
理解Mysqldump工作原理，一定要将事务表(innodb)和非事务表(比如myisam)区别对待，因为备份的流程与此息息相关。而且，到目前为止，我们也无法规避myisam表，即使我们的所有业务表都是innodb，因为mysql库中系统表仍然采用的myisam表。备份的基本流程如下：
1.调用FTWRL(flush tables with read lock)，全局禁止读写
2.开启快照读，获取此时的快照(仅对innodb表起作用)
3.备份非innodb表数据(*.frm,*.myi,*.myd等)
4.非innodb表备份完毕后，释放FTWRL锁
5.逐一备份innodb表数据
6.备份完成。
而5.6的mysqldump利用保存点机制，每备份完一个表就将一个表上的MDL锁释放，避免对一张表锁更长的时间。这里可以参考我之前的blog：FLUSH TABLE WITH READ LOCK
大家可能有一个疑问，为啥备份innodb表之前，就已经将锁释放掉了，这实际上是利用了innodb引擎的MVCC机制，开启快照读后，就能获取那个时间的一致的数据，无论需要备份多长时间，直到整个事务结束(commit)为止。
物理备份(Xtrabackup)
相对于逻辑备份利用查询提取数据中的所有记录，物理备份更直接，拷贝数据库文件和日志来完成备份，因此速度会更快。当然，无论是开源的Mydumper还是官方最新的备份工具(5.7.11的mysqlpump)都支持了多线程备份，所以速度差异可能会进一步缩小，至少从目前生产环境来看，物理备份使用还是比较多的。由于Xtrabackup支持备份innodb表，实际生产环境中我们使用的工具是innobackupex，它是对xtrabackup的一层封装。innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表，innobackupex的基本流程如下：
1.开启redo日志拷贝线程，从最新的检查点开始顺序拷贝redo日志；
2.开启idb文件拷贝线程，拷贝innodb表的数据
3.idb文件拷贝结束，通知调用FTWRL（flash tables with read lock），获取一致性位点
4.备份非innodb表(系统表)和frm文件
5.由于此时没有新事务提交，等待redo日志拷贝完成
6.最新的redo日志拷贝完成后，相当于此时的innodb表和非innodb表数据都是最新的
7.获取binlog位点，此时数据库的状态是一致的。
8.释放锁，备份结束。
LOCK TABLES FOR BACKUP
作用：备份数据
1.禁止非innodb表更新
2.禁止所有表的ddl
优化点：
1.不会被大查询堵塞(关闭表)
2.不会堵塞innodb表的读取和更新，这点非常重要，对于业务表全部是innodb的情况，则备份过程中DML完全不受损
UNLOCK TABLES
LOCK BINLOG FOR BACKUP
作用：获取一致性位点。
1.禁止对位点更新的操作
优化点：
1.允许DDl和更新，直到写binlog为止。
UNLOCK BINLOG
#####
对于INNODB，xtrabackup基于innodb的crash-recovery功能进行备份。
innodb维护了一个redo log（事务日志），包含了INNODB数据所有改动情况，INNODB启动时，先去检查datafile 和transaction log然后应用所有已提交的事务前滚
，未提交进行回滚。在备份过程中是不锁表，1页页复制数据。同时，XTRABACKUP还有另外一个线程监视着REDOLOG，一个监控线程会监视transaction log一旦变化，就会被复制走。 .xtrabackup工具备份到最后执行flash tables with read lock ,对数据库进行锁表以便进行一致性备份 保证数据的一致性。在全部数据文件完成之后，停止复制logfie
xtrabackup 采用内置的INNODB库以READ WRITE模式打开INNODB的数据文件。然后每次RW是1MB的数据，一页一页的查看，同时用INNODB的BUF_PAGE_IS_CORRUPTED()函数检查此页数据是否正常。如果正常，复制，不正常推出，最多读取10次，复制REDOLOG的原理也是一样的，只是每次读史512KB
xtrabackup工具备份到最后执行flash tables with read lock ,对数据库进行锁表以便进行一致性备份
增量备份原理：在完整备份和增量备份文件中都有一个文件，xtrabackup_checkpoints会记录备份完成时检查点LSN ，在进行新的增量备份时，XTRABACKUP会比较表空间中每页的LSN是否大于上次备份完成的LSN号，如果是备份，则备份，并记录当前的LSN号
Mysqldump用于备份，不得不提两个关键的参数：
--single-transaction：在开始备份前，执行start transaction命令，以此来获取一致性备份，该参数仅对innodb存储引擎有效。
--master-data=2：主要用于记录一致性备份的位点。
理解Mysqldump工作原理，一定要将事务表(innodb)和非事务表(比如myisam)区别对待，因为备份的流程与此息息相关。而且，到目前为止，我们也无法规避myisam表，即使我们的所有业务表都是innodb，因为mysql库中系统表仍然采用的myisam表。备份的基本流程如下：
1.调用FTWRL(flush tables with read lock)，全局禁止读写
2.开启快照读，获取此时的快照(仅对innodb表起作用)
3.备份非innodb表数据(*.frm,*.myi,*.myd等)
4.非innodb表备份完毕后，释放FTWRL锁
5.逐一备份innodb表数据
6.备份完成。
而5.6的mysqldump利用保存点机制，每备份完一个表就将一个表上的MDL锁释放，避免对一张表锁更长的时间。这里可以参考我之前的blog：FLUSH TABLE WITH READ LOCK
大家可能有一个疑问，为啥备份innodb表之前，就已经将锁释放掉了，这实际上是利用了innodb引擎的MVCC机制，开启快照读后，就能获取那个时间的一致的数据，无论需要备份多长时间，直到整个事务结束(commit)为止。
物理备份(Xtrabackup)
相对于逻辑备份利用查询提取数据中的所有记录，物理备份更直接，拷贝数据库文件和日志来完成备份，因此速度会更快。当然，无论是开源的Mydumper还是官方最新的备份工具(5.7.11的mysqlpump)都支持了多线程备份，所以速度差异可能会进一步缩小，至少从目前生产环境来看，物理备份使用还是比较多的。由于Xtrabackup支持备份innodb表，实际生产环境中我们使用的工具是innobackupex，它是对xtrabackup的一层封装。innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表，innobackupex的基本流程如下：
1.开启redo日志拷贝线程，从最新的检查点开始顺序拷贝redo日志；
2.开启idb文件拷贝线程，拷贝innodb表的数据
3.idb文件拷贝结束，通知调用FTWRL（flash tables with read lock），获取一致性位点
4.备份非innodb表(系统表)和frm文件
5.由于此时没有新事务提交，等待redo日志拷贝完成
6.最新的redo日志拷贝完成后，相当于此时的innodb表和非innodb表数据都是最新的
7.获取binlog位点，此时数据库的状态是一致的。
8.释放锁，备份结束。
LOCK TABLES FOR BACKUP
作用：备份数据
1.禁止非innodb表更新
2.禁止所有表的ddl
优化点：
1.不会被大查询堵塞(关闭表)
2.不会堵塞innodb表的读取和更新，这点非常重要，对于业务表全部是innodb的情况，则备份过程中DML完全不受损
UNLOCK TABLES
LOCK BINLOG FOR BACKUP
作用：获取一致性位点。
1.禁止对位点更新的操作
优化点：
1.允许DDl和更新，直到写binlog为止。
UNLOCK BINLOG
#####
对于INNODB，xtrabackup基于innodb的crash-recovery功能进行备份。
innodb维护了一个redo log（事务日志），包含了INNODB数据所有改动情况，INNODB启动时，先去检查datafile 和transaction log然后应用所有已提交的事务前滚
，未提交进行回滚。在备份过程中是不锁表，1页页复制数据。同时，XTRABACKUP还有另外一个线程监视着REDOLOG，一个监控线程会监视transaction log一旦变化，就会被复制走。 .xtrabackup工具备份到最后执行flash tables with read lock ,对数据库进行锁表以便进行一致性备份 保证数据的一致性。在全部数据文件完成之后，停止复制logfie
xtrabackup 采用内置的INNODB库以READ WRITE模式打开INNODB的数据文件。然后每次RW是1MB的数据，一页一页的查看，同时用INNODB的BUF_PAGE_IS_CORRUPTED()函数检查此页数据是否正常。如果正常，复制，不正常推出，最多读取10次，复制REDOLOG的原理也是一样的，只是每次读史512KB
xtrabackup工具备份到最后执行flash tables with read lock ,对数据库进行锁表以便进行一致性备份
增量备份原理：在完整备份和增量备份文件中都有一个文件，xtrabackup_checkpoints会记录备份完成时检查点LSN ，在进行新的增量备份时，XTRABACKUP会比较表空间中每页的LSN是否大于上次备份完成的LSN号，如果是备份，则备份，并记录当前的LSN号
Mysqldump用于备份，不得不提两个关键的参数：
--single-transaction：在开始备份前，执行start transaction命令，以此来获取一致性备份，该参数仅对innodb存储引擎有效。
--master-data=2：主要用于记录一致性备份的位点。
理解Mysqldump工作原理，一定要将事务表(innodb)和非事务表(比如myisam)区别对待，因为备份的流程与此息息相关。而且，到目前为止，我们也无法规避myisam表，即使我们的所有业务表都是innodb，因为mysql库中系统表仍然采用的myisam表。备份的基本流程如下：
1.调用FTWRL(flush tables with read lock)，全局禁止读写
2.开启快照读，获取此时的快照(仅对innodb表起作用)
3.备份非innodb表数据(*.frm,*.myi,*.myd等)
4.非innodb表备份完毕后，释放FTWRL锁
5.逐一备份innodb表数据
6.备份完成。
而5.6的mysqldump利用保存点机制，每备份完一个表就将一个表上的MDL锁释放，避免对一张表锁更长的时间。这里可以参考我之前的blog：FLUSH TABLE WITH READ LOCK
大家可能有一个疑问，为啥备份innodb表之前，就已经将锁释放掉了，这实际上是利用了innodb引擎的MVCC机制，开启快照读后，就能获取那个时间的一致的数据，无论需要备份多长时间，直到整个事务结束(commit)为止。
物理备份(Xtrabackup)
相对于逻辑备份利用查询提取数据中的所有记录，物理备份更直接，拷贝数据库文件和日志来完成备份，因此速度会更快。当然，无论是开源的Mydumper还是官方最新的备份工具(5.7.11的mysqlpump)都支持了多线程备份，所以速度差异可能会进一步缩小，至少从目前生产环境来看，物理备份使用还是比较多的。由于Xtrabackup支持备份innodb表，实际生产环境中我们使用的工具是innobackupex，它是对xtrabackup的一层封装。innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表，innobackupex的基本流程如下：
1.开启redo日志拷贝线程，从最新的检查点开始顺序拷贝redo日志；
2.开启idb文件拷贝线程，拷贝innodb表的数据
3.idb文件拷贝结束，通知调用FTWRL（flash tables with read lock），获取一致性位点
4.备份非innodb表(系统表)和frm文件
5.由于此时没有新事务提交，等待redo日志拷贝完成
6.最新的redo日志拷贝完成后，相当于此时的innodb表和非innodb表数据都是最新的
7.获取binlog位点，此时数据库的状态是一致的。
8.释放锁，备份结束。
LOCK TABLES FOR BACKUP
作用：备份数据
1.禁止非innodb表更新
2.禁止所有表的ddl
优化点：
1.不会被大查询堵塞(关闭表)
2.不会堵塞innodb表的读取和更新，这点非常重要，对于业务表全部是innodb的情况，则备份过程中DML完全不受损
UNLOCK TABLES
LOCK BINLOG FOR BACKUP
作用：获取一致性位点。
1.禁止对位点更新的操作
优化点：
1.允许DDl和更新，直到写binlog为止。
UNLOCK BINLOG
#####
对于INNODB，xtrabackup基于innodb的crash-recovery功能进行备份。
innodb维护了一个redo log（事务日志），包含了INNODB数据所有改动情况，INNODB启动时，先去检查datafile 和transaction log然后应用所有已提交的事务前滚
，未提交进行回滚。在备份过程中是不锁表，1页页复制数据。同时，XTRABACKUP还有另外一个线程监视着REDOLOG，一个监控线程会监视transaction log一旦变化，就会被复制走。 .xtrabackup工具备份到最后执行flash tables with read lock ,对数据库进行锁表以便进行一致性备份 保证数据的一致性。在全部数据文件完成之后，停止复制logfie
xtrabackup 采用内置的INNODB库以READ WRITE模式打开INNODB的数据文件。然后每次RW是1MB的数据，一页一页的查看，同时用INNODB的BUF_PAGE_IS_CORRUPTED()函数检查此页数据是否正常。如果正常，复制，不正常推出，最多读取10次，复制REDOLOG的原理也是一样的，只是每次读史512KB
xtrabackup工具备份到最后执行flash tables with read lock ,对数据库进行锁表以便进行一致性备份
增量备份原理：在完整备份和增量备份文件中都有一个文件，xtrabackup_checkpoints会记录备份完成时检查点LSN ，在进行新的增量备份时，XTRABACKUP会比较表空间中每页的LSN是否大于上次备份完成的LSN号，如果是备份，则备份，并记录当前的LSN号
本文转自 DBAspace 51CTO博客，原文链接:http://blog.51cto.com/dbaspace/1874088
