CN107102934A - 一种关系型数据库二进制日志重放的方法和设备 - Google Patents

一种关系型数据库二进制日志重放的方法和设备 Download PDF

Info

Publication number
CN107102934A
CN107102934A CN201610096150.6A CN201610096150A CN107102934A CN 107102934 A CN107102934 A CN 107102934A CN 201610096150 A CN201610096150 A CN 201610096150A CN 107102934 A CN107102934 A CN 107102934A
Authority
CN
China
Prior art keywords
reset
playback
daily record
binary log
need
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201610096150.6A
Other languages
English (en)
Other versions
CN107102934B (zh
Inventor
王波
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201610096150.6A priority Critical patent/CN107102934B/zh
Publication of CN107102934A publication Critical patent/CN107102934A/zh
Application granted granted Critical
Publication of CN107102934B publication Critical patent/CN107102934B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请的目的是提供一种关系型数据库二进制日志重放的方法和设备，通过从待重放关系型数据库服务设备的备份集获取待恢复的重放相关数据；获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志；基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件；启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放，避免了所述需重放的二进制日志重放时的出现重放失败，有效地提高了所述需重放的二进制日志的重放效率。

Description

一种关系型数据库二进制日志重放的方法和设备
技术领域
本申请涉及计算机领域，尤其涉及一种关系型数据库二进制日志重放的技术。
背景技术
随着计算机技术的不断发展，由于误操作等原因，经常会有将数据库中的数据恢复到过去时间点的需求。例如，在关系型数据库系统(MySQL)中的二进制日志(binlog)会记录与数据库中的数据相关的更新操作，而对数据库所做的定期的备份集相当于数据存档点，因此可将binlog中的记录从前到后依次应用在备份集上，就可以将数据库恢复到过去任意一个时间点的状态。
现有技术中，由于二进制日志(binlog)是二进制文件且关系型数据库服务器(MySQL Server)只能执行一条条的结构化查询语句(StructuredQuery Language，SQL)，因此在用户端(client)的用户线程中需采用二进制日志解析工具(例如mysqlbinlog)将binlog解析为结构化查询语句文本，并通过网络协议将用户线程解析出的SQL按照从前到后的顺序串行发送给MySQL Server以达到进行binlog的重放。由于binlog中有时会记录执行失败操作，然后会用一个错误码(error code)标志标识执行失败，此种失败操作是需要跳过的，然而现有技术中的用户线程采样二进制日志解析工具解析binlog然后应用SQL时不会跳过所述失败操作的错误码，从而直接报错，导致应用SQL进行数据的重放失败；又由于client需通过网络协议将用户线程解析出的SQL发送给MySQL Server，而协议中规定网络包的大小上限是1G，但是binlog对单个数据库的记录执行事件(event)没有限制上限，造成不能够重放记录event过大的binlog；由于通过网络连接将用户线程解析出的SQL按照从前到后的顺序串行发送给MySQLServer以达到进行binlog的重放，若需重放的binlog量很大，串行执行时间过长，导致重放binlog的重放效率低。
因此，现有技术中，采样二进制日志解析工具对需重放的二进制日志(binlog)进行解析，因执行解析操作是单线程的，导致对binlog重放效率低，再者需重放的binlog中的执行事件(event)过大或event记录中有错误码，从而有可能导致binlog的重放过程的重放失败。
发明内容
本申请的目的是提供一种关系型数据库二进制日志重放的方法与设备，以解决现有技术中采样二进制日志解析工具对需重放的二进制日志(binlog)进行解析，因执行解析操作是单线程的，导致对binlog重放效率低，再者需重放的binlog中的执行事件(event)过大或event记录中有错误码，从而有可能导致binlog的重放过程的重放失败的问题。
根据本申请的一个方面，提供了一种关系型数据库二进制日志重放的方法，包括：
从待重放关系型数据库服务设备的备份集获取待恢复的重放相关数据；
获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志；
基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件；
启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放。
进一步地，所述启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放包括：
启动关系型数据库系统中的复制应用线程；
从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放。
根据本申请的另一方面，还提供了一种关系型数据库二进制日志重放的设备，包括：
获取装置，用于从待重放关系型数据库服务设备的备份集获取待恢复的重放相关数据；
确定装置，用于获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志；
更新装置，用于基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件；
重放装置，用于启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放。
进一步地，所述重放装置包括：
启动单元，用于启动关系型数据库系统中的复制应用线程；
重放单元，用于从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放。
与现有技术相比，根据本申请的实施例所述的一种用于关系型数据库二进制日志重放的方法与设备，首先通过从待重放关系型数据库服务设备的备份集获取待恢复的重放相关数据，有效地基于从待重放关系型数据库服务设备的备份集中获取待恢复的重放相关数据对二进制日志进行重放；接着获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志，以得到经过剪裁后的需重放的二进制日志；然后基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件，使得在重放过程中能够对所述需重放的二进制日志进行重放；最后启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放，由于通过启动复制应用线程来解析并执行所述需重放的二进制日志对应的中继日志，不走网络通信，因而重放过程不会受到关系型数据库系统网络协议的网络包大小的限制，有效地提高应用二进制日志进行重放的重放效率。
进一步地，根据本申请的实施例所述的一种用于关系型数据库二进制日志重放的方法与设备，通过启动关系型数据库系统中的复制应用线程；从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放，由于关系型数据库系统中的复制应用线程能够将重放二进制日志过程中出现的与执行失败有关的错误码与二进制日志中记录的错误码进行对比，若相同则不会报错并继续执行二进制日志中的下一执行事件，直至完成二进制日志的重放，避免了所述需重放的二进制日志重放时的出现重放失败，又由于可通过启动多个复制应用线程并行执行所述需重放的二进制日志对应的中继日志的执行事件，从而达到有效提高所述需重放的二进制日志的重放效率。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：
图1示出根据本申请一个方面的一种关系型数据库二进制日志重放的设备的结构示意图；
如图2示出根据本申请一个方面的一种优选地关系型数据库二进制日志单线程串行重放的流程示意图；
如图3示出根据本申请一个方面的一种优选地关系型数据库二进制日志多线程并行重放的流程示意图；
图4示出根据本申请一个方面的一种关系型数据库二进制日志重放的方法的流程示意图；
图5示出根据本申请一个方面的一种关系型数据库二进制日志重放的方法的整体流程示意图。
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
下面结合附图对本申请作进一步详细描述。
图1示出根据本申请一个方面的一种关系型数据库二进制日志重放的设备的结构示意图。该设备1包括获取装置11、确定装置12、更行装置13和重放装置14。
其中，所述获取装置11从待重放关系型数据库服务设备的备份集获取待恢复的重放相关数据；所述确定装置12获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志；所述更新装置13基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件；所述重放装置14启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放。
在此，所述设备1包括但不限于用户设备、或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备其包括但不限于任何一种所述移动电子产品，所述移动电子产品可以采用任意操作系统，如安卓(android)操作系统、苹果(iOS)操作系统等。其中，所述网络设备包括一种能够按照事先设定或存储的指令，自动进行数值计算和信息处理的电子设备，其硬件包括但不限于微处理器、专用集成电路(ASIC)、可编程门阵列(FPGA)、数字处理器(DSP)、嵌入式设备等。所述网络包括但不限于互联网、广域网、城域网、局域网、VPN网络、无线自组织网络(Ad Hoc网络)等。优选地，设备1还可以是运行于所述用户设备与网络设备通过网络相集成所构成的设备上的脚本程序。当然，本领域技术人员应能理解上述设备1仅为举例，其他现有的或今后可能出现的设备1如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。
上述各装置之间是持续不断工作的，在此，本领域技术人员应理解“持续”是指上述各装置分别实时地或者按照设定的或实时调整的工作模式要求。
需要说明的是，在所述获取装置11中的待重放关系型数据库服务设备的备份集是存储待恢复的重放相关数据的关系型数据库中的一个备份集。当然，本领域技术人员应能理解上述获取装置11中的待重放关系型数据库服务设备的备份集仅为举例，其他现有的或今后可能出现的存储待恢复的重放相关数据的关系型数据库服务设备的备份集如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。
本申请的实施例中，在二进制日志重放过程中，首先所述获取装置11从待重放的关系型数据库服务设备的备份集获取待恢复的重放相关数据，其中，所述重放相关数据是待重放的关系型数据库服务设备的备份集待恢复的重放相关数据；在所述确定装置12中获取重放相关数据的重放起始位点，并获取从重放起始位点起至重放目标位点止的需重放的二进制日志，其中，所述重放目标位点为重方目标时间点所对应的位点。例如，从重放起始位点{mysql-bin.000005,11234}恢复到“2015-12-03 22：15：00”，即从文件名为mysql-bin.000005的二进制日志(binlog)的第11234字节开始，将应用binlog进行重放，将关系型数据库服务设备中的数据恢复到重放目标时间点“2015-12-03 22：15：00”处对应的binlog的重放目标位点处；在所述更新装置13中将二进制日志文件名规则的binlog以中继日志规则重命名并将重命名后的二进制日志存储在中继日志所在目录下，并更新相应中继日志位点信息文件和中继日志索引文件，例如，将将文件名为mysql-bin.xxxxx的binlog重命名为relay-log.xxxxx的中继日志(relay-log)，并将重命名后的binlog存储在中继日志所在目录下；在所述重放装置14中启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放，例如，关系型数据库服务设备(MySQL Server)提供关系型数据库系统中的数据库服务的程序，其中复制应用线程是通过应用binlog中的执行事件将通过备份集恢复出来的重放相关数据进行重放的，以使备份集所恢复的关系型数据库服务设备中的数据恢复至重放目标位点处所对应的数据库。
进一步地，所述确定装置12获取所述重放相关数据所对应的所述二进制日志的位点，将所述重放相关数据所对应的最后一个位点确定为所述重放起始位点。
在所述确定装置12中，若所述重放相关数据所对应的所述二进制日志的位点为{mysql-bin.000005,11230}，可知所述重放相关数据所对应的所述二进制日志的最后一个位点11230为所述需重放的二进制日志的重放起始位点。
进一步地，所述确定装置12获取从所述重放起始位点起的所有二进制日志；将所述所有二进制日志中对应所述重放起始位点之后的执行事件进行裁剪，以获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志。
例如，在所述确定装置12中，所述需重放的二进制日志(binlog)为以下三个binlog：mysql-bin.000004，mysql-bin.000005和mysql-bin.000006，其中所述需重放的binlog的重放起始位点为(mysql-bin.000004,1125)，用裁剪工具(例如mysqlbinlogtailor)对binlog进行剪裁，去掉最后一个binlog即mysql-bin.000006在'2015-06-12 16:22:11'之后的所有binlog及其对应的所有执行事件(event)，得到经过剪裁之后的需重放的binlog最后一个binlog的截止位点为(mysql-bin.000006,4385678)，即所述需重放的的binlog的重放目标位点为(mysql-bin.000006,4385678)，从而获取从所述重放起始位点(mysql-bin.000004,1125)起到所述重放目标位点(mysql-bin.000006,4385678)止的需重放的binlog。
再例如，在所述确定装置12中，有以下三个二进制日志(binlog)：mysql-bin.000004，mysql-bin.000005和mysql-bin.000006，其中，
mysql-bin.000004记录的是'2015-06-12 10:00:00'到'2015-06-1211:00:00'之间的binlog；
mysql-bin.000005记录的是'2015-06-12 11:00:00'到'2015-06-1212:00:00'之间的binlog；
mysql-bin.000006记录的是'2015-06-12 12:00:00'到'2015-06-1213:00:00'之间的binlog；若需要将数据库恢复到重放目标时间点'2015-06-1211:45:00'的时刻处，根据所述重放目标时间点可知不需要mysql-bin.000006这个binlog，只需用裁剪工具(例如mysqlbinlogtailor)将mysql-bin.000005中的所述重放目标时间点'2015-06-12 11:45:00'之后的执行事件(event)裁剪掉，得到从所述需重放的binlog的重放起始位点为(mysql-bin.000004,1125)起，到mysql-bin.000005中的重放目标时间点'2015-06-12 11:45:00'之前的event对应的binlog作为所述需重放的binlog。进一步地，mysql-bin.000005在重放目标时间点'2015-06-12 11:45:00'对应的位点为(mysql-bin.000005,2345639)，则经过裁剪工具裁剪之后的需重放的binlog也就是从所述重放起始位点(mysql-bin.000004,1125)起到所述重放目标位点(mysql-bin.000005,2345639)止的需重放的binlog。
进一步地，所述更新装置13基于中继日志规则中的文件名规则对所述需重放的二进制日志进行重命名；将所重命名的所述需重放的二进制日志存储至对应的中继日志所在的目录下，确定与所述需重放的二进制日志对应的中继日志；基于从所述重放起始位点起至重放目标位点止的所有位点，更新相应中继日志位点信息文件，将所述需重放的二进制日志对应的中继日志的路径追加至相应中继日志索引文件，并更新所述相应中继日志索引文件。
在本申请的上述实施例中，在所述更新装置13中，将二进制日志(binlog)按照中继日志(relay log)文件名规则进行重命名，然后将所重命名的所述需重放的binlog存储至对应的中继日志所在的目录下。例如，将上述需重放的三个binlog：mysql-bin.000004，mysql-bin.000005和mysql-bin.000006分别进行重命名后，并将需重放的三个binlog存储于对应的中继日志目录下，分别为:slave-relay.000003，slave-relay.000004和slave-relay.000005；并在relaylog索引文件下追加上述三个新加的relay log的路径，追加路径后的relay log索引文件如下：
/home/xiangluo.wb/db/10001/mysql/slave-relay.000001
/home/xiangluo.wb/db/10001/mysql/slave-relay.000002
/home/xiangluo.wb/db/10001/mysql/slave-relay.000003
/home/xiangluo.wb/db/10001/mysql/slave-relay.000004
/home/xiangluo.wb/db/10001/mysql/slave-relay.000005
基于从所述重放起始位点(mysql-bin.000004,1125)起至重放目标位点(mysql-bin.000006,4385678)止的所有位点，在相应中继日志位点信息文件(info文件)中更新重放起始位点为：
/home/xiangluo.wb/db/10001/mysql/slave-relay.000003//中继日志位点信息文件
1125//重放起始位点为1125
进一步地，所述重放装置14包括：
启动单元141(未示出)，用于启动关系型数据库系统中的复制应用线程；
重放单元142(未示出)，用于从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放。
在本申请的上述实施例中，在启动单元141(未示出)中启动关系型数据库服务器(MySQL server)，并通过启动命令(start slave sql_thread)启动复制应用线程(SQL线程)，从所述重放起始位点slave-relay.000003 1125开始，应用所有新追加的中继日志：slave-relay.000003，slave-relay.000004和slave-relay.000005，直至所述重放目标位点slave-relay.000005 4385678的字节位置，则所述需重放的二进制日志对应的中继日志完成重放。
进一步地，所述复制应用线程为单个，所述启动单元141(未示出)，用于利用所述复制应用线程串行执行所述中继日志的执行事件。
在本申请的上述实施例中，若需要进行重放的二进制日志的执行事件能在单个的复制应用线程(SQL线程)中很快重放完，则在启动单元141(未示出)只启动了一个复制应用线程(SQL线程)，如图2示出根据本申请一个方面的一种优选地关系型数据库二进制日志单线程串行重放的流程示意图。在图2中，若上述需重放的二进制日志(binlog)中共有8个执行事件(event)，分别为:{event 1、event 2、event 3、event 4、event 5、event 6、event 7和event8}，在启动的单个复制应用线程(SQL线程)中按照二进制日志中的执行事件从前到后的顺序依次对所有的8个执行事件进行重放。
进一步地，所述复制应用线程为多个，所述启动单元141(未示出)，用于利用多个所述复制应用线程并行执行所述中继日志的执行事件。
在本申请的上述实施例中，若需要进行重放的二进制日志的执行事件量比较大，在单个的复制应用线程(SQL线程)中需要很长的时间才能重放完，为了节省重放时间，提高重放的效率，则在启动单元141(未示出)中启动多个复制应用线程(SQL线程)，如图3示出根据本申请一个方面的一种优选地关系型数据库二进制日志多线程并行重放的流程示意图。在图3中，若上述需重放的二进制日志(binlog)中共有8个执行事件(event)，分别为:{event1、event 2、event 3、event 4、event 5、event 6、event 7和event 8}，在启动的多个复制应用线程(SQL线程)中可对需重放的二进制日志中的所有执行事件同时进行重放，以达到并行重放的目的，从而有效地提高重放效率。
进一步地，所述确定装置12获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志，所述需重放的二进制日志包括若干执行事件及相应执行事件的事件标识。
需要说明的是，执行事件的事件标识包括但不限于错误码。当然，本领域技术人员应能理解其他现有的或今后可能出现的用于标志所述执行事件的事件标识如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。
在本申请的实施例中，所述执行事件包括执行目标数据表、执行操作类型、执行位点以及事件标识。例如，若执行事件1(event1)为{表A、插入、35、error code＝0，则执行事件1表示从执行位点35开始对数据库中的表A执行插入的操作并且执行事件1的插入操作执行成功；若执行事件2(event2)为{表B、删除、65、error code＝1062，则执行事件2表示从执行位点65开始对数据库中的表B执行删除的操作并且执行事件2的删除操作执行失败。
进一步地，所述重放单元142(未示出)，用于解析所述中继日志以获取所述执行事件；执行每一所述执行事件，当所述执行事件执行失败，获取执行失败错误码与所需重放的二进制日志中对应事件的事件标识中的错误码进行比对，若相同，则不报错并继续执行下一执行事件，直至执行完所有执行事件。
例如，所述复制应用线程(SQL线程)能够解析中继日志目录下的二进制日志(binlog)得到需重放的二进制日志对应的所有的执行事件(event)，并通过启动命令(start slave sql_thread)开始对所有的执行事件进行重放，若在重放过程中执行event4时遇到执行失败的情况，SQL线程会记录下执行失败的错误码(error code)，并将所述执行失败的错误码(error code)与所需重放的二进制日志中对应事件(event4)的事件标识中的错误码进行比对，若两者记录的错误码相同，就不会出现报错，并继续执行下一个执行事件，直至执行完所有执行事件，避免了所述需重放的二进制日志重放时的出现重放失败，从而有效地提高了所述需重放的二进制日志重放时的成功概率。
图4示出根据本申请一个方面的一种关系型数据库二进制日志重放的方法的流程示意图。该方法包括步骤S11、步骤S12、步骤S13和步骤S14。
其中，所述步骤S11从待重放关系型数据库服务设备的备份集获取待恢复的重放相关数据；所述步骤S12获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志；所述步骤S13基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件；所述步骤S14启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放。
需要说明的是，在所述步骤S11中的待重放关系型数据库服务设备的备份集是存储待恢复的重放相关数据的关系型数据库中的一个备份集，与现有技术中的关系型数据库服务器中的数据库的备份集是一样的。当然，本领域技术人员应能理解上述步骤S11中的待重放关系型数据库服务设备的备份集仅为举例，其他现有的或今后可能出现的存储待恢复的重放相关数据的关系型数据库服务设备的备份集如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。
本申请的实施例中，在二进制日志重放过程中，首先所述步骤S11从待重放的关系型数据库服务设备的备份集获取待恢复的重放相关数据，其中，所述重放相关数据是待重放的关系型数据库服务设备的备份集待恢复的重放相关数据；在所述步骤S12中获取重放相关数据的重放起始位点，并获取从重放起始位点起至重放目标位点止的需重放的二进制日志，例如，从重放起始位点{mysql-bin.000005,11234}恢复到“2015-12-03 22：15：00”，即从文件名为mysql-bin.000005的二进制日志(binlog)的第11234字节开始，将应用binlog进行重放，将关系型数据库服务设备中的数据恢复到时间截点“2015-12-03 22：15：00”处对应的binlog的重放目标位点处；在所述步骤S13中将二进制日志文件名规则的binlog以中继日志规则重命名并将重命名后的二进制日志存储在中继日志所在目录下，并更新相应中继日志位点信息文件和中继日志索引文件，例如，将文件名为mysql-bin.xxxxx的binlog重命名为relay-log.xxxxx的中继日志(relay log)，并将重命名后的binlog存储在中继日志所在目录下；在所述步骤S14中启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放，例如，关系型数据库服务设备(MySQL Server)提供关系型数据库系统中的数据库服务的程序，其中复制应用线程是通过应用binlog中的执行事件将通过备份集恢复出来的重放相关数据进行重放的，以使备份集所恢复的关系型数据库服务设备中的数据恢复至重放目标位点处所对应的数据库。
进一步地，所述步骤S12基于所述重放相关数据获取重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志，其中，所述重放目标位点为重放目标时间点所对应的位点，具体地，所述步骤S12获取所述重放相关数据所对应的所述二进制日志的位点，将所述重放相关数据所对应的最后一个位点确定为所述重放起始位点。
在所述步骤S12中，若所述重放相关数据所对应的所述二进制日志的位点为{mysql-bin.000005,11230}，且所述重放相关数据所对应的所述二进制日志的最后一个位点11230的下一个位点是11235，则将位点{mysql-bin.000005,11235}确定为所述重放起始位点。
具体地，所述步骤S12获取从所述重放起始位点起的所有二进制日志；将所述所有二进制日志中对应所述重放起始位点之后的执行事件进行裁剪，以获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志。
例如，在所述步骤S12中，所述需重放的二进制日志(binlog)为以下三个binlog：mysql-bin.000004，mysql-bin.000005和mysql-bin.000006，其中所述需重放的binlog的重放起始位点为(mysql-bin.000004,1125)，用裁剪工具(例如mysqlbinlogtailor)对binlog进行剪裁，去掉最后一个binlog即mysql-bin.000006在'2015-06-12 16:22:11'之后的所有binlog及其对应的所有执行事件(event)，得到经过剪裁之后的需重放的binlog最后一个binlog的截止位点为(mysql-bin.000006,4385678)，即所述需重放的binlog的重放目标位点为(mysql-bin.000006,4385678)，从而获取从所述重放起始位点(mysql-bin.000004,1125)起到所述重放目标位点(mysql-bin.000006,4385678)止的需重放的binlog。
再例如，在所述步骤S12中，有以下三个二进制日志(binlog)：mysql-bin.000004，mysql-bin.000005和mysql-bin.000006，其中，
mysql-bin.000004记录的是'2015-06-12 10:00:00'到'2015-06-1211:00:00'之间的binlog；
mysql-bin.000005记录的是'2015-06-12 11:00:00'到'2015-06-1212:00:00'之间的binlog；
mysql-bin.000006记录的是'2015-06-12 12:00:00'到'2015-06-1213:00:00'之间的binlog；若需要将数据库恢复到重放目标时间点'2015-06-1211:45:00'的时刻处，根据所述重放目标时间点可知不需要mysql-bin.000006这个binlog，只需用裁剪工具(例如mysql binlogtailor)将mysql-bin.000005中的所述重放目标时间点'2015-06-12 11:45:00'之后的执行事件(event)裁剪掉，得到从所述需重放的binlog的重放起始位点为(mysql-bin.000004,1125)起，到mysql-bin.000005中的重放目标时间点'2015-06-12 11:45:00'之前的event对应的binlog作为所述需重放的binlog。进一步地，mysql-bin.000005在重放目标时间点'2015-06-12 11:45:00'对应的位点为(mysql-bin.000005,2345639)，则经过裁剪工具裁剪之后的需重放的binlog也就是从所述重放起始位点(mysql-bin.000004,1125)起到所述重放目标位点(mysql-bin.000005,2345639)止的需重放的binlog。
进一步地，所述步骤S13基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件，具体地，所述步骤S13基于中继日志规则中的文件名规则对所述需重放的二进制日志进行重命名；将所重命名的所述需重放的二进制日志存储至对应的中继日志所在的目录下，确定与所述需重放的二进制日志对应的中继日志；基于从所述重放起始位点起至重放目标位点止的所有位点，更新相应中继日志位点信息文件，将所述需重放的二进制日志对应的中继日志的路径追加至相应中继日志索引文件，并更新所述相应中继日志索引文件。
在本申请的上述实施例中，在所述步骤S13中，将二进制(binlog)日志二进制日志(binlog)按照中继日志(relay log)文件名规则进行重命名，然后将所重命名的所述需重放的binlog存储至对应的中继日志所在的目录下。例如，将上述需重放的三个binlog：mysql-bin.000004，mysql-bin.000005和mysql-bin.000006分别进行重命名后，并将需重放的三个binlog存储于对应的中继日志目录下，分别为:slave-relay.000003，slave-relay.000004和slave-relay.000005；并在relay log索引文件下追加上述三个新加的relay log的路径，追加路径后的relay log索引文件如下：
/home/xiangluo.wb/db/10001/mysql/slave-relay.000001
/home/xiangluo.wb/db/10001/mysql/slave-relay.000002
/home/xiangluo.wb/db/10001/mysql/slave-relay.000003
/home/xiangluo.wb/db/10001/mysql/slave-relay.000004
/home/xiangluo.wb/db/10001/mysql/slave-relay.000005
基于从所述重放起始位点(mysql-bin.000004,1125)起至重放目标位点(mysql-bin.000006,4385678)止的所有位点，在相应中继日志位点信息文件(info文件)中更新重放起始位点为：
/home/xiangluo.wb/db/10001/mysql/slave-relay.000003//中继日志位点信息文件
1125//重放起始位点为1125进一步地，所述步骤S14利用所述关系型数据库服务设备启动复制应用线程，并利用所述复制应用线程解析应用所述中继日志，以完成所述二进制日志的重放，具体地，所述步骤S14包括步骤S141(未示出)和步骤S142(未示出)，其中所述步骤S141(未示出)启动关系型数据库系统中的复制应用线程；所述步骤S142(未示出)从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放。
在本申请的上述实施例中，在步骤S141(未示出)中启动关系型数据库服务器(MySQL server)，并通过启动命令(start slave sql_thread)启动复制应用线程(SQL线程)，从所述重放起始位点slave-relay.000003 1125开始，应用所有新追加的中继日志：slave-relay.000003，slave-relay.000004和slave-relay.000005，直至所述重放目标位点slave-relay.000005 4385678的字节位置，则所述需重放的二进制日志对应的中继日志完成重放。
进一步地，所述复制应用线程为单个，所述步骤S141(未示出)利用所述复制应用线程串行执行所述中继日志的执行事件。
在本申请的上述实施例中，若需要进行重放的二进制日志的执行事件能在单个的复制应用线程(SQL线程)中很快重放完，则在启动单元141(未示出)只启动了一个复制应用线程(SQL线程)，如图2示出根据本申请一个方面的一种优选地关系型数据库二进制日志单线程串行重放的流程示意图。在图2中，若上述需重放的二进制日志(binlog)中共有8个执行事件(event)，分别为:{event 1、event 2、event 3、event 4、event 5、event 6、event 7和event8}，在启动的单个复制应用线程(SQL线程)中按照二进制日志中的执行事件从前到后的顺序依次对所有的8个执行事件进行重放。
进一步地，所述复制应用线程为多个，所述步骤S141(未示出)利用多个所述复制应用线程并行执行所述中继日志的执行事件。
在本申请的上述实施例中，若需要进行重放的二进制日志的执行事件量比较大，在单个的复制应用线程(SQL线程)中需要很长的时间才能重放完，为了节省重放时间，提高重放的效率，则在启动单元141(未示出)中启动多个复制应用线程(SQL线程)，如图3示出根据本申请一个方面的一种优选地关系型数据库二进制日志多线程并行重放的流程示意图。在图3中，若上述需重放的二进制日志(binlog)中共有8个执行事件(event)，分别为:{event1、event 2、event 3、event 4、event 5、event 6、event 7和event 8}，在启动的多个复制应用线程(SQL线程)中可对需重放的二进制日志中的所有执行事件同时进行重放，以达到并行重放的目的，从而有效地提高重放效率。
进一步地，所述步骤S12基于所述重放相关数据获取重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志，其中，所述重放目标位点为重方目标时间点所对应的位点，具体地，所述步骤S12获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志，所述需重放的二进制日志包括若干执行事件及相应执行事件的事件标识。
需要说明的是，执行事件的事件标识包括但不限于错误码。当然，本领域技术人员应能理解其他现有的或今后可能出现的用于标志所述执行事件的事件标识如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。
在本申请的实施例中，所述执行事件包括执行目标数据表、执行操作类型、执行位点以及事件标识。例如，若执行事件1(event1)为{表A、插入、35、succeed code}，则执行事件1表示从执行位点35开始对数据库中的表A执行插入的操作并且执行事件1的插入操作执行成功；若执行事件2(event2)为{表B、删除、65、error code}，则执行事件2表示从执行位点65开始对数据库中的表B执行删除的操作并且执行事件2的删除操作执行失败。
进一步地，所述步骤S142(未示出)从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放，具体地，所述步骤S142(未示出)解析所述中继日志以获取所述执行事件；执行每一所述执行事件，当所述执行事件执行失败，获取执行失败错误码与所需重放的二进制日志中对应事件的事件标识中的错误码进行比对，若相同，则不报错并继续执行下一执行事件，直至执行完所有执行事件。
例如，所述复制应用线程(SQL线程)能够解析中继日志目录下的二进制日志(binlog)得到需重放的二进制日志对应的所有的执行事件(event)，并通过启动命令(start slave sql_thread)开始对所有的执行事件进行重放，若在重放过程中执行event4时遇到执行失败的情况，SQL线程会记录下执行失败的错误码(error code)，并将所述执行失败的错误码(error code)与所需重放的二进制日志中对应事件(event4)的事件标识中的错误码进行比对，若两者记录的错误码相同，就不会出现报错，并继续执行下一个执行事件，直至执行完所有执行事件，避免了所述需重放的二进制日志重放时的出现重放失败，从而有效地提高了所述需重放的二进制日志重放时的成功概率。
图5示出根据本申请一个方面的一种关系型数据库二进制日志重放的方法的整体流程示意图。该方法包括步骤S51、步骤S52、步骤S53和步骤S54。
其中，所述步骤S51获取二进制日志(binlog)；所述步骤S52对二进制日志进行裁剪处理；所述步骤S53复制应用线程(SQL线程)读取应用；所述步骤S54重放所述需重放的二进制日志。
在所述步骤S51中获取二进制日志以使在所述步骤S12中对所述二进制日志进行裁剪；在所述步骤S12中基于重放起始位点和重放目标位点利用裁剪工具(例如binlogtailor)对在所述步骤S51中获取的二进制日志进行裁剪处理，并得到需重放的二进制日志；在所述步骤S53中将所述需重放的二进制日志进行重命名并存储于对应的中继日志(relay log)中，将存储需重放的二进制日志的新加的中继日志的路径追加到中继日志索引文件(relay-log.index)，并更新所述中继日志索引文件，基于所述重放起始位点起到所述重放目标位点止的二进制日志的位点更新中继日志位点文件(relay-log.info)；在所述步骤S54中通过启动命令(start slave sql_thread)对二进制日志进行解析得到需重放的二进制日志对应的所有的执行事件，并将所述所有执行事件应用到备份集所恢复的一关系型数据库系统，使得将数据库中的数据恢复到过去任意时间点的数据状态，进一步地，在所述步骤S54中若虚重放的二进制日志量大且所需的重放时间长的话，则启动多个结构化语句(SQL)线程，从而能够多线程并行执行需重放的二进制日志的所有执行事件，以达到并行重放的目的，从而有效地提高重放效率。
与现有技术相比，根据本申请的实施例所述的一种用于关系型数据库二进制日志重放的方法与设备，首先通过从待重放关系型数据库服务设备的备份集获取待恢复的重放相关数据，有效地基于从待重放关系型数据库服务设备的备份集中获取待恢复的重放相关数据对二进制日志进行重放；接着获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志，以得到经过剪裁后的需重放的二进制日志；然后基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件，使得在重放过程中能够对所述需重放的二进制日志进行重放；最后启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放，由于通过所述关系型数据库服务设备启动复制应用线程来解析应用所述需重放的二进制日志对应的中继日志，不走网络通信，因而重放过程不会受到关系型数据库系统网络协议的网络包大小的限制，有效地提高应用二进制日志进行重放的重放效率。
进一步地，根据本申请的实施例所述的一种用于关系型数据库二进制日志重放的方法与设备，通过启动关系型数据库系统中的复制应用线程；从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放，由于关系型数据库系统中的复制应用线程能够将重放二进制日志过程中出现的与执行失败有关的错误码与二进制日志中记录的错误码进行对比，若相同则不会报错并继续执行二进制日志中的下一执行事件，直至完成二进制日志的重放，避免了所述需重放的二进制日志重放时的出现重放失败，又由于可通过启动多个复制应用线程并行执行所述需重放的二进制日志对应的中继日志的执行事件，从而达到有效提高重放二进制日志的重放效率。
需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。
另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。
对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (18)

1.一种用于关系型数据库二进制日志重放的方法，其中，所述方法包括：
从待重放关系型数据库服务设备的备份集获取待恢复的重放相关数据；
获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志；
基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件；
启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放。
2.根据权利要求1所述的方法，其中，所述获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志包括：
获取所述重放相关数据所对应的所述二进制日志的位点，将所述重放相关数据所对应的最后一个位点确定为所述重放起始位点。
3.根据权利要求1所述的方法，其中，所述获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志包括：
获取从所述重放起始位点起的所有二进制日志；
将所述所有二进制日志中对应所述重放起始位点之后的执行事件进行裁剪，以获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志。
4.根据权利要求1至3中任一项所述的方法，其中，所述基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件包括：
基于中继日志规则中的文件名规则对所述需重放的二进制日志进行重命名；
将所重命名的所述需重放的二进制日志存储至对应的中继日志所在的目录下，确定与所述需重放的二进制日志对应的中继日志；
基于从所述重放起始位点起至重放目标位点止的所有位点，更新相应中继日志位点信息文件，将所述需重放的二进制日志对应的中继日志的路径追加至相应中继日志索引文件，并更新所述相应中继日志索引文件。
5.根据权利要求1至4中任一项所述的方法，其中，所述启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放包括：
启动关系型数据库系统中的复制应用线程；
从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放。
6.根据权利要求1至5中任一项所述的方法，其中，所述复制应用线程为单个，所述启动关系型数据库系统中的复制应用线程包括：
利用所述复制应用线程串行执行所述中继日志的执行事件。
7.根据权利要求1至6中任一项所述的方法，其中，所述复制应用线程为多个，所述启动关系型数据库系统中的复制应用线程包括：
利用多个所述复制应用线程并行执行所述中继日志的执行事件。
8.根据权利要求1至7中任一项所述的方法，其中，所述获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志包括：
获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志，所述需重放的二进制日志包括若干执行事件及相应执行事件的事件标识。
9.根据权利要求1至8中任一项所述的方法，其中，所述从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放包括：
解析所述中继日志以获取所述执行事件；
执行每一所述执行事件，当所述执行事件执行失败，获取执行失败错误码与所需重放的二进制日志中对应事件的事件标识中的错误码进行比对，若相同，则不报错并继续执行下一执行事件，直至执行完所有执行事件。
10.一种用于关系型数据库二进制日志重放的设备，其中，所述设备包括：
获取装置，用于从待重放关系型数据库服务设备的备份集中获取待恢复的重放相关数据；
确定装置，用于获取所述重放相关数据的重放起始位点，并获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志；
更新装置，用于基于中继日志规则将所述需重放的二进制日志存储于对应中继日志所在的目录下，并更新相应中继日志位点信息文件和中继日志索引文件；
重放装置，用于启动复制应用线程，解析并执行所述中继日志，以完成所述二进制日志的重放。
11.根据权利要求10所述的设备，其中，所述确定装置用于：
获取所述重放相关数据所对应的所述二进制日志的位点，将所述重放相关数据所对应的最后一个位点确定为所述重放起始位点。
12.根据权利要求10所述的设备，其中，所述确定装置用于：
获取从所述重放起始位点起的所有二进制日志；
将所述所有二进制日志中对应所述重放起始位点之后的执行事件进行裁剪，以获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志。
13.根据权利要求10至12中任一项所述的设备，其中，所述更新装置用于：
基于中继日志规则中的文件名规则对所述需重放的二进制日志进行重命名；
将所重命名的所述需重放的二进制日志存储至对应的中继日志所在的目录下，确定与所述需重放的二进制日志对应的中继日志；
基于从所述重放起始位点起至重放目标位点止的所有位点，更新相应中继日志位点信息文件，将所述需重放的二进制日志对应的中继日志的路径追加至相应中继日志索引文件，并更新所述相应中继日志索引文件。
14.根据权利要求10至13中任一项所述的设备，其中，所述重放装置包括：
启动单元，用于启动关系型数据库系统中的复制应用线程；
重放单元，用于从所述重放起始位点开始，将所述需重放的二进制日志对应的中继日志中的执行事件进行重放，直至所述需重放的二进制日志对应的中继日志完成重放。
15.根据权利要求10至14中任一项所述的设备，其中，所述复制应用线程为单个，所述启动单元用于：
利用所述复制应用线程串行执行所述中继日志的执行事件。
16.根据权利要求10至15中任一项所述的设备，其中，所述复制应用线程为多个，所述启动单元用于：
利用多个所述复制应用线程并行执行所述中继日志的执行事件。
17.根据权利要求10至16中任一项所述的设备，其中，所述确定装置用于：
获取从所述重放起始位点起至重放目标位点止的需重放的二进制日志，所述需重放的二进制日志包括若干执行事件及相应执行事件的事件标识。
18.根据权利要求10至17中任一项所述的设备，其中，所述重放单元用于：
解析所述中继日志以获取所述执行事件；
执行每一所述执行事件，当所述执行事件执行失败，获取执行失败错误码与所需重放的二进制日志中对应事件的事件标识中的错误码进行比对，若相同，则不报错并继续执行下一执行事件，直至执行完所有执行事件。
CN201610096150.6A 2016-02-22 2016-02-22 一种关系型数据库二进制日志重放的方法和设备 Active CN107102934B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610096150.6A CN107102934B (zh) 2016-02-22 2016-02-22 一种关系型数据库二进制日志重放的方法和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610096150.6A CN107102934B (zh) 2016-02-22 2016-02-22 一种关系型数据库二进制日志重放的方法和设备

Publications (2)

Publication Number Publication Date
CN107102934A true CN107102934A (zh) 2017-08-29
CN107102934B CN107102934B (zh) 2020-12-04

Family

ID=59658807

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610096150.6A Active CN107102934B (zh) 2016-02-22 2016-02-22 一种关系型数据库二进制日志重放的方法和设备

Country Status (1)

Country Link
CN (1) CN107102934B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109388523A (zh) * 2018-09-26 2019-02-26 四川巧夺天工信息安全智能设备有限公司 一种基于二进制日志文件恢复MySQL数据库的方法
CN110597725A (zh) * 2019-09-19 2019-12-20 浙江诺诺网络科技有限公司 一种Mysql的模拟返回方法、装置及设备
CN110674079A (zh) * 2019-09-10 2020-01-10 杭州数梦工场科技有限公司 日志文件记录方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101008957A (zh) * 2006-01-24 2007-08-01 国际商业机器公司 用于从备份数据映像建立数据库的方法和系统
US20120173490A1 (en) * 2010-12-30 2012-07-05 Verisign, Inc. Method and system for implementing business logic
CN103560906A (zh) * 2013-10-22 2014-02-05 珠海多玩信息技术有限公司 数据复制的方法及装置
CN104951474A (zh) * 2014-03-31 2015-09-30 阿里巴巴集团控股有限公司 一种用于获取MySQL binlog增量日志的方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101008957A (zh) * 2006-01-24 2007-08-01 国际商业机器公司 用于从备份数据映像建立数据库的方法和系统
US20120173490A1 (en) * 2010-12-30 2012-07-05 Verisign, Inc. Method and system for implementing business logic
CN103560906A (zh) * 2013-10-22 2014-02-05 珠海多玩信息技术有限公司 数据复制的方法及装置
CN104951474A (zh) * 2014-03-31 2015-09-30 阿里巴巴集团控股有限公司 一种用于获取MySQL binlog增量日志的方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
田关伟: "MySQL复制技术分析研究", 《哈尔滨师范大学自然科学学报》 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109388523A (zh) * 2018-09-26 2019-02-26 四川巧夺天工信息安全智能设备有限公司 一种基于二进制日志文件恢复MySQL数据库的方法
CN109388523B (zh) * 2018-09-26 2021-11-30 四川巧夺天工信息安全智能设备有限公司 一种基于二进制日志文件恢复MySQL数据库的方法
CN110674079A (zh) * 2019-09-10 2020-01-10 杭州数梦工场科技有限公司 日志文件记录方法和装置
CN110674079B (zh) * 2019-09-10 2022-07-12 杭州数梦工场科技有限公司 日志文件记录方法和装置
CN110597725A (zh) * 2019-09-19 2019-12-20 浙江诺诺网络科技有限公司 一种Mysql的模拟返回方法、装置及设备

Also Published As

Publication number Publication date
CN107102934B (zh) 2020-12-04

Similar Documents

Publication Publication Date Title
GB2575952A (en) Blockchain for open scientific research
US9183268B2 (en) Partition level backup and restore of a massively parallel processing database
CN106844089B (zh) 一种用于恢复树形数据存储的方法与设备
CN111399873A (zh) 一种模型更新方法及装置
CN106233259A (zh) 在分散存储网络中检索多世代存储数据
CN111125298A (zh) 重建ntfs文件目录树的方法、设备及存储介质
CN107102934A (zh) 一种关系型数据库二进制日志重放的方法和设备
WO2007068600B1 (en) Generating backup sets to a specific point in time
CN110058969B (zh) 一种数据恢复方法及装置
CN105068887B (zh) 一种基于被损坏SQLServer数据库的数据恢复方法
CN103699548A (zh) 一种通过使用日志恢复数据库数据的方法及设备
CN103177022A (zh) 一种恶意文件搜索方法及装置
CN110795614A (zh) 一种索引自动优化方法及装置
US9836360B2 (en) Recovery strategy with dynamic number of volumes
CN109992476B (zh) 一种日志的分析方法、服务器及存储介质
CN107209707A (zh) 基于云的分级系统保存
CN107301186B (zh) 一种无效数据的识别方法及装置
US7801859B1 (en) Tracking filesystem backups
Du et al. Deduplicated disk image evidence acquisition and forensically-sound reconstruction
WO2016206395A1 (zh) 周报信息处理方法及装置
CN104391945B (zh) 数据库文件数据索引的处理方法和装置
CN110245037A (zh) 一种基于日志的Hive用户操作行为还原方法
CN110489432B (zh) 基于模型的数据库自动同步方法、介质、设备及装置
US11734232B2 (en) Initial baselines of file systems
Christopher et al. SCHEMADB: Structures in relational datasets

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant