分布式关系型数据库恢复点目标测试方法

吕韬 田峰 李征宇 张雪

摘   要： 分布式关系型数据库具有广泛应用和技术探究空间，其质量指标关乎信息系统稳定运行、业务连续性等，其中恢复点目标（RPO）是衡量分布式关系型数据库可靠性的核心指标。讨论了分布式关系型数据库RPO的内涵和外延，印证了分布式关系型数据库理论上可以保证RPO等于0，拥有对数据完整性的完全保障能力。针对RPO指标，提出了一种基于场景的测试方法，以写入数据库的事务数量与数据库中记录数的差值表征数据丢失情况。搭建测试环境，应用LoadRunner测试工具，以平均响应时间、每秒虚拟用户HTTP请求数、Tomcat日志等为依据，测试得到三款分布式关系型数据库产品的RPO指标，实现了对数据库容灾能力的评价。

关键词： 分布式关系型数据库;恢复点目标（RPO）;容灾能力; LoadRunner;平均响应时间

引言

信息技术、互联网技术的深度应用，以及大数据挖掘、智能化发展，促使信息系统不断扩展规模，要求信息系统向高性能、易扩展、泛兼容的技术方向演进，其中安全存储、可靠传输、精准应用信息资源是信息系统中的关键技术。信息资源的可用性、完整性、有效性是关键指标，存储信息资源的数据库作为支撑信息系统稳定运行的基础软件，技术体系不断革新，从集中式向分布式架构演进成为重要技术趋势[1]。

相对传统的大型集中式关系型数据库，分布式关系型数据库具有成本低、部署灵活、性能高等优势，可以支撑当前互联网应用的大规模、高并发、多模式业务类型，也是当前金融领域信息化升级的重要技术方向[2]。2019年10月，蚂蚁金服科技研发的分布式关系型数据库OceanBase成功登顶TPC-C[3]，反映出我国分布式关系型数据库技术逐步成熟，正在被越来越多的行业所认可并投入实际应用。

科学、客观、准确地评价一款分布式关系型数据库产品的质量是保证信息资源安全、信息系统可靠的 重要课题。除了功能、性能、安全等质量属性外，一些关键行业的信息系统对数据库的可靠性提出了更高的要求：一方面需要数据库厂商通过日志、副本等技术保障可靠性;另一方面也需要客观评价可靠性的指标和方法。考虑到分布式关系型数据库一般具有多副本实时备份的技术特点，恢复点目标（Recovery Point Object，RPO）指标成为衡量其可靠性的核心指标[4]。为此，本文结合分布式关系型数据库的技术特点，提出一种基于场景的分布式关系型数据库恢复点目标的测试方法，以实现对分布式关系型数据库可靠性的测评，并在工程实践中进行验证，以反映测试方法的正确性和合理性。

1  分布式关系型数据库与RPO

分布式关系型数据库作为基础软件产品，符合软件产品的所有质量特性。一般软件产品的质量特性包括功能、效率、可靠性、安全性、兼容性、可扩展性等，对于特定的软件产品，需要结合软件本身的技术特点，在质量特性的框架下进行设计，并细化测试指标，明确测试方法，最终达到评价软件产品的目的。

1.1  分布式关系型数据库

一般来说，分布式关系型数据库是用计算机网络将物理上分散的多个数据库单元连接起来，并采用关系模型加以组织的一个逻輯上统一的数据库[5]。分布式关系型数据库具有物理分布性、逻辑整体性和站点自治性的特点，从其所具有的能力上可以归纳为：

（1）管理、调度、处理分布式事务;

（2）支持跨数据中心的横向扩展;

（3）具备高可用能力，具备进行实时备份及恢复的容灾能力。

从以上的技术特点可以看出，相对于传统的集中式关系型数据库，分布式关系型数据库的扩展性和容灾能力更强，尤其是当一个或多个节点遇到故障时，分布式关系型数据库能够持续运行并迅速拉起备份节点，承担故障节点的工作[6-7]。

1.2  RPO的内涵与外延

RPO的作用是灾难发生后，令容灾系统把数据恢复到灾难发生前时间点的数据，故RPO是衡量灾难发生后会丢失多少生产数据的指标，具体表示为从灾难发生到最近一次备份的时间度量。本质上，RPO指标主要反映了业务连续性管理体系下备用数据的有效性，系统RPO越小，表示系统对数据完整性的保障能力越强，即故障发生后可能损失的数据就越少。

