CN117971981A - 分布式数据库系统下的热备方法、装置和电子设备 - Google Patents

Abstract

本申请涉及一种分布式数据库系统下的热备方法、装置和电子设备，包括接收待处理写入事务，将所述待处理写入事务的状态信息添加至预设日志中，判断所述预设日志是否能读取所述待处理写入事务，在所述预设日志中含有预设标志记录时，判定可以读取所述待处理写入事务。通过本发明，可以利用大量闲置的Mirror节点基于MVCC的方式提供读服务，通过负载均衡，能够降低Primary节点的负载，使系统具备更高的稳定性和延迟，同时增加系统的整体吞吐，加速查询业务，提高了系统的资源利用率。

Description

分布式数据库系统下的热备方法、装置和电子设备

技术领域

本申请涉及互联网基础设施技术领域，尤其涉及一种分布式数据库系统下的热备方法、装置和电子设备。

背景技术

现有技术中，在PostgreSQL数据库中存在一种高可用实现，一台主数据库(又称primary database)提供读写服务，通过WAL日志记录，把数据变更同步到另外一台从库(又称mirror database)，然后从库不断地应用从主库接收的WAL日志记录，从库只提供读服务，不提供写服务。从库接收主库数据的同时又能提供读服务，当主库出现故障时，可以切换到从库，并提供读写服务，这种高可用方案叫做Hot Standby。

这种高可用方案，既能在主数据库出现故障时，快速切换到从库，保证数据库系统的可用性；同时从库还能对外提供查询服务，降低主库的负载，提高数据库系统的整体利用率。

PostgreSQL的Hot Standby方案是在单机数据库上实现的，对于基于PostgreSQL构建的分布式数据库来说，在分布式环境下，每个单机数据库实例都有自己的本地事务，主备之间的WAL同步进度也不一定相同,所以单机的Hot Standby方案无法直接应用在分布式数据库上。

在MPP分布式数据库中一般有Coordinator(协调服务)和Executor(执行服务)两种角色，为了保证任何一个角色出现故障时系统依然可用，都会有相应角色的Mirror节点存在，分布式系统的节点数一般都很多，在支持传统Standby方案的分布式数据库中，大量的Mirror节点在数据库系统正常工作时，都处于空闲状态，存在大量的资源闲置。在分布式数据库系统中引入Hot Standby方案，让Mirror节点支持读操作，可以提升数据库系统的性能和资源利用率。

发明内容

有鉴于此，本申请提出了一种分布式数据库系统下的热备方法，以解决上述背景技术所体现的问题。

根据本申请的一方面，提供了一种分布式数据库系统下的热备方法，包括：

接收待处理写入事务；

将所述待处理写入事务的状态信息添加至预设日志中；

判断所述预设日志是否能读取所述待处理写入事务；

在所述预设日志中含有预设标志记录时，判定可以读取所述待处理写入事务。

作为本申请的一种可选实施方案，将所述待处理写入事务的状态信息添加至预设日志中，包括：

建立第一分布式快照信息；

将所述待处理写入事务的运行记录添加到所述第一分布式快照信息中，在所述第一分布式快照信息中根据所述运行记录得到待处理写入事务的状态信息；

将所述待处理写入事务的状态信息添加至预设日志。

作为本申请的一种可选实施方案，判断所述预设日志是否能读取所述待处理写入事务，包括：

建立第二分布式快照信息；

读取所述预设日志中所述待处理写入事务的状态信息，根据所述状态信息在所述第二分布式快照信息中更新所述待处理写入事务的状态信息；

根据待处理写入事务的状态信息判断是否能读取所述待处理写入事务。

作为本申请的一种可选实施方案，还包括：

接收读取事务请求；

根据所述读取事务请求得到对应数据的事务ID；

根据所述事务ID判断所述读取事务请求能否读取所述对应数据。

作为本申请的一种可选实施方案，根据所述事务ID判断所述读取事务请求能否读取所述对应数据，包括：

根据事务ID判断所述对应数据的属性；

