CN104951474B - 一种用于获取MySQL binlog增量日志的方法和装置 - Google Patents

Abstract

本申请公开了一种用于获取MySQL binlog增量日志的方法，包括：在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录；根据该记录所在二进制日志文件的文件名和该记录在所述文件中的位置，获取所述当前MySQL数据库的增量日志。本申请同时提供一种用于获取MySQL binlog增量日志的装置。采用本申请提供的方法，可以通过时间戳指定获取增量日志的起始位点，从而在MySQL主数据库变更的情况下仍然可以正确获取增量日志数据。

Description

一种用于获取MySQL binlog增量日志的方法和装置

技术领域

本申请涉及MySQL数据库技术，具体涉及一种用于获取MySQL binlog增量日志的方法。本申请同时提供一种用于获取MySQL binlog增量日志的装置。

背景技术

MySQL数据库有各种不同类型的日志文件：错误日志、二进制日志、查询日志、慢查询日志、redo日志等，根据这些日志可以查询MySQL数据库执行的操作以及状态等信息，对于MySQL数据库的管理与维护来说，这些日志文件都是不可或缺的。

其中二进制日志（binlog），记录了对MySQL数据库的更改操作，例如：创建数据库或表（create）、***操作（insert）、更新操作（update）、删除操作（insert）等，每个更改操作都以一条记录的形式写入二进制日志文件中，每条记录中都包含了当前记录更新的时间戳、该记录在当前二进制日志文件中的位置（即：偏移量）以及与数据库更改操作相关的其他信息。MySQL数据库通常有一个或者多个二进制日志文件，不同的二进制日志文件通过文件扩展名采用不同的数字编号形式加以区分，例如：mysql-bin.00001。使用上述二进制日志文件，一方面可以实现MySQL数据库的数据恢复功能，另一方面可以通过主备复制实现MySQL主备数据库的数据一致性。

MySQL使用二进制日志文件进行主备复制的基本过程是这样的：备用数据库与主数据库建立连接，并请求获取从指定二进制日志文件的指定位置之后的日志记录；主数据库将位于指定二进制日志文件中的指定位置之后的日志记录，返回给备用数据库；备用数据库接收到主数据库返回的数据后，从中解析出在主数据库上执行的更改操作，并在备用数据库上执行这些更改操作，也就是说，在主数据库和备用数据库上执行同样的数据库操作，从而通过主备复制过程实现了主备数据库的数据一致性。

由此可见，MySQL主数据库支持采用增量方式，向其他需要获取二进制日志数据的备用数据库或应用程序提供二进制日志数据；相应的，需要从MySQL主数据库获取二进制日志数据的备用数据库或者其他应用程序则需要在获取增量日志数据的请求中，明确地指定希望从中获取日志数据的二进制日志文件的文件名、以及所需获取的日志数据在所述二进制日志文件中的偏移量，这样才能够正确地从主数据库获取所需的二进制日志数据。

上述通过指定“文件名+偏移量”来获取增量日志的方式，有助于减少主数据库与备数据库或者其他获取二进制日志数据的应用程序之间的交互数据量，减少对带宽的占用，但是在具体实施过程存在一定的缺陷。对于需要从主数据库抓取增量二进制日志数据、以满足增量订阅或消费等相关业务需求的应用程序来说，通常情况下可以采用与备数据库类似的方式从主数据库抓取增量二进制日志数据。但是在主数据库故障导致主备数据库切换的情况下，由于主数据库和备数据库的二进制日志文件是彼此独立编号的，主备之间不存在对应关系，而抓取增量日志的应用程序使用的起始位点信息（文件名+偏移量）是和主数据库相关联的，因此无法在备用数据库（当前的主数据库）的二进制日志文件中找到与原起始位点信息相对应的起始位点，从而导致所述应用程序无法继续抓取增量日志数据或者抓取到错误的增量日志数据。

发明内容

本申请提供一种用于获取MySQL binlog增量日志的方法，以解决现有技术采用“文件名+偏移量”指定位点的方式在MySQL主数据库变更的情况下无法正确获取增量日志的问题。本申请另外提供一种用于获取MySQL binlog增量日志的装置。

本申请提供一种用于获取MySQL binlog增量日志的方法，包括：

在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录；

根据该记录所在二进制日志文件的文件名和该记录在所述文件中的位置，获取所述当前MySQL数据库的增量日志。

可选的，所述在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录，包括：

在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件；

在所述最后一个文件中查找其时间戳不早于所述预先指定的时间戳的第一个记录。

可选的，执行在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件的步骤时，采用的是二分查找法。

可选的，所述方法包括：

与所述当前MySQL数据库建立数据连接；

获取所述当前MySQL数据库的二进制日志文件列表；

相应的，所述在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录，就是在上述获取的二进制日志文件列表包含的文件集合中执行的查找操作。

可选的，所述与所述当前MySQL数据库建立数据连接包括：

获取所述当前MySQL数据库所在服务器的IP地址和所述当前MySQL数据库提供数据库服务的端口号；

使用所述IP地址和所述端口号与所述当前MySQL数据库建立数据连接。

可选的，所述获取所述当前MySQL数据库所在服务器的IP地址和所述当前MySQL数据库提供数据库服务的端口号，采用如下方式实现：

