openGauss之主备切换

2022-05-11 15:33:50 3.2k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

openGauss实例主备切换对于同一数据库，上一次主备切换未完成，不能执行下一次切换。当业务正在操作时，发起switchover，可能主机的线程无法停止导致switchover显示超时，实际后台仍然在运行，等主机线程停止后，switchover即可完成。其他备机正在build的情况下，主机需要发送日志到备机后，才能降备，导致主备切换时间长。另外，switchover级联备机后，级联备机切换为备机，原备机降为级联备。切换过程中，因网络故障、磁盘满等原因造成主备实例连接断开，出现双主现象时，此时请参考如下步骤修复。阅读详情

1.主备切换

主备节点都处于正常状态，主备切换只是交换双方在数据库集簇中的角色，通过gs_ctl工具实现主备实例切换，操作步骤如下：
1）查看主备情况，以omm用户登录任意节点主机：

gs_om -t status --detail

2)以omm用户登录备节点主机OG2：
准确来说，执行下述命令的意思是将当前节点升主，其他节点降备，如果在主库上执行，本来就是主库，执行之后当然没有影响了。所以为了达到试验效果，我们在备库上执行下述命令：

gs_ctl switchover -D /data/og2
[omm@OG2 ~]$ gs_ctl switchover -D /data/og2
[2022-05-11 10:51:07.804][19219][][gs_ctl]: gs_ctl switchover ,datadir is /data/og2 
[2022-05-11 10:51:07.804][19219][][gs_ctl]: switchover term (1)
[2022-05-11 10:51:07.821][19219][][gs_ctl]: waiting for server to switchover...........
[2022-05-11 10:51:15.916][19219][][gs_ctl]: done
[2022-05-11 10:51:15.916][19219][][gs_ctl]: switchover completed (/data/og2)

/data/og2为备节点的数据目录

3)记录主备机器信息

gs_om -t refreshconf
[omm@OG2 ~]$ gs_om -t refreshconf
Generating dynamic configuration file for all nodes.
Successfully generated dynamic configuration file.

4)查验

[omm@OG2 ~]$ gs_om -t status --detail
[   Cluster State   ]

cluster_state   : Normal
redistributing  : No
current_az      : AZ_ALL

[  Datanode State   ]

    nodenode_ip         port      instance          state
------------------------------------------------------------------------
1  OG1 192.168.1.100   15400      6001 /data/og1   P Standby Normal
2  OG2 192.168.1.101   15400      6002 /data/og2   S Primary Normal

经查，备节点OG2确实切换成了主节点。

2.使用场景：

需要进行主备切换时，例如数据库进行故障转移后需要恢复原来的主备关系，或发现数据库主机硬件异常，需要进行主备切换，保证数据库业务的持续性。
说明：
（1）级联备机不能直接转换为主机，只能先通过switchover或者failover成为备机，然后再切换为主机
（2）主备切换为维护操作，确保openGauss状态正常，所有业务结束后，再进行切换操作。

3.双主现象

1）解决双主现象的基本步骤

如果由于网络故障、磁盘满等导致主备连接断开，出现双主现象，恢复步骤如下，否则会导致数据丢失：
（1）查看主备状态，如果都是两个数据库节点都为primary，说明出现故障

gs_om -t status --detail

（2）以omm用户登录待降备的节点，然后关闭服务:

gs_ctl stop -D /data/og2

（3）然后以standby模式启动服务:

gs_ctl start -D /data/og2 -M standby

（4）保存数据库主备机器信息

gs_om -t refreshconf

（5）检查确认

gs_om -t status --detail

2)模拟双主现象

为了做上面的双主现象实验，在og1和og2成功进行主备切换之后，现在的状态为：
og1 备
og2 主
（1）为了达到双主,登录OG1主机，执行如下命令：

gs_ctl stop -D /data/og1
gs_ctl start -D /data/og1 -M primary	//以primary模式启动OG1

然后查看状态:

gs_om -t status --detail
[omm@OG1 ~]$ gs_om -t status --detail
[   Cluster State   ]

cluster_state   : Unavailable
redistributing  : No
current_az      : AZ_ALL

[  Datanode State   ]

    nodenode_ip         port      instance          state