在所述对应数据的属性为数据可见时，所述读取事务请求能读取所述对应数据。

作为本申请的一种可选实施方案，还包括：

在所述对应数据的属性为数据不可见时，所述读取事务请求不能读取所述对应数据。

作为本申请的一种可选实施方案，根据事务ID判断所述对应数据的属性，包括：

获取ID序列表；

获取所述读取事务请求的读取事务ID；

所述事务ID小于所述ID序列表中的最小ID或所述事务ID等于所述读取事务ID且所述事务ID位于所述ID序列表中时，所述对应数据的属性为数据可见。

作为本申请的一种可选实施方案，还包括：

所述事务ID大于所述ID序列表中的最大ID或所述事务ID不等于所述读取事务ID且所述事务ID位于所述ID序列表中时，所述对应数据的属性为数据不可见。

本申请还提供了一种分布式数据库系统下的热备装置，包括以下模块：

接收写入事务模块，用于接收待处理写入事务；

更新状态信息模块，用于将所述待处理写入事务的状态信息添加至预设日志中；

判断模块，用于判断所述预设日志是否能读取所述待处理写入事务；

读取模块，用于在所述预设日志中含有预设标志记录时，判定可以读取所述待处理写入事务。

本申请还提供了一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述可执行指令时实现上述所述的分布式数据库系统下的热备方法。

本申请的有益效果：

本发明通过接收待处理写入事务，将所述待处理写入事务的状态信息添加至预设日志中，判断所述预设日志是否能读取所述待处理写入事务，在所述预设日志中含有预设标志记录时，判定可以读取所述待处理写入事务。可以利用大量闲置的Mirror节点基于MVCC的方式提供读服务，通过负载均衡，能够降低Primary节点的负载，使系统具备更高的稳定性和延迟，同时增加系统的整体吞吐，加速查询业务，提高了系统的资源利用率。

根据下面参考附图对示例性实施例的详细说明，本申请的其它特征及方面将变得清楚。

附图说明

包含在说明书中并且构成说明书的一部分的附图与说明书一起示出了本申请的示例性实施例、特征和方面，并且用于解释本申请的原理。

图1示出本申请实施例的分布式数据库系统下的热备方法的流程图；

图2示出本申请实施例的分布式数据库系统下的热备方法的分布式事务流程图；

图3示出本申请实施例的分布式数据库系统下的热备方法的接收读请求流程图；

图4示出本申请实施例的分布式数据库系统下的热备装置框图。

具体实施方式

以下将参考附图详细说明本申请的各种示例性实施例、特征和方面。附图中相同的附图标记表示功能相同或相似的元件。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

其中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”、“顺时针”、“逆时针”、“轴向”、“径向”、“周向”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请或简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。

另外，为了更好的说明本申请，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本申请同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本申请的主旨。

热备通常指的是在设备或系统出现故障或需要维护时，另一台备用设备能够立即接管工作并承担原设备的功能，而不会造成中断或严重影响网络性能。热备的备用设备通常处于运行状态，可以随时接管主设备的工作。

读写分离指的是一台数据库服务器主要进行写操作，另一台数据库服务器主要进行读操作。

在本申请中，涉及的名词解释如下：

Coordinator：协调服务，负责处理客户端查询请求，接收到客户端请求的SQL，会进行解析，重写和优化，并将分布式查询计划发送给执行节点进行执行，并将最终结果返回给客户端。

Executor：执行服务，负责执行Coordinator分发来的查询计划，处理数据，并返回给Coordinator。

WAL：预写日志，全名Write-Ahead Log，数据变更会预先写入WAL中，用于数据库崩溃后的恢复，确保数据完整性和原子性。

MVCC(Multi-Version Concurrency Control)：它通过创建数据的多个版本来实现，每个事务都可以看到自己的数据版本，从而保证了事务的并发性和一致性。这有助于提高数据库的性能和效率。

Distributed Snapshot：分布式快照信息，其中包含了事务的可见性信息，主要对当前事务可见的最大事务ID(小于它的事务对当前事务都可见)、对当前事务不可见的最小事务ID(大于它的事务对当前事务都不可见)以及目前正在运行的分布式事务数组(正在运行的分布式事务，对当前事务都不可见)。