读取元信息库中与所述当前MySQL数据库相关的信息，并从中提取所述IP地址和所述端口号。

可选的，所述方法包括：

记录从MySQL主数据库获取的增量日志的最后一个记录的时间戳，作为所述预先指定的时间戳。

可选的，在所述记录从MySQL主数据库获取的增量日志的最后一个记录的时间戳，作为所述预先指定的时间戳的步骤之前，执行下述步骤：

判断MySQL数据库***是否执行了主备切换操作；

若是，将接替所述MySQL主数据库继续提供数据库服务的MySQL备用数据库，作为所述当前MySQL数据库。

可选的，所述判断MySQL数据库***是否执行了主备切换操作，采用如下方式实现：

监测存储在元信息库中的、用于记录MySQL主数据库所在服务器的IP地址的字段是否发生变化；若是，则判断MySQL数据库***执行了主备切换操作。

本申请还提供一种用于获取MySQL binlog增量日志的装置，包括：

记录查找单元，用于在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录；

增量日志获取单元，用于根据所述记录查找单元找到的记录所在二进制日志文件的文件名和该记录在所述文件中的位置，获取所述当前MySQL数据库的增量日志。

可选的，所述记录查找单元包括：

文件查找子单元，用于在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件；

记录查找执行子单元，用于在所述最后一个文件中查找其时间戳不早于所述预先指定的时间戳的第一个记录。

可选的，所述文件查找子单元具体用于，采用二分查找法，在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件。

可选的，所述装置包括：

连接建立单元，用于与所述当前MySQL数据库建立数据连接；

文件列表获取单元，用于获取所述当前MySQL数据库的二进制日志文件列表；

相应的，所述记录查找单元在所述文件列表获取单元输出的二进制日志文件列表包含的文件集合中执行查找操作。

可选的，所述连接建立单元包括：

连接信息获取子单元，用于获取所述当前MySQL数据库所在服务器的IP地址和所述当前MySQL数据库提供数据库服务的端口号；

连接建立执行子单元，用于使用所述连接信息获取子单元输出的IP地址和端口号与所述当前MySQL数据库建立数据连接。

可选的，所述连接信息获取子单元具体用于，读取元信息库中与所述当前MySQL数据库相关的信息，并从中提取所述IP地址和所述端口号。

可选的，所述装置包括：

时间戳记录单元，用于记录从MySQL主数据库获取的增量日志的最后一个记录的时间戳，作为所述预先指定的时间戳。

可选的，所述装置包括：

主备切换判断单元，用于判断MySQL数据库***是否执行了主备切换操作；

当前数据库选择单元，用于当所述主备切换判断单元的输出为“是”时，将接替所述MySQL主数据库继续提供数据库服务的MySQL备用数据库，作为所述当前MySQL数据库。

可选的，所述主备切换判断单元具体用于，监测存储在元信息库中的、用于记录MySQL主数据库所在服务器的IP地址的字段是否发生变化；若是，则判断MySQL数据库***执行了主备切换操作。

与现有技术相比，本申请具有以下优点:

本申请的用于获取MySQL binlog增量日志的方法，没有采用现有技术根据文件名和偏移量确定起始位点的方式，而是采用了根据时间戳定位起始位点的方式，即：在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录，并根据该记录所在二进制日志文件的文件名和该记录在所述文件中的位置，获取所述当前MySQL数据库的增量日志数据，实现了基于时间的增量日志获取方法，从而在MySQL数据库变更的情况下仍然可以正确获取增量日志数据。

附图说明

图1为本申请的一种用于获取MySQL binlog增量日志的方法实施例流程图；

图2为本申请的采用二分法查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件的实施例流程图；

图3为本申请的在主备切换场景下所需处理过程的实施例流程图；

图4为本申请的一种用于获取MySQL binlog增量日志的装置实施例示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请中，分别提供了一种用于获取MySQL binlog增量日志的方法、以及一种用于获取MySQL binlog增量日志的装置。为了便于理解本申请的技术方案，在详细描述本申请技术方案之前，先对binlog文件格式作简要的说明。

Binlog是MySQL以二进制形式存储的日志，每个binlog文件头部都是4个字节的标记，值为0xfe0x620x690x6e（即：0xfe后面加上bin）。文件头之后就是一系列的LOG_EVENT（日志事件），LOG_EVENT是binlog文件中的基本单位，即正常情况下binlog按照逐LOG_EVENT的形式增长。每个LOG_EVENT都是独立单元，没有互相引用的关系。LOG_EVENT的事件类型有很多种，其中用于记录数据库更改操作的LOG_EVENT的事件类型为查询事件（queryevent）。上述binlog文件结构中的LOG_EVENT就是本申请所述的记录。

每个LOG_EVENT都有一个长度为19字节的事件头，其中包含事件的长度、事件的时间戳、事件类型等信息。事件头之后就是根据事件类型确定的事件体，

对于类型为query event的记录来说，事件体中记录了代理线程ID、错误码、具体的数据库更改操作语句等。binlog文件格式如下表所示：

表一：binlog文件格式（其中第N字节均指从0开始的排序）

其中，LOG_EVENT头部的第0-3字节记录的执行事件的主机时间，即为本申请所述的时间戳信息，也就是当前记录更新的时间，例如：时间戳1390467118对应的就是ThuJan2316:51:58CST2014这个时间。LOG_EVENT头部的第13-16字节，即为本申请所述的偏移量（记录位于二进制日志文件中的位置）。

