MatrixDB的高可用架构测试实验

上一篇遇到的问题：

Q1: MatriDB可以搭建集群环境吗？

A: 这个是可以的，具体可以参照官方手册：https://ymatrix.cn/doc/4.1/install/mx4_cluster
，另外，MatrixDB除了数据库单节点部署和多节点部署外，还支持数据库的在线扩容， 在扩容过程中，可以实现对定制化业务低峰期进行数据重分布

Q2.MatrixDB有没有olap的多表关联的场景应用

A:  这个是有这样的场景的。MatrixDB是全球首款同时支持在线事务处理（OLTP）、在线分析处理（OLAP）和物联网时序应用的超融合型分布式数据库产品，具备严格分布式事务一致性、水平在线扩容、安全可靠、成熟稳定、兼容PostgreSQL/Greenplum协议和生态等重要特性。作为一款分布式的超融合时序数据库，他的数据库内核版本基于PostgreSQL 12 和 GreenPlum7，除了支持特定的时序场景外，分析型业务场景也是MatrixDB擅长的领域。

文章仅作为我的初学记录，如果错误，敬请指正！

MatrixDB架构概念介绍

由于MatrixDB的多节点集群部署和单节点部署的流程一致，这里就不再赘述了，应朋友要求，他想了解下MatrixDB高可用相关的知识，那么今天我们主要测试下MatrixDB的高可用特性。在说MatrixDB高可用之前，我们需要先了解几个概念：

• master：master节点是MatrixDB数据库集群的入口，他主要负责接受来自客户端的连接并处理用户发出的SQL命令以及SQL执行结果的汇集。在master节点主要不会存储业务数据，他只会存储一些系统元数据和监控用的masteronly表数据
• standby master：这是master节点的备份节点，正常情况下，standby只提供备份服务，不建议进行查询服务。当primary master节点因为故障而不能继续提供服务时，需要数据库系统管理员执行主备切换命令，手工把standby拉成primary 角色，客户端需要重新连接新的primary master节点，这个过程会丢失一部分在原primary节点故障时没有commit的操作。
• segment primary：业务数据的存储节点，在主节点的协调下，参与用户查询的执行
• segment mirror：primary segment的备份节点，Master节点能够检测到primary segment的状态，当primary segment不能继续提供服务时，会主动激活mirror segment成为新的primary。正常情况下primary segment处于active状态

高可用架构实验

实验用数据库架构

postgres=# select * from gp_segment_configuration order by 2;
 dbid | content | role | preferred_role | mode | status | port | hostname | address |         datadir
------+---------+------+----------------+------+--------+------+----------+---------+-------------------------
    1 |      -1 | p    | p              | n    | u      | 5432 | mydb1    | mydb1   | /mxdata/master/mxseg-1
    6 |      -1 | m    | m              | s    | u      | 5432 | mydb2    | mydb2   | /mxdata/standby/mxseg-1
    2 |       0 | p    | p              | s    | u      | 6000 | mydb3    | mydb3   | /mxdata/primary/mxseg0
    4 |       0 | m    | m              | s    | u      | 6001 | mydb4    | mydb4   | /mxdata/mirror/mxseg0
    3 |       1 | p    | p              | s    | u      | 6000 | mydb4    | mydb4   | /mxdata/primary/mxseg1
    5 |       1 | m    | m              | s    | u      | 6001 | mydb3    | mydb3   | /mxdata/mirror/mxseg1

master节点宕机

查看standby节点状态

$ gpstate -f

模拟master节点宕机

# Optional. Shuts down a Greenplum master instance that was started in maintenance mode.
$ gpstop -m

查看集群状态

$ gpstate

集群master异常后，我们应该提升standby作为master

激活standby节点

在standby所在主机操作

[mxadmin@mydb2 ~]$ export PGPORT=5432
[mxadmin@mydb2 ~]$ gpactivatestandby -a -d /mxdata/standby/mxseg-1

查看集群状态

postgres=# select * from gp_segment_configuration order by 2;

恢复宕机master为standby节点

移除master上旧的data_directory

cd /mxdata/master && mv mxseg-1 mxseg-1_old

重新初始化一个新的standby

[mxadmin@mydb2 standby]$ gpinitstandby -s mydb1 -S /mxdata/master/mxseg-1

note: 如果需要恢复集群初始状态，则需要再进行一次同样的操作即可

standby节点宕机

模拟standby节点宕机

/usr/local/matrixdb-4.2.0.community/bin/pg_ctl -D /mxdata/standby/mxseg-1/ stop -mf

如果可以直接启动standby，那么可以直接运行gpinitstandby -n
或者可以选择重新初始化standby节点

segment primary节点宕机

模拟segment primary节点宕机

# 也可以使用命令：gpstop --host xxxx
$ /usr/local/matrixdb-4.2.0.community/bin/pg_ctl -D /mxdata/primary/mxseg0/ stop -mf


$ gpstate -Q

当primary segment异常宕机后，对应的mirror segment会立即接管primary segment的位置，保证服务能够正常提供

恢复宕机节点

# Rebalance your Greenplum Database system after a recovery by resetting all segments to their preferred role. First check that all segments are up and synchronized.
gprecoverseg
gprecoverseg -r

segment mirror节点宕机

当mirror节点挂掉后，不会对业务产生任何影响，找到原因解决后直接恢复即可

gprecoverseg

实验总结

在进行MatrixDB高可用实验过程中，数据库提供了数据库故障检测恢复和故障转移工具，并且segment之间发生故障后会进行自动检测和转移，但是在数据库进行故障转移之后，并没有进行failback的操作，为了集群能够自动进行failback，可以通过shell脚本去实现自动执行

常见问题

Q1. 数据库启动时报错：“gpstart error: Do not have enough valid segments to start the array”

A: 通过报错的可以看出集群启动不成功是因为primary 或者mirror宕机的太多导致的不能构成完整的"gp集群"，例如一个集群对应的primary segment和mirror segment同时启动失败。那么首先我们需要查看节点启动失败原因。

• 资源限制，例如磁盘空间不足/内存不足等。找到启动失败的实例日志，日志中如果有类似如下信息或者任何资源不足的信息，那么请先尝试解决掉他再去重新启动

2021-11-01 11:20:53.168491 CST,,,p378298,th1709701248,,,,0,,,seg0,,,,,"FATAL","53100","could not create lock file ""postmaster.pid"": No space left on device",,,,,,,,"CreateLockFile","miscinit.c",994,1    0xd55303 postgres errstart (elog.c:498)
    0xd6e87c postgres <symbol not found> (miscinit.c:991)
    0xaf77e6 postgres PostmasterMain (postmaster.c:1164)
    0x6ce2f9 postgres main (discriminator 17)
    0x7fc662846555 libc.so.6 __libc_start_main + 0xf5
    0x6d9e1f postgres <symbol not found> + 0x6d9e1f

Q2. 一个集群有120个seg(包括primary60 和 mirror60 ), 问挂掉多少个才会集群起不来？

A: 在MatrixDB集群架构下，Segment primary和Segment mirror是一一对应的，所以理论上在整个集群中，存放相同数据的segment只有两个。在整个MatrixDB集群中，集群起不来和挂掉多少个Segment没有必然的关系，如果运气好，120个segment的集群最多挂掉60个Segment也能正常启动，如果你是同一份数据的Segment的primary和mirror同时挂掉了，那么即使你只挂掉了2个segment，整个集群也不能正常启动，启动时会产生报错”gpstart error: Do not have enough valid segments to start the array“