CN115344430A - 基于最小法定人数和二进制日志的数据库灾备方法 - Google Patents

Abstract

本发明公开了一种基于最小法定人数和二进制日志的数据库灾备方法，属一种分布式数据库的灾备方法，该方法为主实例处理业务请求中的写入操作，并在业务请求返回前将事务日志同步写入至备实例；当主实例失效时，将备实例切换为主实例，用以处理业务请求中的写入操作，并在业务请求返回前将事务日志同步写入至次备实例；当备实例失效时，主实例处理业务请求中的写入操作，在业务请求返回前将事务日志同步写入至次备实例。通过将事务日志数据的份数控制为最小法定人数，通过减少副本数量改善分布式数据库中写入操作放大的问题，节约数据库存储资源，减少了软件缺陷，提高稳定性。

Description

基于最小法定人数和二进制日志的数据库灾备方法

技术领域

本发明涉及一种分布式数据库的灾备方法，更具体的说，本发明主要涉及一种基于最小法定人数和二进制日志的数据库灾备方法。

背景技术

分布式数据库的数据灾备方案是指在一个数据中心发生故障或者灾难的时候，其他数据中心可以正常运行并且对关键业务或全部业务实现接管，达到互为备份的目的。因此数据库灾备是跨数据中心的数据冗余技术，从而保证数据中心出现灾难后，业务和数据能够得到保护。常见的容灾备份系统可以分为两部分进行理解：一是数据备份，这个可以简单理解成灾难备份的基础部分，即先保留好数据，保证它不会丢失。二是业务恢复，即业务的连续性的保障。因为如果业务系统无法使用，即使数据没有丢，也依然是处于不可用的状态，因此对企业而言，不仅要保证数据丢，也要保证业务不停。整个容灾备份过程中，最关键的衡量指标有两个：一个是 RTO，另一个是 RPO。

RTO（Recovery Time Objective,RTO）为恢复时间目标，指在故障或灾难发生之后，一台电脑、系统、网络或应用停止工作的最高可承受时间。该参数定义了最大可容忍时限，必须在此时限内恢复数据。RPO（Recovery Point Object）恢复点目标，指一个过去的时间点，当灾难或紧急事件发生时，数据可以恢复到的时间点，是业务系统所能容忍的数据丢失量。

正如上述所提到的，灾备是为了防备灾难出现，但是灾难出现的概率是非常小的，绝大多数情况下，系统的组件都在正常状态下运行。即，灾难（地震，火灾，战争或其他类似的事件属于小概率）很少发生。为了达到灾备的可靠性，所有的灾备方案都采用大于2个副本的方式进行部署。比如两地三中心，或者更加复杂的三地五中心等。副本数均大于2。因此，系统在绝大多数情况下，都需要完成大于两个数据副本的落盘操作。比如TDSQL的一主两备模式，binlog需要在两个备机上进行回放并落盘。如果一主多备，则需要在N个备机上进行回放并落盘。这导致写放大为N倍。而OceanBase的Paxos协议虽然属于多数派协议，但是在正常情况下，也是会写满所有的副本数，造成写放大。传统数据库无法避免以上的写放大问题，虽然可以通过法定人数来减少事务提交的响应时间，即，无需所有的备机或者副本写成功，只需要多于法定人数即可，剩余的副本或者备机则异步完成复制操作。但是这会带来复杂性，不可控性，势必造成软件的复杂度升高，对性能也会有不利的影响。最重要的，还是写放大效应带来的资源浪费。因而有必要针对分布式的灾备方法作进一步的研究和改进。

发明内容

本发明的目的之一在于针对上述不足，提供一种基于最小法定人数和二进制日志的数据库灾备方法，以期望解决现有技术中数据库的数据副本落盘操作过多会造成数据写入容量放大，造成数据库存储资源浪费等技术问题。

为解决上述的技术问题，本发明采用以下技术方案。

本发明所提供的一种基于最小法定人数和二进制日志的数据库灾备方法，该方法包括如下步骤。

步骤A、主实例处理业务请求中的写入操作，并在业务请求返回前将事务日志同步写入至备实例。