在了解binlog文件格式的基础上，下面对本申请技术方案的实施例逐一进行详细说明。请参考图1，其为本申请的一种用于获取MySQL binlog增量日志的方法实施例流程图。所述方法包括如下步骤：

步骤101：在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录。

本申请的技术方案，根据预先指定的时间戳，在待获取增量日志的当前MySQL数据库的二进制日志文件集合中，定位与所述时间戳对应的起始位点，即：查找其时间戳不早于所述时间戳的第一个记录，并以该记录所在文件的文件名和该记录在所述文件中的偏移量作为起始位点，获取当前MySQL数据库的增量日志数据。

通过上面的描述可以看出，本申请技术方案的核心在于：通过时间戳信息定位起始位点，并根据起始位点获取MySQL数据库的增量日志数据。因此，本申请的技术方案既可以部署在所述MySQL数据库所在的服务器端，采取本地读取的方式获取增量日志数据，也可以部署在不同于MySQL数据库所在服务器的其他设备上，并且通过建立网络连接的方式获取增量日志数据。这两种实施方式都不偏离本申请的核心。

本申请技术方案根据时间戳定位起始位点的功能，是通过本步骤对所述当前MySQL数据库的二进制日志文件集合的查找过程实现的。下面首先对本步骤所述的二进制日志文件集合作简要的介绍。

MySQL数据库在初始运行时会在数据根目录创建两个名称类似xxx-bin.000001和xxx-bin.index的新文件，若配置文件的相关选项没有给出文件名，MySQL将使用主机名称命名这两个文件，例如：mysql-bin.000001和mysql-bin.index。其中，MySQL会把所有对数据库内容和结构的修改情况记入mysql-bin.000001文件，而mysql-bin.index文件则包含了一份当前使用的所有二进制日志文件的清单。MySQL数据库会在重启时、或者日志文件大小超过***变量max_binlog_size指定的上限时，生成一个新的日志文件，其文件扩展名序号依次递增。由此可见，MySQL数据库的二进制日志文件可能是一个，也可能是一组，而本申请所述的二进制日志文件集合则包含了MySQL数据库当前使用的所有二进制日志文件。

由于二进制日志文件按照时间顺序记录对MySQL数据库所作的更改操作，而二进制日志文件集合通常也是按照生成的二进制日志文件由早到晚的顺序排列的（文件扩展名中的数字是依次累加的），因此，本步骤所述的查找操作是指，在所述当前MySQL数据库的二进制日志文件集合包含的、按照时间由早到晚排序的二进制日志文件中执行查找操作，查找其时间戳不早于预先指定的时间戳的第一个记录。

通过前面对binlog文件格式的介绍可以知道，binlog文件就像一个流文件，按照时间顺序记录了对MySQL数据库所做的更改。而且它其中的每一条记录没有明显的开始及结束标志，只能通过长度来判断一条记录的结束位置。基于binlog文件格式的这种特点，要从所述当前MySQL数据库的二进制日志文件集合中找到其时间戳不早于所述预先指定的时间戳，最简单易行的方法，就是逐一分析每个二进制日志文件，并且在分析每个文件时，都从其头部开始读取每一个记录、并判断当前记录的时间戳是否不早于所述预先指定的时间戳，若是，则找到了所需的记录，否则，继续读取下一个记录。采用这种方法，如果所需定位的记录位于最后一个二进制日志文件的尾部，那么上述操作就是对全部二进制日志文件的遍历，整个查找过程的执行效率很低。

为了提高上述查找效率，本申请的技术方案提供了先确定待查找记录所在的二进制日志文件，然后再在所述二进制日志文件中查找所述记录的方法，从而能够减少对二进制日志文件的遍历操作（只需要对一个二进制日志文件进行遍历）。下面分别对定位文件和定位记录这两个步骤作详细说明。

步骤101-1：在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件。

本步骤的具体查找过程是这样的，读取每个二进制日志文件中的第一个记录，判断其时间戳是否早于所述预先指定的时间戳，若是，则读取下一个二进制日志文件的第一个记录，并作同样的判断，直到找到某个文件的第一个记录的时间戳晚于所述预先指定的时间戳，则在当前文件之前查找的文件即为本步骤所需查找的二进制日志文件。如果当前文件的第一个记录的时间戳早于所述预先指定的时间戳，而后续没有其他二进制日志文件（当前文件是所述集合中的最后一个文件），说明待查找记录位于当前文件中，当前文件就是本步骤所需查找的二进制日志文件。

需要说明的是，在上述通过查找定位所需的二进制日志文件的过程中，如果当前读取的二进制日志文件中的第一个记录的时间戳恰好等于所述预先指定的时间戳，说明已经找到了所需的记录，那么该查找过程就可以终止，而且也不必再执行后续步骤101-2（在上述找到的文件中进一步查找时间戳不早于所述预先指定的时间戳的第一个记录），步骤101就全部完成了。

