mysql innobackupex的备份原理概括
发布时间：2022-01-19 14:05:20 所属栏目：MySql教程 来源：互联网
导读：本篇内容主要讲解mysql innobackupex的备份原理总结，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习mysql innobackupex的备份原理总结吧! xtrabackup包含两个主要的工具，即xtrabackup和innobackupex，二者区
|
本篇内容主要讲解“mysql innobackupex的备份原理总结”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“mysql innobackupex的备份原理总结”吧! xtrabackup包含两个主要的工具，即xtrabackup和innobackupex，二者区别如下： 1 xtrabackup只能备份innodb和xtradb两种引擎的表，而不能备份myisam引擎的表;2 innobackupex是一个封装了xtrabackup的Perl脚本，支持同时备份innodb和myisam，但在对myisam备份时需要加一个全局的读锁。还有就是myisam不支持增量备份。 innobackupex工具的备份过程原理：!!! 一：早期版本的innobackupex备份过程 这里的FTWRL(flush tables with read lock)把锁持有的时间主要与非innodb表的数据量有关，如果非innodb表数据量很大，备份很慢，那么持有锁的时间就会很长。即使全部是innodb表，也会因为有mysql库系统表存在，导致会锁一定的时间。为了解决这个问题，Percona公司对Mysql的Server层做了改进，引入了BACKUP LOCK(备份锁)，具体而言，通过"LOCK TABLES FOR BACKUP"命令来获取一致性数据(包括非innodb表);通过"LOCK BINLOG FOR BACKUP"来获取一致性位点，尽量减少因为数据库备份带来的服务受阻! 二：引入备份锁的优势 2.1、LOCK TABLES FOR BACKUP: 只阻塞非事务表的操作!不阻塞innodb 表的dml 作用：获取一致性数据 a)禁止非事务引擎(非InnoDB)表写入(也即DML)。 b)禁止所有表的DDL。 优点： a)不会被大查询阻塞。 b)不会堵塞innodb表的读取和更新，这点非常重要，对于业务表全部是并innodb的情况，则备份过程中DML完全不受损。 2.2、LOCK BINLOG FOR BACKUP: 作用：获取一致性位点。 a)禁止对binlog的位点操作(不允许DML、DDL) 优点： a)时间短，对db的影响很小。 三：具体innobackupex备份的过程： 3.1、低版本的innobackupex，(<2.2.0 )的流程： 1.get Redo LSN 2.copy 系统表空间+事务引擎表的数据文件+后台子进程(IBACKUP)拷贝Redo 3.FLUSH TABLES WITH READ LOCK 4.copy 所有 *.frm文件，非事务引擎表(MyISAM、ARCHIVE等)数据+索引文件 5.Get the binary log coordinates(坐标/位点) 6.finalize the background copy of REDO log 7.unlock tables; 3.2、高版本的innobackupex，(也就是>=2.2.0版本 )的流程：(增加了备份锁，不再使用FLUSH TABLES WITH READ LOCK) 1.get Redo LSN 2.copy 系统表空间+事务引擎表的数据文件+后台子进程(IBACKUP)拷贝Redo 3.LOCK TABLES FOR BACKUP(这时候一直在拷贝redo) 4.copy 所有 *.frm文件，非事务引擎表(MyISAM、ARCHIVE等)数据+索引文件(这时候一直在拷贝redo) 5.LOCK BINLOG FOR BACKUP (为了得到一致性的binlog点位，所有需要写binlog的操作不能执行) 6.finalize the background copy of REDO log (包括flush redo bufer 到磁盘) 7.get the binary log coordinates(坐标/位点) 8.UNLOCK BINLOG ; 9.UNLOCK TABLES; 注意： 避免在业务高峰期执行备份任务： 如果第四步骤完成之后，开始执行LOCK BINLOG FOR BACKUP，获取到binlog锁之后，然后SHOW MASTER STATUS来获取一致性的binlog,然后开始flush redo buffer里的redo 到磁盘(具体命令：FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS)，以便于复制所有的redo, 这里会有个问题， 如果当你的redo buffer比较大，并且在第四步复制非事务表的期间产生的redo非常多，这就会造成第6步骤时间比较长，进而导致持有binlog backup锁的时间就会变长，最后造成数据库的阻塞时间变长，影响业务时间变长，所以需要在业务少的时候来执行备份任务!  （编辑：洛阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