在节点替换期间，需要从备份节点读取并传输大量数据，必然会对现有系统造成影响。在V9版本里是通过重分布的方式实现同步，可以控制并发数，暂停恢复等；而在V8版本里无这个功能，如果用户对性能影响更敏感，接受更长时间的时候，可以通过人工减少同步进程的方式，来减少对系统的影响。
目录导航
参考
有关参数和配置
监控配置文件
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也会启动，请参考前面操作停止掉。如果是纯数据节点，则没有这个问题。