在上面描述的实施方式中，如果所需查找的二进制日志文件是所述二进制日志文件集合中的最后一个文件，那么上述查找定位过程就需要针对每个文件都读取第一个记录、并进行时间戳判断，在实际的MySQL数据库的应用场景下，二进制日志文件集合中的文件可能有十几个、几十个甚至更多，在这种情况下，采用上述逐一读取并判断的方式，处理效率依然是相对较低的。为了有效改善这一问题，本申请的技术方案提供了一种优选实施方式，即：采用二分查找法，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件。

二分查找法，又称折半查找法，是一种效率较高的查找方法，其基本思想如下：假设数据序列是按升序排序的（降序排列道理类似），对于给定值x，从序列的中间位置（作为当前位置）开始比较，如果当前位置值等于x，则查找成功；若x小于当前位置值，则在数据序列的前半段中继续上述查找过程；若x大于当前位置值则在数据序列的后半段中继续上述查找过程，直到找到为止。由于二分查找法，采用了折半查询的方式，每次排除掉待查询数据序列的一半，因此可以减少查找的次数。对于在一个包含N个数的数据序列中查找某个数来说，常规的逐一比较查找算法的时间复杂度为O(N)，但是如果该数据序列是有序的，那么采用二分查找法的时间复杂度仅为O(log2N)（其中2是对数的底数）。例如：对于包含7个数据的序列，采用常规逐一比较的算法最多需要比较7次，才能完成，而采用二分查找法，最多只需要比较3次就可以完成。

具体到本申请的技术方案，由于二进制日志文件中的记录是按照执行相关数据库更改操作的时间顺序写入的，而二进制日志文件也是按照时间顺序逐一生成的（其扩展名递增），因此按照时间顺序排列的全部二进制日志文件中的第一个记录的时间戳也是按照时间顺序排列的，符合二分查找法要求数据序列必须是有序的这一基本要求，因此可以采用二分法查找本步骤所需的二进制日志文件，从而有效提高查找的效率。请参见附图2，其为本申请的采用二分法查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件的基本流程示意图，由于二分查找法比较成熟，因此下面仅结合该附图对于在本技术方案中如何采用二分查找法作简要说明（为了便于描述，将查找条件“其包含的第一个记录的时间戳不晚于所述预先指定的时间戳”简化描述为“不晚于t1”）：

步骤101-1-1：为算法相关变量赋初值。当前有N个二进制日志文件，用数组B代表，B[0]为第一个文件，B[N-1]为最后一个文件。l代表待查找区间的起点位置，h代表待查找区间的结束位置，i代表待查找区间的中间位置。预先指定的时间戳为t1。

步骤101-1-2：定位当前查找的文件区间的中间位置，并获取对应文件的第一个记录的时间戳t。

步骤101-1-3：如果t=t1，则说明找到了所需的记录（B[i]文件中的第一个记录），因此本查找过程结束。

步骤101-1-4：判断l是否小于等于h，若是说明查找过程尚未结束，继续执行后续的查找操作。

步骤101-1-5：如果t<t1，即：当前记录的时间戳早于t1，但是B[i]文件不一定是满足所述“不晚于t1”要求的最后一个文件，因此还需要继续在当前文件区间的后半段中查找，看看是否存在其第一个记录的时间戳晚于本记录时间戳、但是早于t1的文件，转到步骤101-1-6执行。

步骤101-1-6：设置l=i+1，为在当前文件区间的后半段继续查找设置区间的起点位置，转到步骤101-1-2执行。

步骤101-1-7：如果t>t1，即：当前记录的时间戳晚于t1，B[i]文件不满足“不晚于t1”的要求，应该在当前文件区间的前半段中继续查找，转到步骤101-1-8执行。

步骤101-1-8：设置h=i-1，为在当前文件区间的前半段继续查找设置区间的结束位置，转到步骤101-1-2执行。

上述查找过程一直循环执行，该过程在两种情况下终止：第一种情况，在步骤101-1-3中判断出t=t1，则B[i]就是满足要求的最后一个文件，并且B[i]中的第一个记录就是本申请的技术方案所需查找的记录，这种情况下可以跳过后续步骤101-2，直接执行步骤102即可；第二种情况，在步骤101-1-4中判断出l>h（起始位置已经大于结束位置），说明二分查找过程结束，当前B[i]文件就是满足“不晚于t1”要求的最后一个文件。

步骤101-2：在所述最后一个文件中查找其时间戳不早于所述预先指定的时间戳的第一个记录。

执行到本步骤，说明已经在所述当前MySQL数据库的二进制日志文件集合中，找到了其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件，在本步骤中只需要从所述最后一个文件的第一个记录开始，遍历该文件中的所有记录，找到其时间戳不早于所述预先指定的时间戳的第一个记录。

这里需要说明的是，通常情况下，可以在所述最后一个文件中找到其时间戳等于所述预先指定的时间戳的第一个记录，在本步骤中之所以采用了“不早于”（包括等于和大于两种情况）的表述方式，是考虑到具体实施过程中可能发生的特殊情况：在所述当前MySQL数据库的二进制日志文件集合中，无法找到其时间戳与所述预先指定的时间戳完全相同的记录（详细说明请参见后文与主备切换相关的说明）。在这种情况下，为了使本申请技术方案依然能够找到尽可能准确的起始位点，并保证后续获取增量日志的步骤102能够顺利执行，因此在本步骤中采用了查找其时间戳不早于所述预先指定时间戳的第一个记录的方式。

