数据节点基本管理操作

在 GreatDB 集群中，数据节点的管理包含两个概念

1. datanode（node），是一个具体的数据节点实例，实例本身是一个 mysql 服务进程
2. shard，一个或多个 node 组成的数据节点管理单元，同一个 shard 中的不同 node 间共享一份数据

添加新datanode

接口说明详见 add_datanode 。

node_type 目前支持 NODE_MGR 和 NODE_SINGLE 两种，其中 NODE_SINGLE 无法保证数据的可靠性，不推荐线上环境使用。本文接下来将主要介绍 NODE_MGR 类型，及其故障的处理。

初始化shard

操作命令如下：

CALL `mysql`.`greatdb_init_shard`('shard_name');

接口说明详见 init_shard 。

删除datanode

操作命令如下：

CALL `mysql`.`greatdb_drop_datanode`('node_name');

接口说明详见 drop_datanode 。

删除整个shard

操作命令如下：

CALL `mysql`.`greatdb_drop_shard`('shard_name');

接口说明详见 drop_shard 。

查看节点状态

可以分别通过 information_schema 下的表 greatdb_shards, greatdb_datanodes， 查询 shard 和 data-node 节点的信息，如下示例所示。

mysql> SELECT * FROM information_schema.greatdb_shards;
+----------+------------+--------------+---------+
| SHARD_ID | SHARD_NAME | SHARD_STATE  | SUSPEND |
+----------+------------+--------------+---------+
|        8 | sd1        | SHARD_ONLINE | OFF     |
|       15 | sd2        | SHARD_ONLINE | OFF     |
|       22 | sd3        | SHARD_ONLINE | OFF     |
+----------+------------+--------------+---------+
3 rows in set (0.01 sec)

SHARD_STATE 包含如下一些状态信息：

1. SHARD_INIT：还未执行 init_shard 操作，此时 shard 不能对外提供服务；另外，刚执行 init_shard 操作后，监控线程还未捕捉到数据节点示例状态，此时也会短暂处于该状态；
1. SHARD_ONLINE：shard 集群处于可用状态
1. SHARD_ERROR：shard 集群中没有节点处于可用状态，整个 shard 不可用，此时需要查找问题原因


mysql> SELECT * FROM information_schema.greatdb_datanodes WHERE shard_name='sd1';
+---------+-----------+----------+------------+-----------+-------+------+-----------+---------------+------------------------------------------+-----------------------------+------------------------------------------+
| NODE_ID | NODE_NAME | SHARD_ID | SHARD_NAME | HOST      | PORT  | NODE_TYPE | NODE_STATE    | EXECUTED_GTID                            | COUNT_TRANSACTIONS_IN_QUEUE |RECEIVED_TRANSACTION_SET|
+---------+-----------+----------+------------+-----------+-------+------+-----------+---------------+------------------------------------------+-----------------------------+------------------------------------------+
|       8 | n1        |        8 | sd1        | 127.0.0.1 | 13003 | NODE_MGR  | STATE_ACTIVE  | 38000000-0000-0000-0000-000000000000:1-4 |                           0 |38000000-0000-0000-0000-000000000000:1-4|
|      15 | n2        |        8 | sd1        | 127.0.0.1 | 13004 | NODE_MGR  | STATE_STANDBY | 38000000-0000-0000-0000-000000000000:1-4 |                           0 |38000000-0000-0000-0000-000000000000:1-4|
|      22 | n3        |        8 | sd1        | 127.0.0.1 | 13005 | NODE_MGR  | STATE_STANDBY | 38000000-0000-0000-0000-000000000000:1-4 |                           0 |38000000-0000-0000-0000-000000000000:1-4|
+---------+-----------+----------+------------+-----------+-------+------+-----------+---------------+------------------------------------------+-----------------------------+------------------------------------------+
3 rows in set (0.01 sec)

管理操作错误处理

data-node 无法加入组复制关系中

有这么几种情况，可能导致无法建立组复制关系

1. 执行 init_shard 时失败

   解决办法：

   1. 检查是否有节点故障，如果存在节点故障，需要修复故障，或者执行 drop_datanode 操作删除故障节点
   2. 检查所有 data-node 的配置，是否已经配置了 group_repliation_local_address 参数，以及参数是否配置正确
   3. 检查是否有节点已经在运行组复制，且多个节点在不同的组复制集群。如果出现多个节点处于不同的组复制关系中，禁止执行 init_shard，需要执行 drop_datanode 操作删除部分节点
   4. 检查是否节点数据不一致，如果多个 data-node 间数据不一致，gtid 不一致，会导致组复制关系建立失败
   5. 其它异常，通过报错信息和系统错误日志进行综合分析