实施例1

图1示出根据本申请一实施例的分布式数据库系统下的热备方法的流程图。该方法可用于分布式数据库中，提高数据库系统的性能和资源利用率，如图1所示，该流程图包括：

S100，接收待处理写入事务；

由于Cloudberry数据库是分布式数据库，在Mirror中执行读取操作时，由于Primary节点上执行数据写入后，数据同步到Mirror的时机并不一致，数据读取时，需要考虑数据访问的可见性和一致性。在本实施例中，使用pgproxy/pgpool等postgresql的代理程序，实现读写分离。从客户端发送的待处理写入事务由Coordinator的Primary节点接收。

S200，将所述待处理写入事务的状态信息添加至预设日志中；

在本实施例中，预设日志为WAL，Coordinator的Primary节点接收待处理写入事务后，会开启一个分布式事务，创建一个MVCC的分布式快照信息，该分布式快照信息会记录接收的待处理写入事务的运行记录和状态信息，随后将含有待处理写入事务的状态信息的分布式快照信息更新到WAL中，在需要读取详细的运行记录时，此时WAL中含有待处理写入事务的状态信息，可用于判断是否能够读取分布式快照信息中的待处理写入事务的运行记录。

S300，所述预设日志判断是否能读取所述待处理写入事务；

通过Coordinator的Mirror节点读取WAL日志获取待处理写入事务的状态信息，由于Primary上执行数据写入后，数据同步到Mirror节点的时机并不一致，数据读取时，需要考虑数据访问的可见性和一致性，可以根据预设日志中的状态信息判断数据是否同步到Mirror节点。

S400，在所述预设日志中含有预设标志记录时，判定可以读取所述待处理写入事务。

在本实施例中，预设标志记录为一条Forget事务的WAL记录，该条记录体现了待处理写入事务的状态信息，代表待处理写入事务提交，已完成对待处理写入事务的操作处理。待处理写入事务的相关数据已同步到分布式集群中的Mirror节点，对于之后集群中其他通过Mirror节点对该待处理写入事务的读请求，可以读取待处理写入事务的相关数据。

没有预设标志记录时，意为待处理写入事务处于分布式快照信息的正在运行的分布式事务数组中，对待处理写入事务的处理还没有完毕，此时对于读取该待处理写入事务的请求，无法读取待处理写入事务的相关数据。

含有预设标志记录时，意为待处理写入事务已经处理完成，处理待处理写入事务的进程已从分布式快照信息的分布式事务数组中去除，此时对于读取该待处理写入事务的请求，可以读取待处理写入事务的相关数据。

作为本申请的一种可选实施方案，将所述待处理写入事务的状态信息添加至预设日志中，包括：

建立第一分布式快照信息；

参见图2，Coordinator的Primary节点对于每一个待处理写入事务，会开启一个分布式事务，创建一个MVCC的分布式快照信息，在本实施例中，因在后续的Mirror节点也会建立分布式快照信息，便于区分将Coordinator的Primary节点建立的分布式快照信息视为第一分布式快照信息，Coordinator的Mirror节点建立的分布式快照信息视为第二分布式快照信息。

将所述待处理写入事务的运行记录添加到所述第一分布式快照信息中，在所述第一分布式快照信息中根据所述运行记录得到待处理写入事务的状态信息；

Coordinator的Primary节点接收待处理写入事务后，根据所述待处理写入事务进行相关的数据处理操作，生成待处理写入事务的运行记录，将生成的运行记录更新到第一分布式快照信息。根据运行记录能够得知待处理写入事务的状态信息，状态信息包括待处理写入事务处于分布式快照的正在运行的分布式事务数组中和待处理写入事务已经写入完成，已从分布式事务数组中移除。

将所述待处理写入事务的状态信息添加至预设日志。

将分布式快照信息记录到WAL日志，使读取WAL日志的节点可以得到待处理写入事务的状态信息，了解待处理写入事务是否已经写入完成。