例如，在本实施例的一个具体例子中，是这样实现的：从所述最后一个文件的第一个记录开始，如果该记录的时间戳小于预先指定的时间戳，则继续读取下一个记录，并作同样的判断......直到当前记录的时间戳大于或者等于所述预先指定的时间戳，则该查找过程结束，当前记录就是所述最后一个文件中、其时间戳不早于所述预先指定的时间戳的第一个记录。

至此，就根据所述预先指定的时间戳在所述当前MySQL数据库的二进制日志文件集合中找到了对应的记录，那么，就可以根据已找到的记录执行后续步骤102实现获取增量日志的功能。

考虑到在实际应用中，需要从MySQL数据库抓取增量二进制日志数据、以满足增量订阅或消费等相关业务需求的应用程序或者***通常安装在不同于MySQL数据库所在服务器的其他设备上，在常规情况下通过网络连接从MySQL主数据库抓取增量日志数据，在发生主备切换的场景下，则采用本申请提供的方法，继续从备用数据库（即：本申请所述的当前MySQL数据库）抓取增量日志数据。在这种情况下，从MySQL主数据库获取的增量日志的最后一个记录的时间戳，即为本步骤所述的预先指定的时间戳。为了在上述应用场景下实施本申请的技术方案，则需要在执行本步骤101之前执行判断主备切换、记录时间戳、建立数据连接、获取二进制日志文件列表这四个步骤，请参见附图3，其为上述处理过程的实施例流程图，下面结合附图3进行进一步的说明。为了便于下文的描述，将在抓取增量日志过程中实现了本申请技术方案的应用程序或者***，统称为增量日志抓取任务。

步骤100-1：判断MySQL数据库***是否执行了主备切换操作。

增量日志抓取任务采用与MySQL备用数据库类似的方式，按照MySQL网络通信协议的要求，将封装了COM_BINLOG_DUMP命令的数据包发送给MySQL主数据库，该数据包中还要封装希望从中获取增量日志数据的二进制日志文件的文件名和偏移量，MySQL主数据库收到该数据包后，会将符合要求的增量日志返回给所述增量日志抓取任务。

考虑到MySQL主数据库可能出现故障，为了能够及时将抓取增量日志的操作切换到备用数据库上（即：切换后的主数据库），增量日志抓取任务需要监测MySQL数据库***是否发生了主备切换。在本实施例的一个具体例子中，在数据库的元信息库中用一个特定的字符串“GroupKey”表征当前的主备数据库，通过检测该字符串，就可以获得当前主数据库和备数据库的相关信息，如果发现主数据库的IP地址发生了变化，即可以判定主备数据库发生了切换，所述增量日志抓取任务就需要通过执行后续的步骤，将抓取增量日志的操作切换到备用数据库上。

步骤100-2：记录从MySQL主数据库获取的增量日志的最后一个记录的时间戳，作为所述预先指定的时间戳。

为了将从MySQL主数据库获取binlog增量日志的操作切换到MySQL备用数据库上（即：本申请所述的当前MySQL数据库），需要将已经从MySQL主数据库获取的增量日志的最后一个记录的时间戳记录下来，这样才能执行后续的根据所述时间戳在备用数据库的二进制日志文件集合中查找起始位点的操作。

本步骤中，将已经从MySQL主数据库获取的增量日志的最后一个记录的时间戳记录下来，也就是记录所述最后一个记录的头部的第0-3字节的时间戳信息，作为后续在备用数据库的二进制日志文件集合中定位起始位点的依据，从而尽可能保证从备用数据库获取的增量日志与从主数据库上获取的增量日志是连续的，尽量避免出现数据丢失的现象。本步骤获取的时间戳，即为本申请所述的预先指定的时间戳。

步骤100-3：与所述当前MySQL数据库建立数据连接。

增量日志抓取任务遵循MySQL主备数据库之间的交互协议，与所述当前MySQL数据库（在发生主备切换后，原来的备用数据库即成为本申请所述的当前MySQL数据库）建立数据连接，也就是说增量日志抓取任务以备用数据库的身份向所述当前MySQL数据库请求增量日志数据。

本步骤所述的与所述当前MySQL数据库建立数据连接，采用了相对宽泛的表述方式，在具体实施中，本步骤不仅包括连接的建立过程，通常还包括了鉴权等过程，其基本流程是这样的：首先需要获取所述当前MySQL数据库所在服务器的IP地址和所述当前MySQL数据库提供数据库服务的端口号，然后创建一个socket（套接字）与所述当前MySQL数据库建立数据连接，并按照MySQL主备数据库之间的交互协议执行握手和验证等交互过程，在该过程中，所述增量日志抓取任务可能还需要按照MySQL主服务器的要求提供用户名、口令等信息，并且只有通过所述当前MySQL数据库的身份验证，所述数据连接才算建立成功。

为了完成上述连接建立过程，必须要获取当前MySQL数据库的IP地址和提供数据库服务的端口号。在本实施例的一个具体例子中，在数据库的元信息库中用一个特定的字符串“GroupKey”表征当前的主备数据库，通过检测该字符串，就可以获得当前主数据库和备数据库的相关信息，在发生主备切换后，原来的备用数据库成为了当前的主数据库（本申请所述的当前MySQL数据库），因此可以从上述字符串中获取与当前MySQL数据库相关的信息，并从中提取所述IP地址和所述端口号。在其他实施方式中，可以采用其他获取方式，例如：在不修改MySQL配置文件中的端口设置的情况下，可以直接使用MySQL默认的端口号3306来建立数据连接。

