南大通用GBase 8a V8版本节点替换期间通过并发数控制资源使用减少对系统影响的方法

在节点替换期间,需要从备份节点读取并传输大量数据,必然会对现有系统造成影响。在V9版本里是通过重分布的方式实现同步,可以控制并发数,暂停恢复等;而在V8版本里无这个功能,如果用户对性能影响更敏感,接受更长时间的时候,可以通过人工减少同步进程的方式,来减少对系统的影响。

参考

GBase 8a V95版本节点替换操作手顺

GBase 8a 强制节点离线和节点替换replace

有关参数和配置

监控配置文件

gcluster/config/gcmonit.cnf, 注意是1个m,不是gcmmonit.cnf

注释掉如下部分

#[gcrecover]
#fail2ok_trigger_cmd=
#prog_name=gcrecover
#ok2fail_trigger_cmd="sh /opt/gbase/gcluster/server/bin/gcluster_services gcrecover start"

同步配置文件

gcluster/config/gc_recover.cnf

 在文件末尾增加或修改如下参数: 最小是2,最大15,默认值10

recover_thread_num=2

操作过程

将所有管理节点的gcrecover服务停掉,然后修改需要启动的一台的配置参数,然后启动。

停掉管理节点的gcrecover服务

注意只保留1个,在所有其它的每个管理节点都要执行。

将管理节点的gcmonit服务停掉

避免其自动拉起数据库服务。

gcmonit.sh stop

将管理节点的gcrecover服务停掉

其不再参与数据恢复业务。

gcluster_services gcrecover stop


修改gcmonit.conf

将gcrecover部分注释掉:安装目录/gcluster/config/gcmonit.cnf, 注意是1个m,不是gcmmonit.cnf

#[gcrecover]
#fail2ok_trigger_cmd=
#prog_name=gcrecover
#ok2fail_trigger_cmd="sh /opt/gbase/gcluster/server/bin/gcluster_services gcrecover start"

然后重启gcmonit服务

gcmonit.sh restart

修改保留的gcrecover配置

修改同步线程数量

修改文件:安装目录/gcluster/config/gc_recover.cnf ,在文件末尾增加或修改如下参数: 最小是2,最大15,默认值10

recover_thread_num=2

重启服务

gcluster_services gcrecover stop

查看同步服务日志

查看日志可以看到只有指定的线程启动。安装目录/gcluster/log/gcluster/gc_recover.log


==================================================
2019-08-19 15:16:11.251 [INFO ] <RECOVER-INFO>: gcrecover started
2019-08-19 15:16:11.262 [INFO ] <RECOVER-INFO>: Create socket Thread is been bulit success now!, threadid: 0x7f3fda34c700
2019-08-19 15:16:11.298 [INFO ] <RECOVER-INFO>: Recover Thread(0x7f3fd9b4b700) is been built success
2019-08-19 15:16:11.298 [INFO ] <RECOVER-INFO>: Recover Thread(0x7f3fd934a700) is been built success
2019-08-19 15:16:11.298 [INFO ] <GCWare>: master node is: 1705224384 192.168.163.101

总结

如上操作后,只有保留的管理节点才有gcrecover进程,每个管理节点启用指定数量的同步进程。如果晚上空闲,可以增加管理节点数量,白天减少数量来调整资源使用情况。

注意:

  • 等同步完成后,记得将如上配置修改的都【还原】,停掉的服务都重启,恢复到最初状态。
  • 故障恢复的节点,如果包含了管理节点,其同步服务gcrecover也会启动,请参考前面操作停止掉。如果是纯数据节点,则没有这个问题。