对于传统的集中式关系型数据库，由于其数据存储机制为主节点执行写操作，因此一旦其主节点遇到故障，数据就存在丢失的可能性，且故障恢复时间受到软硬件、机房基础设施等多种因素影响，RPO指标较高;即使是引入了热备份等相关机制的现代的集中式数据库，虽然当主节点遇到故障时系统能够快速切换到备份节点，但其“多读单写”的机制仍然无法完全保证其RPO等于0。

对于分布式关系型数据库，为了实现真正的多读多写，一般通过中间件或同步协议保障多个数据库副本之间的数据一致性，从数据处理机制上实现实时的备份，理论上可以保证RPO等于0。因此对分布式关系型数据库进行RPO测试验证成为一个新的课题[8-9]。

2  分布式关系型数据库RPO测试方法设计

结合分布式关系型数据库的技术特点，我们创新地将RPO引入数据库质量测试，作为可靠性的测试指标之一，用以验证分布式关系型数据库的容灾能力，对当前分布式关系型数据库应用较多且对业务连续性要求较高的电子商务、金融行业具有重要的参考价值。

对分布式关系型数据库进行RPO测试的主要思路是，在被测数据库执行一个连续事务的过程中，人为制造故障场景，如切断一个或多个节点，在故障发生后，观察被测数据库是否仍可稳定连续运行，并且在故障发生的时间段统计所有数据是否丢失，计算其RPO。

RPO的测试方法设计如下：

（1）通过客户端持续对分布式关系型数据库的一个节点进行写操作，在客户端记录写操作成功的次数，在数据库端记录每条插入数据的时间;

（2）断开该节点的网络，判断数据库是否稳定运行不退出，以及写操作能否迅速恢复，记录断网时间;

（3）待被测数据库稳定后，终止测试;

（4）对比写操作成功次数与数据库中的记录数是否一致，并计算分析断网之后插入数据的时间间隔。

RPO的判定方法如下：

按照GB/T 20889-2007《信息安全技术 信息系统灾难恢复规范》[10]的要求，RPO约为0或者等于0的情况对应的容灾等级为第5级、第6级，换算成可靠性的要求，其系统可用性应为99.99%及以上。因此，在测试完成后，应计算丢失记录数与总成功插入记录的比值，若丢失记录数的比值小于0.01%，则认为被测的分布式关系型数据库产品RPO约为0;若比值小于0.001%，则认为被测的分布式关系型数据库产品RPO等于0。

3  RPO测试过程

分布式关系型数据库的测试过程主要分为三个部分：一是按照被测数据库的技术特点及实际业务场景需求搭建测试环境，准备能够准确量化RPO指标的测试工具;二是根据RPO测试指标制定测试步骤，明确测试的次序和每步需要记录的测试数据;三是对所有的测试结果进行分析，评价被测产品的RPO能力。

3.1  测试环境搭建

按照分布式关系型数据库的技术特点，在硬件设备上一般需要准备6台服务器及配套的交换机，用于部署被测数据库，此外服务器还可复用部署测试相关的系统，需要一台桌面终端。

测试工具建议选择LoadRunner，此工具的作用一是模拟实际用户，对Web应用系统进行持续访问，从而对被测数据库进行持续的写操作;二是监测在故障发生时数据库的性能表现。

此外，为了模拟实际业务场景，还需开发一个小型的Web应用系统，此系统的作用一是对被测产品进行连续写操作，二是在故障发生时，通过监测此系统的运行状态来判断数据库是否连续运行。

综上，测试环境的软硬件构成如图1所示。

测试环境在搭建时，需要被测数据库的厂商按照数据库的特点进行节点分配，测试环境的标准拓扑图如图1所示。

3.2  测试实施步骤

測试流程图如图2所示，以下对各个步骤进行介绍。

3.2.1  测试环境部署与确认

按照图1所示的测试环境拓扑图搭建分布式关系型数据库测试环境。搭建完成后，试运行被测数据库，确保数据库系统正常运行。

3.2.2  Web应用部署与确认

选择一台数据库服务器部署Web应用系统，部署完成后，确保Web应用系统与数据库连接成功且可对被测数据库进行操作。在被测数据库中，构造数据库表单，要求表单最后一列为时间戳;在Web应用系统中，构建一条SQL语句，对被测数据库进行操作，SQL语句为插入操作，且插入的最后一列为插入数据时的时间戳。

3.2.3  测试工具部署及调试

在桌面终端部署LoadRunner工具，录制脚本并调试，直至成功，确保可以对Web应用程序进行压力测试。

3.2.4  使用测试工具执行压力测试

通过LoadRunner实现100用户并发对创建表单的插入操作（压力测试执行前，务必清除已创建表单中所有数据）。参数设置：thinktime=0;运行时长20 min。执行压力测试，并观察测试工具Transactions（事务总数）的Total Passed与Total Failed数值，若Total Failed出现非0数据，则停止压力测试，并返回至章节3.2.3，重新对测试工具和Web应用进行部署调试。