作为本申请的一种可选实施方案，判断所述预设日志是否能读取所述待处理写入事务，包括：

建立第二分布式快照信息；

Coordinator的Mirror节点读取WAL日志时，构建分布式快照信息，用于记录待处理写入事务的状态信息，该状态信息能够反映该待处理写入事务是否已经写入完成进而确定是否能够被读取。

读取所述预设日志中所述待处理写入事务的状态信息，根据所述状态信息在所述第二分布式快照信息中更新所述待处理写入事务的状态信息；

读取WAL日志中待处理写入事务的运行记录时，若没有一条Forget事务的WAL记录，Coordinator的Mirror节点在分布式快照信息中会标记待处理写入事务未提交，意为该待处理写入事务还位于第一分布式快照的正在运行的分布式事务数组中。

再次读取WAL日志时，若含有一条Forget事务的WAL记录，Coordinator的Mirror节点修改分布式快照信息，标记待处理写入事务已提交，意为该待处理写入事务已经运行完毕，从所述分布式事务数组中去除。

根据待处理写入事务的状态信息判断是否能读取所述待处理写入事务。

待处理写入事务状态信息通过Coordinator的Mirror节点对待处理写入事务标记获得。当标记待处理写入事务已提交，意为在Primary节点上写入的数据已同步到Mirror节点，待处理写入事务相关数据可以被读取；当标记待处理写入事务未提交，意为该待处理写入事务还未运行完毕，数据未同步到Mirror节点上，此时待处理写入事务相关数据不能被读取。

作为本申请的一种可选实施方案，还包括：

接收读取事务请求；

在本实施例中，从每一个通过Mirror节点的读事务接收请求。

根据所述读取事务请求得到对应数据的事务ID；

例如假设所述读取事务请求为Q，通过请求的内容得知Q所需要读取的数据为data1，data2，data3，data4，data5，而以上五份数据也是由开启分布式事务记录的，因此以上五份数据有着对应的事务ID，假设data1，data2，data3，data4，data5，对应的事务ID为：1，11，12，13，20。

事务ID用于区分每个事务，保证在读取事务时，根据读取事务请求精确读取客户端所需的数据。

根据所述事务ID判断所述读取事务请求能否读取所述对应数据。

参见图3，接收读取事务请求后，使用以上五份数据对应的事务ID和分布式快照信息，读取数据表，扫描数据，按照MVCC进行可见性判断，读取可见数据和过滤不可见数据。

作为本申请的一种可选实施方案，根据所述事务ID判断所述读取事务请求能否读取所述对应数据，包括：

根据事务ID判断所述对应数据的属性；

在本实施例中，通过MVCC的可见性判断规则判断上述五份数据的属性，其中MVCC的可见性判断规则为：分布式快照信息，包含正在执行的分布式事务ID序列表，形如[xmin，xip1，...xip N，xmax]，用于进行可见性判断。判断规则如下：

所有分布式事务ID小于xmin的数据都可见；

所有分布式事务ID大于xmax的数据都不可见；

所有在序列表中的分布式事务ID，若和当前事务ID不相等，对应数据都不可见。

在所述对应数据的属性为数据可见时，所述读取事务请求能读取所述对应数据。

经过MVCC的可见性判断规则，所述读取请求需要的对应数据判断为数据可见时，该对应数据会返回至发送读取请求端便于查看。

作为本申请的一种可选实施方案，还包括：

在所述对应数据的属性为数据不可见时，所述读取事务请求不能读取所述对应数据。

使用MVCC的可见性判断规则判断对应数据的属性为不可见时，意为对应的事务还未提交，对该对应数据进行过滤处理，这部分数据不返回至客户端。

作为本申请的一种可选实施方案，根据事务ID判断所述对应数据的属性，包括：

获取ID序列表；

MVCC创建数据的多个版本，每个事务都可以看到自己的数据版本，数据版本包括分布式快照信息，分布式快照信息有着正在运行的分布式事务数组，数组中正在运行的分布式事务，每个事务都有对应的事务ID，在本实施例中，以ID序列表的形式表示正在运行的分布式事务。

