dump与xtra介绍-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

dump与xtra介绍

简介:

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号

wKioL1gt0Gegp1UAAAB2dYMbbjg068.png



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号

wKioL1gt0Gegp1UAAAB2dYMbbjg068.png

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号

wKioL1gt0Gegp1UAAAB2dYMbbjg068.png





本文转自 DBAspace 51CTO博客,原文链接:http://blog.51cto.com/dbaspace/1874088


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章