数据库系列之GaussDB数据库高可用能力测试验证

数据库的高可用能力是数据库的基本能力，可靠性的设计和机制能够保证数据库节点异常时能够正常切换、减少业务的影响范围和时间，保证业务的可用性和连续性。本文主要介绍GaussDB数据库的高可用能力测试验证情况，通过模拟故障场景来验证GaussDB集中式数据库在异常情况下的高可用能力。如果对测试过程不感兴趣的，可以直接跳到最后测试总结部分。

1、测试环境准备

1.1 环境部署架构

测试环境采用生产同城同一个数据库集群3AZ三节点部署方式，每个节点一个数据库服务器，这里的AZ可以认为是不同的机房模块。如下图所示：

在这里插入图片描述

CM由CM Agent、CM Server和OM monitor构成：
- CM Agent：管理服务组件，由OMM拉起（周期1秒），主要负责CMS、DN进程的保活及启停，仲裁指标采集、仲裁命令执行等。集群的每台主机上均有CM Agent进程。CMA故障可能会导致启停能力丢失、实例故障检测能力丢失。
- CM Server：管理服务组件，由CMA拉起（周期1秒），根据CM Agent上报的实例状态判定当前状态是否正常，是否需要修复，并下发指令给CM Agent执行。CM Server会将集群的拓扑信息保存在ETCD。
- OM Monitor：管理服务组件，由crontab定时任务控制拉起（周期1分钟），主要负责OMM、etcd、cm_agent进程的保活及启停
DN节点：数据服务组件，由CMA拉起（周期1秒），负责存储业务数据、执行数据查询任务以及返回应用结果。DN主备节点之间采用Quorum复制或Paxos协议复制。
ETCD节点：管理服务组件，由OMM自动拉起（周期1秒），主要协助CMS选主、持久化集群仲裁信息、保存集群的拓扑信息等。

其中DN主节点、ETCD主节点和CM Server主节点不一定在同一台主机上，实际会分布在不同的服务器上。

1.2 高可用测试脚本

1.2.1 Benchmark-TPCC测试

1）脚本配置

db=postgers
driver=com.huawei.gaussdb.jdbc.Driver
conn=jdbc:gaussdb://xx.xx.xx.xx:port, xx.xx.xx.xx:port/dbxx?currentSchema=xx&targetServerType=master&socketTimeout=60&connectionTimeout=2&LoginTimeout=6&ltRowFetchSize=1000

2）运行脚本

##准备数据
sh runDatabaseBuild.sh props.gs
##测试运行
sh runBenchmark.sh props.gs
##清理数据
sh runDatabaseDestroy.sh props.gs

1.2.2 Sysbench测试

1）下载并安装sysbench工具，配置时指定支持pgsql

yum install –y make automake libtool pkgconfig libaio-devel
yum install –y openssl-devel mysql-devel postgresql-devel
./autogen.sh
./configure -prefix=xx --with-pgsql
Make && make install

2）修改GaussDB参数并重启

##修改参数password_encryption_type
Gs_guc set -Z datanode -N all -c “password_encryption_type=1”
##修改gs_hba.conf配置文件，添加以下内容
Host all all 0.0.0.0/0 md5
##修改完成后生效
##重新配置用户密码，否则不生效
=> alter user xxxx identified by ‘xxxx’;
因为sysbench连接gaussdb使用md5加密算法，默认是不支持的

3）创建用户和库后，运行脚本测试

##prepare语句
#sysbench oltp_read_write.lua --db-driver=pgsql --pgsql-host=xx.xx.xx.xx --pgsql-port=xx --pgsql-user=xx --pgsql-password=xx --pgsql-db=xx --tables=10 --table-size=1000000 --threads=10 --time=300 --report-interval=1 prepare
##run语句
#sysbench oltp_read_write.lua --db-driver=pgsql --pgsql-host=xx.xx.xx.xx --pgsql-port=xx --pgsql-user=xx --pgsql-password=xx --pgsql-db=xx --tables=10 --table-size=1000000 --threads=10 --time=300 --report-interval=1 run

1.2.3 中断继续执行

由于TPCC和sysbench测试的时候出现错误会中断退出，为了验证中断能重连，准备监控脚本在中断时候能够重新拉起任务执行，以验证故障时候业务的恢复时间。

#!/bin/sh

#输入变量
log_output=$1

#定义要监控的进程名称
PROCESS_NAME="runBenchmark.sh"

#定义启动进程的命令
cd /tmp/benchmarksq5.0/run
START_COMMAND="/bin/sh /tmp/benchmarksq5.0/run/runBenchmark.sh props.gs >> $1"

#日志文件路径
LOG_FILE="/tmp/monitor_and_restart.log"