步骤100-4：获取所述当前MySQL数据库的二进制日志文件列表。

为了实现本申请的技术方案，依据步骤100-2中获取的时间戳信息，在当前MySQL数据库的二进制日志文件集合中查找与该时间戳对应的位点，还需要获取所述当前MySQL数据库的二进制日志文件列表，即：确定本申请技术方案的步骤101的查找范围。

在本实施例的一个具体例子中，采用如下方式获取二进制日志文件列表：增量日志抓取任务基于在步骤100-3中已经建立的数据连接，向所述当前MySQL数据库发送“showmaster logs”命令，所述当前MySQL数据库接收该命令后，就会将其本地的二进制日志文件列表返回给增量日志抓取任务，例如，在本例中，增量日志抓取任务接收到的二进制日志文件列表包含7个文件，mysql-bin.000001、mysql-bin.000002、......mysql-bin.000007。

在其他实施方式中，也可以采用不同于上述具体例子的其他方式获取所述当前MySQL数据库的二进制日志文件列表，例如可以通过文件共享的方式访问所述当前MySQL数据库的二进制日志索引文件（例如：mysql-bin.index），从中读取所需的文件列表信息。

至此，增量日志抓取任务就可以继续执行步骤101，根据已经获取的时间戳在上述已获取的二进制日志文件列表包含的文件集合中查找与该时间戳对应的记录，即：查找其时间戳不早于预先指定的时间戳的第一个记录。

前面在步骤101中已经提到过，之所以要查找其时间戳不早于预先指定的时间戳的第一个记录，而不是直接查找其时间戳等于预先指定的时间戳的第一个记录，是考虑到具体实现中的特殊情况，该特殊情况就是与上面描述的主备切换场景相关的，下面对此作进一步的详细说明。

当MySQL主数据库发生故障（例如宕机）时，由于MySQL的主备复制过程存在一定延迟，因此存在备用数据库尚未将主数据库宕机前的最新增量日志拉取到本地的情况，这时发生了主备切换，备用数据库成为了主数据库，继续提供数据库服务，继续向二进制日志文件中写入新的记录。在这种情况下，备用数据库丢失了主数据库宕机前的部分增量日志记录，而增量日志抓取任务却有可能成功抓取了这部分记录。因此，当增量日志抓取任务依据这部分记录中的最后一个记录的时间戳，在备用数据库（即：本申请所述的当前MySQL数据库）的二进制日志文件集合中查找时，就无法找到其时间戳与该时间戳完全相同的记录。为了使本申请技术方案在这种情况下依然能够找到尽可能准确的位点，并保证抓取增量日志的任务能够顺利执行，因此在步骤101中查找的是其时间戳不早于所述预先指定的时间戳的第一个记录。

需要明确的是，本申请的技术方案并不仅仅限于上述发生主备切换的应用场景，也可以应用在其他应用场景中，而且上面提及的步骤也并非都是必需的。例如：实现了本申请技术方案的应用程序或者***位于当前MySQL数据库的本地（在同一台服务器上），而且需要根据指定的时间信息获取增量日志，那么就不需要执行上述与主备切换和建立数据连接相关的子步骤（步骤100-1至步骤100-4），而是直接采用遍历的方式或者采用本实施例中的先定位文件（步骤101-1）、再定位记录（步骤101-2）的方式，在本地的二进制日志文件集合中进行记录的查找。不管采用何种方式实现本步骤，只要能够找到其时间戳不早于预先指定的时间戳的第一个记录即可，上述实施方式的变更，并不偏离本申请技术方案的核心，也在本申请的保护范围之内。

步骤102：根据该记录所在二进制日志文件的文件名和该记录在所述文件中的位置，获取所述当前MySQL数据库的增量日志。

通过步骤101，已经在当前MySQL数据库的二进制日志文件集合中，找到了与预先指定的时间戳对应的记录，根据前面介绍过的binlog文件的格式，读取该记录头部的第13-16字节就获取了该记录在当前二进制日志文件中的偏移量，由该记录所在二进制日志文件的文件名和所述偏移量，就得到了所述预先指定的时间戳在所述MySQL二进制日志文件集合中的位点信息，根据该位点信息就可以进一步获取当前MySQL数据库的、位于该位点信息之后的增量日志数据了。

在具体实施过程中，可以通过向当前MySQL数据库发送获取增量日志数据的命令来实现。以本实施例所述的增量日志抓取任务为例，在MySQL数据库***发生主备切换后，在步骤101中查找到与预先指定的时间戳对应的记录位于mysql-bin.000003文件的偏移量为126字节的位置。增量日志抓取任务通过已经与当前MySQL数据库建立的数据连接，向当前MySQL数据库发送MySQL的原生命令COM_BINLOG_DUMP，并且根据该命令的格式要求，携带希望获取增量日志数据的位点信息，即：文件名为mysql-bin.000003，偏移量为126字节。所述当前MySQL服务器接收到上述COM_BINLOG_DUMP命令后，会根据该命令携带的位点信息，向增量日志抓取任务推送位于该位点信息之后的增量日志数据。至此，在MySQL数据库***发生主备切换之后，增量日志抓取任务也实现了从主数据库到备用数据库的切换过程，从而最大限度地保证了抓取增量日志数据的连续性和正确性。而增量日志抓取任务则可以进一步解析获取的增量日志数据，并根据相关的业务需求进行必要的后续处理。