------------------------------------------------------------------------
1  OG1 192.168.1.100   15400      6001 /data/og1   P Primary Normal
2  OG2 192.168.1.101   15400      6002 /data/og2   S Primary Normal

确实出现了双主现象。
当然我们可以通过failover模拟双主现象，例如：在主备正常的情况下，在备库下执行gs_ctl failover故障转移，将当前备库提升为主，此时查看数据库集簇的状态就会发现，两个节点都是主节点。当然failover故障转移是用在，当主库挂掉了，在备库上执行，将备库提升为主，继续向外提供服务，保持业务的持续稳定性。

3）恢复

此时我想要将数据库集簇恢复到一主一备的状态，且og1为主，og2为备，根据恢复基本步骤，登录og2节点，进行如下操作：

gs_ctl stop -D /data/og2 
gs_ctl start -D /data/og2 -M standby
gs_om -t refreshconf

操作完毕之后，查看数据库集簇状态：

[omm@OG2 ~]$ gs_om -t status --detail
[   Cluster State   ]

cluster_state   : Degraded
redistributing  : No
current_az      : AZ_ALL

[  Datanode State   ]

    nodenode_ip         port      instance          state
------------------------------------------------------------------------
1  OG1 192.168.1.100   15400      6001 /data/og1   P Primary Normal
2  OG2 192.168.1.101   15400      6002 /data/og2   S Standby Need repair(WAL)

发现一主一备的关系恢复了，但是OG2出现故障需要恢复，可能是主备不一致导致的问题。

4）修复 Standby Need repair

方法一：重新安装openGauss：
卸载：
(1)以omm用户登录任意主机执行：
gs_uninstall --delete-data
(2)安装openGauss
gs_install -X /opt/software/openGauss/cluster_config.xml --gsinit-parameter="–
locale=en_US.utf8"
其中要求输入数据库密码。
这种方法你估计不喜欢。

方法二：
概述：备份og2节点数据目录下的配置文件，将og2节点的数据库数据目录清空，然后将og1节点的数据目录下的文件拷贝过来，使用备份的配置文件替换拷贝过来的配置文件。
（0）关闭数据库集簇

gs_om -t stop

（1）备份og2节点数据目录下的配置文件

[root@OG2 ~]# mkdir /og2conf
[root@OG2 ~]# chown omm.dbgrp /og2conf
[root@OG2 ~]# su - omm
Last login: Wed May 11 09:49:38 CST 2022 on pts/0
[omm@OG2 ~]$ cp /data/og2/*.conf /og2conf

（2）清空og2节点的数据目录

[omm@OG2 ~]$ rm -rf /data/og2/*

（3）登录og1，将og1节点的数据目录下的所有文件拷贝到og2节点的数据目录下：

[omm@OG1 ~]$ scp -rp /data/og1/* og2:/data/og2

（4）登录og2，替换配置文件

[omm@OG2 ~]$ cp /og2conf/* /data/og2

（5）启动数据库集簇,并检查集簇状态

[omm@OG1 ~]$ gs_om -t start
Starting cluster.
=========================================
[SUCCESS] OG1
2022-05-11 11:23:30.967 627b2c32.1 [unknown] 140707753452480 [unknown] 0 dn_6001_6002 01000  0 [BACKEND] WARNING:  Failed to initialize the memory protect for g_instance.attr.attr_storage.cstore_buffers (1024 Mbytes) or shared memory (2462 Mbytes) is larger.
[SUCCESS] OG2
2022-05-11 11:23:34.410 627b2c36.1 [unknown] 140529291215808 [unknown] 0 dn_6001_6002 01000  0 [BACKEND] WARNING:  Failed to initialize the memory protect for g_instance.attr.attr_storage.cstore_buffers (1024 Mbytes) or shared memory (2462 Mbytes) is larger.
Waiting for check cluster state...
=========================================
Successfully started.
[omm@OG1 ~]$ gs_om -t status --detail
[   Cluster State   ]

cluster_state   : Normal
redistributing  : No
current_az      : AZ_ALL

[  Datanode State   ]

    nodenode_ip         port      instance          state
------------------------------------------------------------------------
1  OG1 192.168.1.100   15400      6001 /data/og1   P Primary Normal
2  OG2 192.168.1.101   15400      6002 /data/og2   S Standby Normal

可以发现，Standby Need repair故障就解决了。

...全文