CN105512284A

CN105512284A - 基于事务形态数据和binlog文件的MySQL数据保护方法

Info

Publication number: CN105512284A
Application number: CN201510892005.4A
Authority: CN
Inventors: 罗强
Original assignee: Shanghai Eisoo Information Technology Co Ltd
Current assignee: Shanghai Eisoo Information Technology Co Ltd
Priority date: 2015-12-07
Filing date: 2015-12-07
Publication date: 2016-04-20

Abstract

本发明涉及一种基于事务形态数据和binlog文件的MySQL数据保护方法，用于将master节点中的MySQL数据库复制到slave节点中，包括：初始化复制步骤，master节点将MySQL数据文件的全事务形态数据初始化复制到slave节点中；增量复制步骤，master节点实时监控binlog文件，根据监控结果实现增量复制。与现有技术相比，本发明通过解析mysqldump源码来获取MySQL全事务形态的数据来做初始化复制，并实时捕获记录MySQL事务的二进制日志文件binlog的变化来进行MySQL原生态高效率的数据复制，具有复制快速、可实时保护等优点。

Description

基于事务形态数据和binlog文件的MySQL数据保护方法

技术领域

本发明涉及一种数据保护方法，尤其是涉及一种基于事务形态数据和binlog文件的MySQL数据保护方法。

背景技术

MySQL是一个关系型数据库管理系统(RelationalDatabaseManagementSystem，RDBMS)，由瑞典MySQLAB公司开发，目前属于Oracle旗下公司。MySQL是目前最流行的关系型数据库系统，在WEB应用方面MySQL是最好的RDBMS应用软件之一。关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL所使用的SQL语言是用于访问数据库的最常用标准化语言。

随着云计算在中国的普及，作为主流公有云服务运营商的阿里云、天翼云、青云等的RDS都是以开源数据库MySQL搭建的，而且用户在这些云服务商的云服务器上搭建数据库大多数是MySQL数据库。到现在为止还一直非常流行的以开源软件架构LAMP(Linux+apche+MySQL+PHP)为主的中小企业网站架构，其中用的后台数据库就是MySQL。因此可以看出MySQL在全球数据库市场的占有率是非常高的。

当今存在例如地震、火灾、存储损坏、DBA人员离去等诸多数据安全风险，因此MySQL的数据保护是一个不能忽视的问题。常用的MySQL数据保护方案有mysqldump定时备份、主机层的实时复制和存储层的复制，但是都有各种各样的弊端，不能完全精准快速的对其进行保护。如下是现有的各种保护方案的优缺点描述：

mysqldump定时备份：mysqldump是MySQL用于转存储数据库的实用程序，mysqldump定时备份是一种MySQL逻辑备份方案，能对当前时间点做精准备份没有冗余数据，但是不能持续性地进行保护，RPO(RecoveryPointObject，恢复点目标)和RTO(RecoveryTimeObject，恢复时间目标)效果不好，而且是备份到本地需要占用本地磁盘空间；

主机层的实时复制：通过捕获文件系统I/O去实时地进行保护，但是捕获文件系统层的I/O会对应用本身的性能造成影响；

存储层的实时复制：快速地做逻辑卷镜像复制，能实时快速保护，但是会复制很多不需要的冗余数据，因为逻辑卷上的数据有些是不需要进行复制的。

发明内容

本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种效率高、复制快速、可实现实时保护的基于事务形态数据和binlog文件的MySQL数据保护方法。

本发明的目的可以通过以下技术方案来实现：

一种基于事务形态数据和binlog文件的MySQL数据保护方法，用于将master节点中的MySQL数据库复制到slave节点中，包括：

初始化复制步骤，master节点将MySQL数据文件的全事务形态数据初始化复制到slave节点中；

增量复制步骤，master节点实时监控binlog文件，根据监控结果实现增量复制。

所述初始化复制步骤具体为：

A1)连接MySQL实例；

A2)查询当前MySQL实例的进行是否正在运行，若是，则执行步骤A3)，若否，则退出；

A3)获取当前MySQL实例下所有的数据库和视图；