上面介绍的获取增量日志的方式，是以增量日志抓取任务为背景的，该方式需要借助网络通信的方式（与数据库建立连接）来获取当前MySQL数据库的增量日志数据。但是在其他的实施方式中，本申请的技术方案也可以不借助网络，直接在MySQL数据库的本地执行获取增量日志数据的操作。例如，在所述当前MySQL数据库的本地使用fopen（）函数或者类似函数打开希望从中获取增量日志数据的二进制日志文件，并通过seek()函数或者类似函数将文件读写指针定位到希望获取增量日志数据的偏移量位置，然后调用fread()或者类似函数从指定的偏移量处开始按照二进制日志文件格式读取所需的数据，同样可以实现本步骤所述的获取所述当前MySQL数据库增量日志数据的功能。

综上所述，无论是采用本地方式，还是采用通过网络的方式，也不管本申请技术方案的触发事件是本实施例所述的主备切换事件或者其他事件，只要是需要根据时间信息在MySQL的二进制日志文件集合中确定位点（文件名+偏移量），并且基于该位点获取MySQL增量日志数据的应用场合，都可以采用本申请的技术方案。

本申请的用于获取MySQL binlog增量日志的方法，没有采用现有技术根据文件名和偏移量确定起始位点的方式，而是采用了根据时间戳定位起始位点的方式，即：在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录，并根据该记录所在二进制日志文件的文件名和该记录在所述文件中的位置，获取所述当前MySQL数据库的增量日志数据，实现了基于时间的增量日志获取方法，从而在MySQL数据库变更的情况下仍然可以正确获取增量日志数据。

在上述的实施例中，提供了一种用于获取MySQL binlog增量日志的方法，与之相对应的，本申请还提供一种用于获取MySQL binlog增量日志的装置。

请参看图4，其为本申请提供的一种用于获取MySQL binlog增量日志的装置实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关的部分请参见方法实施例的对应说明即可。下述描述的装置实施例仅仅是示意性的。

本实施例的一种用于获取MySQL binlog增量日志的装置，包括：记录查找单元401，用于在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录；增量日志获取单元402，用于根据所述记录查找单元找到的记录所在二进制日志文件的文件名和该记录在所述文件中的位置，获取所述当前MySQL数据库的增量日志。

可选的，所述记录查找单元包括：

文件查找子单元，用于在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件；

记录查找执行子单元，用于在所述最后一个文件中查找其时间戳不早于所述预先指定的时间戳的第一个记录。

可选的，所述文件查找子单元具体用于，采用二分查找法，在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件。

可选的，所述装置包括：

连接建立单元，用于与所述当前MySQL数据库建立数据连接；

文件列表获取单元，用于获取所述当前MySQL数据库的二进制日志文件列表；

相应的，所述记录查找单元在所述文件列表获取单元输出的二进制日志文件列表包含的文件集合中执行查找操作。

可选的，所述连接建立单元包括：

连接信息获取子单元，用于获取所述当前MySQL数据库所在服务器的IP地址和所述当前MySQL数据库提供数据库服务的端口号；

连接建立执行子单元，用于使用所述连接信息获取子单元输出的IP地址和端口号与所述当前MySQL数据库建立数据连接。

可选的，所述连接信息获取子单元具体用于，读取元信息库中与所述当前MySQL数据库相关的信息，并从中提取所述IP地址和所述端口号。

可选的，所述装置包括：

时间戳记录单元，用于记录从MySQL主数据库获取的增量日志的最后一个记录的时间戳，作为所述预先指定的时间戳。

可选的，所述装置包括：

主备切换判断单元，用于判断MySQL数据库***是否执行了主备切换操作；

当前数据库选择单元，用于当所述主备切换判断单元的输出为“是”时，将接替所述MySQL主数据库继续提供数据库服务的MySQL备用数据库，作为所述当前MySQL数据库。

可选的，所述主备切换判断单元具体用于，监测存储在元信息库中的、用于记录MySQL主数据库所在服务器的IP地址的字段是否发生变化；若是，则判断MySQL数据库***执行了主备切换操作。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

Claims (16)

1.一种用于获取MySQL binlog增量日志的方法，其特征在于，包括：

当MySQL主数据库未发生故障时，在当前MySQL数据库的二进制日志文件集合中，查找其时间戳等于预先指定的时间戳的第二个记录；

当MySQL主数据库发生故障时，将接替所述MySQL主数据库继续提供数据库服务的MySQL备用数据库，作为当前MySQL数据库；在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录，包括：在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件；在所述最后一个文件中查找其时间戳不早于所述预先指定的时间戳的第一个记录；

根据该第一个记录或者第二个记录所在二进制日志文件的文件名和该第一个记录或者第二个记录在所述文件中的位置，获取所述当前MySQL数据库的增量日志。

2.根据权利要求1所述的用于获取MySQL binlog增量日志的方法，其特征在于，执行在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件的步骤时，采用的是二分查找法。

