CN116226093B - 基于双活高可用架构的实时数据库系统 - Google Patents

Abstract

本发明利用API模块、第一实时数据库、第二实时数据库三者之间建立有效的通信连接，同时有效利用缓存和时间戳的配合，有效实现了主数据库和备数据库之间的丝滑过渡，真正做到了“双活高可用”。进一步，本发明提出基于双活高可用的实时数据库系统，可以彻底避免单点故障问题，提升系统的容灾能力，提高系统的可用性，保障业务的持续可用，业务中断时间从几分钟~几十分钟不等优化到1秒以内，保证数据零丢失，可以使用户因为系统故障带来的业务损失几乎为零。

Description

基于双活高可用架构的实时数据库系统

技术领域

本发明涉及信息处理技术，更具体地，涉及一种基于双活高可用架构的实时数据库系统。

背景技术

实时数据库主要用于收集运动系统（如工业现场）中大量的、快速变化的数据，并对数据进行采集、处理、记录、共享。实时数据以时间为主坐标轴，所以实时数据库往往要对时间字段做了大量优化以适应快速存储与检索。实时数据库是数据库系统发展的一个分支，它适于处理不断快速变化的时间序列数据。因此可以说，实时数据库技术是实时系统和数据库技术相结合的产物。

由此可见，实时数据库至少具备两个特点，其一，“海纳百川”，存储的数据量往往较大，甚至是海量的数据量；其二，“与时俱新”，往往随着时间的推进不断更新变化。正是由于这些特点，如果只配备单独一台服务器来承载实时数据库，那就犹如达摩克利斯之剑悬于头上，风险将无时无刻不在。一旦如此单独一台服务器出现“三长两短”，则实时数据库的所有历史数据可能丧失，当前正在实时记录的数据也可能戛然而止。

因此，为增强数据安全性，很有必要在主机承载实时数据库的同时也提供备机来实时共享对应数据，由此确保主机“趴窝”时，备机能够及时侦测到主机故障还能随时作为后备军顶上。正所谓“宁可备而不用，不可用而不备”。

然而，目前市面上的主备机系统往往无法保证实时数据库在主机“趴窝”时的实时性要求。一旦主机出现故障，要完成设备向备机的切换，需要完成设备切换、备机实时数据库启动就绪等一系列操作，如此备机才可能进行替代服务。而实时数据库在软件中可谓“重量级选手”，是重型复杂软件，相应地，其启动时间较长，也因此导致备机切换过程中长时间的业务中断，中途需要等待个把小时并不鲜见。而对于很多敏感性重要行业的工业控制而言，不用说中断待机个把小时，就算仅仅中断几秒钟都会造成巨大损失。

因此，在主机故障时，备机的即插即用、丝滑过渡，成为了负责数据库安全维护的技术人员梦寐以求的理想状态。

发明内容

本发明提供的一种基于双活高可用架构的实时数据库系统，恰恰是安全维护人员所孜孜以求，确保即使在主机故障时，主备机之间仍能做到丝滑过渡，数据的安全性和实时性均能得到最大保障。

具体而言，本发明提供一种基于双活高可用架构的实时数据库系统，其特征在于：包括应用程序、第一实时数据库、第二实时数据库、API模块，应用程序通过所述API模块分别连接至第一实时数据库和第二实时数据库，第一实时数据库包含第一网络通信服务、第一标签点信息服务、第一快照数据服务、第一历史数据服务，第二实时数据库包含第二网络通信服务、第二快照数据服务、第二历史数据服务，第一网络通信服务负责第一实时数据库与API模块之间的网络通信，第二网络通信服务负责第二实时数据库与API模块之间的网络通信，第一网络通信服务与第二网络通信服务也形成相互间的通信连接，所述实时数据库系统执行如下数据写入流程：应用程序通过API模块写入数据，所写入的数据形成数据包，该数据包被API模块发往第一实时数据库，同时在API模块处将所写入的数据进行本地缓存形成缓存数据；一旦向第一实时数据库成功写入数据，则第一实时数据库将写入成功信号反馈至API模块，API模块则再将该写入成功信号反馈至应用程序，进而，第一实时数据库通过第一网络通信服务向第二实时数据库的第二网络通信服务同步写入的数据，由此使得第二实时数据库具有与写入的数据同步的数据；一旦向第一实时数据库写入数据不成功，则第一实时数据库将写入不成功信号反馈至API模块，API模块收到写入不成功信号的反馈之后立即切换至第二实时数据库，首先将API模块中的缓存数据写入第二实时数据库，然后再将要写入的数据写入第二实时数据库，一旦第二实时数据库的数据写入成功，第二实时数据库将写入成功信号反馈至API模块，API模块再向应用程序反馈写入成功信号。