A4)提取一数据库，获取将该数据库中所有的表，并解锁，对解锁后的表进行快照，；

A5)将数据库中所有的表保存入databuffer中，同时将所有的表的索引数据保存入databuffer中，slave节点接收并保存databuffer中的数据；

A6)重复步骤A4)～A5)，直至整个MySQL实例的所有数据库和视图均复制完成后，完成初始化复制。

所述数据库中的表是以SQL语句类事务形态存在的。

所述步骤A5)中，数据库中所有的表传输至slave节点的具体过程为：

A501)提取一个表，将表中数据保存入databuffer中；

A502)将databuffer中的数据通过网络传输给slave节点；

A503)查询即将复制的下一个表是否为锁定状态，若是，则对其解锁后，返回步骤A501)，若否，则直接返回步骤A501)。

所述增量复制步骤具体为：

B1)复制agent主线程创建binlog文件的实时监控线程；

B2)查询最新的正在记录事务的binlog文件，作为监控数据源；

B3)对所述监控数据源注册操作系统内核事件；

B4)监听所述操作系统内核事件，当捕获到新的操作系统内核事件时，获取此次事件后binlog文件的截止字节位，根据该截止字节位完成二进制日志解析，将解析到的数据传输给slave节点保存；

B5)根据所述截止字节位判断是否有新的binlog文件产生，若是，则返回步骤B2)，若否，则返回步骤B4)。

所述步骤B3)中，操作系统内核事件包括binlog文件的写操作、创建操作和删除操作。

所述步骤B4)中，slave节点启动I/O线程接收解析到的数据，然后启动SQL线程将接收到的数据应用到容灾MySQL数据库中。

所述步骤B5)中，若截止字节位为0，则判定为有新的binlog文件产生，若截止字节位非0，则判定为没有新的binlog文件产生。

与现有技术相比，本发明具有以下优点：

1)本发明结合MySQL关系型数据库的相关特性，创造性地提出一种全事务形态的MySQL数据库初始化复制和binlog文件实时监控方法，通过解析mysqldump源码来获取MySQL全事务形态的数据来做初始化复制，并实时捕获记录MySQL事务的二进制日志文件binlog的变化来进行MySQL原生态高效率的数据复制。

2)相对于物理数据块的复制不管是初始化阶段还是增量复制阶段，本发明采用的全事务形态的复制技术能减少数据量的复制，例如一个上限大小为100G的数据表但是数据量很小只有5G，物理块的复制方法需要复制整个100G数据，但是全事务形态的复制只需要复制实际存在的数据5G；而且不需要安装一个文件系统层上面的中间件驱动程序监控文件I/O。

3)相对于其他方法，本发明可以减少需要复制数据总量，特别是在公有云上网络资源非常宝贵的前提下，能有效的快速复制，以达到MySQL数据库的实时保护。

附图说明

图1为一对多复制拓扑图；

图2为一对一复制拓扑图；

图3为本发明复制master到slave节点的数据流图；

图4为本发明slave节点应用事务的流程图；

图5为本发明初始化复制方法的详细流程图；

图6为本发明binlog二进制日志文件的实时监控。

具体实施方式

下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。

本实施例提供一种基于事务形态数据和binlog文件的MySQL数据保护方法，用于将master节点中的MySQL数据库复制到slave节点中，包括初始化复制步骤和增量复制步骤，其中，初始化复制步骤，master节点将MySQL数据文件的全事务形态数据初始化复制到slave节点中；增量复制步骤，master节点实时监控binlog文件，根据监控结果实现增量复制。

MySQL数据库事务形态数据复制一般分为两种：一种是如图1所示的一个master->多个slave(一对多的方式)，master为复制的源端MySQL数据库服务器，是生产数据库；slave为复制的目标端MySQL数据库服务器，是容灾数据库；另外一种是如图2所示的一个master->一个slave(一对一的方式)。通常情况下的用户数据库只需要冗余一份数据，也是图2显示的一对一的方案，本实施例就以一对一方案来阐述本发明技术方案。