2. init_shard 后，执行 add_datanode 失败

   解决办法：

   1. 检查 shard 是否处于 ONLINE 状态，如果 shard 没有处于 ONLINE 状态，此时需要先恢复现有的 shard 集群
   2. 检查新 node 是否节点故障
   3. 检查新 node 是否配置了 group_repliation_local_address 参数，以及参数是否配置正确
   4. 检查新 node 是否和现有 shard 运行在不同的组复制集群
   5. 检查新 node 是否包含 shard 中没有的数据和 gtid
   6. 其它异常，通过报错信息和系统错误日志进行综合分析

无法删除节点或者 shard

主要检查节点是否包含了用户表数据信息。

其它操作异常

1. init_shard 后，执行 add_datanode 失败，但 node 加入到 shard 的组复制

   由于节点在 shard 组复制关系中，却又没有成功添加到集群的 datanode，可能导致切换主的过程中，该节点被选为新主，导致集群无节点可用。

   解决办法：如果执行 add_datanode 失败，可以登录 node 节点，查询组复制状态 SELECT * FROM performance_schema.replication_group_members。如果节点成功加入了组复制，则执行STOP GROUP_REPLICATION 退出组复制；或者再次执行 add_datandoe 尝试加入。

   延伸错误：节点先是加入组复制成功，然后节点 mysql 进程故障，导致执行失败。此时也无法查看节点是否加入组复制。但节点重启后，可能通过 group_replication_start_on_boot 又自动加入 shard 的组复制，导致一样的问题。因此，如果是这种原因，最好在节点重启后检查节点状态。

2. data-node节点故障，使用 drop_datanode 移除节点，节点重启后，自动加入到组复制关系中

针对上述几种问题，最好的方式是通过监控的方式，查询每个 data-node 的 performance_schema.replication_group_members，判断是否所有节点都在 shard 中。如果发现存在表中的节点，不在 shard 集群内的 datanode 中，则需要对该节点手动执行 STOP GROUP_REPLICATION 将其移除。

节点实例异常处理

单个 datanode 故障

1. 网络异常（SERVER SHUTDOWN OR NETWORK ERROR）：待网络恢复后，一般不需要对节点进行额外处理。在 GreatDB 内，会配置 group_replication_autorejoin_tries 参数，网络恢复后，会自动重新加入 shard 的组复制集群。如果网络恢复后一段时间，数据节点仍处于错误状态，此时需要检查错误原因并手动修复。

2. 节点 mysql 服务异常（SERVER SHUTDOWN OR NETWORK ERROR）：待节点服务重启后，一般不需要对节点进行额外处理。在 GreatDB 内，会配置 group_replication_start_on_boot 参数，重启后，会自动重新加入 shard 的组复制集群。如果重启一段时间后，数据节点仍处于错误状态，需要检查错误原因并手动恢复。

3. 其它异常（STATE_ERROR）：需要手动检查错误原因，分析并修复。

全部 datanode 故障

1. 网络分区导致全部节点不可用：所有节点网络恢复后，GreatDB 会自动进行恢复处理。恢复过程中，shard 不可用。如果恢复失败，需要检查原因并手动恢复。如果只是部分节点网络恢复，需要人工手动进行恢复。

2. 所有节点 mysql 服务异常。所有节点重启后，GreatDB 会自动恢复处理。同理，恢复过程中，shard 不可用。如果恢复失败，需要检查原因并手动恢复。如果只是部分节点网络恢复，需要人工手动进行恢复。

3. 其它异常，需要手动需要。

！！！ 注意：为了防止脑裂，一定需要等所有节点恢复后，GreatDB才会去进行 shard 的整体恢复。部分节点恢复时，需要进行手动恢复。

多数节点同时故障

同全部节点故障情形，集群不可用，并且需要等待所有节点均故障恢复后，GreatDB 才会自动进行恢复，否则需要人工恢复处理。

强制重启shard操作

详见 force_restart_shard。

！！！注意，谨慎使用该命令，该命令会强制启动sqlnode集群，但不保证数据的安全 ！！！执行该命令前，数据库管理员需要进行如下确认：

1. 存活的datanode节点包含最新数据
2. 存活的datanode节点可能丢了数据，但业务确认这些数据的丢失是可以容忍的
3. 如果是多机房部署且发生网络分区，如果其它机房集群处于正常可用的状态，强制在执行的sqlnode节点所在的分区中强制重启集群，则会发生脑裂现象，需要业务保证故障的机房分区不能进行新的数据写入操作

管理操作接口命令为：

CALL `mysql`.`greatdb_force_restart_shard`('shard_name');

执行该命令，不管是否多数datanode节点存活，都会强制启动datanode的组复制，提供服务。

人工恢复逻辑

具体可以参考 组复制问题处理 章节中 多数节点同时故障的问题 中关于重新恢复集群的描述。