优选地，一旦向第二实时数据库的数据写入亦不成功，则第二实时数据库反馈写入不成功信号至API模块，API模块则接着将写入不成功信号反馈至应用程序，此时应用程序将收到第一和第二实时数据库的写入不成功信号，此时由应用程序来自行决定后续操作。

更优选地，API模块采用其内存进行缓存，API模块与所述第一和第二实时数据库中的任一数据库的每一次连接都建立起一次独立缓存，用于缓存API最近写入所述任一数据库的数据，一旦缓存占满内存则随着后期数据的存入陆续释放前期数据。

优选地，所述实时数据库系统还能执行查询流程，在查询流程中，应用程序通过API模块向实时数据库查询数据，API模块首先将查询请求发送至第一实时数据库，当第一实时数据库查询成功时，第一实时数据库反馈查询成功信号以及查询结果数据集至API模块，API模块再向应用程序反馈查询成功信号以及查询结果数据集，如果第一实时数据库查询不成功，则第一实时数据库反馈查询不成功信号至API模块，API模块将查询操作切换连接至第二实时数据库，再将查询请求发往第二实时数据库，第二实时数据库反馈查询成功信号及查询结果数据集至API模块，API模块向应用程序反馈查询成功信号及查询结果数据集。

更优选地，若查询第二实时数据库不成功，则第二实时数据库反馈查询不成功信号至API模块，API模块则返回查询不成功信号给应用程序，此时第一和第二实时数据库均无法查询，由应用程序决定后续处理策略。

优选地，所述实时数据库系统还执行数据恢复流程，在数据恢复流程中，一旦第二实时数据库出现故障停止启动时，第二实时数据库中的历史数据服务与第一实时数据库中的历史数据服务建立连接，接着，第二实时数据库扫描本地磁盘上存储数据在故障停止前记录的最终时间戳，获取第一实时数据库当前时刻存储数据记录的最新时间戳，依据这两个时间戳确定需要恢复数据的时间范围，随后，第二实时数据库的历史数据服务从第一实时数据库的历史数据服务中获取上述时间范围内的数据并保存到本地磁盘。

更优选地，在第二实时数据库恢复磁盘数据的期间，第一实时数据库的网络通信服务缓存这期间入库的数据，待第二实时数据库的历史数据服务恢复数据后，第二实时数据库的网络通信服务开始接收第一实时数据库的网络通信服务所缓存的数据，直到第二实时数据库完全与第一实时数据库保存实时同步，第二实时数据库开始对外提供数据服务。

优选地，在第一和第二实时数据库中均增加WAL日志，当第一和第二实时数据库中的任一实时数据库对其中的元数据进行修改时，元数据的修改结果写入对应实时数据库的缓存之中，且元数据的修改记录写入对应的WAL日志之中。

更优选地，在第一和第二实时数据库之间实现元数据的全量同步，在全量同步中，第一实时数据库直接读取所有元数据，并通过第一和第二实时数据库这两个数据库之间的网络通信连接，同步到第二实时数据库中。

更优选地，在全量同步结束后，开启增量同步的操作，其中，首先对第一实时数据库和第二实时数据库各自的WAL日志的最新更新版本进行比较，如果两个实时数据库的WAL日志的最新更新版本相互一致，则每一次针对第一和第二实时数据库中的任一数据库的元数据修改操作，直接通过网络通信服务连接同步到对方数据库，如果任一数据库中的WAL日志最大版本大于对方数据库，则由同步线程将WAL日志先同步到对方数据库中，期间所有的修改操作，放入同步队列中，WAL日志同步完毕后，同步线程继续将队列中的数据同步到对方数据库。

本发明利用API模块、第一实时数据库、第二实时数据库三者之间建立有效的通信连接，同时有效利用缓存和时间戳的配合，有效实现了主数据库和备数据库之间的丝滑过渡，真正做到了“双活高可用”。进一步，本发明提出基于双活高可用的实时数据库系统，可以彻底避免单点故障问题，提升系统的容灾能力，提高系统的可用性，保障业务的持续可用，业务中断时间从几分钟~几十分钟不等优化到1秒以内，保证数据零丢失，可以使用户因为系统故障带来的业务损失几乎为零。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，以下将对实施例或现有技术描述中所需要使用的附图进行论述，显然，在结合附图进行描述的技术方案仅仅是本发明的一些实施例，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图所示实施例得到其它的实施例及其附图。