步骤B1、当主实例失效时，将备实例切换为主实例，用以处理业务请求中的写入操作，并在业务请求返回前将事务日志同步写入至次备实例。

步骤B2、当备实例失效时，主实例处理业务请求中的写入操作，在业务请求返回前将事务日志同步写入至次备实例。

数据库中主实例、备实例、次备实例中存储的事务日志数据份数，始终等于最低法定人数。

作为优选，进一步的技术方案是：所述最低法定人数为2。

更进一步的技术方案是：所述主实例部署于主数据中心内，所述备实例部署于备数据中心内，所述次备实例部署于次备数据中心内，所述次备数据中心与主数据中心之间的物理距离大于100km。

更进一步的技术方案是：所述主实例失效包括实例故障与、数据中心停止服务以及主数据中心与备数据中心之间的网络中断；备实例失效包括实例故障、备数据中心停止服务以及主数据中心与备数据中心之间的网络中断。

更进一步的技术方案是：所述方法还包括步骤C1、主实例失效故障排除后，清空主实例的全部数据，将备实例的数据全量迁移至主实例，并将主实例的角色设置为备实例。

更进一步的技术方案是：所述方法还包括步骤C2、备实例失效故障排除后，从次备实例中获取备实例失效后至当前的增量数据，然后重新作为备实例角色。

更进一步的技术方案是：所述方法还包括步骤C3、备实例失效故障排除后，清空备实例的全部数据，将主实例的数据全量迁移至备实例，然后重新作为备实例角色。

与现有技术相比，本发明的有益效果之一是：通过将事务日志数据的份数控制为最小法定人数，且利用二进制日志的主动推送的特性，可以实现备实例和次备实例的灵活切换，无需多于最低法定人数的副本存在，通过减少副本数量改善分布式数据库中写入操作放大的问题，节约数据库存储资源，且相较于同类的Paxos/Raft协议而言，本发明更易实现，维护方便，提升了系统性能，减少了软件缺陷，提高稳定性。

附图说明

图1为用于说明本发明一个实施例的分布式数据库架构示意图。

具体实施方式

在进一步阐述本发明所示的技术方案前，首先对如下名词以及其与现有技术的主要区别进行说明。

OBServer：一个OBServer指的是一个独立提供服务（share-nothing）的OceanBase数据库节点，这是一个软件层面的定义。但通常一台物理服务器上只有一个OBServer，因此也可以认为一个OBServer等同于OceanBase数据库集群的一个物理节点。

Zone：这是OceanBase数据库的一个内部概念。一个Zone是一个或者一些OBServer组成的逻辑集合，一个Zone里的所有OBServer都在一个机房内。从分布式多副本数据一致性协议的角度来看，可以认为一个Zone就是OceanBase数据库集群的一个“副本”，如果是三副本架构那就会有三个Zone。

DC就是通常理解的“机房”的概念，一个DC就代表一个机房。OceanBase基于Paxos副本协议的数据库灾备方案有多种，我们取典型的2地3机房5副本为例。

在城市1中部署两个数据中心DC1和DC2，在另外一个城市部署一个数据中心DC3。在每个数据中心安装OceanBase数据库。在DC1和DC2中各配置2个数据副本，在DC3中配置1个数据副本。不同的数据副本采用Paxos协议保障一致性。但这些副本都是需要落盘的。因此在上述方案中，最终数据有5个副本，无论是否需要。

本发明的核心思路在于，在整体系统正常运行情况下，只写入最低法定人数的副本数，在故障发生时，写入副本数不足最低法定人数情况下，选取后备实例进行写入，保证到达最低法定人数后即可。因此，可以总结为在任何时刻，整体系统保证每一个数据都有等于最低法定人数的副本数，不少于最低法定人数，也不高于最低法定人数，而是始终等于最低法定人数。

在本发明的一个实施例，仍然以上述的典型的2地3机房为例，结合附图对本发明作进一步的阐述。

参考图1所示，本发明的一种基于最小法定人数和二进制日志的数据库灾备方法，该方法是按照如下的步骤实现的。

在正常的状态下，主实例处理业务请求中的写入操作，并在业务请求返回前将事务日志同步写入至备实例。