3.2.5  故障模拟

在测试中平稳运行5 min后，手动关闭其中一个计算节点，模拟该节点运行发生故障并退出。执行断网操作后，观察LoadRunner工具响应时间曲线图，若Hits per Second数值降至零，且Total Failed出现非0数据、Total Passed数值停止增长、数据库单一节点故障引起数据库不可用，则说明该分布式关系型数据库的配置不正确，返回章节3.2.1对分布式测试环境重新进行部署与确认。执行断网操作后，待Hits per Second数值降低并稳定后，继续保持压力，20 min压力测试完成后，记录测试数据。

3.2.6  记录分析测试结果

测试完成后，记录LoadRunner的事务通过数、未通过数，Web应用系统的成功连接数，被测数据库表单中的记录数等数据。

3.3  测试结果记录及处理

首先，测试工具LoadRunner通过的Transactions数量，该测试结果是对事务进行综合分析的结果，是性能分析的第一步。其一，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常，若Transactions的Total Failed数值持续增长，则判定客户端通过Web应用访问数据库失败，需中断测试工作;其二，运行正常的情况下，在测试完成后，通过记录Transactions的Total Passed数值，记录测试工具端客户端成功发送数据库的事务数量X1。

其次，记录Web应用通过的Transactions数量X2，该数值可直观反映出客户端成功执行SQL语句并成功写入数据库的事务数量。

再次，登录数据库端通过SQL语句查询数据库表所有记录数X3，X3数值为本次测试过程中实际成功写入数据库的事务数量。

最后，根据以上测试数，对测试结果进行计算分析：

（1）若X1=X3，则客户端成功发送数据库的事务数量等于成功写入数据库端的事务数量，整个测试过程中未发生数据丢失，测试过程中RPO等于0。

（2）若X1>X3，则客户端成功发送数据库的事务数量大于成功写入数据库端的事务数量，为了保证测试的严谨性，需查看Web应用通过的Transactions数量X2。

① 若X2≤X3，说明成功写入数据库端的事务数量大于或等于Web应用成功发送的数据量，测试过程中未发生数据丢失，测试过程中RPO等于0（注：在并发压力测试过程中，因网络延迟、响应超时等原因导致数据库写入成功的响应结果未反馈Web服务器端）。

② 若X2>X3，则Web应用成功發送的数据量大于成功写入数据库端的事务数量，测试过程中发生的数据丢失情况需要按照以下公式进行计算：

X4=（X2-X3）/X2 （1）

a. 若X4≥0.01%，则认为被测的分布式关系型数据库产品RPO不等于0，在执行故障模拟的过程中出现事务丢失，且丢失数据量大于每秒写入数据库的数据。计算事务丢失数据量，查看数据库事务日志中事务连续写入时间记录，分析数据库记录时间戳不连续的时间间隔。

b. 若0.001%≤X4<0.01%，则认为被测的分布式关系型数据库产品RPO约等于0。

c. 若X4<0.001%，则认为被测的分布式关系型数据库产品RPO等于0。

4  测试结果及分析

为了验证提出的基于场景的分布式关系型数据库恢复点目标的测试方法，搭建实验测试环境，对A、B、C三款分布式关系型数据库产品进行RPO测试，并对测试结果进行分析。

4.1  A款数据库测试结果及分析

按照测试要求搭建A款数据库测试环境，部署测试工具，测试结果如下：

（1）测试过程中平均响应时间Average Response Time（单位：s）。从图3可以看出，模拟单节点故障后，切换过程中响应时间有明显的提升;切换完成后，整个响应时间趋于稳定，数据库连接正常。

（2）测试过程中每秒虚拟用户HTTP请求数（Hits per Second）。从图4可以看出，当模拟单节点故障后，每秒虚拟用户HTTP请求数出现较大浮动的下降;运行4 min后，每秒虚拟用户HTTP请求数趋于稳定且恢复至故障前水平。整个过程中，数据库连接正常。

（3）LoadRunner测试工具记录的通过Transactions数量。如图5所示，X1=7 860 902，该数值为客户端发送至Web应用并成功响应的Transactions数量。

（4）测试结束后在数据库通过SQL语句

select count （1） form t_gh;

查看数据库该表中的记录数，得到X3=7 814 974，如图6所示。

（5）对比差值X1-X3=45 928，即数据库端丢失数据条数为45 928，计算数据丢失比，得

X4=（7 860 902-7 814 974）/7 860 902=0.584%

（2）

