GBase 8c数据库分布式形态采用share nothing的分布式架构,计算节点和存储节点分离。节点间通过高速网络进行通信,所有节点都有主从互备,确保系统的极致高可用。

本文主要包含GBase 8c V5_3.0.0 分布式部署(单机安装)的简单流程,供测试。

一、架构介绍
image.png

GBase 8c分布式数据库实际包含CN、DN、GTM和HA管理组件,各个组件具体介绍如下:

CN:协调器
CN:协调器,采用完全对等的部署方式。对外提供接口,负责进行SQL解析和优化、生成执行计划,并协调数据节点进行数据查询和写入。在功能上CN上只存储系统的全局元数据,并不存储实际的业务数据;在部署上,CN多个节点完全对等的部署方式,每个节点在同一时间对外都提供相同的数据库视图,所以我们的CN节点高可用可以根据实际的业务需求,部署1个或多个都可以,多个CN节点可以部署在同机房、同城、异地都可以。

DN:数据节点
DN:数据节点,采用主备的高可用架构,主备之间可以配置同步或异步方式。用于处理存储本节点相关的元数据,每个节点还存储它所在的业务数据的分片。在功能上,DN节点负责完成执行协调器节点分发的执行请求,完成数据存储和本地数据查询和写入;在部署上,DN节点每个高可用组采用主从备份的方式,可以部署单主、一主一从以及一主多从的部署方式均可,主从之间可以配置为同步的备份方式也可以配置为异步的备份方式,也可以在一个高可用组内同时存在同步和异步的节点,一般同机房同城的节点之间采用同步的备份方式,异地的节点之间采用异步的备份方式。

GTM:全局事务管理器
GTM:全局事务管理器,采用主备的高可用架构,主备之间可以配置同步或异步方式。主要是做分布式事务,负责生成并维护全局时间戳,保证集群数据一致性。在部署上,GTM的与DN节点的部署类似,也是一主多从的备份方式,节点间可以采用同步的备份方式也可以采用异步的备份方式。

HA Center / DCS(等效于ETCD)
HA Center(等效于ETCD):集群状态管理器,采用Raft的复制协议。存储各个节点的高可用状态,负责在故障情况下判断集群各个节点状态。

GHA Server(等效于patroni)
GHA Server(等效于patroni):集群管理器,采用主备的高可用架构,主备之间可以配置同步或异步方式。用以管理整个集群各个节点的高可用状态(主备、死活等)。GHA Server的主备信息与DN类似,也是将leader信息存在HA Center上,谁先写谁就是主,需要周期更新,如果超过TTL没更新就会删掉leader信息,其他节点去写就能写进去就变成leader了。

具体在server服务器上体现的是高可用进程:
gha_server是主要运行在管理节点的服务进程,管理整个集群节点间进程和集群状态,具体工作原理如下:

rpc:消息通信,gha_ctl所有消息都是通过rpc发给gha_server,gha_server处理完之后通过rpc发给gha_agent,gha_agent返给gha_server再返出去
arbiter:决策进程,是gha_server最繁忙的进程。 用来决策节点死活、断网等。
leader checker:gha_server本身是主备的架构,为了防止出现双主的情况,做了主的检测。leader ping所有的ha center节点,如果都失败说明孤岛了,就自己把leader让出来。
cluster_info_publisher:网络拓扑信息通信,周期发给gha_agent。
dcs_updater:因为gha_server内部存的状态信息会频繁变化,有时候往ha center上写会写失败,写失败就放到dcs_updater里面置个标志位,接着往下写(为了保证ha center上的状态都是最新的是正确的)
GHA Agent
GHA Agent跟着每个CN和DN上都有,作为代理,接收GHA Server的消息并处理。

gha_agent运行在每个节点上,执行由gha_server进程下发或主动监控上报消息给gha_server,具体工作原理如下:

rpc:和gha_server进行消息通信
reporter:周期查询数据库状态,会周期(3秒)更新给gha_server的arbiter。
state reporter:取自己节点的pgxcnode表周期更新给gha_server,gha_server跟自己的网络拓扑对比,发现跟自己的网络拓扑不一样就做查缺补漏
ha state reporter:为了防止出现DN双主,现在的高可用系统在判断DN主坏掉的过程是gha_server收不到gha_agent的消息了。但是如果是断网的情况,就会有主备倒换的误操作(DN主没坏,只是跟gha_server通不上信了),就会双主。为了防止出现双主的情况, ha state reporter用于DN备机与DN主机周期通信,需要半数以上DN备机判断DN主失联才会触发主备倒换。
leader checker:DN或者GTM的主发现自己进入孤岛,就会自动把自己的leader让出来并重启。
部署一套GBase 8c单机分布式环境至少需要以下节点:

1个 GHA_SERVER 节点
1个 DCS 节点
1个 GTM 节点
1个 CN 节点
1个 DN 节点(2个 DN 节点才能体验到数据分布式特性)
二、准备环境
1.用户配置

groupadd gbase
useradd -m -d /home/gbase gbase -g gbase
passwd gbase 
 
vi /etc/sudoers
//按键“i”进入编辑模式,在打开文件如下位置,增加gbase用户及权限:
 
## Allow root to run any commands anywhere
root ALL=(ALL) ALL
gbase ALL=(ALL) NOPASSWD:ALL

2.配置系统内核信号量参数