图1示出了根据本发明的基于双活高可用架构的实时数据库系统的基本框架图；

图2示出了根据本发明的基于双活高可用架构的实时数据库系统的数据写入流程示意图；

图3示出了根据本发明的基于双活高可用架构的实时数据库系统的数据查询流程示意图；

图4示出了根据本发明的基于双活高可用架构的实时数据库系统的数据恢复流程示意图。

具体实施方式

以下将结合附图对本发明各实施例的技术方案进行清楚完整描述，显然，所描述的实施例仅为本发明的一部分实施例，而不是全部实施例。基于本发明中所述的实施例，本领域普通技术人员在不需要创造性劳动的前提下所得到的所有其它实施例，都在本发明所保护的范围内。

一言以蔽之，本发明所提供的基于双活高可用架构的实时数据库系统，能够确保两个实时数据库之间做到实时的有效的实时数据交流，在此情况下，即使其中一个实时数据库出现故障，另一个实时数据库亦能够随时启用，从而做到两个实时数据库之间的丝滑切换。本发明所涉“双活”即是如此内涵。下文中将对此进行详细描述。

具体而言，本发明提供一种基于双活高可用架构的实时数据库系统。图1示出了根据本发明的基于双活高可用架构的实时数据库系统的基本框架图。如图1所示，所述实时数据库系统包括第一实时数据库、第二实时数据库、应用程序编程接口模块（即，图1中所示的API模块）。

如图1可见，应用程序通过所述API模块连接至第一和第二实时数据库。而第一和第二实时数据库，何谓主，何谓备，则可以由API模块按照IP递增排序进行选取。在本文中，为方便描述，选取第一实时数据库为主数据库，第二实时数据库为备数据库。而实际上这两个数据库之间的主备关系是可以相互调换的。

API模块在其中作为应用编程接口，可以基于多种语言实现，例如基于C++语言来实现。

在运行时，应用程序将其写入的数据包发给API模块，API模块将该数据包写入第一实时数据库内，一旦写入成功，则第一实时数据库将反馈回写入成功信号。同时，第一实时数据库与第二实时数据库也同步通信，由此，第一实时数据库也与第二实时数据库同步所述数据包。

优选地，在数据查询时，应用程序将查询请求发给API模块，API模块将该查询请求发给第一实时数据或第二实时数据库，收到查询请求的第一或第二实时数据库再将所需查询的数据包返回给API模块。

如图1可见，第一实时数据库包含第一网络通信服务、第一标签点信息服务、第一快照数据服务、第一历史数据服务，第二实时数据库包含第二网络通信服务、第二快照数据服务、第二历史数据服务。

第一网络通信服务负责第一实时数据库与API模块之间的网络通信，换言之，网络通信服务就如同实时数据库的“传达室”。API模块可向第一实时数据库发出数据写入和查询请求，而第一网络通信服务则将该数据写入和查询请求转发给第一快照数据服务和第一历史数据服务。

第一快照数据服务管理“当下”，负责管理数据库内的实时快照数据，而随着时间推移，过去的“实时”自然变成了现在的“历史”用于存档，由此形成的历史存档数据则由第一历史数据服务负责管理。

如图1所示，第一实时数据库还包含标第一签点信息服务。如同人与人之间利用姓名、身份证号等等标记区别还进行有效区分，实时数据库中的数据与数据之间则利用各自的标签点信息进行有效区分，第一标签点信息服务就负责管理第一实时数据库中的各数据的标签点信息。在图1中，API模块可向第一实时数据库发送元数据增删改查请求，该增删改查请求仍然通过“传达室”—第一网络通信服务转发给第一标签点信息服务。

类似地，在第二实时数据库中，第二网络通信服务也作为“传达室”负责第二实时数据库与API模块之间的网络通信，API模块可向第二实时数据库发出数据写入和查询请求，而第二网络通信服务则将该数据写入和查询请求转发给第二快照数据服务和第二历史数据服务。第二快照数据服务负责管理第二实时数据库内的实时快照数据，第二历史存档数据则负责管理第二实时数据库中的历史存档数据。API模块可向第二实时数据库发送元数据增删改查请求，该增删改查请求通过第二网络通信服务转发给第二标签点信息服务。

