DCFTest：DCF框架的测试工具

• 前期配置工作
• DCFTest的设计
• DCFTest的测试

---

目录

• 1 配置工作
• 2 DCFTest的设计
• 3 DCFTest的测试
  • 3.1 集群选举
  • 3.2 日志复制
  • 3.3 节点宕机

---

1 配置工作

1.1 关于DCF

DCF(Distributed Consensus Framework) 是华为Gauss数据库推出的基于Paxos协议的高可用一致性组件，该组件使得GaussDB(for openGauss)在保证数据一致性的同时，在高可用方面可进一步得到增强，包括：

• (1)通过自仲裁、多数派选主能力摆脱第三方仲裁组件，极大缩短RTO时间，且可预防任何故障下的脑裂双主；
• (2)支持节点同步、同异步混合部署的多集群部署模式；
• (3)提升主备间节点日志复制效率，提升系统的最大吞吐能力。
  借助GaussDB(for openGauss)的DCF高可用组件，用户不仅可以免去系统脑裂的风险，还提升了可用性。

项目地址：https://gitee.com/opengauss/DCF

DCFTest基于GitHub上的项目DCF-Demo，希望通过设计测试程序来验证DCF的可用性与性能，在验证DCF框架的可用性后，也便于后期和其他的项目对接。DCFTest希望能够通过DCF-Demo中的代码来进行测试，具体做法是从DCF-Demo中将部分代码段提取出来，将dcf_test_main.c中的部分代码封装到dcf_demo.h当中，供DCFTest调用。

DCF-Demo项目地址：https://github.com/NPUWDBLab/DCF-Demo

关于DCFTest具体的安装与配置过程，在DCFTest主页有详细介绍。

DCFTest项目地址：https://github.com/lamber1123/DCFTest

---

2 DCFTest的设计

暂时跳过，后期补上。

---

3 DCFTest的测试

本次参与集群测试的三台服务器初始配置如下：

{“stream_id” : 1, “node_id” : 1, “ip” : “172.19.0.202”, “port” : 29222,”role” : “LEADER”},
{“stream_id” : 1, “node_id” : 2, “ip” : “172.19.0.203”, “port” : 29222, “role” : “FOLLOWER”},
{“stream_id” : 1, “node_id” : 3, “ip” : “172.19.0.204”, “port” : 29222, “role” : “FOLLOWER”}

3.1 集群选举

DCF采用类paxos协议，集群在启动时首先会由集群所有成员选举出一个leader，该leader会接管后续所有的client的请求，且集群日志状态以leader为准。除了在集群初始化启动时需要执行leader选举的过程，当leader失效的时也需要集群的成员选举出新的leader，所谓leader失效包括leader意外宕机，或同多数的follower发生网络隔离，甚至是leader因负载过重导致其不能及时同其他多数follower保持心跳。当然，另外还有一种情况是leader主动降到follower，此时它会让权给集群指定的follower。本节的测试暂不考虑异常情况，只测试集群启动时进行的选举与集群主动发起的选举。

• 首先打开三台服务器服务器，运行DCFTest

cd DCFTest
sh build.sh

• 分别看到启动成功的信息后，输入query指令查看集群状态

query

• 可见DCFTest节点均启动成功，node2当选为leader节点
• 在leader节点上主动推选node1成为leader

promote leader 1
query

• node1当选为leader节点
• 本节测试结束

---

3.2 日志复制

在openGauss中，负责落盘的线程通过调DCF的write接口，把数据写到buffer队列里面，写完后无阻塞立即返回。当本次写入得到大多认可后，会异步的write callback。而buffer里的数据会经过一系列的复制流水线，经过组包发送给备机。备机收到数据包后会回调Replay callback通知数据库内核，然后将数据拷贝到xlog日志里面。

这一节主要通过DCF的读写来测试日志复制情况。

• 在leader节点中写入数据 dcftestisgood

write dcftestisgood

• 在所有节点中通过index来读取这一数据

read 14

• 所有节点均可以读到这一数据
• 然后，在follower节点写入数据 hellodcftest

write hellodcftest

• 在所有节点中通过index来读取这一数据

read 19

• 所有节点均可以读到这一数据
• 本节测试结束

---

3.2 节点宕机

节点的宕机一种常见的异常事件，但是，若没有妥善处理则会影响到集群的安全性。宕机节点重启后能否正确的同步日志就是一个重要的问题。举个例子，在一个包含3个节点的集群中，S1为leader节点。若S1接收到了客户端的写请求，并将数据包发送给S2与S3。此时，若S3在接收到数据包之前发生宕机，但是S2正确接收并反馈了，此时S1依然会提交这一写请求。一段时间后S3重启，如果没有进行日志同步的话，S3的日志将落后于集群，针对S3的读请求将出现异常。本节中将通过读写数据对日志同步情况进行测试。

• 将一个follower节点手动宕机

stop

• 在另一节点中写入一条数据 outagetest

write outagetest

• 在所有节点中通过index来读取这一数据

read 4

• 除宕机节点外，所有节点均可以正确读取数据
• 然后，将宕机节点手动恢复并读取数据

start
read 4

• 宕机节点已经正确同步了前面的日志
• 本节测试结束

---