原文链接：https://www.gbase.cn/community/post/5583
更多精彩内容尽在南大通用GBase技术社区，南大通用致力于成为用户最信赖的数据库产品供应商。
节点替换的理论1.节点故障
2.集群硬件升级
替换的节点类型：
1.coordinator节点
原理：替换安装程序会修改corosync的配置文件，使得新节点能够在集群内代替旧节点
清除ddl恢复日志
2.data节点
原理：替换安装程序会创建用户数据库，设置所有的用户数据全同步标志；
清除ddl恢复日志，dml恢复日志和dml全同步日志（以前节点的同步信息没作用）
3.复合节点（coordinator+data）
注：节点替换会执行清除同步日志信息，同步元数据信息等操作，随后数据同步由自动恢复服务完成
准备替换节点设备硬件-->重新安装集群软件-->进行数据同步操作
注：节点替换的过程中，集群不支持写操作，只能执行select等读操作0
节点替换过程中集群模式的变化：
NORMAL -> READONLY -> NORMAL
同步元数据前：集群模式为 NORMAL,集群可以正常操作
同步元数据期间：集群模式为 READONLY,只允许进行查询操作，不允许任何 dml、 ddl 以及加载操作，此 时进行数据表结构的同步操作，对用户数据表设置全同步标志
同步完成后：集群模式为 NORMAL,集群可以正常操作
替换完成后，集群可以正常进行操作。
节点替换过程中节点的变化：
OFFLINE -> UNAVAILABLE(无效) -> REPLACE -> ONLINE
替换开始前：节点损坏，节点的状态为 OFFLINE,用户必须设置节点状态为 UNAVAILABLE；
替换开始后：节点状态转换为 REPLACE
替换成功后：节点状态转换为 ONLINE
替换执行失败：节点状态回滚为 UNAVAILABLE
注：数据不会丢失
节点替换的步骤1.检查网络状态
保证集群内网络畅通，带宽充裕
2.设置要替换的节点的状态为unavailable；
在操作系统的gbase用户下（demo.options文件中dbauser参数指定的用户）下运行 gcadmin setnodestate 命令设置要替换的节点状态为unavailable（改成unavailable之后，只能做替换操作，不能改成其他模式）
如：gcadmin setnodestate 192.168.18.11 unavailable
3.准备用于节点替换的机器
1).新机器安装和原节点机器的操作系统相同， ip地址设置相同
将原节点关闭，然后将替换节点的ip地址改为被替换节点ip，删除原ssh信任关系
2).符合集群的安装要求，如：关闭防火墙，关闭selinux等
4.查看集群各项状态
CLUSTER STATE: ACTIVE
VIRTUAL CLUSTER MODE: NORMAL
节点状态为unavailable
5.replace.py对节点进行替换安装
[gbase@gbaseman gcinstall]$ python replace.py --help
Usage: replace.py [options] 3
Options:
-h, --help show this help message and exit
-a do not prompt the user for confirmation
--host=HOSTLIST replaced nodes' ip splitting by comma 指定要替换的节点ip， 用','隔离
--rootPwd root 用户的密码， 要求所有节点 root 密码一致。
--root_pwd_file 该参数支持 root 用户在多节点不同密码方式， 与参数rootPwd 不能同时使用， 否 则报错。
--type=NODETYPE replaced nodes' type,value:coor,data 替换节点的类型
--freenode=FREENODE cluster freenodes' ip splitting by comma
--dbaUser=DBAUSER dba user
--dbaUserPwd=DBAPWD dba user password
--generalDBUser=GENDBUSER cluster database user
--generalDBPwd=GENDBPWD
cluster database user password
--overwrite new and complete overwrite 强制覆盖，参数可选
--sync_coordi_metadata_timeout=SYNC_COORDI_METADATA_TIMEOUT 设置coor节点替换的超时时 间，默认为15
sync coordinators' metadata timeout,default 15mins
--parallel_pack=PARALLEL_PACK 节点替换并行打包开关
whether to parallel packaging,value<0 |1>,default 0
--retry_times=RETRY_TIMES 节点替换时同步系统表retry次数默认为3，最小值 为1，最大值为2147483647
replace node retry times,default 3
--use_shm=USE_SHM whether to set path of package,value<0|1>,default 0
--license_file=LICENSE_FILE 在执行节点替换时，需要提前生产lic文件，通过此参数传入
import license file
--vcname=VC_NAME vc name,only support one vc
-p, --addr_protocol domain map address,default False(IPv4)
--passwordInputMode=PASSWORDINPUTMODE 指定密码的获取方式
get password method[file,pwdsame],
file: get from command line parameters,default 文件中获取
pwdsame: nodes have same user passwd 终端输入
pwddiff: 表示从终端由用户输入密码，并且节点间的密码不一致情况下使用该 参数，对于不同用户密码每个节点分别输入一次，适用于不同节点使用不同的密码；
复合节点替换：
1.将节点设置为unavailable
[gbase@gbaseman gcinstall]$ gcadmin setnodestate 192.168.18.11 unavailable;
after set node state into unavailable,can not set the state into normal,
must run gcadmin replacenodes to replace this node ,after that command node state return into normal.
you realy want to set node state into unavailable(yes or no)?
yes
node 192.168.18.11 state already is unavailable, not need repeat set
2.清理feventlog日志
[gbase@gbaseman opt]$ gcadmin rmfeventlog 192.168.18.11
after rmfeventlog 192.168.18.11, fevent log will be removed, must run gcadmin replacenodes to replace this node.
you realy want to remove node 192.168.18.11 fevent log(yes or no)?
yes
delete ddl event log on node 192.168.18.11 start
delete ddl event log on node 192.168.18.11 end
delete dml event log on node 192.168.18.11 start
delete dml event log on node 192.168.18.11 end
delete dml storage event log on node 192.168.18.11 start
delete dml storage event log on node 192.168.18.11 end
3.进行coor节点替换命令
[gbase@gbasedata1 gcinstall]$ ./replace.py --host 192.168.18.11 --type=coor --
dbaUser=gbase --dbaUserPwd=gbase@123 --generalDBUser=gbase --generalDBPwd=gbase@123
4.检查节点状态
[gbase@gbaseman opt]$ gcadmin showcluster
5.清理feventlog日志
[gbase@gbaseman opt]$ gcadmin rmfeventlog 192.168.18.11
after rmfeventlog 192.168.18.11, fevent log will be removed, must run gcadmin replacenodes to replace this node.
you realy want to remove node 192.168.18.11 fevent log(yes or no)?
yes
delete ddl event log on node 192.168.18.11 start
delete ddl event log on node 192.168.18.11 end
delete dml event log on node 192.168.18.11 start
delete dml event log on node 192.168.18.11 end
delete dml storage event log on node 192.168.18.11 start
delete dml storage event log on node 192.168.18.11 end
6.创建中间的distributeion
建立新的 distribution，该分布信息用于剔除被替换节点，其他节点分片分布保持不变。
查看分片信息
[gbase@gbaseman opt]$ gcadmin showdistribution node
Distribution ID: 1 | State: new | Total segment num: 6
========================================================================================
============================================
nodes | 192.168.18.13 | 192.168.18.11
192.168.18.14 |
----------------------------------------------------------------------------------------
------------------------------------------
primary | 1 | 2 | 3 |
segments | 4 | 5 | 6 |
----------------------------------------------------------------------------------------
------------------------------------------
duplicate | 3 | 1 | 2 |
segments 1 | 6 | 4 | 5 |
========================================================================================
============================================
使用 gcadmin getdistribution 命令将待替换节点所在的 vc 的 distribution 信息保存在指定的文件中
[gbase@gbaseman gcinstall]$ gcadmin getdistribution 1 distribution_info_1.xml
gcadmin getdistribution 1 distribution_info_1.xml ...
get segments information
write segments information to file [distribution_info_1.xml]
gcadmin getdistribution information successful
修改新的 distribution 的分布规则信息。
修改原则为让被替换节点没有任何分片，其他节点分片的分布规则不变，
若被替换节点存储的分片是作为主分片，则将该分片的备份分片节点修改为主分片节点，即节点 IP 在 primarynode 标签中，则将该 segment 内的 duplicatenodes标签内的 IP 替换被替换节点 IP，并删除 duplicatenodes 标签。
若被替换节点存储的分片是作为备份分片，即被替换的节点 IP 在 duplicatenodes标签中，则将 该 duplicatenodes 标签删除。
[gbase@gbaseman gcinstall]$ cat distribution_info_1.xml
<?xml version='1.0' encoding="utf-8"?>
<distributions>
<distribution>
<segments>
<segment>
<primarynode ip="192.168.18.13"/>
<duplicatenodes>
<duplicatenode ip="192.168.18.11"/> //删除
</duplicatenodes>
</segment> 13
<segment>
<primarynode ip="192.168.18.11"/> //将备份节点分片修改为主分 片，即把192.168.18.11改为14
<duplicatenodes>
<duplicatenode ip="192.168.18.14"/> //删除
</duplicatenodes>
</segment> 21
<segment>
<primarynode ip="192.168.18.14"/> 24
<duplicatenodes>
<duplicatenode ip="192.168.18.13"/>
</duplicatenodes>
</segment> 29
<segment>
<primarynode ip="192.168.18.13"/> 32
<duplicatenodes>
<duplicatenode ip="192.168.18.11"/> //删除
</duplicatenodes>
</segment> 37
<segment>
<primarynode ip="192.168.18.11"/> //将备份节点分片修改为主 分片，即把192.168.18.11改为14
<duplicatenodes>
<duplicatenode ip="192.168.18.14"/> //删除
</duplicatenodes>
</segment>
<segment>
<primarynode ip="192.168.18.14"/> 48
<duplicatenodes>
<duplicatenode ip="192.168.18.13"/>
</duplicatenodes>
</segment>
</segments>
</distribution>
</distributions>
修改创建 distribution 所需的 gcChangeInfo_vc2.xml 文件
[gbase@gbaseman gcinstall]$ cat gcChangeInfo.xml
<?xml version="1.0" encoding="utf-8"?>
<servers>
<cfgFile file="distribution_info_1.xml"/>
</servers>
执行创建新的 distribution
[gbase@gbaseman gcinstall]$ gcadmin distribution gcChangeInfo.xml
gcadmin generate distribution ...
gcadmin generate distribution successful
查看分片信息
[gbase@gbaseman gcinstall]$ gcadmin showdistribution node
执行 initnodedatamap 命令初始化 hashmap，然后将数据通过 rebalance instance 命令重分布到 最新的 distribution（ Distribution ID： 1）上。
说明：按 distribution 分布规则，此次 rebalance 操作不会实际进行数据搬移，所以会很快完成；
本次 rebalance 操作后不要删掉旧版 nodedatamap 和 distribution。
初始化hashmap
gbase> initnodedatamap;
Query OK, 0 rows affected, 6 warnings (Elapsed: 00:00:00.35)
数据重分布
gbase> rebalance instance;
Query OK, 19 rows affected (Elapsed: 00:00:00.73)
查看rebalance状态
gbase> select index_name,status,percentage,priority,host,distribution_id from gclusterdb.rebalancing_status;
+---------------+-----------+------------+----------+---------------+-----------------+
index_name | status | percentage | priority | host | distribution_id |
+---------------+-----------+------------+----------+---------------+-----------------+
test.t4 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.liguixin | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t10 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t5 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t12 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t16 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t6 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t7 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t15 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t_user1 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t11 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t_user | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t20 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t17 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t1 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t2 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t3 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t14 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
test.t9 | COMPLETED | 100 | 5 | 192.168.18.11 | 2 |
+---------------+-----------+------------+----------+---------------+-----------------+
执行data节点替换命令
[gbase@gbasedata1 gcinstall]$ ./replace.py --host 192.168.18.11 --type=data --
dbaUser=gbase --dbaUserPwd=gbase@123 --generalDBUser=gbase --generalDBPwd=gbase@123
查看节点状态
数据重分布
本次数据重分布将进行实际数据的重分布；重分布的所需时间需要根据数据量，系统 CPU,磁盘，网络 等综合情况进行评估
删除旧的分片id
[gbase@gbasedata1 gcinstall]$ gcadmin rmdistribution 2
cluster distribution ID [2]
it will be removed now
please ensure this is ok, input [Y,y] or [N,n]: y
select count(*) from gbase.nodedatamap where data_distribution_id=2 result is not 0
refreshnodedatamap drop 2 success
gcadmin remove distribution [2] success
节点替换过程需要注意以下问题：1.如果替换coordiantor集群节点，要求总数不可以超过coordiantor集群总数的一半，也就是保证集 群不能是lock状态，因为超过一半集群就进入锁定状态
2.如果是data节点，不可以同时替换主备分片的节点，保证分片必须有可用的备份源数据，如果同时 替换，数据无法拷贝，会导致数据丢失。
3.损坏的节点上有 nocopies 表，数据无法恢复，必须用户手工进行恢复。 nocopies 表数据没有副 本，无法拷贝。
4.损坏的节点上存在不通过集群命令创建的数据，这些数据无法恢复，必须用户手工进行恢复。比 如：集群数据节点当单机使用，在不是集群状态，对数据进行写入。
5.在节点替换过程中，如果出现 replace.py 命令被强杀或者执行replace.py 命令的机器掉电等现象， 可能会导致集群状态处于READONLY状态无法自行恢复正常。此时可以使用gcadmin switchmode normal 恢复集群状态然后继续使用集群。或者再一次执行
6.节点状态转换为 UNAVAILABLE 后，只有在节点替换成功的时候，节点状态才能转换为 ONLINE。
用户不能对 corosync 中的节点状态持久化文件进行手工操作，如果手工修改持久化文件中的节点状态 （UNAVAILABLE - > ONLINE),会导致数据丢失。
7.设置节点为 UNAVAILABLE 时，若集群中有大量 ddl event， dml event或 dmlstorage event
时，程序需要检查所有的 event，判断被设置状态的节点的备份节点是否正常，有大量 event 时，该 过程可能需要较长时间。
8.开始节点替换时，若被替换节点有大量 ddl event， dml event 或dmlstorage event 时，节点替换 程序要将被替换节点的所有 event 删除，该过程可能会需要较长时间。
常见问题：
host key verification failed
解决方法：
1.编辑文件/home/gbase/.ssh/known_hosts文件（最简单直接删除，重新建立互信）
2.删除替换节点对应的ssh-rsa秘钥
3.通过ssh连接新节点，重新建立连接互信。
原文链接：https://www.gbase.cn/community/post/5583
更多精彩内容尽在南大通用GBase技术社区，南大通用致力于成为用户最信赖的数据库产品供应商。
