English

MySQL全方位灾备保护 Ⅲ 物理备份

【编者按:上期我们分析和了解了亚博足球app对MySQL的逻辑备份。本期我们重点解析亚博足球app对MySQL的物理备份。】

上期回顾:

MySQL全方位灾备保护 Ⅰ 应用趋势

MySQL全方位灾备保护 Ⅱ 逻辑备份

在实现MySQL的逻辑备份后,亚博足球app即刻投入对MySQL数据库物理备份的研究和实现,通过对数据库文件的备份来提高备份效率和解决锁表问题。

物理备份包括了完全备份、增量备份、日志备份。

主要是通过定制作业策略来备份MySQL的数据文件和日志文件,由于是基于数据文件的复制,所以物理备份比逻辑备份的速度快很多,而且采用的是热备份,在备份过程中也减少影响业务系统对数据库的使用。

DBackup在进行物理备份时,支持自适应MyISAM、InnoDB等多种存储引擎,根据不同的引擎来提取对应的文件进行备份。

在MyISAM存储引擎中,每张数据表都有3个文件,分别为表结构定义文件(frm),表索引文件(MYI),表数据文件(MYD)。

对于InnoDB存储引擎,增加了事务处理、回滚、崩溃修复能力和多版本并发控制的事务安全,数据文件更为复杂,每个InnoDB都会存在表结构定义文件(frm),而表索引和表数据存放在表空间文件【共享表空间文件(ibdata1),独享表空间(ibd)】中,另外还有相关的日志文件(binary log、redo log、undo log、errorlog等)。

在MySQL的物理备份中包括两部分的备份数据:对数据文件的完全备份和增量备份,对二进制日志文件的复制。

这两部分备份数据的备份处理流程不一样,需要配置在不同的备份任务中完成。

数据文件备份

DBackup同时支持对InnoDB和MyISAM引擎的数据文件和表数据进行备份,对InnoDB引擎中的数据文件,采用文件复制方式一页一页地复制InnoDB的数据,而且不锁定表,在文件复制的过程中,需要时刻监控着redo log的变化,一旦log发生变化,就即刻同步添加到事务日志文件中,直至复制完所有数据文件,才停止对redo log的监控和同步。

完成对ibd文件的备份后,将开始对非InnoDB表数据进行备份,包括MyISAM表和InnoDB表结构等信息,需要采用flush tables with lock来获得一个读锁,保障复制数据的一致性位点,复制完成后将进行解锁。

DBackup对数据文件的备份处理,通过同步事务日志信息,并整合到备份集中,在进行数据恢复时将保障数据文件和日志文件的一致性。

而对备份中的加锁处理,也进行了优化,实现定向备份锁技术,只有在备份非InnoDB表数据的时候才启动加锁处理,这有效地缩短了备份中的锁表时间,大大降低了因为数据库备份对业务服务的中断影响。

日志备份

日志备份是对二进制日志(binary log)文件的定制备份,二进制日志文件用来记录所有用户对数据库操作,即记录用户对数据库操作的sql语句。

binary log的文件有两种类型:index文件有.index的后缀;log文件用.NNNNNN后缀命名,如mysql-bin.000001等。

对二进制日志文件的备份,首先需要启动开启 MySQL 的二进制日志记录,常规的启动方式是需要在MySQL的服务器上,通过后台指令输入来进行配置启动。

DBackup为了简化配置流程,提升用户使用感知,把二进制日志的启动设置,整合到前台的配置页面中,用户只需做简单配置后即可启动。

物理备份的实现,虽然提升了MySQL的备份效率,且降低了备份过程中对业务访问数据的影响。

但由于备份是定时策略,无法做到密集型的备份,也就是在灾难恢复时,会丢失上次备份到故障点发生之间的数据。

为了提升数据恢复的RPO,亚博足球app开始MySQL连续日志实时保护的研究和实现。

下期预告:MySQL全方位灾备保护 Ⅳ 连续日志备份


联系我们

//360推送 //百度自动推送 //51la