以上描述是对本发明所提供的基于双活高可用架构的实时数据库系统的框架描述，下文将详细描述在上述框架下的数据写入流程、数据查询流程、数据恢复流程。

图2示出了根据本发明的基于双活高可用架构的实时数据库系统的数据写入流程示意图。

如图2所示，数据写入流程是本发明中的基础流程，在优选状况下可以对分别写入两个实时数据库是否成功进行判定并基于判定决定接下来的操作。

如图2所示，数据写入流程，自然有成功，也有不成功，写入成功的子流程为：应用程序通过API模块写入数据，所写入的数据形成数据包，该数据包被API模块发往第一实时数据库，同时在API模块处本地缓存所写入数据的数据副本。一旦第一实时数据库的数据写入成功，则第一实时数据库将写入成功信号反馈至API模块，API模块则再将该写入成功信号反馈至应用程序。进而，第一实时数据库通过网络通信服务向第二实时数据库同步写入的数据，由此保证第二实时数据库的数据同步性和完整性。

而写入不成功的子流程为：一旦第一实时数据库写入不成功，第一实时数据库将写入不成功信号反馈至API模块，API模块收到写入不成功信号的反馈之后立即切换至第二实时数据库，首先将API模块中缓存的数据写入第二实时数据库，然后再将本次要写入的数据写入第二实时数据库，缓存数据的写入确保了第二实时数据库不会在切换过程中出现数据损失，并确保本次要写入的数据能及时写入备数据库，由此确保数据的及时性。

一旦第二实时数据库的数据写入成功，第二实时数据库将写入成功信号反馈至API模块，API模块再向应用程序反馈写入成功信号，由此在第一实时数据库出现故障的情况下，确保了应用程序、API模块、第二实时数据库这一条数据存储备用线的及时畅通。

一旦写入第二实时数据库亦不成功，则第二实时数据库反馈写入不成功信号至API模块，API模块则接着将写入不成功信号反馈至应用程序，此时应用程序将收到第一和第二实时数据库的写入不成功信号，此时由应用程序来自行决定后续操作。

优选的是，API模块采用其内存进行缓存，API模块与其对应的实时数据库的每一次连接都建立起一次独立缓存，用于缓存API最近写入实时数据库的数据，一旦缓存占满则随着后期数据的存入陆续释放前期数据，该独立缓存的容量并不大，但该缓存可以确保两个实时数据库在切换时备数据库接收数据的及时性。

图3示出了根据本发明的基于双活高可用架构的实时数据库系统的数据查询流程示意图。

如图3所示，在查询流程中，应用程序通过API模块向实时数据库查询数据，API模块首先将查询请求发送至第一实时数据库，当第一实时数据库查询成功时，第一实时数据库反馈查询成功信号以及查询结果数据集至API模块，API模块再向应用程序反馈查询成功信号以及查询结果数据集。

如果第一实时数据库查询不成功，第一实时数据库反馈查询不成功信号至API模块，API模块将查询操作切换连接至第二实时数据库，再将本次查询请求发往第二实时数据库，第二实时数据库反馈查询成功信号及查询结果数据集至API模块，API模块向应用程序反馈查询成功信号及查询结果数据集。

若查询第二实时数据库不成功时，则第二实时数据库反馈查询不成功信号至API模块，API模块则返回查询不成功信号给应用程序，此时第一和第二实时数据库均无法查询，由应用程序决定后续处理策略。

由此可见，数据查询流程实际上与图2所示的数据写入流程相似，关键区别在于，数据写入流程为了确保数据写入的及时性，需要调动API模块的缓存功能，而数据查询则不要求数据及时性，因此不涉及API模块的缓存功能。

图4示出了根据本发明的基于双活高可用架构的实时数据库系统的数据恢复流程示意图。

如图4所示，在数据恢复流程中，一旦第二实时数据库出现故障停止启动时，第二实时数据库中的历史数据服务与第一实时数据库中的历史数据服务建立连接。

接着，第二实时数据库扫描本地磁盘上存储数据在故障停止前记录的最终时间戳，获取第一实时数据库当前时刻存储数据记录的最新时间戳，依据这两个时间戳确定需要恢复数据的时间范围。