如图中所示的，正常业务由DC1主数据中心中的应用和master数据库实例进行支撑，应用发送业务请求给master实例。

读取操作请求不需要进行数据修改，也不产生二进制binlog日志，故无需和备实例以及次备实例同步。

写入请求由master处理，生成二进制binlog日志。Master本地处理结束后，在返回应用之前，将binlog日志同步写入备实例backup1。

值得注意的是，上述主实例只将binlog同步至备实例即结束。达到了最低法定人数，在本实施例中，将最低法定人数设置为2进行说明。因此写入请求过程结束。即数据库中主实例、备实例、次备实例中存储的事务日志数据份数，始终等于最低法定人数，即分布式数据库系统中只保留两个事务日志数据副本。

在异常情况发生，例如主实例或备实例失效。主实例失效包括实例故障、数据中心停止服务以及主数据中心与备数据中心之间的网络中断；备实例失效包括实例故障、备数据中心停止服务以及前述的主数据中心与备数据中心之间的网络中断。

在主实例失效，而备实例正常时，将备实例切换为主实例，用以处理业务请求中的写入操作，并在业务请求返回前将事务日志同步写入至次备实例。

在此时，备实例拥有完整的数据，且DC2上有应用部署，因此切换至DC2。将备实例升级至主实例，并且将DC3中的次备实例升级为备实例。

配置DC3和次备实例的主要用途即在这种故障的复杂情况下保障RPO=0.

如上所述，备实例被切换为主实例的前提条件是备实例拥有完整的数据，RPO=0，即备实例和主实例的数据一致。

多数情况下，数据中心之间的网络可能存在短期或者长时间的故障。为了保障主实例和备实例数据一致，必须在主备之间进行二进制binlog日志的强同步，即如果binlog不能写入备实例，则事务提交回滚。这会带来主实例的可用性下降，而不是增强。因为一旦数据中心之间的网络故障，或者备实例故障，都会导致主实例停止服务。传统的方案是Paxos或者一主两备，这样只要有一个备系统能写入，则主实例继续服务。本发明的次备实例也是做这种用途。当主实例和备实例之间的网络故障发生后，视为备实例失效，切换次备实例为备实例，从而保障主实例继续提供服务，保证系统的可用性。

即在本发明中，设置次备实例仅仅在备实例失效期间才用来写入二进制binlog日志，而不是在整个系统正常运行期间写入。

同时基于最低法定人数的要求也用来处理DC1的复杂故障场景。当数据中心发生火灾等严重事故的情况下，是无法预知哪些设备先发生故障，因此有可能应用系统和数据库主实例依然工作，只是DC1和外界的网络设备先故障，这样主实例不仅无法写入备实例，也无法写入次备实例，从而终止业务。通过这样的方式就可以保证主实例的数据和备实例的数据一致，从而允许业务切换。

在备实例失效，主实例正常时，主实例处理业务请求中的写入操作，在业务请求返回前将事务日志同步写入至次备实例。

此时，主实例可以继续正常工作。但是由于无法将二进制binlog同步至备实例，无法达到法定人数，因此需要将二进制binlog发送给次备实例。如果发送成功，则达到法定人数2，继续工作。

在次备实例失效或者DC3失效时，整个分布式数据库系统不受影响。即在主备均正常的情况下，次备实例不参与任何数据库工作。

同时由于主实例与备实例同时失效的情形较为少见，且不在本发明的技术目的所讨论的范围之内，故此处不再详述。

正如图中所出的，主实例部署于主数据中心DC1内，备实例部署于备数据中心DC2内，次备实例部署于次备数据中心DC3内。按照要求，前述次备数据中心与主数据中心之间的物理距离大于100km。

上述主实例失效故障排除后，清空主实例的全部数据，将备实例的数据全量迁移至主实例，并将主实例的角色设置为备实例。

上述备实例失效故障排除后，分为两种情况，如为临时故障，那么此时数据一般可恢复，即直接从次备实例中获取备实例失效后至当前的增量数据，然后重新作为备实例角色。

