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

【编者按：上期我们分析和了解了鼎甲对MySQL的逻辑备份。本期我们重点解析鼎甲对MySQL的物理备份。】

上期回顾：

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

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

在实现MySQL的逻辑备份后，鼎甲即刻投入对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，鼎甲开始MySQL连续日志实时保护的研究和实现。

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