GBase 8a里通过rsync加速调度coor节点的扩容和替换效率

在GBase 8a的早期版本里，扩容或者节点替换调度节点(coordinator)时，是通过本地tar打包，然后scp传输到新节点来实现的，而tar本身不支持并行，所以代码上是将打包任务按表名字分解成多个任务，发到多个调度节点执行(并行打包)。新版本支持通过rsync的方式进行更快速的高效同步。本文介绍与此有关的内容。

GBase 8a的调度集群，只包含表结构等基本元数据，不保存数据，当表数量多时，就成了典型的大量小文件场景。通过rsync可以实现接近1个数量级的同步性能提升。

检查版本是否支持

语法

新增加了gcadmi的参数 check_rsync_valid。 对于不支持该语法的，直接不支持。

gcadmin check_rsync_valid

在V8版本里，没有提供指定dba用户的参数，只需要提供密码，完整格式如下

gcadmin check_rsync_valid <target_coor_ip> dba_os_password password

在V95里，需要指定dbaUser,完整格式如下

gcadmin check_rsync_valid <target_coor_ip> dba_os_user user_name dba_os_password password

提示，如上的 dba_os_user和 dba_os_password是参数名字，对应后面的 user_name 和 password 才是用户要输入的。

提示，密码是加密的，不是明文，具体加密方法，请联系项目对应售后支持人员，熟悉ASCII的可以猜出来算法。

使用样例

根据返回值判断是否成功，0表示成功，支持rsync,其它的不支持。 密码错误也是返回非0

[gbase@gbase_rh7_001 ~]$ gcadmin check_rsync_valid 10.0.2.115 dba_os_user gbase dba_os_password 676261736531323334
[gbase@gbase_rh7_001 ~]$ echo $?
0
[gbase@gbase_rh7_001 ~]$ gcadmin check_rsync_valid 10.0.2.115 dba_os_user gbase dba_os_password 676261736531323335
[gbase@gbase_rh7_001 ~]$ echo $?
1
[gbase@gbase_rh7_001 ~]$

扩容调度节点coor的日志

查看 gcinstall.log， 内部会有检查rsync状态的部分，如果成功，会使用rsync来同步元数据

2022-04-13 11:37:20,293-INFO check rsync command status on available coordinator and new coordinator
2022-04-13 11:37:31,191-INFO use rsync command sync metadata
2022-04-13 11:37:31,192-DEBUG /bin/chown -R gbase:gbase coorHosts.xml
2022-04-13 11:37:36,201-INFO . /home/gbase/.gbase_profile;gcadmin cpcorditbl coorHosts.xml db_user_name root db_password '***' dba_os_user gbase dba_os_password '***' timeout '15' rsync_valid 1
generate sync command file
copy sync command file to available coordinator
execute sync gcluster metadata command on coordinator
check target coordinator metadata begin
check target coordinator metadata end
restart target coordinator gclusterd
sync coordinator metedata start ......
sync coordinator metedata end ......
sync coordinator metedata end,spend time 37951 ms......

2022-04-13 11:38:14,574-DEBUG rm -f coorHosts.xml
2022-04-13 11:38:14,580-INFO ExtendCluster Successfully.

节点替换调度节点coor时的rsync日志

在replace.log里面

2022-04-13 15:57:42,867-DEBUG Starting all gcluster nodes...
2022-04-13 15:57:50,016-INFO start service successfull on host 10.0.2.115.
2022-04-13 15:57:51,540-DEBUG . /home/gbase/.gbase_profile;gcadmin showcluster f
2022-04-13 15:57:51,968-INFO check rsync command status on available coordinator and replaced coordinator
2022-04-13 15:58:05,783-INFO replace node use rsync command sync metadata
2022-04-13 15:58:05,784-INFO Begin to exec gcadmin replacenodes ...
2022-04-13 15:58:05,784-INFO gcadmin replacenodes command: gcadmin replacenodes coor host 10.0.2.115 freenode '' db_user_name root db_password '***' dba_os_user gbase dba_os_password '***' sync_coordi_metadata_timeout 3000 retry_times 1 parallel_pack 0 use_shm 0 rsync_valid 1 2>&1 | tee -a /home/gbase/gcinstall_9.5.2.43.5/replace.log;if [ ${PIPESTATUS[0]} -ne 0 ]; then exit 1; fi;
generate sync command file
copy sync command file to available coordinator
execute sync gcluster metadata command on coordinator
check target coordinator metadata begin
check target coordinator metadata end
restart target coordinator gclusterd
check ip start ......
check ip end ......

switch cluster mode into READONLY start ......
wait all ddl statement stop ......

总结

关于rsync的性能就不讨论了，从各种测试中，针对大量小文件，基本都有接近一个数量级的提升。