随后，第二实时数据库的历史数据服务从第一实时数据库的历史数据服务中获取上述时间范围内的数据并保存到本地磁盘。

在第二实时数据库恢复磁盘数据的期间，第一实时数据库的网络通信服务缓存这期间入库的数据，待第二实时数据库的历史数据服务恢复数据后，第二实时数据库的网络通信服务开始接收第一实时数据库的网络通信服务所缓存的数据，直到第二实时数据库完全与第一实时数据库保存实时同步，第二实时数据库开始对外提供数据服务。

行文至此，本文已经详细描述了根据本发明的基于双活高可用架构的实时数据库系统的框架结构和三个基本流程（写入流程、查询流程、恢复流程）。如上文所述可知，本发明利用API模块、第一实时数据库、第二实时数据库三者之间建立有效的通信连接，同时有效利用缓存和时间戳的配合，有效实现了主数据库和备数据库之间的丝滑过渡，真正做到了“双活高可用”。

进一步，本发明提出基于双活高可用的实时数据库系统，可以彻底避免单点故障问题，提升系统的容灾能力，提高系统的可用性，保障业务的持续可用，业务中断时间从几分钟~几十分钟不等优化到1秒以内，保证数据零丢失，可以使用户因为系统故障带来的业务损失几乎为零。

另一方面，本发明所提供的基于双活高可用架构的实时数据库系统还可以做到元数据同步。元数据又称中介数据，是描述数据的数据。在本发明的实时数据库系统的双活模式下，主备数据库双机运行，应用程序在操作元数据的过程中，当任一实时数据库发生故障导致切换的时候，元数据需保证同步。

具体而言，可在第一和第二实时数据库中均增加WAL日志，当任一实时数据库对其中的元数据进行修改时，元数据的修改结果写入对应实时数据库的缓存之中，且元数据的修改记录写入对应的WAL日志之中。

在两个实时数据库之间实现元数据同步，本发明可考虑两种同步方式：全量同步和增量同步。

在全量同步操作中，第一实时数据库直接读取所有元数据，并通过两个数据库之间的网络通信连接，同步到第二实时数据库中。如果在全量同步期间，元数据有修改操作，则中断同步。

在全量同步结束后，可开启增量同步的操作。

在增量同步操作中，首先对第一实时数据库和第二实时数据库各自的WAL日志的最新更新版本进行比较，如果两个实时数据库的WAL日志的最新更新版本相互一致，则每一次针对任意实时数据库的元数据修改操作，直接通过网络通信服务连接同步到对方数据库。

而如果WAL日志最大版本大于对方数据库，则由同步线程将WAL日志先同步到对方数据库中。期间所有的修改操作，放入同步队列中。WAL日志同步完毕后，同步线程继续将队列中的数据同步到对方数据库。

以上所述仅为本发明的示例性实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种基于双活高可用架构的实时数据库系统，其特征在于：包括应用程序、第一实时数据库、第二实时数据库、API模块，应用程序通过所述API模块分别连接至第一实时数据库和第二实时数据库，第一实时数据库包含负责第一实时数据库与API模块之间的网络通信的第一网络通信服务，第二实时数据库包含负责第二实时数据库与API模块之间的网络通信的第二网络通信服务，第一网络通信服务与第二网络通信服务相互间通信连接，

在所述实时数据库系统中，应用程序通过API模块写入数据，所写入的数据形成数据包，该数据包被API模块发往第一实时数据库，同时在API模块处将所写入的数据进行本地缓存形成缓存数据；

一旦向第一实时数据库成功写入数据，则第一实时数据库将写入成功信号反馈至API模块，API模块则再将该写入成功信号反馈至应用程序，进而，第一实时数据库通过第一网络通信服务向第二网络通信服务同步写入的数据，由此使得第二实时数据库具有与写入的数据同步的数据；

一旦向第一实时数据库写入数据不成功，则第一实时数据库将写入不成功信号反馈至API模块，API模块收到写入不成功信号的反馈之后立即切换至第二实时数据库，将API模块中的缓存数据写入第二实时数据库，

一旦第二实时数据库的数据写入成功，第二实时数据库将写入成功信号反馈至API模块，API模块再向应用程序反馈写入成功信号。

2.根据权利要求1所述的基于双活高可用架构的实时数据库系统，其特征在于，所述第一实时数据库还包括第一标签点信息服务、第一快照数据服务、第一历史数据服务，所述第二实时数据库还包括第二快照数据服务、第二历史数据服务。

