CN113377582B - 基于日志推送的分布式数据库容灾方法 - Google Patents
基于日志推送的分布式数据库容灾方法 Download PDFInfo
- Publication number
- CN113377582B CN113377582B CN202110934890.3A CN202110934890A CN113377582B CN 113377582 B CN113377582 B CN 113377582B CN 202110934890 A CN202110934890 A CN 202110934890A CN 113377582 B CN113377582 B CN 113377582B
- Authority
- CN
- China
- Prior art keywords
- log
- transaction
- pushing
- database cluster
- transaction log
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
- G06F11/1464—Management of the backup or restore process for networked environments
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
Abstract
本发明公开了一种基于日志推送的分布式数据库容灾方法,属一种数据库容灾的方法,方法包括在客户端通过主数据库集群中进行事务的操作时,主数据库集群启动事务日志同步线程,同步将当前事务的操作记录为事务日志;将所述事务日志发送给日志推送实例,由日志推送实例将所述事务日志推送至备数据库集群的事务日志表中等步骤;本发明相对于MySQL数据库中备数据库集群从主数据库集群拉取事务日志而言,节约了拉取时间,让主备数据库集群数据同步更加高效;并且在主备数据库集群进行数据推送的过程中,可针对异常情况进行处理,保证了主备数据库集群事务日志一致性,有效减少了主备数据库集群数据不一致的风险。
Description
技术领域
本发明涉及一种数据库容灾的方法,更具体的说,本发明主要涉及一种基于日志推送的分布式数据库容灾方法。
背景技术
在数据库分布式数据库领域,容灾技术对于客户来说至关重要,所以一直是领域研究的热门方向之一。目前主流的主备数据库集群数据同步方案都与MySQL主备数据库集群数据同步类似,MySQL数据库主要由三种同步方案,分别为异步复制、半同步复制与全同步复制,前述的三种方式均存在各自的不足,在异步复制中,binlog日志记录在主数据库集群,备数据库集群需要从主数据库集群拉取binlog日志进行回放。假如备数据库集群没有拉取到主数据库集群上的binlog数据之前主数据库集群出现故障,那么binlog日志会丢失,主备数据库集群数据出现不同步的情况。在半同步复制中,binlog日志记录在主数据库集群,备数据库集群需要从主数据库集群拉取binlog日志进行回放。尽管主数据库集群会等待至少一个备数据库集群将bilog数据写入到replay log中后才返回给客户端,但是当存在多个备数据库集群的情况下,也存在主备数据库集群数据不会同步的情况。在全同步复制中,binlog日志记录在主数据库集群,备数据库集群需要从主数据库集群拉取binlog日志进行回放。主数据库集群执行完客户端提交的事务后会等待所有备数据库集群接收到写入replay log中才返回给客户端,不存在主备数据库集群数据不一致的情况,但是由于主数据库集群需要等待所有备数据库集群都回放完成返回后才返回给客户端,所以性能很差。因此MySQL数据库这种将binlog日志记录在主数据库集群上存在一定丢失的风险,尽管全同步复制的策略可以保证主备数据库集群数据是一致的,但是采用全同步复制性能会很差,而且全同步复制也是将binlog日志记录在主数据库集群,备数据库集群需要从主数据库集群拉取数据,然后备数据库集群进行binlog日志回放操作。因而有必要针对数据库的容灾技术做进一步的研究和改进。
发明内容
本发明的目的之一在于针对上述不足,提供一种基于日志推送的分布式数据库容灾方法,以期望解决现有技术中MySQL的主备数据库集群数据复制需从主数据库集群拉取事务日志,在主数据库集群出现故障时日志容易丢失,造成主备数据库集群数据不会同步,亦或为了保持数据库同步性而影响数据库的性能等技术问题。
为解决上述的技术问题,本发明采用以下技术方案:
本发明提供了一种基于日志推送的分布式数据库容灾方法,所述的方法包括如下步骤:
步骤A、在客户端通过主数据库集群中进行事务的操作时,主数据库集群启动事务日志同步线程,同步将当前事务的操作记录为事务日志;
步骤B、将所述事务日志发送给日志推送实例,由日志推送实例将所述事务日志推送至备数据库集群的事务日志表中;如推送成功,则将推送成功的信息返回至当前事务,当前事务提交返回至客户端;如推送失败,则重试至少一次,如仍推送失败,日志推送实例则将当前事务日志推送到事务日志缓存队列中进行存储。
优选的是,上述的方法还包括步骤C、当日志推送实例重试仍推送事务日志失败时,主数据库集群通过事务日志表探测线程,探测备数据库集群的事务日志表是否可推送数据进入;如探测结果为是,则启动另一个事务日志同步线程,将当前日志缓存队列中存储的当前事务日志推送至备数据库集群的事务日志表中,且在推送失败且重试后仍失败时,重复步骤C;如探测结果为否,则将当前事务日志暂存至日志缓存队列中。
作为优选,进一步的技术方案是:所述的方法还包括步骤D、备数据库集群的事务日志回放线程在接收到日志推送实例推送的事务日志时,事务日志回放线程立即读取事务日志进行回放。
更进一步的技术方案是:所述日志推送实例在主数据库集群首次接收到客户端事务的操作时,进行初始化,然后进入正常状态。
本发明还提供了另一种基于日志推送的分布式数据库容灾方法,其特征在于所述的方法包括如下步骤:
步骤A、在客户端通过主数据库集群中进行事务的操作时,主数据库集群启动事务日志同步线程,同步将当前事务的操作记录为事务日志;
步骤B、将所述事务日志发送给日志推送实例,由推送实例将所述事务日志推送至用于存储事务日志的安全队列中,然后将执行结果返回给当前事务,当前事务提交返回给客户端;再由日志推送实例同步或陆续的将安全队列中的事务日志的推送至备数据库集群的事务日志表中;如推送失败,则重试至少一次,如仍推送失败,日志推送实例则将当前事务日志推送到事务日志缓存队列中进行存储。
作为优选,进一步的技术方案是:步骤B中,日志推送实例启用flush线程,每间隔单位时间将安全队列中的事务日志推送至备数据库集群的事务日志表中;或者安全队列存储满后,再由日志推送实例启用flush线程将安全队列中的事务日志推送至备数据库集群的事务日志表中。
更进一步的技术方案是:所述的方法还包括步骤C、当日志推送实例重试仍推送事务日志失败时,主数据库集群通过事务日志表探测线程,探测备数据库集群的事务日志表是否可推送数据进入;如探测结果为是,则启动另一个事务日志同步线程,将当前日志缓存队列中存储的当前事务日志推送至备数据库集群的事务日志表中,且在推送失败且重试后仍失败时,重复步骤C;如探测结果为否,则将当前事务日志暂存至日志缓存队列中。
更进一步的技术方案是:所述的方法还包括步骤D、备数据库集群的事务日志回放线程在接收到日志推送实例推送的事务日志时,事务日志回放线程立即读取事务日志进行回放。
更进一步的技术方案是:所述日志推送实例在主数据库集群首次接收到事务的操作时,进行初始化,然后进入正常状态。
与现有技术相比,本发明的有益效果之一是:通过利用分布式数据库中主数据库集群中的日志推送实例,将客户端对事务的操作生成为事务日志,推送至备数据库集群的事务日志表中,相对于MySQL数据库中备数据库集群从主数据库集群拉取事务日志而言,节约了拉取时间,让主备数据库集群数据同步更加高效;并且在主备数据库集群进行数据推送的过程中,可针对异常情况进行处理,保证了主备数据库集群事务日志一致性,有效减少了主备数据库集群数据不一致的风险。
附图说明
图1为用于说明本发明的逻辑流程图。
图2为用于说明本发明一个实施例的处理流程图。
图3为用于说明本发明另一个实施例的处理流程图。
具体实施方式
本发明基于对分布式数据容灾技术的研究,在数据库***中实现了主数据库数据实时同步到备数据库的两种解决方案,分别为最大可靠模式与最大性能模式。两种模式的处理方式如图1所示。在主数据库集群中进行事务操作时,主数据库集群日志推送实例会直接将事务日志实时推送到备数据库集群的事务日志表中,备数据库集群上启动事务日志回放线程读取事务日志表中的数据,然后对事务操作进行实时回放,使得主备数据库集群达到数据实时同步状态。另外针对异常情况下,采用缓存技术手段存储事务日志,而且不影响主数据库集群上事务提交操作,极大程度保障了主备数据库集群的数据一致性。正如本说明书背景技术所提到的,对于主备数据库数据同步方案,目前主流数据库实现的技术都是在主库中先将事务操作存储在主数据库集群上,然后备数据库上会启动拉取线程从主数据库集群上拉取事务操作进行回放操作。与之不同的是,在主数据库上事务操作的时候,直接将事务日志推送到备数据库事务日志表中,省去了备数据库集群从主数据库集群上拉去事务日志的操作,缩短了主备数据库集群事务日志同步的时间,降低了主备数据库数据不同步的概率。
基于主数据库集群将事务日志推送到备数据库集群事务日志表的技术手段,也实现了最大可靠以及最大性能主备数据库集群数据同步模式。在最大可靠模式下,主数据库集群伴随事务操作会产生事务日志,主数据库集群事务操作会等待事务日志推送到备数据库集群事务日志表后才返回提交成功。在最大性能模式下,主数据库集群伴随事务产生时会产生事务日志,事务日志会被主数据库集群上生成的日志推送实例写入一个安全队列中,然后事务提交。安全队列中的数据会被主数据库集群的日志推送实例定时推送到备数据库集群事务日志表中。当然,本发明也实现了日志回放功能,即备数据库集群上可以开启事务日志的实时回放功能,当主数据库集群上的事务日志被日志推送实例推送到备数据库集群事务日志表中后,备数据库集群上的事务回放线程会实时读取到事务日志表中的数据并实时回放,主备数据库集群的数据就会实时一致。
下面结合附图对本发明作进一步阐述。
现以一个主数据库集群与一个备数据库集群举例进行说明,且在本方法实施时,还需要满足如下几个前提条件:
一是为了达到将主数据库集群事务日志推送到备数据库集群事务日志表中,需要基于两个集群环境信息做好配置工作;二是为了达到主备数据库集群数据实时同步,备数据库集群需要开启基于事务日志的实时回放功能;三是由于本申请实现的是分布式数据库下主备数据库集群的同步,在分布式数据库中每个节点的功能几乎一摸一样,所以下述的内容都是以单个节点举例说明。
参考图2所示,基于上述的介绍,本发明的第一实施例是上述的最大可靠模式,在该模式下,基于日志推送的分布式数据库容灾方法按照如下步骤进行:
步骤S11、在客户端通过主数据库集群中进行事务的操作时,主数据库集群启动事务日志同步线程,同步将当前事务的操作记录为事务日志。
步骤S12、将所述事务日志发送给日志推送实例,由日志推送实例将所述事务日志推送至备数据库集群的事务日志表中;在本步骤中,日志推送实例在主数据库集群首次接收到客户端事务的操作时,进行初始化,然后进入正常状态。
如推送成功,则将推送成功的信息返回至当前事务,当前事务提交返回至客户端;如推送失败,则重试至少一次(例如将其设置为三次),如仍推送失败,日志推送实例则将当前事务日志推送到事务日志缓存队列中进行存储。
上述的步骤结束后,主备数据库集群即完成事务日志推送,基于上述的方法,还可继续进行如下步骤。
步骤S13、当日志推送实例重试仍推送事务日志失败时,主数据库集群通过事务日志表探测线程,探测备数据库集群的事务日志表是否可推送数据进入。
如探测结果为是,则启动另一个事务日志同步线程,将当前日志缓存队列中存储的当前事务日志推送至备数据库集群的事务日志表中,且在推送失败且重试后仍失败时,重复步骤S13。如探测结果为否,则将当前事务日志暂存至日志缓存队列中。
进一步的,继续进行步骤S14、备数据库集群的事务日志回放线程在接收到日志推送实例推送的事务日志时,事务日志回放线程立即读取事务日志进行回放。
基于本实施例上述的步骤,更为具体的是,在最大可靠模式下:主备数据库集群根据备数据库集群信息配置主数据库集群事务日志推送到备数据库集群,备数据库集群需要打开事务日志回放功能。
主数据库集群上执行事务的过程中,主数据库集群上事务日志推送实例在第一次事务操作时进行初始化工作,初始化时实例状态为正常状态,事务操作在提交前会同步将操作记录成事务日志,事务日志会发送给主数据库集群上的日志推送实例,主数据库集群上日志推送实例会对事务日志进行处理。主数据库集群上事务需要等待日志推送实例将事务日志数据推送到备数据库集群事务日志表中后才返回给客户端。
主数据库集群上日志推送实例拿到事务日志后,会将事务日志直接推入到备数据库集群事务日志表中,然后将推送成功的信息返回给事务,事务就会正常提交返回给客户端。
如果主数据库集群日志推送实例将事务日志推送到备数据库集群事务日志表中失败,日志推送实例会重试3次,假如3次重试后事务日志还是不能正常推送到备数据库集群事务日志表中,那么主数据库集群日志推送实例会进入到缓存状态,事务日志会推送到事务日志缓存队列中进行存储。事务正常提交返回给客户端,同时主数据库集群会启用事务日志表探测线程去探测备数据库集群事务日志表是否可推送数据进入,如果数据可推送写入,那么主数据库集群会启用另外的一个事务日志同步线程将事务日志缓存队列中的数据推送到备数据库集群事务日志表中,日志推送实例也会从缓存状态切换回正常状态。
备数据库集群上由于启用了事务日志回放功能,那么事务日志回放线程会实时监控自身集群上事务日志表中是否有数据写入,如果有事务日志写入,事务日志回放线程马上读取事务日志进行回放,这样主备数据库集群数据能保证数据一致。
在本实施例中,最大可靠模式下主备数据库集群数据同步具有如下特点:一是主备数据库集群正常情况下,主数据库集群事务日志通过日志推送实例实时推送到备数据库集群事务日志表中,备数据库集群没有从主数据库集群上拉取事务日志操作,节约了数据拉取的时间。如果备数据库集群开启实时事务日志回放功能,主备数据库集群数据实时一致。二是备数据库集群异常情况下,主数据库集群事务不会受到影响,主数据库集群事务日志记录会推送到主数据库集群上的事务日志缓存队列中,事务日志缓存队列为主数据库集群磁盘上存储事务日志的空间,主备数据库集群数据会出现短暂不一致情况,等待备数据库集群恢复正常,主数据库集群上的事务日志会被推送到备数据库集群事务日志表中,主备数据库集群之间数据又会实时同步,不会出现主数据库集群数据丢失。三是由于主备数据库集群之间数据是实时同步,所以会带来一定的性能损耗,但是由于是分布式数据库,所以事务的损耗会比单机数据库小很多。
参考图3所示,本发明的第二实施例是上述的最大性能模式,在该模式下,基于日志推送的分布式数据库容灾方法按照如下步骤进行。
步骤S21、在客户端通过主数据库集群中进行事务的操作时,主数据库集群启动事务日志同步线程,同步将当前事务的操作记录为事务日志。
步骤S22、将所述事务日志发送给日志推送实例,由推送实例将所述事务日志推送至用于存储事务日志的安全队列中,然后将执行结果返回给当前事务,当前事务提交返回给客户端;再由日志推送实例同步或陆续的将安全队列中的事务日志的推送至备数据库集群的事务日志表中。
如推送失败,则重试至少一次,如仍推送失败,日志推送实例则将当前事务日志推送到事务日志缓存队列中进行存储。
同时,与上述实施例相同的是,日志推送实例在主数据库集群首次接收到事务的操作时,进行初始化,然后进入正常状态。
具体的是,在本步骤中,日志推送实例启用flush线程,每间隔单位时间将安全队列中的事务日志推送至备数据库集群的事务日志表中;或者安全队列存储满后,再由日志推送实例启用flush线程将安全队列中的事务日志推送至备数据库集群的事务日志表中。
上述的步骤结束后,主备数据库集群即完成事务日志推送,基于上述的方法,还可继续进行如下步骤。
步骤S23、当日志推送实例重试仍推送事务日志失败时,主数据库集群通过事务日志表探测线程,探测备数据库集群的事务日志表是否可推送数据进入。
如探测结果为是,则启动另一个事务日志同步线程,将当前日志缓存队列中存储的当前事务日志推送至备数据库集群的事务日志表中,且在推送失败且重试后仍失败时,重复步骤S23;如探测结果为否,则将当前事务日志暂存至日志缓存队列中。
进一步的,继续进行步骤S24、备数据库集群的事务日志回放线程在接收到日志推送实例推送的事务日志时,事务日志回放线程立即读取事务日志进行回放。
基于本实施例上述的步骤,在最大性能模式下,更为具体的是:主备数据库集群根据备数据库集群信息配置主数据库集群事务日志推送到备数据库集群,备数据库集群需要打开事务日志回放功能。
主数据库集群上执行事务的过程中,主数据库集群上日志推送实例会在第一次事务操作时进行初始化工作,初始化后实例状态为正常状态,事务操作在提交前会同步将操作记录事务日志,事务日志会发送给主数据库集群上日志推送实例进行处理,日志推送实例拿到事务数据后,将事务日志推送到主数据库集群上存储事务日志的安全队列中,然后将执行结果返回给事务,事务返回给客户端。主数据库集群上事务不会等待事务日志推送到备数据库集群事务日志表中才返回给客户端。
当主数据库集群上日志推送实例拿到事务日志后,会将事务日志推送到安全队列中,安全队列是内存中存储事务日志的缓存区,有两种机制会将安全队列中的事务日志推送到备数据库集群事务日志表中。一种是日志推送实例会启用flush线程,每20毫秒将安全队列中的数据推送到备数据库集群上事务日志表中,注意flush推送时间可配置;一种是当安 全队列满的情况下,安全队列中数据也会被flush线程推送到备数据库集群事务日志表中,注意安全队列的大小也是可配置的。
如果主数据库集群日志推送实例中的flush线程将事务日志推送到备数据库集群事务日志表中失败,日志推送实例会进行3次重试,假如3次重试后推送还是失败,那么主数据库集群日志推送实例会进入到缓存状态, 事务日志会推送到事务日志缓存队列中进行存储。事务正常提交返回给客户端,同时主数据库集群会启用事务日志表探测线程去探测备数据库集群事务日志表是否可推送数据进入,如果数据可推送写入,那么主数据库集群会启用另外的一个事务日志同步线程将事务日志缓存队列中的数据推送到备数据库集群事务日志表中,日志推送实例也会从缓存状态切换回正常状态。
备数据库集群上由于启用了事务日志回放功能,那么事务日志回放线程会实时监控自身集群上事务日志表中是否有数据写入,如果有事务日志写入,事务日志回放线程马上读取事务日志进行回放,这样主备数据库集群数据能保证数据一致。
在本实施例中,最大性能模式下主备数据库集群数据同步具有如下特点:一是主备数据库集群正常情况,主数据库集群上事务日志短暂存储在主数据库集群上,然后主数据库集群上日志推送实例中flush线程将会将事务日志推送到备数据库集群事务日志表中,备数据库集群没有从主数据库集群上进行事务日志拉取操作,节约了数据拉取的时间。如果备数据库集群开启实时回放功能的前提下,主备数据库集群数据实时一致。二是备数据库集群异常情况下,主数据库集群事务不会受到影响,主数据库集群事务日志记录会被日志推送实例中flush线程推送到主数据库集群上的事务日志缓存队列中,事务日志缓存队列为主数据库集群磁盘上存储事务日志的空间,主备数据库集群数据会出现短暂不一致情况,等待备数据库集群恢复正常,主数据库集群上的事务日志会被推送到备数据库集群事务日志表中,主备数据库集群之间数据又会同步,不会出现主数据库集群数据丢失。三是在最大性能模式下,引入安全队列技术解决了性能问题,且配合异常处理机制,主备数据库集群数据几乎达到实时同步。
基于本发明上述的实施例可知,本发明对于现有技术贡献的关键之一是将主数据库集群事务操作产生的事务日志会由主数据库集群直接推送到备数据库集群上事务日志表中,节约了备数据库集群从主数据库集群上拉取事务日志的时间,推出了主数据库集群将事务日志推送到备数据库集群的技术创新点,综合对比性能影响和异常情况下数据一致性的情况,实现了最大性能模式、最大可靠模式下的主备数据库集群数据同步技术方案。从而节约了备数据库集群从主数据库集群拉取事务日志的时间,让主备数据库集群数据同步更加高效。另外两种基于主数据库集群推送事务日志到备数据库集群的事务日志表的方案中,针对异常的情况进行了处理,极大程度上保证了主备数据库集群事务日志一致性,大大减少了主备数据库集群数据不一致的风险。
除上述以外,还需要说明的是在本说明书中所谈到的“一个实施例”、“另一个实施例”、“实施例”等,指的是结合该实施例描述的具体特征、结构或者特点包括在本申请概括性描述的至少一个实施例中。在说明书中多个地方出现同种表述不是一定指的是同一个实施例。进一步来说,结合任一实施例描述一个具体特征、结构或者特点时,所要主张的是结合其他实施例来实现这种特征、结构或者特点也落在本发明的范围内。
尽管这里参照本发明的多个解释性实施例对本发明进行了描述,但是,应该理解,本领域技术人员可以设计出很多其他的修改和实施方式,这些修改和实施方式将落在本申请公开的原则范围和精神之内。更具体地说,在本申请公开、附图和权利要求的范围内,可以对主题组合布局的组成部件和/或布局进行多种变型和改进。除了对组成部件和/或布局进行的变型和改进外,对于本领域技术人员来说,其他的用途也将是明显的。
Claims (7)
1.一种基于日志推送的分布式数据库容灾方法,其特征在于所述的方法包括如下步骤:
步骤A、在客户端通过主数据库集群中进行事务的操作时,主数据库集群启动事务日志同步线程,同步将当前事务的操作记录为事务日志;
步骤B、将所述事务日志发送给日志推送实例,由日志推送实例将所述事务日志推送至备数据库集群的事务日志表中;
如推送成功,则将推送成功的信息返回至当前事务,当前事务提交返回至客户端;如推送失败,则重试至少一次,如仍推送失败,日志推送实例则将当前事务日志推送到事务日志缓存队列中进行存储;并将事务提交返回至客户端;
步骤C、当日志推送实例重试仍推送事务日志失败时,主数据库集群通过事务日志表探测线程,探测备数据库集群的事务日志表是否可推送数据进入;
如探测结果为是,则启动另一个事务日志同步线程,将当前日志缓存队列中存储的当前事务日志推送至备数据库集群的事务日志表中,且在推送失败且重试后仍失败时,重复步骤C;
如探测结果为否,则将当前事务日志暂存至日志缓存队列中。
2.根据权利要求1所述的基于日志推送的分布式数据库容灾方法,其特征在于:所述的方法还包括步骤D、备数据库集群的事务日志回放线程在接收到日志推送实例推送的事务日志时,事务日志回放线程立即读取事务日志进行回放。
3.根据权利要求1所述的基于日志推送的分布式数据库容灾方法,其特征在于:所述日志推送实例在主数据库集群首次接收到客户端事务的操作时,进行初始化,然后进入正常状态。
4.一种基于日志推送的分布式数据库容灾方法,其特征在于所述的方法包括如下步骤:
步骤A、在客户端通过主数据库集群中进行事务的操作时,主数据库集群启动事务日志同步线程,同步将当前事务的操作记录为事务日志;
步骤B、将所述事务日志发送给日志推送实例,由日志推送实例将所述事务日志推送至用于存储事务日志的安全队列中,然后将执行结果返回给当前事务,当前事务提交返回给客户端;再由日志推送实例同步或陆续的将安全队列中的事务日志的推送至备数据库集群的事务日志表中;
如推送失败,则重试至少一次,如仍推送失败,日志推送实例则将当前事务日志推送到事务日志缓存队列中进行存储;
步骤C、当日志推送实例重试仍推送事务日志失败时,主数据库集群通过事务日志表探测线程,探测备数据库集群的事务日志表是否可推送数据进入;
如探测结果为是,则启动另一个事务日志同步线程,将当前日志缓存队列中存储的当前事务日志推送至备数据库集群的事务日志表中,且在推送失败且重试后仍失败时,重复步骤C;
如探测结果为否,则将当前事务日志暂存至日志缓存队列中。
5.根据权利要求4所述的基于日志推送的分布式数据库容灾方法,其特征在于:所述步骤B中,日志推送实例启用flush线程,每间隔单位时间将安全队列中的事务日志推送至备数据库集群的事务日志表中;或者安全队列存储满后,再由日志推送实例启用flush线程将安全队列中的事务日志推送至备数据库集群的事务日志表中。
6.根据权利要求4或5所述的基于日志推送的分布式数据库容灾方法,其特征在于:所述的方法还包括步骤D、备数据库集群的事务日志回放线程在接收到日志推送实例推送的事务日志时,事务日志回放线程立即读取事务日志进行回放。
7.根据权利要求4所述的基于日志推送的分布式数据库容灾方法,其特征在于:所述日志推送实例在主数据库集群首次接收到事务的操作时,进行初始化,然后进入正常状态。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110934890.3A CN113377582B (zh) | 2021-08-16 | 2021-08-16 | 基于日志推送的分布式数据库容灾方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110934890.3A CN113377582B (zh) | 2021-08-16 | 2021-08-16 | 基于日志推送的分布式数据库容灾方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113377582A CN113377582A (zh) | 2021-09-10 |
CN113377582B true CN113377582B (zh) | 2021-11-05 |
Family
ID=77577273
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110934890.3A Active CN113377582B (zh) | 2021-08-16 | 2021-08-16 | 基于日志推送的分布式数据库容灾方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113377582B (zh) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114780293A (zh) * | 2022-04-26 | 2022-07-22 | 北京科杰科技有限公司 | 基于hadoop的异地双活容灾方法、装置、设备和可读存储介质 |
CN114579671A (zh) * | 2022-05-09 | 2022-06-03 | 高伟达软件股份有限公司 | 集群间数据同步方法及装置 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109766219A (zh) * | 2015-07-23 | 2019-05-17 | 深圳市沃信科技有限公司 | 一种数据库容灾*** |
CN106897288B (zh) * | 2015-12-18 | 2021-01-08 | 阿里巴巴集团控股有限公司 | 数据库的服务提供方法和*** |
US10216588B2 (en) * | 2016-11-22 | 2019-02-26 | Sap Se | Database system recovery using preliminary and final slave node replay positions |
CN108319543A (zh) * | 2018-01-24 | 2018-07-24 | 广州江南科友科技股份有限公司 | 一种计算机日志数据的异步处理方法及其介质、*** |
CN110807062B (zh) * | 2018-08-02 | 2021-06-22 | 中兴通讯股份有限公司 | 一种数据同步的方法、装置和数据库主机 |
-
2021
- 2021-08-16 CN CN202110934890.3A patent/CN113377582B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN113377582A (zh) | 2021-09-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113377582B (zh) | 基于日志推送的分布式数据库容灾方法 | |
US7499954B2 (en) | Consistent reintegration of a failed primary instance | |
US7254686B2 (en) | Switching between mirrored and non-mirrored volumes | |
US10114710B1 (en) | High availability via data services | |
US10235375B1 (en) | Persistent file system objects for management of databases | |
KR0128271B1 (ko) | 재해회복을 위한 일관성 그룹 형성방법 및 레코드갱싱의 섀도잉 방법, 주시스템, 원격데이타 섀도잉 시스템과 비동기 원격데이타 복제 시스템 | |
US7539703B2 (en) | Setup method for disaster recovery system | |
JP2708386B2 (ja) | 同時更新及び複写手順を通して重複データベースを回復させる方法及び装置 | |
US8051328B1 (en) | Recovering from a system failure | |
US7487311B2 (en) | System and method for asynchronous backup of virtual disks in a distributed storage array | |
US9189348B2 (en) | High availability database management system and database management method using same | |
JP4282030B2 (ja) | データ二重化制御方法および二重化した記憶サブシステム | |
US20040193658A1 (en) | Disaster recovery processing method and apparatus and storage unit for the same | |
JPH07239799A (ja) | 遠隔データ・シャドーイングを提供する方法および遠隔データ二重化システム | |
US7853571B2 (en) | Techniques for file system recovery | |
US20090070528A1 (en) | Apparatus, system, and method for incremental resynchronization in a data storage system | |
WO2017041616A1 (zh) | 数据读写方法及装置、双活存储***及其实现方法 | |
WO2014059804A1 (zh) | 数据同步方法及*** | |
CN102955720A (zh) | 一种提高ext文件***稳定性的方法 | |
WO2016095372A1 (zh) | 实现事务日志镜像备份的方法及装置 | |
WO2019020081A1 (zh) | 分布式***及其故障恢复方法、装置、产品和存储介质 | |
US8799216B1 (en) | Mirror resynchronization of bulk load and append-only tables during online transactions for better repair time to high availability in databases | |
US9087115B1 (en) | Mirror resynchnronization of fixed page length tables for better repair time to high availability in databases | |
CN114238353A (zh) | 一种分布式事务的实现方法及*** | |
CN110121694A (zh) | 一种日志管理方法、服务器和数据库*** |
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 |