3.根据权利要求1-2任意一项所述的用于获取MySQL binlog增量日志的方法，其特征在于，包括：

与所述当前MySQL数据库建立数据连接；

获取所述当前MySQL数据库的二进制日志文件列表；

相应的，所述在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录，就是在上述获取的二进制日志文件列表包含的文件集合中执行的查找操作。

4.根据权利要求3所述的用于获取MySQL binlog增量日志的方法，其特征在于，所述与所述当前MySQL数据库建立数据连接包括：

获取所述当前MySQL数据库所在服务器的IP地址和所述当前MySQL数据库提供数据库服务的端口号；

使用所述IP地址和所述端口号与所述当前MySQL数据库建立数据连接。

5.根据权利要求4所述的用于获取MySQL binlog增量日志的方法，其特征在于，所述获取所述当前MySQL数据库所在服务器的IP地址和所述当前MySQL数据库提供数据库服务的端口号，采用如下方式实现：

读取元信息库中与所述当前MySQL数据库相关的信息，并从中提取所述IP地址和所述端口号。

6.根据权利要求3所述的用于获取MySQL binlog增量日志的方法，其特征在于，包括：

记录从MySQL主数据库获取的增量日志的最后一个记录的时间戳，作为所述预先指定的时间戳。

7.根据权利要求6所述的用于获取MySQL binlog增量日志的方法，其特征在于，在所述记录从MySQL主数据库获取的增量日志的最后一个记录的时间戳，作为所述预先指定的时间戳的步骤之前，执行下述步骤：

判断MySQL数据库***是否执行了主备切换操作；

若是，将接替所述MySQL主数据库继续提供数据库服务的MySQL备用数据库，作为所述当前MySQL数据库。

8.根据权利要求7所述的用于获取MySQL binlog增量日志的方法，其特征在于，所述判断MySQL数据库***是否执行了主备切换操作，采用如下方式实现：

监测存储在元信息库中的、用于记录MySQL主数据库所在服务器的IP地址的字段是否发生变化；若是，则判断MySQL数据库***执行了主备切换操作。

9.一种用于获取MySQL binlog增量日志的装置，其特征在于，包括：

记录查找单元，用于当MySQL主数据库发生故障时，将接替所述MySQL主数据库继续提供数据库服务的MySQL备用数据库，作为当前MySQL数据库；在当前MySQL数据库的二进制日志文件集合中，查找其时间戳不早于预先指定的时间戳的第一个记录；

增量日志获取单元，用于根据所述记录查找单元找到的记录所在二进制日志文件的文件名和该记录在所述文件中的位置，获取所述当前MySQL数据库的增量日志；文件查找子单元，用于在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件；

记录查找执行子单元，用于在所述最后一个文件中查找其时间戳不早于所述预先指定的时间戳的第一个记录；

当所述MySQL主数据库未发生故障时，在所述当前MySQL数据库的二进制日志文件集合中，查找其时间戳等于预先指定的时间戳的第二个记录。

10.根据权利要求9所述的用于获取MySQL binlog增量日志的装置，其特征在于，所述文件查找子单元具体用于，采用二分查找法，在所述当前MySQL数据库的二进制日志文件集合中，查找其包含的第一个记录的时间戳不晚于所述预先指定的时间戳的最后一个文件。

11.根据权利要求9-10任意一项所述的用于获取MySQL binlog增量日志的装置，其特征在于，包括：

连接建立单元，用于与所述当前MySQL数据库建立数据连接；

文件列表获取单元，用于获取所述当前MySQL数据库的二进制日志文件列表；

相应的，所述记录查找单元在所述文件列表获取单元输出的二进制日志文件列表包含的文件集合中执行查找操作。

12.根据权利要求11所述的用于获取MySQL binlog增量日志的装置，其特征在于，所述连接建立单元包括：

连接信息获取子单元，用于获取所述当前MySQL数据库所在服务器的IP地址和所述当前MySQL数据库提供数据库服务的端口号；

连接建立执行子单元，用于使用所述连接信息获取子单元输出的IP地址和端口号与所述当前MySQL数据库建立数据连接。

13.根据权利要求12所述的用于获取MySQL binlog增量日志的装置，其特征在于，所述连接信息获取子单元具体用于，读取元信息库中与所述当前MySQL数据库相关的信息，并从中提取所述IP地址和所述端口号。

14.根据权利要求11所述的用于获取MySQL binlog增量日志的装置，其特征在于，包括：

时间戳记录单元，用于记录从MySQL主数据库获取的增量日志的最后一个记录的时间戳，作为所述预先指定的时间戳。

15.根据权利要求14所述的用于获取MySQL binlog增量日志的装置，其特征在于，包括：

主备切换判断单元，用于判断MySQL数据库***是否执行了主备切换操作；

当前数据库选择单元，用于当所述主备切换判断单元的输出为“是”时，将接替所述MySQL主数据库继续提供数据库服务的MySQL备用数据库，作为所述当前MySQL数据库。

16.根据权利要求15所述的用于获取MySQL binlog增量日志的装置，其特征在于，所述主备切换判断单元具体用于，监测存储在元信息库中的、用于记录MySQL主数据库所在服务器的IP地址的字段是否发生变化；若是，则判断MySQL数据库***执行了主备切换操作。

Images