X4>0.01%，表明被测的分布式关系型数据库产品RPO不等于0。

（6）通过查看数据库写入日志记录发现，数据库记录时间戳不连续的时间间隔为80 s，日志部分截图如图7所示。因此，被测的分布式关系型数据库产品RPO为80 s。

4.2  B款数据库测试结果及分析

按照测试要求搭建B款数据库测试环境，部署测试工具，测试结果如下：

（1）测试过程中Average Response Time。从图8可以看出，模拟单节点故障后，切换过程中响应时间有明显的提升;切换完成后，整个响应时间趋于稳定，数据库连接正常。

（2）测试过程中每秒虚拟用户HTTP请求数。从图9可以看出，模拟单节点故障后，每秒虚拟用户HTTP请求数出现较大幅度的下降;运行2 min后，每秒虚拟用户HTTP请求数趋于稳定，且恢复至故障前水平。整个过程中，数据库连接正常。

（3）LoadRunner测试工具记录的通过Transactions数量。如图10所示，X1的数值为17 070 507，测试过程中Transactions的Total Failed数值为0 ，未出现报错。

（4）查看Tomcat日志记录不通过Transactions数量为100（如图11所示），实际通过的Transactions数量X2=17 070 407。

（5）测试结束后，在数据库通过SQL语句

select count （1） form t_gh;

查看数据库该表中的记录数，得到X3=17 070 408，如图12所示。

（6）通过以上测试数据可以看出，X1>X3，X2

4.3  C款数据库测试结果及分析

（1）测试过程中Average Response Time。从图13中可以看出，模拟单节点故障后，响应时间较故障前提升4倍;切换完成后，整个响应时间趋于稳定，数据库连接正常。

（2）测试过程中每秒虚拟用户HTTP请求数。从图14可以看出，当模拟单节点故障后，每秒虚拟用户HTTP请求数出现较大幅度的下降，整体性能下降，但整个过程中数据库未出现中断，连接正常。

（3）LoadRunner测试工具记录的通过Transactions数量。如图15所示，X1的数值为4 867 970，测试过程中Transactions的Total Failed数值为0 ，未出现报错。

（4）查看Tomcat日志记录通过Transactions数量X2为4 867 936，如图16所示。

（5）测试结束后，在数据库通过SQL语句

select count （1） form t_gh;

查看数据库该表中的记录数X3为4 867 958。

（6）通过以上测试数据可以看出，X1>X3，X2

5  结束语

本文提出了一种基于场景的分布式关系型数据库恢复点目标的测试方法，将RPO测试指标引入分布式关系型数据库质量测试，能够对被测数据库的容灾能力进行评价，且通过实际的工程实践证明了方法的可行性与正确性，对数据库的应用方具有很高的参考价值，也为后续数据库相关产品的测试评价提供了思路与方法。

致谢

感谢中国软件评测中心的领导和同事，在本文写作过程中，他们提供了许多无私的帮助，使得这篇文章得以顺利完成。感谢审稿专家在百忙之中审阅我们的文章，您们的意见为提高我们文章的质量带来了很大帮助。欢迎读者批评和指正。

参考文献

[1] 王昆， 高可用分布式任务调度与执行系统设计与实现[D]. 西安： 西安电子科技大学， 2019.

[2] 中国人民银行. 中国金融业信息技术“十三五”发展规划[OL]. http：//www.pbc.gov.cn/zhengwugongkai/127924/128038/128109/3333998/index.html. 2017-06-27.

[3] 蚂蚁金服科技. 蚂蚁金服自研数据库OceanBase如何登 顶TPC-C[OL]. https：//segmentfault.com/a/1190000020597597. 2019-10-05

[4] 陈宏， 郭素芹， 罗顺辉， 等. 信息系统灾难备份策略及关键技术研究[J]. 电力信息化， 2011， 9（10）：8-13.

[5] 邵侧英. 分布式数据库系统及其应用： 第2版[M]. 北京： 科学出版社， 2005.

[6] 叶骄龙. 面向数据库的CDP容灾系统关键技术研究[D]. 杭州： 杭州电子科技大学，2015

[7] 王君军. 分布式异构数据库系统的网络容灾技术研究[D]. 长春： 长春理工大学， 2011.

[8] 朱涛， 郭进伟， 周欢， 等. 分布式数据库中一致性与可用性的关系[J]. 软件学报， 2018， 29（1）： 131-149

[9] 张宇. 分布式数据库一致性和可用性方法优化方案研究[D]. 成都： 成都理工大學， 2014.

[10] 信息安全技术 信息系统灾难恢复规范： GB/T 20889-2007[S]. 北京： 中国标准出版社， 2007.