如图3所示是一对一方案的具体数据流步骤。在进行数据复制前需要进行以下设置：

1、在slave节点上搭建一个与master节点中的MySQL版本一致的MySQL数据库，并保证slave节点挂载的存储空间够复制存储，而且master节点可以连通slave节点供数据传输和控制消息通信。slave节点的操作系统可以与master节点不一致。

2、确定master节点参数文件的binlog选项是否开启，如果没开启，需要设置开启。否则就不会产生binlog文件。

3、master节点有开启和停止按钮，供用户选择使用，分别是开启复制进行数据传输和暂停传输。

数据复制过程为：首先需要将master节点上的MySQL数据文件中的数据以事务形态解析出来，通过网络把数据传入到slave节点上，slave节点再将接收到的数据应用到slave节点上MySQL容灾数据库中完成MySQL的初始化；然后实时监控binlog文件的变化，根据上次记录的binlog文件偏移位置，读取解析增量更新的事件并将事件实时传入到slave节点上供MySQL容灾数据库应用进行增量复制。这两个阶段就可以保证master和slave上的MySQL数据库的数据基本一致。

结合当前最流行的图2场景，上述初始化复制步骤和通过binlog文件监控实现增量复制步骤具体方案如下：

(一)、全事务形态数据初始化复制阶段：

该阶段具体流程如图5所示，包括以下内容：

1>连接MySQL实例：通过给定的实例名用户名密码端口号调用MySQL原生态的mysql_real_connect_c连接到需要复制的实例中，并获取到当前实例中的max_allowed_packet最大传输包大小值，并将此设置为复制线程的缓存大小。

2>执行SHOWPROCESSLIST查询当前MySQL的进程是否还运行，如果运行则进行复制，如果停止则抛错退出初始化。

3>执行SHOWDATABASES获取MySQL实例下所有数据库和所有的视图，并过滤掉系统数据库自带的如information_schemaperformance_schemadata_dictionary#mysql50#.mozilla#mysql50#.wapi这些readonly数据库。系统视图需要进入到各个数据库中通过SHOWTABLESTATUS的值来判断，如果返回的是“VIEW”开头的则为视图。

4>依次执行use数据库名进入到所选的数据库中，再执行SHOWTABLES将所选数据库中所有表都获取出来，获取当前初始化复制阶段需要进行复制的数据源。

5>执行UNLOCKTABLES先将所有的表都解锁掉，因为整个数据库可能被各种原因锁定的表很多，UNLOCKTABLE本身执行很快且基本不影响性能，判断单个表是否被锁再解锁更影响性能，这样可以防止表锁定之后出现不能复制而数据丢失。再执行STARTTRANSACTION/*！40108WITHCONSISTENTSNAPSHOT*/对当前需要复制的数据库进行快照，使复制时从快照状态中进行数据的读取，从而保证数据库的一致性。

6>根据步骤4>获取到的表集合，执行SHOWINDEXFROM`数据库名`.`表名`获取数据库表中的索引数据传入到databuffer中，因为有些表是建过索引的，如果不把索引数据给同步过去会造成slave节点的MySQL对应表中缺少索引信息，从而影响数据的读取性能；再执行SELECT/*！40001SQL_NO_CACHE*/*FROM`数据库名`.`表名`就将表中数据源源不断地压入databuffer中，这些表数据是以SQL语句这类事务形态存在的，比物理块这类数据量小很多，适合在云端这类窄带环境中做复制。

7>再将从databuffer中装入的视图和表中数据通过网络传给slave复制目标端节点中，slave节点接收到这些事务形态的数据再应用到MySQL容灾数据库中。

8>通过showOPENTABLESwhereIn_use>0andName_locked>0查询即将复制的这个表是否是锁定状态，如果是需要对即将复制的这个表执行UNLOCKTABLE`数据库名`.`表名`进行解锁，因为如果锁定这个表会导致数据不能写入到这个表中，导致masterMySQL上层的应用数据延时入库。

9>再次进入到步骤4>进行循环，保证整个数据库中的所有表都复制到slaveMySQL中。当循环结束，则标示整个实例的所有数据库的数据都复制完成，初始化复制结束。