# 无限循环，持续监控进程  
while true; do  
    # 检查进程是否存在  
    if ! pgrep -x "$PROCESS_NAME" > /dev/null; then  
        echo "$(date): $PROCESS_NAME is not running. Restarting..." | tee -a "$LOG_FILE"  
        # 尝试启动进程  
        eval $START_COMMAND  
        if [ $? -eq 0 ]; then  
            echo "$(date): $PROCESS_NAME restarted successfully." | tee -a "$LOG_FILE"  
        else  
            echo "$(date): Failed to restart $PROCESS_NAME." | tee -a "$LOG_FILE"  
        fi  
    else  
        echo "$(date): $PROCESS_NAME is running." | tee -a "$LOG_FILE"  
    fi  
    # 等待1秒钟  
    sleep 1  
done

2、高可用测试场景

2.1 DN主节点故障有效性

2.1.1 测试目标

考察GaussDB数据库DN主节点异常的情况下，对业务处理的影响，DN节点能否正常切换、业务影响的时间是多少。

2.1.2 故障场景

1）DN主节点停进程

#查询节点信息
Cm_ctl query -Cv
#执行停止操作
Cm_ctl stop -n 1 -D /xx/dn_6001

TPS降为0，持续约16s，为DN节点主备切换时间。

2）DN主节点进程kill

ps –fu $USER|grep ‘bin/gaussdb’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -9

TPS降为0，持续约10s，为DN节点主备切换时间

3）DN主节点进程挂起

ps –fu $USER|grep ‘bin/gaussdb’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -19

TPS降为0，持续约102s，为检测DN主节点异常及主备切换时间。进程挂起状态下，触发DN节点僵死检测机制。

4）DN主节点服务器禁用网卡

##禁用网卡
ifdown eth0
##恢复网卡
ifup eth0

测试发现DN主节点很快发生切换，但是应用连接挂起无响应，旧的连接没有释放并且链路不通，应用侧需要有链路超时断开机制。新的连接请求会使用新的DN主节点建立链接。

5）DN主节点服务器重启

##重启服务器
reboot

TPS降为0，持续约14s，为DN节点主备切换时间。

2.1.3 DN僵死检测机制

当DN进程处于D、T、Z或者连接超时等僵死状态时，DN无法及时处理业务请求，导致业务中断，影响业务正常功能。CM支持根据配置值定时检测DN是否处于僵死状态，对连续处于僵死状态的DN，达到配置次数后做重启恢复操作。

在这里插入图片描述

如果开启了enable_e2e_rto开关，当检测到1次僵死后会立即将实例状态置为UNKNOWN，进而触发选主仲裁流程。默认是没开启这个参数，由控制参数agent_phony_dead_check_interval（默认值10s）、phony_dead_effective_time（默认值5次）控制检测的时长。

连接类僵死默认(10 * 5)秒后标记为僵死，触发重启。
由于实例正常运行也会出现D状态，执行gstack等定位动作会出现T状态，为避免这种场景导致的误判和core生成不完整，D/T状态僵死规格为持续3分钟状态未变化，则触发重启。
coredump时也会有D/T状态，检测到数据库core标记后，此时不会做重启动作，但是会将实例置为UNKNOWN，进而触发选主仲裁流程。

2.2 DN节点副本故障有效性

2.2.1 测试目标

考察单个DN备节点和所有DN备节点异常时对业务的影响。

2.2.2 故障场景

1）单个DN节点停进程

#查询节点信息
Cm_ctl query -Cv
#执行停止操作
Cm_ctl stop -n 1 -D /xx/dn_6001

对业务无影响，进程需要手动start

2）单个DN节点进程kill

ps –fu $USER|grep ‘bin/gaussdb’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -9

对业务无影响，进程1s后由CMA自动拉起

3）单个DN节点进程挂起

ps –fu $USER|grep ‘bin/gaussdb’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -19

对业务无影响，进程触发僵死检测，100s后kill并由CMA自动拉起

4）单个DN节点服务器禁用网卡

##禁用网卡
ifdown eth0
##恢复网卡
ifup eth0

对业务无影响，网络正常后恢复。

5）单个DN节点服务器重启

##重启服务器
reboot

对业务无影响，DN进程在备机重启后自动拉起。

6）所有DN备节点进程kill

ps –fu $USER|grep ‘bin/gaussdb’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -9

业务变成只读，持续约6s，为备节点DN进程恢复时间。

7）所有DN备节点进程挂起

ps –fu $USER|grep ‘bin/gaussdb’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -19

业务变成只读，持续约150s后恢复，为检测DN备节点异常并kill后重新拉起恢复。DN进程挂起时触发DN僵死检测机制。

8）所有DN备节点网络异常

##禁用网卡
ifdown eth0
##恢复网卡
ifup eth0

业务变成只读，影响时长为网络恢复时间。

9）所有DN节点服务器重启

##重启服务器
reboot

业务变成只读，持续约110s后恢复，为DN备节点服务器重启恢复时间。

2.3 ETCD节点故障有效性

2.3.1 测试目标

考察ETCD节点异常时对业务的影响。

2.3.2 故障场景

1）ETCD所有节点kill进程

ps –fu $USER|grep ‘bin/etcd’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -9

业务无影响，ETCD进程1s后由OMM组件自动拉起。ETCD主节点异常会发生切换。

2）ETCD所有节点进程挂起

ps –fu $USER|grep ‘bin/etcd’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -19