根据分布式快照信息得到当前事务可见的最大事务ID。当前事务可见的最大事务ID表示小于最大事务ID对应的事务对当前事务都可见。

获取所述读取事务请求的读取事务ID；

以前述Q为例，为该读取事务请求Q分配一个读取事务ID，并假设该读取事务ID为12。

所述事务ID小于所述ID序列表中的最小ID或所述事务ID等于所述读取事务ID且所述事务ID位于所述ID序列表中时，所述对应数据的属性为数据可见。

假设Q看到的数据版本中的ID序列表为[11，12，13，14，15]，其中xmin＝11，xmax＝15；结合前述的例子，Q所需要读取的数据对应的事务ID为：1，11，12，13，20；读取事务ID12为当前事务ID。

根据MVCC规则判断：

data1的分布式事务ID是1，小于xmin＝11的，所以对当前事务Q可见；

data2的分布式事务ID是11，在ID列表里，又不等于当前事务ID12，所以对当前事务不可见；

data3的分布式事务ID是12，在ID列表里，等于当前事务ID12，所以对当前事务可见；

data4的分布式事务ID是13，在ID列表里，不等于当前事务ID12，所以对当前事务不可见；

data5的分布式事务ID是20，大于xmax＝15，所以对当前事务Q不可见。

综上的判断过程，Q只能读取数据data1和data3，数据data1和data3会返回发送读取请求端，数据data2、data4、data5将作过滤处理。

作为本申请的一种可选实施方案，还包括：

所述事务ID大于所述ID序列表中的最大ID或所述事务ID不等于所述读取事务ID且所述事务ID位于所述ID序列表中时，所述对应数据的属性为数据不可见。

同样以前述例子为例，若当前事务ID为16，则没有当前事务ID与对应数据的事务ID相等的情况，只需要判断data1，data2，data3，data4，data5对应的事务ID对于当前事务是否可见，其对应的事务ID为1，11，12，13，20，通过前述的分析，事务ID20大于序列表中xmax15，因此data5是不可见的；

事务ID11，12，13在序列表中，但和当前事务ID16不相等，因此数据data2，data3，data4是不可见的。

综上的判断过程，若当前事务ID为16时，Q只能读取数据data1，数据data2，data3，data4，data5都将作过滤处理。

通过以上方法，Coordinator的Mirror节点支持读操作，通过负载均衡，可以降低Coordinator的Primary节点的负载，使Primary节点主要负责写服务，Mirror节点主要负责读服务，出现故障时，可以快速切换到Mirror节点，系统具备更高的稳定性和延迟；还使Executor闲置的Mirror节点提供读服务，通过负载均衡操作，可以增加系统的整体吞吐，加速查询业务，整体提高了分布式数据库系统的资源利用率。

实施例2

基于前述方法相同的原理，还提出一种分布式数据库系统下的热备装置，参见图4，本公开实施例的一种分布式数据库系统下的热备装置100包括：

110，接收写入事务模块，用于接收待处理写入事务；

120，更新状态信息模块，用于将所述待处理写入事务的状态信息添加至预设日志中；

130，判断模块，用于判断所述预设日志是否能读取所述待处理写入事务；

140，读取模块，用于在所述预设日志中含有预设标志记录时，判定可以读取所述待处理写入事务。

显然，本领域的技术人员应该明白，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成的，程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各控制方法的实施例的流程。上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

本领域技术人员可以理解，实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成的，程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各控制方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)、随机存储记忆体(RandomAccessMemory，RAM)、快闪存储器(FlashMemory)、硬盘(HardDiskDrive，缩写：HDD)或固态硬盘(Solid-StateDrive，SSD)等；存储介质还可以包括上述种类的存储器的组合。

实施例3

更进一步的，提出一种电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述可执行指令时实现实施例1所述的分布式数据库系统下的热备方法。

