GBase 8a 扩容操作意外的处理方案

GBase 8a 数据库扩容时，可能发生各种意外情况，本文针对扩容每个操作步骤进行分析，考虑发生的各种意外，以及人工处理方法。

整体步骤

分为如下几大块，后面详细介绍。本文样例内容是V8的，但整体处理V9也可以用。

1.   扩容安装节点
2.   加入distribution
3.   初始化nodedatamap
4.   重分布
5.   删除老的nodedatamap
6.   删除distribution

目录导航

• 1.   扩容安装节点
  • 1.1.  安装
  • 1.2.  回退删除
• 2.   加入distribution
  • 2.1.  增加distribution
  • 2.2.  删除distribution
• 3.   初始化nodedatamap
  • 3.1.  创建新的nodedatamap
  • 3.2.  删除nodedatamap
• 4.   重分布
  • 4.1.  开始重分布
  • 4.2.  意外处理
  • 4.3.  无法回退
• 5.   删除老的nodedatamap
• 6.   删除distribution

1.   扩容安装节点

详细步骤请参考【安装手册】，有关【增加、减少集群节点】部分。

1.1.  安装

通过gcinstall.py 在新的节点安装新的服务，并将节点信息同步到老的集群。

安装配置文件有关参数样例如下：demo.options

原有2节点(192.168.0.1和192.168.0.2),新扩容1个节点(192.168.0.3)

# 安装coor类节点IP

coordinateHost = 192.168.0.3

# 安装data类节点IP

dataHost = 192.168.0.3

# 应存在的coor类节点IP

existCoordinateHost = 192.168.0.1,192.168.0.2

# 已经存在的data类节点IP

existDataHost =192.168.0.1,192.168.0.2

安装命令

gcinstall.py –silent=demo.options

1.2.  回退删除

从现有的3节点集群中，卸载不使用的192.168.0.3节点。

前提是，被删除的节点，并没有加入任何distribution, 否则请转到第2部分

查看方法：

gcadmin showdistribution 看不到任何和要卸载节点相关的信息。

# 安装coor类节点IP

coordinateHost = 192.168.0.3

# 安装data类节点IP

dataHost = 192.168.0.3

uninstall.py –silent=demo.options

2.   加入distribution

参考【管理员手册】的【集群扩容和缩容操作流程】部分。

2.1.  增加distribution

gcadmin distribution gcChangeInfo.xml p 1 d 1

检查方式

gcadmin showdistribution

看到新的分布方案

2.2.  删除distribution

gcadmin rmdistribution 1

其中数字是要删除的分布方案编号，请根据实际扩容showdistribution出来的设定。扩容新生成的ID都是 >=2的。

前提：该distribution 并没有使用中，如已经使用，请看步骤3

检查方式

gcadmin showdistribution

看不到指定ID分布方案了。

3.   初始化nodedatamap

参考【管理员手册】的【集群扩容和缩容操作流程】部分

3.1.  创建新的nodedatamap

gccli 登陆数据库，执行如下SQL命令

initnodedatamap

前提：

  有新的distribution创建，且没有初始化过。

检查方式：

  select distinct data_distribution_id  from gbase.nodedatamap;

扩容后，会看到2个数值，其中大的是新初始化的。

3.2.  删除nodedatamap

refreshnodedatamap drop 1

其中数字为没有使用中的nodedatamap的ID. 如果已经使用，请参考第4步骤。

refreshnodedatamap drop报错：Can not drop nodedatamap ,Some table are using it.

前提：

  该ID必须是没有任何表在使用中。

检查方式：

  select distinct data_distribution_id  from gbase.nodedatamap;

删除后，只保留了1个ID,确认前面的ID已经不存在。

4.   重分布

参考【管理员手册】的【集群扩容和缩容操作流程】部分

4.1.  开始重分布

rebalance instance;

检查方法：

  查看正在重分布的表。

select status,count(*) from rebalancing_status group by status

  查看哪些表还在使用老的ID

select * from gbase.table_distribution where data_distribution_id=XXXX

4.2.  意外处理

如果重分布的表已经全部是完成状态，但依然有表使用老的ID, 请执行如下命令，将表手工加入重分布。 并在一键安装脚本里，额外处理这部分。此现象极少遇到，一般是新增了某些功能后，测试不彻底的BUG。

 rebalance table 库名.表名

其中库名和表名，来自于前面查看使用老的Id的SQL命令的DBName和TbName

4.3.  无法回退

重分布一旦开始，那么部分表已经在新节点，此时只能

1、等到重分布全部完成

2、暂停重分布，减少对当前业务影响。

3、停止重分布，等待老化数据自动删除后，再继续重分布，比如1个月后。

具体命令看管理员手册rebalance部分。

5.   删除老的nodedatamap

与第3步操作完全一样，区别是这里是删除老的，不用的nodedatamap. 那个是回退，删除刚创建的nodedatamap。

refreshnodedatamap drop 1

其中数字为没有使用中的nodedatamap的ID.

前提：

  该ID必须是没有任何表在使用中。如果已经使用，请参考第4步骤【意外处理部分】。

检查方式：

  select distinct data_distribution_id  from gbase.nodedatamap;

删除后，只保留了1个ID,确认前面的ID已经不存在。

6.   删除distribution

如失败，无可用操作，稍后重试还不行，可以联系厂商支持人员。

扩容详细操作实例，请参考 GBase 8a MPP Cluster扩容操作详例。

 Post Views: 254