如何实现openGauss的异构复制以及备份恢复

民生运维人 2021-06-23

1294

引言

openGauss是华为在2020年六月正式开源的关系型数据库，是Gauss数据库家族中的单机版本，自开源之日起就支持多平台及架构。考虑到数据安全性、操作规范等问题，常见的模式是在相同的系统环境以及硬件架构的两台服务器上搭建主备，以应对数据库发生异常情况。但同时，我们也想知道openGauss是否能在跨平台以及异构的情况下，成功搭建主备并建立顺畅的复制通道以及能否满足备份恢复的场景。如果可以成功实现，这将大大提高openGauss在极端情况下的稳健性，并且能够扩展出更加丰富的使用场景。因此对openGauss在异构环境下进行了数据复制以及备份恢复两项测试。

测试环境

按照openGauss支持的系统环境，选择了以下三种搭配进行测试。

测试环境
CPU	X86	ARM	国产X86
OS	Centos 7.6	Kylin V10	Kylin V10

测试目的

本次的测试分为两个部分：备份恢复以及异构主从复制。备份恢复测试希望能够探寻openGauss在不同架构环境下，能否成功使用备份文件恢复数据，并拉起数据库对外提供服务。主从复制测试则希望在两台不同架构的服务器上，建立起主备复制通道，为openGauss拓展出更多的使用场景。

测试范围限定在以下四种：

编号	源	目标
1.	X86	ARM
2.	X86	国产X86
3.	ARM	国产X86
4.	国产X86	ARM

测试过程

3.1. 备份恢复

3.1.1.安装数据库

首先依照openGauss的安装规范，在三台服务器上分别安装单机版openGauss数据库。

随后在omm用户下为源数据库创建备份用户，添加白名单，重启数据库。

gsql -d postgres -p 26000 -r -c "create user backupuser with sysadmin password '<密码>'"
gs_guc reload -N all -I all -h "host  all   all  0.0.0.0/0  sha256"
gs_guc reload -N all -I all -h "host  replication  backupuser  0.0.0.0/0  sha256"
gs_guc reload -N all -I all -c "listen_addresses='*'"
gs_om -t restart

3.1.2.创建测试数据

在源数据库插入测试数据库和数据。可以看到在testdb数据库中，有三个对象：物化视图mv_test，表test以及序列test_c3_seq。其中序列test_c3_seq是表test中绑定到字段c3上的自增序列，mv_test物化视图通过as select * from test生成。在物化视图创建完成后，再向test表中插入一条数据，可以看到此时test表比它的视图多一条数据。如果对物化视图mv_test执行刷新操作，会将新数据加载到视图中。

3.1.3.远程备份并恢复数据库

在目标服务器上创建数据复制路径，关闭数据库并远程物理备份数据。

mkdir /gaussdata/openGauss/remote
gs_basebackup -U backupuser -h <源数据库ip> -p 26000 -D /gaussdata/openGauss/remote

可以看到远程备份执行成功，接下来停止数据库，备份当前服务器上的数据文件，并尝试使用异构数据库的远程备份文件恢复数据。

# 确保本机能够访问数据库
gs_guc reload -N all -I all -c  "listen_addresses='*'"
gs_om -t restart

# 备份
mkdir /gaussdata/openGauss/backup
gs_basebackup -h 127.0.0.1 -p 26000 -D /gaussdata/openGauss/backup/