此时主实例拥有故障发生前的完整数据，需要从次备实例抓取增量数据。流程为：首先备系统恢复工作，master主实例自动将二进制binlog日志同步到备实例，不再同步到次备实例。Backup1备实例同时需要从backup2，即次备实例抓取增量数据。当增量数据抓取回放完毕，backup1可以恢复为完整数据，可对外提供读取的服务。

如为严重故障，则清空备实例的全部数据，将主实例的数据全量迁移至备实例，然后重新作为备实例角色，继续对外提供读取的服务。

上述次备实例故障排除后，直接修复次备实例，使系统正常运行，对外提供服务，由于主实例并未同步将事务日志数据同步写入至此备实例，因此次备实例上原本就没有故障前的完整数据，因此无需进行数据迁移，即在本发明中次备实例本身就是用来在备实例故障事存储增量数据使用的，因此在分布式数据库系统的容量配置上亦可设计为非对称的形式。

本发明相对于TDSQL等基于传统日志复制方式来说，在保证相同的RPO/RTO前提下，改善了写入放大的问题，减少了数据副本个数。同OceanBase方案相比，简化了系统开发设计。相比于复杂难懂的Paxos/Raft协议，实现更为简单，维护方便，亦同样改善了写入放大的问题，提升了系统性能，减少了软件缺陷，提高稳定性，节约分布式数据库系统的存储资源。

除上述以外，还需要说明的是在本说明书中所谈到的“一个实施例”、“另一个实施例”、“实施例”等，指的是结合该实施例描述的具体特征、结构或者特点包括在本申请概括性描述的至少一个实施例中。在说明书中多个地方出现同种表述不是一定指的是同一个实施例。进一步来说，结合任一实施例描述一个具体特征、结构或者特点时，所要主张的是结合其他实施例来实现这种特征、结构或者特点也落在本发明的范围内。

尽管这里参照本发明的多个解释性实施例对本发明进行了描述，但是，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。更具体地说，在本申请公开、附图和权利要求的范围内，可以对主题组合布局的组成部件和/或布局进行多种变型和改进。除了对组成部件和/或布局进行的变型和改进外，对于本领域技术人员来说，其他的用途也将是明显的。

Claims (7)

1.一种基于最小法定人数和二进制日志的数据库灾备方法，其特征在于所述的方法包括如下步骤：

主实例处理业务请求中的写入操作，并在业务请求返回前将事务日志同步写入至备实例；

当主实例失效时，将备实例切换为主实例，用以处理业务请求中的写入操作，并在业务请求返回前将事务日志同步写入至次备实例；

当备实例失效时，主实例处理业务请求中的写入操作，在业务请求返回前将事务日志同步写入至次备实例；

数据库中主实例、备实例、次备实例中存储的事务日志数据份数，始终等于最低法定人数。

2.根据权利要求1所述的基于最小法定人数和二进制日志的数据库灾备方法，其特征在于：所述最低法定人数为2。

3.根据权利要求1所述的基于最小法定人数和二进制日志的数据库灾备方法，其特征在于：所述主实例部署于主数据中心内，所述备实例部署于备数据中心内，所述次备实例部署于次备数据中心内，所述次备数据中心与主数据中心之间的物理距离大于100km。

4.根据权利要求3所述的基于最小法定人数和二进制日志的数据库灾备方法，其特征在于：所述主实例失效包括实例故障与、数据中心停止服务以及主数据中心与备数据中心之间的网络中断；备实例失效包括实例故障、备数据中心停止服务以及主数据中心与备数据中心之间的网络中断。

5.根据权利要求1或4所述的基于最小法定人数和二进制日志的数据库灾备方法，其特征在于：主实例失效故障排除后，清空主实例的全部数据，将备实例的数据全量迁移至主实例，并将主实例的角色设置为备实例。

6.根据权利要求5所述的基于最小法定人数和二进制日志的数据库灾备方法，其特征在于：备实例失效故障排除后，从次备实例中获取备实例失效后至当前的增量数据，然后重新作为备实例角色。

7.根据权利要求5所述的基于最小法定人数和二进制日志的数据库灾备方法，其特征在于：备实例失效故障排除后，清空备实例的全部数据，将主实例的数据全量迁移至备实例，然后重新作为备实例角色。

Images