南大通用GBase 8a修改gcadmin中NodeName、IpAddress对应关系的方法及distribution、nodedatamap、nodename等概念解释
概述
本文档描述了如何修改gbase数据库中各计算节点（gnode节点）的逻辑nodename方法，用于对使用gcinstall.py脚本进行软件初始化安装后，执行gcadmin命令时显示的nodename（逻辑节点名）对应的实际gnode实例IP之间对应关系进行修改的方法。
同时介绍了节点上分布的对应分片的segment_id进行调整的方法，即在集群节点规模不发生变化的情况下，调整各节点上分布的分片号的方法。
修改前集群信息
具体举例如下：
软件版本：9.5.3.27.20_patch.9
2个物理节点，每节点2个IP地址，安装2个实例：
物理机1：IP1:192.168.56.191，IP2:192.168.56.193
物理机2：IP1:192.168.56.192，IP2:192.168.56.194
采用兼容模式进行集群安装，demo.options如下：
[gbase@rh952node1 gcinstall]$ cat demo.options
installPrefix= /opt
coordinateHost = 192.168.56.191,192.168.56.192
coordinateHostNodeID = 191,192
dataHost = 192.168.56.191,192.168.56.192,192.168.56.193,192.168.56.194
#existCoordinateHost =
#existDataHost =
#existGcwareHost=
gcwareHost = 192.168.56.191,192.168.56.192
gcwareHostNodeID = 191,192
dbaUser = gbase
dbaGroup = gbase
dbaPwd = 'gbase'
#rootPwd = ''
#dbRootPwd = ''
#rootPwdFile = rootPwd.json
#characterSet = utf8
#sshPort = 22gcadmin显示拓扑如下：
计算集群的gnode节点的NodeName（逻辑节点名）与实例IP之间的对应关系为：
node1:192.168.56.192
node2:192.168.56.194
node3:192.168.56.191
node4:192.168.56.193
distribution信息如下：
修改目标
修改目标：
逻辑节点名与IP地址的对应关系如下：
node1:192.168.56.191
node2:192.168.56.192
node3:192.168.56.193
node4:192.168.56.194
目标distribution：
修改方法示例
修改原理
gbase中节点拓扑信息保存在gcware组件中，因此修改节点逻辑名与IP示例的对应关系需要修改gcware中的集群拓扑关系数据，具体记录计算集群拓扑关系的配置信息文件在gcware组件的data/gcware 目录下的SNAPSHOT.*.*配置文件中，对于上述案例环境具体为如下：
/opt/192.168.56.191/gcware/data/gcware
具体目录中的信息一般如下：
gcware目录下一般会包含如上的内容：
2个GCWARE_META.A ,GCWARE_META.B 以及可能的一个lock文件，确定快照信息的元数据A、B版本，当LOCK文件存在时B版本有效，否则A版本有效；
三个REDOLOG.*文件，对应不同版本的gcware，redolog；
2个SNAPSHOT.*.*文件，持久化保存最近两个版本的集群拓扑信息；
计算节点gnode的逻辑名nodename和实例IP间的对应关系就保存在SNAPSHOT.*.*文件目录中，本文只介绍修改目标相关的配置文件信息，其他配置文件信息具体解释在本文档中不做介绍，具体需咨询GBase技术支持人员。
具体需要修改的配置文件及其信息如下：对应本例中为2个SNAPSHOT.*.*目录中的SNAPSHOT.*.*/statemachine/vc00001/DATASERVER，文件中的具体信息如下：
其中nodename对应了gcadmin中显示nodename列中的逻辑节点名，ipaddr对应了gcadmin中显示的节点ip地址。
修改此文件可以修改gcadmin中保存的nodename和实例IP的对应关系，以及gcadmin的对应的显示信息。
注意：gcadmin中显示顺序和文件中配置信息顺序是相同的，因此修改时按照node1、node2、node3、node4这样的配置循序符合一般人对显示的习惯，否则gcadmin显示时会出现逻辑nodename不按大小顺序显示的问题。
修改节点逻辑名与gnode实例IP对应关系
修改前需要先刷新gcware的快照信息，因为gcware的最新信息是保存在gcware组件的内存中的，因此在修改配置信息前，需要先操作将gcware内存中的最新信息先刷新到SNAPSHOT.*.*的文件中，具体刷新gcware快照信息的方法如下：
1.停止集群的gcluster、gonde、syncserver等除gcware外的所有服务：目的是组织SQL任务进入改变gcware中信息的最新状态，保证刷新到SNAPSHOT中的信息是最新的：
#实验环境中配置了c3工具，用c3工具关闭集群各节点服务：
[gbase@rh952node1 gcware]$ cexec all: 'gcluster_services all stop'
************************* all *************************
--------- 192.168.56.191---------
Stopping gcrecover : [ OK ]
Stopping gcluster : [ OK ]
Stopping gbase : [ OK ]
Stopping gbase : [ OK ]
Stopping syncserver : [ OK ]
Stopping syncserver : [ OK ]
--------- 192.168.56.192---------
Stopping gcrecover : [ OK ]
Stopping gcluster : [ OK ]
Stopping gbase : [ OK ]
Stopping gbase : [ OK ]
Stopping syncserver : [ OK ]
Stopping syncserver : [ OK ]2.使用gcware的python API接口函数进行快照刷新，只需要在一个安装了gcware服务的节点上执行即可：
[gbase@rh952node1 gcware]$ python
Python 2.7.5 (default, Aug 2 2016, 04:20:16)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gcware;
>>> help(gcware);
>>> gcware.flush_statemachine();
1
>>>exit();每次执行gcware.flush_statemachine()，后观察/opt/192.168.56.191/gcware/data/gcware 目录下 REDOLOG.*文件的大小，当出现2个文件为320K，1个文件为160K大小，且SNAPSHOT.*.*中的第二段数字的最大一个比REDOLOG.*中最大的一个小1（例子中的REDOLOG中最大值为REDOLOG.825，SNAPSHOT.1.824是最大的SNAPSHOT比REDOLOG中的最爱825小1），则是快照已刷新到最新状态，如果还未到如上面的大小，则可多次执行gcware.flush_statemachine();
3.关闭集群gcware服务，修改SNAPSHOT中的元数据文件信息，需要在每个gcware组件的安装节点修改2个SANPSHOT*.*目录中的文件：
#使用C3工具关闭所有节点gcware服务
[gbase@rh952node1 gcware]$ cexec all: 'gcware_services all stop'
************************* all *************************
--------- 192.168.56.191---------
Stopping GCWareMonit success!
Stopping gcware : [ OK ]
--------- 192.168.56.192---------
Stopping GCWareMonit success!
Stopping gcware : [ OK ]
#修改SNAPSHOT中的配置信息，2个SNAPSHOT目录中的版本都需要修改
#注意："nodeid"、"nodename"、"ipaddr"三个值中只能修改nodename，nodeid和ipaddr的对应关系不能修改，否则会造成nodeid和ipaddr之间对应关系的混乱，推荐先将每个ipaddr对应的nodename先修改过来，然后在将文件中的信息顺序按照nodename从小到大的顺序重新排列：
修改前的文件信息：
{
"version":1,
"epoch":0,
"list_entries":4,
"nodes":[
{
"nodeid":3224938688,
"nodename":"node1",
"ipaddr":"192.168.56.192"
},
{
"nodeid":3258493120,
"nodename":"node2",
"ipaddr":"192.168.56.194"
},
{
"nodeid":3208161472,
"nodename":"node3",
"ipaddr":"192.168.56.191"
},
{
"nodeid":3241715904,
"nodename":"node4",
"ipaddr":"192.168.56.193"
}
]
}
#修改后的文件内容：
{
"version":1,
"epoch":0,
"list_entries":4,
"nodes":[
{
"nodeid":3208161472,
"nodename":"node1",
"ipaddr":"192.168.56.191"
},
{
"nodeid":3224938688,
"nodename":"node2",
"ipaddr":"192.168.56.192"
},
{
"nodeid":3241715904,
"nodename":"node3",
"ipaddr":"192.168.56.193"
},
{
"nodeid":3258493120,
"nodename":"node4",
"ipaddr":"192.168.56.194"
}
]
}
#nodeid和ipaddr的对应关系修改后不能变化，只修改每个节点的nodename，并且重新排列文件中的信息顺序依次修改所有gcware组件安装节点的SNAPSHOT目录中 /statemachine/vc00001/DATASERVER 中的配置信息。
4.修改完SNAPSHOT目录中 /statemachine/vc00001/DATASERVER的信息后，还要修改所有gcware组件安装节点的SNAPSHOT目录中 /statemachine/vc00001/DATACLUSTERSTATE中的配置信息，使其中的nodeid顺序与DATASERVER 中的nodeid顺序保持一致，DATACLUSTERSTATE文件中的信息决定gcadmin命令中，节点状态信息中的内容显示，如果该文件中节点的顺序与DATASERVER 文件中节点的顺序不一致，会发生使用gcadmin setnodestate ip failure/unavialbe 等状态后，其状态在几个节点间不停闪动的问题，问题的原因是DATASERVER和DATACLUSTERSTATE中的节点顺序不一致造成。
DATACLUSTERSTATE文件中存储的内容类似如下：
[gbase@rh952node1 vc00001]$ cat DATACLUSTERSTATE
{
"version":1,
"epoch":0,
"dataservernodes":[
{
"nodeid":-1086805824,
"nodestate":1,
"gnodestate":1,
"syncserverstate":1
},
{
"nodeid":-1053251392,
"nodestate":1,
"gnodestate":1,
"syncserverstate":1
},
{
"nodeid":-1070028608,
"nodestate":1,
"gnodestate":1,
"syncserverstate":1
},
{
"nodeid":-1036474176,
"nodestate":1,
"gnodestate":1,
"syncserverstate":1
}
],
"dataserverlist_entries":4
}注意：如果DATACLUSTERSTATE中的nodeid为负数（负数值为inet_aton(ip地址的倒序)-4294967296得到），则需要进行如下操作：
a)：根据函数计算可得到每个ip对应的nodeid值、nodeid-4294967296得到的负数值。
b)：根据得到的负数值，在DATACLUSTERSTATE中匹配对应值，并调整顺序，使其与DATASERVER 中的ip经过计算得到的负数值顺序保持一致。
5.重启集群gcware和gcluster、gnode、syncserver服务
#使用c3工具重启集群服务：
[gbase@rh952node1 gcware]$ cexec all: 'gcluster_services all start'
************************* all *************************
--------- 192.168.56.191---------
Starting gbase : [ OK ]
Starting gbase : [ OK ]
Starting syncserver : [ OK ]
Starting syncserver : [ OK ]
Starting gcluster : [ OK ]
Starting gcrecover : [ OK ]
--------- 192.168.56.192---------
Starting gbase : [ OK ]
Starting gbase : [ OK ]
Starting syncserver : [ OK ]
Starting syncserver : [ OK ]
Starting gcluster : [ OK ]
Starting gcrecover : [ OK ]
[gbase@rh952node1 gcware]$ cexec all: 'gcware_services all start'
************************* all *************************
--------- 192.168.56.191---------
Starting gcware : [ OK ]
Starting GCWareMonit success!
--------- 192.168.56.192---------
Starting gcware : [ OK ]
Starting GCWareMonit success!检查修改结果
执行gcadmin命令，检查nodename和实例ip的对应关系：
已经按照预定目标完成了nodename与实例IP之间对应关系的修改
注意：此时我们只是修改了实例IP地址和实例节点gnode逻辑nodename之间对绑定关系，并没有修改数据分片的分布关系即DISTRIBUTION，这点非常关键，因为DISTRIBUTION决定数据在节点间的分布关系，我们的上述修改目的不是改变DISTRIBUTION只是为了改变每个实例IP和逻辑节点名namenode的逻辑对应关系。
此时我们检查集群的DISTRIBUTION信息：
发现执行上面步骤的修后DISTRIBUION的信息并没有发生变化，和修改前是相同的。
如果我们的目的只是修改实例IP和逻辑节点名nodename间的对应关系而不是调整分片的分布DISTRIBUTION，则做完上述的步骤就可以完成了。本例中我们的目标除了要修改IP和逻辑节点名nodename间的对应关系外，还需要根据我们的需求修改DISTRIBUTION，因此需要执行后续的步骤。
调整DISTRIBUTION
创建自定义DISTRIBUTION xml文件
执行gcadmin getdistribution命令获取当前distribution信息作为模版，在此基础上修改目标distribution：
#获取当前distribution作为模版
[gbase@rh952node1 gcware]$ gcadmin getdistribution 1 distribution.xml
gcadmin getdistribution 1 distribution.xml ...
get segments information
write segments information to file [distribution.xml]
gcadmin getdistribution information successful
#修改为自定义的distribution
[gbase@rh952node1 ~]$ cat distribution.xml
<?xml version='1.0' encoding="utf-8"?>
<distributions>
<distribution>
<segments>
<segment>
<primarynode ip="192.168.56.191"/>
<duplicatenodes>
<duplicatenode ip="192.168.56.194"/>
</duplicatenodes>
</segment>
<segment>
<primarynode ip="192.168.56.192"/>
<duplicatenodes>
<duplicatenode ip="192.168.56.191"/>
</duplicatenodes>
</segment>
<segment>
<primarynode ip="192.168.56.193"/>
<duplicatenodes>
<duplicatenode ip="192.168.56.192"/>
</duplicatenodes>
</segment>
<segment>
<primarynode ip="192.168.56.194"/>
<duplicatenodes>
<duplicatenode ip="192.168.56.193"/>
</duplicatenodes>
</segment>
</segments>
</distribution>
</distributions>创建自定义DISTRIBUTION
执行gcadmin distribution命令创建自定义distribution：
#编辑gcChangeInfo.xml文件应用distribution.xml文件
[gbase@rh952node1 ~]$ cat gcChangeInfo.xml
<?xml version="1.0" encoding="utf-8"?>
<servers>
<cfgFile file="distribution.xml"/>
</servers>
#执行gcadmin distribution命令创建新distribution
[gbase@rh952node1 ~]$ gcadmin distribution gcChangeInfo.xml
gcadmin generate distribution ...
gcadmin generate distribution successful检查新创建DISTRIBUTION
使用gcadmin showdistribution检查新创建的自定义distribution：
可以看到新创建的distribution 2已经是目标distribution，之后进行rebalance操作，调整数据分布。
执行rebalance重分布数据
#执行initnodedatamap操作
[gbase@rh952node1 ~]$ gccli -uroot
GBase client 9.5.3.27.20_patch.9.16730d84. Copyright (c) 2004-2024, GBase. All Rights Reserved.
gbase> initnodedatamap;
Query OK, 1 row affected, 6 warnings (Elapsed: 00:00:00.43)
#执行rebalance操作重分布数据
gbase> set global gcluster_rebalancing_concurrent_count = 0;
Query OK, 0 rows affected (Elapsed: 00:00:00.01)
gbase> rebalance instance;
Query OK, 3 rows affected (Elapsed: 00:00:00.23)检查数据分布正确性
由于我们的操作是在不增加新节点，即不增加集群中数据分片数量的情况下进行的distribution调整，因此优化后的集群逻辑是将对应分片的整体数据搬移到调整后的IP地址实例下，即采用分片搬移的方式进行的数据分布调整，并不调整segment_id与具体每个segment分片中绑定的数据分布hashkey值。
为了检查上述操作的正确性，建议挑选几张表进行一次数据分布检查，检查方法如下：
#Session级设置 _t_gcluster_temp_table_trace = 1参数
gbase> set _t_gcluster_temp_table_trace = 1;
Query OK, 0 rows affected (Elapsed: 00:00:00.01)
#挑选若干hash分布表，执行select * from [dbname].[tbname] limit 10000，检查分布正确性，如果数据分布正确，则执行select后的结果没有warning，如果有错误数据分布则将显示waring信息，可以执行show warnings来查看错误数据信息：
...
| 40 | 5373680 | 23104884 | 9 | 4890048 | 80605 | 0 | 19920219 | REG AIR |
| 16550 | 2 | 2554 | 7932 | 7608 | 19920108 | 3-MEDIUM | 0 | 40 | 7359720 | 23104884 | 8 | 6770942 | 110395 | 6 | 19920217 | MAIL |
| 16550 | 3 | 2554 | 98323 | 2193 | 19920108 | 3-MEDIUM | 0 | 31 | 4096092 | 23104884 | 9 | 3727443 | 79279 | 5 | 19920327 | AIR |
+-------------+---------------+------------+------------+------------+--------------+------------------+-----------------+-------------+------------------+------------------+-------------+------------+---------------+--------+---------------+-------------+
10000 rows in set (Elapsed: 00:00:00.82)
gbase>
#检查结果无warings说明数据分布正确，推荐挑选几张hash分布表做一下校验删除老的DISTRIBUTION
执行gcadmin rmdistribution命令删除老distribution：
#删除老的distribution
[gbase@rh952node1 ~]$ gcadmin rmdistribution 1
cluster distribution ID [1]
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=1 result is not 0
refreshnodedatamap drop 1 success
gcadmin remove distribution [1] success执行gcadmin showdistribution检查当前DISTRIBUTION分布
显示集群已将数据分布到最新的DISTRIBUTION
几个概念和原理的澄清
DISTRIBUTION
DISTRIBUION在gbase集群中的作用是描述gnode实例IP与分片号SegmentID之间的对应关系的，即那个IP地址上绑定的实例会处理某一个分片上的数据的关系，可以通过gcadmin showdistribution [node]方式查看，或者gcadmin getdistribution [DISTRITUION ID] [filename] 方式获取并保存到一个xml描述文件中。
gbase.nodedatamap
nodedatamap描述了数据分片SegmentID与数据分布的hashkey之间的绑定关系，gbasenodedatamap中有三个字段：
hashkey：数据分布hash桶号；
nodeid：实际代表的意思是SegmentID，即逻辑分片号0代表n1分片，依次类推；
data_distribution_id：nodedatamap对应的DISTRIBUTIONID号
因此，在进行数据RSyncTool数据同步时，只要保证源端集群和目标端集群的nodedatamap中的hashkey和nodeid在主备集群中完全一致，即分片的SegmentID和其上绑定的hashkey是一致的就可以保证主备同步数据的正确性。原因是RSyncTool会检查主备集群两端的拓扑，找到分片SegmentID和实例IP地址的对应关系即DISTRIBUTION中的IP对应关系来调用备集群节点的gc_syncclient去连接对端主集群有映射关系节点的gc_syncserver，这一过程是自动的。只要手工保证SegmentID和Hashkey之间的绑定关系主备一致，即nodedatamap主备一致，同步过去的数据就是正确的。
Nodename
Nodename在gbase集群中是一个节点的逻辑名，分不同组件角色，如coordinator节点逻辑名为coordinator1、coordinator2...，gnode实例逻辑名为node1、node2...，这个逻辑名会影响gcrcman.py备份恢复时在本地备份目录内生成的目录名称。备份目录名是和该节点角色相匹配的，如GclusterData_coordinator1，说明对应的服务器上有一个coordinator节点，逻辑名为coordinator1，如GclusterData_node1说明对应服务器上有一个gnode实例节点，逻辑名为node1。
当两套集群之间除了有RsyncTool关系的主备同步，还有使用gcrcman从一端备份数据并在另一端恢复数据的需求时，我们需要特别注意保证coordinator和node的逻辑节点名称和物理IP之间的对应关系，因为gcrcman进行恢复时需要把各节点本地备份的目录数据copy到对应的另一套集群本地目录下，所以一定要让一套集群的node1、node2、...的实例IP地址与另一套集群对应的node1、node2的实例IP地址相对应起来，才能正确进行数据恢复。
9.5.3版本开始，demo.options中写入的节点实例IP地址的顺序并不是最终安装完成后gcadmin显示的nodename中的IP顺序，而是一种随机的状态，因此，如果我们在服务器的服务器名逻辑上主备集群对应的节点间有映射关系，就希望这种映射关系反映到gbase节点的逻辑名的对应上，因此就有必要进行本文档中的逻辑名对应修改使其具备从物理名到gbase节点实例nodename的一致对应性，从而化简后续备份恢复时的逻辑。
文档中第4和5章节中对nodename的修改只影响实例IP的逻辑命名，并不影响DISTRIBUTION，如果希望统一调整DISTRIBUTION，则需要进行6章节中的操作。
具体的原因为：
gcware组件 /安装目录/IP/gcware/data/SNAPSHOT.*.*/statemachine/vc00001/DATASERVER 文件中只包含了nodeid、nodename、ipaddr之间的映射关系，没有nodeid与segmentid之间的映射关系，因此修改DATASERVER文件并不影响DISTRIBUTION。而是在/安装目录/IP/gcware/data/SNAPSHOT.*.*/statemachine/vc00001/DISTRIBUTION文件中保存了segmentid与nodeid之间的映射关系，具体内容如下示例：
其中的prinodeid和dup1nodeid对应了DATASERVER文件中的nodeid。
我们在本文对创建新的distribution中进行的操作实际上修改了DISTRIBUTION这个文件中的信息。
注意：所有gcware的SNAPSHOT中的信息都是持久化后的，最新的信息保留在内存中，因此要做到修改持久化文件和内存中信息的一致性，一定要通过刷快照的方式将最新信息刷到外部存储的SNAPSHOT文件中才能进行修改。而gcware启停操作实际也会触发刷快照的动作。其内容会先记录在REDOLOG中，REDOLOG相当于是gcware内存中易逝性信息的日志文件，我们的刷快照的目录实际上是清空REDOLOG文件，并将gcware内存中的信息刷到磁盘的SNAPSHOT文件中，因为REDOLOG是二级制文件无法编辑，我们只能编辑SNAPSHOT中的文件。
评论
热门帖子
- 12025-12-01浏览数：182759
- 22023-05-09浏览数：25044
- 42023-09-25浏览数：18519
- 52020-05-11浏览数：17526