3.根据权利要求2所述的基于双活高可用架构的实时数据库系统，其特征在于，一旦向第二实时数据库的数据写入亦不成功，则第二实时数据库反馈写入不成功信号至API模块，API模块则接着将写入不成功信号反馈至应用程序，此时应用程序将收到第一和第二实时数据库的写入不成功信号，此时由应用程序来自行决定后续操作。

4.根据权利要求1-3中任一项所述的基于双活高可用架构的实时数据库系统，其特征在于，API模块采用其内存进行缓存，API模块与所述第一和第二实时数据库中的任一数据库的每一次连接都建立起一次独立缓存，用于缓存API最近写入所述任一数据库的数据，一旦缓存占满内存则随着后期数据的存入陆续释放前期数据。

5.根据权利要求1所述的基于双活高可用架构的实时数据库系统，其特征在于，所述实时数据库系统还能执行查询流程，在查询流程中，应用程序通过API模块向实时数据库查询数据，API模块首先将查询请求发送至第一实时数据库，当第一实时数据库查询成功时，第一实时数据库反馈查询成功信号以及查询结果数据集至API模块，API模块再向应用程序反馈查询成功信号以及查询结果数据集，

如果第一实时数据库查询不成功，则第一实时数据库反馈查询不成功信号至API模块，API模块将查询操作切换连接至第二实时数据库，再将查询请求发往第二实时数据库，第二实时数据库反馈查询成功信号及查询结果数据集至API模块，API模块向应用程序反馈查询成功信号及查询结果数据集。

6.根据权利要求5所述的基于双活高可用架构的实时数据库系统，其特征在于，若查询第二实时数据库不成功，则第二实时数据库反馈查询不成功信号至API模块，API模块则返回查询不成功信号给应用程序，此时第一和第二实时数据库均无法查询，由应用程序决定后续处理策略。

7.根据权利要求2所述的基于双活高可用架构的实时数据库系统，其特征在于，所述实时数据库系统还执行数据恢复流程，在数据恢复流程中，一旦第二实时数据库出现故障停止启动时，第二实时数据库中的历史数据服务与第一实时数据库中的历史数据服务建立连接，

接着，第二实时数据库扫描本地磁盘上存储数据在故障停止前记录的最终时间戳，获取第一实时数据库当前时刻存储数据记录的最新时间戳，依据这两个时间戳确定需要恢复数据的时间范围，

随后，第二实时数据库的历史数据服务从第一实时数据库的历史数据服务中获取上述时间范围内的数据并保存到本地磁盘。

8.根据权利要求7所述的基于双活高可用架构的实时数据库系统，其特征在于，在第二实时数据库恢复磁盘数据的期间，第一实时数据库的网络通信服务缓存这期间入库的数据，待第二实时数据库的历史数据服务恢复数据后，第二实时数据库的网络通信服务开始接收第一实时数据库的网络通信服务所缓存的数据，直到第二实时数据库完全与第一实时数据库保存实时同步，第二实时数据库开始对外提供数据服务。

9.根据权利要求2所述的基于双活高可用架构的实时数据库系统，其特征在于，在第一和第二实时数据库中均增加WAL日志，当第一和第二实时数据库中的任一实时数据库对其中的元数据进行修改时，元数据的修改结果写入对应实时数据库的缓存之中，且元数据的修改记录写入对应的WAL日志之中。

10.根据权利要求9所述的基于双活高可用架构的实时数据库系统，其特征在于，在第一和第二实时数据库之间实现元数据的全量同步，在全量同步中，第一实时数据库直接读取所有元数据，并通过第一和第二实时数据库这两个数据库之间的网络通信连接，同步到第二实时数据库中，

在全量同步结束后，开启增量同步的操作，其中，首先对第一实时数据库和第二实时数据库各自的WAL日志的最新更新版本进行比较，如果两个实时数据库的WAL日志的最新更新版本相互一致，则每一次针对第一和第二实时数据库中的任一数据库的元数据修改操作，直接通过网络通信服务连接同步到对方数据库，

如果任一数据库中的WAL日志最大版本大于对方数据库，则由同步线程将WAL日志先同步到对方数据库中，期间所有的修改操作，放入同步队列中，WAL日志同步完毕后，同步线程继续将队列中的数据同步到对方数据库。