业务无影响，ETCD进程1s后由OMM组件kill并自动拉起。ETCD主节点异常会发生切换。

2.4 CM Server组件故障有效性

2.4.1 测试目标

考察CM Server组件异常时对业务的影响。

2.4.2 故障场景

1）CM Server所有节点kill进程

ps –fu $USER|grep ‘bin/cm_server’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -9

业务无影响，CM Server进程1s后由CMA组件自动拉起。CM Server主节点异常会发生切换。

2）CM Server所有节点进程挂起

ps –fu $USER|grep ‘bin/cm_server’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -19

业务无影响，CM Server进程1s后由CMA组件kill并自动拉起。CM Server主节点异常会发生切换。

2.5 CM Agent组件故障有效性

2.5.1 测试目标

考察CM Agent异常时对业务的影响。

2.5.2 故障场景

1）CM Agent所有节点kill进程

ps –fu $USER|grep ‘bin/cm_agent’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -9

业务无影响，CM Server进程1s后由OMM组件自动拉起。

2）CM Agent所有节点进程挂起

ps –fu $USER|grep ‘bin/cm_agent’|grep –v ‘grep’ | awk ‘{print $2}’|xargs kill -19

业务无影响，CM Server进程1s后由OMM组件kill并自动拉起。

2.6 备份影响验证

2.6.1 测试目标

考察GaussDB数据库在主节点和备节点备份时候对读写业务的影响。

2.6.2 测试场景

1）GaussDB数据库主节点发起备份对读写业务影响

经测试验证，主节点备份期间TPS下降40%左右，备份结束后恢复。

2）GaussDB数据库备节点发起备份对读写业务影响

经测试验证，备节点备份期间TPS和响应时间没有明显变化，对业务无影响。

3）GaussDB数据库备节点发起备份对备节点读业务影响

经测试验证，备节点备份期间备节点只读业务TPS和响应时间没有明显变化，对业务无影响。

2.7 AZ故障切换影响验证

2.7.1 测试目标

考察GaussDB数据库在AZ故障手动切换的时候对业务的影响。

2.7.2 测试场景

1）DN节点执行AZ切换

#switchover切换操作
cm_ctl switchover -z AZ2

切换期间TPS降为0，持续约9s，为DN节点主备AZ切换时间。

2）数据库管理平台（TPOPS）执行AZ切换

切换期间TPS降为0，持续约9s，为DN节点主备AZ切换时间。

2.8 DN主节点服务器性能degrade

2.8.1 测试目标

考察GaussDB数据库DN主节点服务器网络性能异常时对业务的影响。

2.8.2 测试场景

1）DN主节点网络延时高

#模拟网络延迟高操作
tc qdisc add dev eth0 root netem delay 2ms 0.3ms
#取消网络延迟高操作
tc qdisc del dev eth0 root netem delay 2ms 0.3ms

故障期间TPS下降约60%，网络恢复后TPS恢复正常。

2）DN主节点网络抖动高

#模拟网络抖动高操作
tc qdisc add dev eth0 root netem delay 0.1ms 2ms
#取消网络抖动高操作
tc qdisc del dev eth0 root netem delay 0.1ms 2ms

故障期间TPS下降约60%，网络恢复后TPS恢复正常。

3）DN主节点网络重传高

#模拟网络重传高操作
tc qdisc add dev eth0 root netem loss 10%
#取消网络重传高操作
tc qdisc del dev eth0 root netem loss 10%

故障期间TPS下降约95%，网络恢复后TPS恢复正常。

3、高可用测试总结

总体上来说，GaussDB数据库具备DN主节点进程和服务器异常时自动切换的能力、支持AZ机房级别的手动切换。这里测试验证了DN主节点故障、DN备节点异常等主要场景的高可用能力，测试结果如下表所示：

DN主节点异常时，能够正常切换到备节点，切换期间业务TPS降为0，影响时长约10s。
DN备节点异常时，CMA会自动拉起进程。在所有DN备节点异常时，保证高可靠性的前提下，数据库会变成只读状态，故障恢复时间为备节点恢复时间。
当DN节点进程挂起或服务端口假活状态时，DN会触发僵死状态的检测，此时DN异常处理的时长100s~200s。
当DN主节点网络异常时，DN主备虽然发生了切换，但是应用和DN原主节点之间的旧链接并没有立即释放，此时数据库端是无法主动断开这个连接（网络通信已经异常了，无法发送网络包），需要在应用侧或驱动侧配置链路超时断开机制，这样旧的连接会及时释放掉，业务请求会通过新主建立新的链接。不然业务请求会一直通过旧连接过来，交易会访问失败的。
ETCD节点、CM Server节点和CM Agent节点异常时，对业务无影响，只会影响本身的监控和切换功能。ETCD主节点和CM Server主节点异常时都会发生主备切换。
GaussDB数据库支持AZ级别的手动切换，切换期间业务TPS降为0，影响时长约10s。
备份期间的影响，如果是在DN主节点备份，TPS会下降40%，所以要求在备节点备份。备节点备份期间对主备节点的业务没有影响。

在这里插入图片描述