openGauss之主备切换

如清风一般 2022-05-11 15:33:50

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故障就解决了。

...全文
943 回复 打赏 收藏 举报
写回复
回复
切换为时间正序
请发表友善的回复…
发表回复
相关推荐
发帖
Gauss松鼠会
加入

1.9w+

社区成员

汇集数据库的爱好者和关注者,大家共同学习、探索、分享数据库前沿知识和技术,像松鼠一样剥开科学的坚果;交流Gauss及其他数据库的使用心得和经验,互助解决问题,共建数据库技术交流圈。
社区管理员
  • Gauss松鼠会
帖子事件
创建了帖子
2022-05-11 15:33
社区公告

欢迎大家同时关注Gauss松鼠会专家酷哥。

https://www.zhihu.com/people/ku-ge-78-98