本公开实施例的电子设备包括处理器以及用于存储处理器可执行指令的存储器。其中，处理器被配置为执行可执行指令时实现前面任一所述的分布式数据库系统下的热备方法。

需要说明的是，处理器的个数可以为一个或多个。同时，在本公开实施例的电子设备中，还可以包括输入装置和输出装置。其中，处理器、存储器、输入装置和输出装置之间可以通过总线连接，也可以通过其他方式连接，此处不进行具体限定。

存储器作为分布式数据库系统下的热备方法计算机可读存储介质，可用于存储软件程序、计算机可执行程序和各种模块，如：本公开实施例的分布式数据库系统下的热备方法所对应的程序或模块。处理器通过运行存储在存储器中的软件程序或模块，从而执行电子设备的各种功能应用及数据处理。

输入装置可用于接收输入的数字或信号。其中，信号可以为产生与设备/终端/服务器的用户设置以及功能控制有关的键信号。输出装置可以包括显示屏等显示设备。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (10)

1.一种分布式数据库系统下的热备方法，其特征在于，包括：

接收待处理写入事务；

将所述待处理写入事务的状态信息添加至预设日志中；

判断所述预设日志是否能读取所述待处理写入事务；

在所述预设日志中含有预设标志记录时，判定可以读取所述待处理写入事务。

2.根据权利要求1所述的分布式数据库系统下的热备方法，其特征在于，将所述待处理写入事务的状态信息添加至预设日志中，包括：

建立第一分布式快照信息；

将所述待处理写入事务的运行记录添加到所述第一分布式快照信息中，在所述第一分布式快照信息中根据所述运行记录得到待处理写入事务的状态信息；

将所述所述待处理写入事务的状态信息添加到预设日志。

3.根据权利要求1所述的分布式数据库系统下的热备方法，其特征在于，判断所述预设日志是否能读取所述待处理写入事务，包括：

建立第二分布式快照信息；

读取所述待处理写入事务的运行记录，根据所述运行记录在所述第二分布式快照信息中更新所述待处理写入事务的状态信息；

根据待处理写入事务的状态信息判断是否能读取所述待处理写入事务。

4.根据权利要求1-3任一项所述的分布式数据库系统下的热备方法，其特征在于，还包括：

接收读取事务请求；

根据所述读取事务请求得到对应数据的事务ID；

根据所述事务ID判断所述读取事务请求能否读取所述对应数据。

5.根据权利要求4所述分布式数据库系统下的热备方法，其特征在于，根据所述事务ID判断所述读取事务请求能否读取所述对应数据，包括：

根据事务ID判断所述对应数据的属性；

在所述对应数据的属性为数据可见时，所述读取事务请求能读取所述对应数据。

6.根据权利要求5所述的分布式数据库系统下的热备方法，其特征在于，还包括：

在所述对应数据的属性为数据不可见时，所述读取事务请求不能读取所述对应数据。

7.根据权利要求5所述的分布式数据库系统下的热备方法，其特征在于，根据事务ID判断所述对应数据的属性，包括：

获取ID序列表；

获取所述读取事务请求的读取事务ID；

所述事务ID小于所述ID序列表中的最小ID或所述事务ID等于所述读取事务ID且所述事务ID位于所述ID序列表中时，所述对应数据的属性为数据可见。

8.根据权利要求7所述的分布式数据库系统下的热备方法，其特征在于，还包括：

所述事务ID大于所述ID序列表中的最大ID或所述事务ID不等于所述读取事务ID且所述事务ID位于所述ID序列表中时，所述对应数据的属性为数据不可见。

9.一种分布式数据库系统下的热备装置，其特征在于，包括以下模块：

接收写入事务模块，用于接收待处理写入事务；

更新状态信息模块，用于将所述待处理写入事务的状态信息添加至预设日志中；

判断模块，用于判断所述预设日志是否能读取所述待处理写入事务；

读取模块，用于在所述预设日志中含有预设标志记录时，判定可以读取所述待处理写入事务。

10.一种电子设备，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述可执行指令时实现上述权利要求1-8任一项所述的分布式数据库系统下的热备方法。