生产数据库运行过程中可能会涉及到升级或者打补丁，导致各节点的角色有计划的发生改变。如果集群内角色发生改变，是否还能保持原有架构继续对外提供服务呢？我们来做一下测试。

采用2+2模式模拟同城两机房部署4节点 MogDB 数据库集群，即主机房是primary节点和1个备库，同城节点是1个备库和1个级联从库。

测试的目标是：无论我们怎么切换主库，希望在集群节点都正常运行的情况下始终保持这个2+2的架构。接下来我们以switchover的方式来进行切换测试。

1 测试

数据库准备

利用PTK一键安装 MogDB 进行数据库安装。安装后集群的初始状态是1主2备1级联。如下图所示，45是主库，46和47是备库，48是级联从库。

各节点同步角色配置

45(dn_6001): synchronous_standby_names='first 2 (dn_6002,dn_6003)'


46(dn_6002): synchronous_standby_names='first 2 (dn_6001,dn_6003)'


47(dn_6003): synchronous_standby_names='first 2 (dn_6001,dn_6004)'


48(dn_6004): synchronous_standby_names='first 2 (dn_6001,dn_6003)'

本地机房切主

将主库由45切到46，执行ptk cluster switchover -n switchtest -H 172.16.3.46

在46上查询同步状态，45和47是同步备，48是级联从，符合预期。

同城机房切主

将主库由46切到47，执行ptk cluster switchover -n switchtest -H 172.16.3.46

在47上查询同步状态，45是同步备，46是异步备，48是Need repair状态，不符合预期。

原因分析

级联从永远是级联从，不会将角色自动变为同步备或异步备；
备库可以升级为主库，但不会变为级联从。

处理步骤

修改数据库参数，将需要变成级联从的replconninfo参数添加iscascade=true，将其他replconninfo中的iscascade=true去掉；
重启原级联节点和新级联节点，重启的方式有两种，一种是直接通过gs_ctl命令重启，另一种是修改ptk的配置参数后重启。

47节点修改参数前后：

48节点修改参数前后，需要添加其他备库同步信息：

46节点修改参数前后，需要去掉其他同步备信息：

45节点修改参数前后：

重启新级联节点

重启原级联节点

2 结论

如果集群中不存在级联从，不需要人为参与；
如果集群中有级联从，需要手工修改数据库参数，并且需要对原级联和新级联节点进行重启。

关于作者

高云龙，云和恩墨南北大区服务总监，擅长 PostgreSQL / Greenplum / Citus 数据库架构设计、故障处理、运维优化及数据库迁移，乐于数据库技术分享，曾任职去哪儿网及某金融公司，负责核心数据库架构建设，目前在云和恩墨从事 PG / MogDB / openGauss 数据库交付管理工作。

ITPub博客

循序渐进丨MogDB 数据库带级联从库的集群切换后如何保持原有架构？

数据库准备

各节点同步角色配置

本地机房切主

同城机房切主

最新文章