//配置系统内核参数,避免信号量不足无法初始化。编辑系统内核的配置文件,修改参数:
 
echo "kernel.sem = 40960 2048000 40960 20480" >> /etc/sysctl.conf
//并执行sysctl -p使配置生效
 
sysctl -p

3.互信配置
当前分布式版本中,虽然我们部署在一台服务器上,但因为部署安装包的过程中默认会使用 ssh 协议进行安装,因此我们仍需要配置单台服务器的ssh免密互信。

[root@gbase8c ~]$ su - gbase
[gbase@gbase8c ~]$ mkdir ~/.ssh
[gbase@gbase8c ~]$ chmod 700 ~/.ssh
[gbase@gbase8c ~]$ ssh-keygen -t rsa
 
//将公钥文件上传至本机(此操作需输入gbase用户密码),本机IP请根据实际情况修改。
[gbase@gbase8c ~]$ ssh-copy-id gbase@IP

4.调整 overcommit 参数
Overcommit指的是进程能够申请到的内存,可能比实际可用内存大。这是Linux为了提高内存的利用率,以便能够运行更多的程序。在这种情况下,有的进程分配内存可能会失败,而有的进程则可能被操作系统kill掉。此处机制是由 vm.overcommit_memory参数进行控制,该参数有3个可选值:

vm.overcommit_memory = 0:允许 overcommit,申请内存的时候根据⼀定的算法估算可用的内存量, 拒绝明显无效的请求(比如⼀次malloc的内存超过了系统总内存)
vm.overcommit_memory = 1:允许 overcommit,申请内存的时候不进行限制
vm.overcommit_memory = 2:不允许 overcommit
一般默认的vm.overcommit_memory参数为0。测试环境可以将此值调节成1,来设定总是允许申请的内存超过物理内存大小。
调整方式:

echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf
sysctl -p

三、部署分布式数据库
1、上传安装包并解压

[root@gbase8c ~]$ su - gbase
[gbaset@gbase8c ~]$ mkdir /home/gbase/gbase_package

上传安装包到/home/gbase/gbase_package 目录下,并进行解压

tar -xf GBase8cV5_S3.0.0B114_centos7.8_x86_64.tar.gz
tar -xf GBase8cV5_S3.0.0B114_CentOS_x86_64.tar.bz2

2、编辑 yml 配置文件
编辑gbase.yml

 cp /home/gbase/gbase_package/gbase.yml /home/gbase
vim /home/gbase/gbase.yml

例如,我们在一台服务器上部署1个GTM、1个CN、3个DN节点以及其他高可用相关节点,根据安装环境修改配置文件中的host参数等信息。配置文件内容如下:

gha_server:
  - gha_server1:
      host: 172.20.10.8
      port: 20001
dcs:
  - host: 172.20.10.8
    port: 2379
gtm:
  - gtm1:
      host: 172.20.10.8
      agent_host: 172.20.10.8
      role: primary
      port: 6666
      agent_port: 8001
      work_dir: /home/gbase/data/gtm
coordinator:
  - cn1:
      host: 172.20.10.8
      agent_host: 172.20.10.8
      role: primary
      port: 5432
      agent_port: 8003
      work_dir: /home/gbase/data/coord/cn1
datanode:
  - dn1:
      - dn1_1:
          host: 172.20.10.8
          agent_host: 172.20.10.8
          role: primary
          port: 15432
          agent_port: 8005
          work_dir: /home/gbase/data/dn1/dn1_1
  - dn2:
      - dn2_1:
          host: 172.20.10.8
          agent_host: 172.20.10.8
          role: primary
          port: 15442
          agent_port: 8006
          work_dir: /home/gbase/data/dn2/dn2_1
  - dn3:
      - dn3_1:
          host: 172.20.10.8
          agent_host: 172.20.10.8
          role: primary
          port: 15452
          agent_port: 8007
          work_dir: /home/gbase/data/dn3/dn3_1
env:
  # cluster_type allowed values: multiple-nodes, single-inst, default is multiple-nodes
  cluster_type: multiple-nodes
  pkg_path: /home/gbase/gbase_package
  prefix: /home/gbase/gbase_db
  version: V5_S3.0.0B114
  user: gbase
  port: 22
  third_ssh: false
# constant:
#   virtual_ip: 100.0.1.254/24

3、部署分布式数据库
通过安装目录script工具库下的gha_ctl工具进行安装部署,执行命令:

[gbase@gbase8c ~]$ /home/gbase/gbase_package/script/gha_ctl install -c gbase -p /home/gbase/

-c参数:指定数据库名称,为可选字段。缺省默认值gbase。
-p参数:指定配置文件保存路径,为可选字段。缺省默认值/home/gbase。
安装过程报了缺少 patch包的问题,yum install -y patch后解决
image.png

我因为本地内存配置太小起不来库,因此手动调整gtm、cn、dn节点的内存参数,手动拉起数据库。
最后启动成功的结果显示

image.png

部署成功后,使用gha_ctl monitor查看节点运行情况(跟dcs的地址和端口)

[gbase@gbase8c ~]$ gha_ctl monitor -c gbase -l http://172.20.10.6:2379 -H

image.png

登录cn节点

image.png

cn的数据库,默认postgres数据库下的schema还是挺多的。

image.png


读研的抽屉
1 声望0 粉丝