(二)binlog文件的实时变化监控，并实现增量复制：

具体流程可见图6，因为MySQL部署在WindowsLinux系统主机都比较多，因此实时变化监控方法以两个平台来进行分析，以下是各个步骤原理和方法解析。

1>复制agent主线程创建binlog文件的实时监控线程，Windows用AfxBeginThread()Linux用pthread_create()方法来创建，线程处理函数是文件监控函数，主线程继续执行做其它的工作。

2>根据环境变量Linux系统为$MYSQL_HOME/dataWindows系统为％MYSQL_HOME％/data目录获取下面的以binlog_序列号.log的文件，序列号是从000001开始递增的，最新的序列号是最大的。这样就可以找到最新的正在记录事务的binlog文件，获取监控的数据源。

3>对需要监控的最新的binlog文件注册操作系统内核事件。此方法需要关注的事件是写事件如binlog文件的写(IN_WRITE)创建(IN_CREATE)删除(IN_DELETE)，读文件事件是无需关注的，因为这些事件是没有MySQL事务日志事件变更的。

4>对步骤3>注册的binlog文件内核事件进行绑定监听，Linux用系统提供的inotifysdk接口Windows用MFC类的Windows消息处理机制的ReadDirectoryChangesW监听WaitForSingleObject捕获事件通知来进行的。

5>当捕获到步骤4>的系统内核事件后，对应的接口会将此次binlog文件写操作后的文件截止字节位返回出来，并在本地临时文件中保存。把获取到这个截止字节位传给binlog解析模块以完成二进制日志解析，接收到数据再传给slave节点。参考图4，slave节点启动I/O线程接收master节点dump过来的数据，再启动SQL线程将I/O线程接收的数据应用到容灾MySQL数据库中。

6>根据步骤5>获取到的这个截止字节位(偏移字节位)就可以知道是否有新的binlog文件产生，非0是没有0为产生新的binlog文件产生。如果产生新的binlog文件则返回到步骤2>循环进行；如果没有产生新的binglo文件返回到步骤4>循环执行。

Claims

1.一种基于事务形态数据和binlog文件的MySQL数据保护方法，用于将master节点中的MySQL数据库复制到slave节点中，其特征在于，包括：

2.根据权利要求1所述的基于事务形态数据和binlog文件的MySQL数据保护方法，其特征在于，所述初始化复制步骤具体为：

A1)连接MySQL实例；

A3)获取当前MySQL实例下所有的数据库和视图；

3.根据权利要求2所述的基于事务形态数据和binlog文件的MySQL数据保护方法，其特征在于，所述数据库中的表是以SQL语句类事务形态存在的。

4.根据权利要求2所述的基于事务形态数据和binlog文件的MySQL数据保护方法，其特征在于，所述步骤A5)中，数据库中所有的表传输至slave节点的具体过程为：

A501)提取一个表，将表中数据保存入databuffer中；

A502)将databuffer中的数据通过网络传输给slave节点；

5.根据权利要求1所述的基于事务形态数据和binlog文件的MySQL数据保护方法，其特征在于，所述增量复制步骤具体为：

B1)复制agent主线程创建binlog文件的实时监控线程；

B2)查询最新的正在记录事务的binlog文件，作为监控数据源；

B3)对所述监控数据源注册操作系统内核事件；

6.根据权利要求5所述的基于事务形态数据和binlog文件的MySQL数据保护方法，其特征在于，所述步骤B3)中，操作系统内核事件包括binlog文件的写操作、创建操作和删除操作。

7.根据权利要求5所述的基于事务形态数据和binlog文件的MySQL数据保护方法，其特征在于，所述步骤B4)中，slave节点启动I/O线程接收解析到的数据，然后启动SQL线程将接收到的数据应用到容灾MySQL数据库中。

8.根据权利要求5所述的基于事务形态数据和binlog文件的MySQL数据保护方法，其特征在于，所述步骤B5)中，若截止字节位为0，则判定为有新的binlog文件产生，若截止字节位非0，则判定为没有新的binlog文件产生。