# 停止服务并替换数据文件，随后拉起数据库
gs_om -t stop
rm -rf /gaussdata/openGauss/db1/*
cp -rf /gaussdata/openGauss/remote/* /gaussdata/openGauss/db1/
gs_om -t start

此时看到此时数据库正常启动。

3.1.4.对比数据

数据库正常启动，并不能认为此时恢复的数据也与源服务器上完全一致。接下来进行对比。

Testdb数据库成功恢复。

名为test的表、物化视图mv_test以及序列test_c3_seq都与源数据库相同，同时test_c3_seq序列也与字段绑定在一起。

可以看到mv_test与test相比缺少一条数据，表和物化视图的数据以及状态都与源数据库相同。

3.1.5.测试结果

在对三种不同架构的进行测试后发现，经过gs_basebackup命令备份的数据库能够在异构环境下都能正常恢复，而直接复制数据库路径下的文件则不能保证恢复。gs_basebackup命令在备份过程中会对数据打上备份的标签，openGauss在启动时读取标签，解析xlog进行数据的备份恢复。直接使用复制的数据文件可能会无法正常启动数据库。

3.2. 异构复制

首先依照openGauss的一般安装流程，挂载数据盘以及日志盘并设置权限，创建omm用户和对应的用户组并配置互信和权限，分别下载解压对应的安装介质到本机上。随后进入到安装的步骤。

3.2.1.主备安装

按照openGauss通常的主备搭建模式，会在openGauss主机上创建XML格式的配置文件。openGauss在安装过程中会将所需的文件传输到备机上。这样的方式大大提高了安装效率，并且在一定程度上减少了因为人为误操作导致安装失败的概率。因此在本次测试中也首先使用了这种方式搭建从库。

1）创建主备模式配置文件

<?xml version="1.0" encoding="UTF-8"?>
<ROOT>
  <CLUSTER>
    <PARAM name="clusterName" value="openGauss" />  
    <PARAM name="nodeNames" value="主机名,备机名" />
    <PARAM name="backIp1s" value="主机IP,备机IP"/>
    <PARAM name="gaussdbAppPath" value="/gauss/openGauss/app" />
    <PARAM name="gaussdbLogPath" value="/gaussarch/log" />
    <PARAM name="tmpMppdbPath" value="/gauss/openGauss/tmp" />
    <PARAM name="gaussdbToolPath" value="/gauss/openGauss/om" />
    <PARAM name="corePath" value="/gaussarch/corefile"/>
    <PARAM name="clusterType" value="single-inst"/>
  </CLUSTER>
  <DEVICELIST>
    <DEVICE sn="1000001">
        <PARAM name="name" value="主机名"/>
        <PARAM name="azName" value="AZ1"/>
        <PARAM name="azPriority" value="1"/>
        <PARAM name="backIp1" value="主机IP"/>
        <PARAM name="sshIp1" value="主机IP"/>
        <PARAM name="dataNum" value="1"/>
        <PARAM name="dataPortBase" value="26000"/>
        <PARAM name="dataNode1" value="/gaussdata/openGauss/db1,备机名,/gaussdata/openGauss/db1"/>
        <PARAM name="dataNode1_syncNum" value="1"/>
    </DEVICE>
    <DEVICE sn="1000002">
        <PARAM name="name" value="备机名"/>
        <PARAM name="azName" value="AZ1"/>
        <PARAM name="azPriority" value="1"/>
        <PARAM name="backIp1" value="备机IP"/>
        <PARAM name="sshIp1" value="备机IP"/>
    </DEVICE>
  </DEVICELIST>

2）在主机上执行gs_preinstall.py进行安装前检查

python3 gs_preinstall  -U omm -G dbgrp -X /gauss/soft/cluster.xml --skip-hostname-set   --non-interactive

在X86为主配置下，报错安装环境不满足需求。通过gs_checkos命令检查发现这是因为搭载X86的操作系统是CentOS7.6，而ARM和国产X86配套的操作系统是麒麟V10，因此无法通过安装前检查。

ARM和国产X86的搭配在安装过程中都出现了错误信息，修改环境变量也无法解决这个问题。

3.2.2.单机模式

由于主备安装的方式会将部分备机所需的安装介质以及配置文件从主机直接传输过去，导致备机使用的是不符合架构或操作系统的安装文件，无法正常安装。因此考虑先在不同架构的服务器上安装两台单机版openGauss数据库，然后再搭建成为主备。

在两台单机版数据库安装完成后，配置数据库参数。

# 添加白名单
gs_guc reload -N all -I all -h "host  all  all  0.0.0.0/0  sha256"  &&
gs_guc reload -N all -I all -h "host    all    all    <本机ip>/32    trust"  &&
gs_guc reload -N all -I all -h "host    all    all    <对机ip>/32    trust"
# 修改guc参数，max_connections在两台服务器上一定要保证一致
gs_guc reload -N all -I all -c "remote_read_mode=off" &&
gs_guc reload -N all -I all -c "listen_addresses  = '*'" &&
gs_guc reload -N all -I all -c "max_connections = 800"
#修改replconninfo1  
replconninfo1 = ‘localhost=<本机ip> localport=26002 localservice=26004 localheartbeatport=26005 localheartbeatport=26005 remotehost=<对机ip>  remoteport=26002 remoteservice=26004 remoteheartbeatport=26005’
# 重启数据库 一台机器以主的身份启动后，另一台以从启动。
#主机
gs_ctl restart -D . -M primary
#备机
gs_ctl restart -D . -M standby && gs_ctl build -D . -b full

等到备机的全量同步数据执行完毕后，查询集群状态。如上图所示可以看到主备关系已经成功建立了，备机上的数据已经100%与主机同步。测试后发现，主机上更新的数据可以正常同步到备机上，复制通道成功建立。此时，openGauss的异构主备就搭建完毕了。

3.2.3.测试结果

由于openGauss安装介质不同的原因，异构服务器需要以先按照单机数据库的方式安装，随后配置复制通道的方式搭建主备。openGauss在三种架构下都可以正常同步数据，数据的复制效果与相同架构上的主备模式完全相同。

发现的问题

4.1. MOT与NUMA冲突

在备份恢复和异构复制两项测试过程中，会发现某型号的CPU在数据重建、参数配置等前期过程都十分顺利，但是随后启动时就发生故障，数据库无法拉起。查找日志后发现根本原因是由于MOT引擎启动失败导致的。

这是因为openGauss的MOT引擎与某些特殊的NUMA结构存在冲突，导致数据库无法启动，而本次测试中使用的某个CPU恰巧有这样的问题。为了规避这个问题，需要将mot.conf文件中的enable_numa参数显性地设置为false，随后数据库就可以正常启动。

4.2. 同步配置文件

openGauss有三个配置文件：pg_hba.conf、postgresql.conf以及mot.conf。这三个文件都在数据文件的路径下。因此在进行备份恢复操作时，这三个配置文件都会随着数据文件备份。同样的在主备复制的过程中，主机上的mot.conf文件会被同步到备机上。

因此如果在数据库启动过程中出现问题，可能是因为这三个配置文件与当前系统环境发生了冲突，尤其是postgresql.conf中的replconninfo参数对数据库启动有较大影响。当数据库不能成功拉起时，可以尝试使用原数据库的配置文件对db1路径下的配置文件进行替换。

总结

这两项测试的结果显示openGauss对于跨平台有不错的支持，异构复制以及跨平台的备份恢复都能够成功实现。虽然使用相同架构的服务器是常规选择，但是也证明了在特殊情况下可以openGauss支持使用异构服务器搭建集群。

opengauss

文章转载自民生运维人，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。