查看所有 GreatDB 用户存储过程

[root@greatdb1 ~]# greatsql -ugreatdb -pgreatdb -h192.168.0.81 -P3306
GreatDB Cluster[(none)]> SHOW PROCEDURE STATUS like 'greatdb%';
+-------+--------------------------------------------------+-----------+-----------------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+
| Db    | Name                                             | Type      | Definer               | Modified            | Created             | Security_type | Comment | character_set_client | collation_connection | Database Collation |
+-------+--------------------------------------------------+-----------+-----------------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+
| mysql | greatdb_add_backup_node                          | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_add_datanode                             | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_add_sqlnode                              | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_auto_migrate_tables_after_upscale        | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_auto_migrate_tables_before_downscale     | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_build_group_replication                  | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_change_shard_primary_node                | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_check_upgrade                            | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_drop_backup_node                         | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_drop_backup_task                         | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_drop_datanode                            | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_drop_shard                               | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_drop_sqlnode                             | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_force_restart_cluster                    | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_force_restart_shard                      | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_init_cluster                             | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_init_shard                               | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_install_clone_plugin                     | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_mgr_check                                | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_migrate_table                            | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_persist_variables                        | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_plugin_check                             | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_purge_binlog_before_seconds_for_datanode | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_restart_cluster                          | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_restart_datanode_server                  | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_restart_sqlnode_server                   | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_restore_shard_from_backup                | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_restore_sqlnode_from_backup              | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_set_var_for_all_sqlnodes                 | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_set_var_for_datanode                     | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_start_full_backup                        | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_start_group_replication                  | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_start_inc_backup                         | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_stop_backup_task                         | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_stop_datanode_server                     | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_stop_migrate_task                        | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
| mysql | greatdb_stop_sqlnode_server                      | PROCEDURE | greatdb.sys@localhost | 2021-02-26 09:17:11 | 2021-02-26 09:17:11 | DEFINER       |         | utf8mb4              | utf8mb4_0900_ai_ci   | utf8mb4_unicode_ci |
+-------+--------------------------------------------------+-----------+-----------------------+---------------------+---------------------+---------------+---------+----------------------+----------------------+--------------------+
37 rows in set (0.00 sec)

SQL-NODE管理接口

初始化集群

• 示例

CALL `mysql`.`greatdb_init_cluster`('cluster_name', 'cluster_user', 'cluster_password');

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB分布式数据库的安装部署（1） <创建集群> 章节。

初始化集群时，还会根据初始的 SqlNode 节点的 gdb_zone_name 和 group_replication_zone_id 参数值，初始化⼀个机房信息，并设置初始机房的选举权重为最⼤值 9 。

• 注意：

1. 该操作只能在⼀个 SqlNode 节点执⾏⼀次。如果在不同的节点中都执⾏了同样的命令，则实际创建了两个不同的集群，并可能导致集群脑裂，影响正常使⽤。
2. 集群中所有的 SqlNode，DataNode 和 backup_node 均需要包含 cluster_user，密码⼀致为 cluster_password，同时该⽤户需要具有 super 权限。
3. 保证节点是⼀个⼲净的节点，⼲净的意思是该 mysql 实例之前没有加⼊过其它的 GreatDB 集群（⽆论是作为 SqlNode 节点还是 DataNode 节点），也没有额外的数据写⼊，否则，后续操作可能会导致各种异常。
4. 如果该数据库实例作为 SqlNode 节点加⼊过其它 GreatDB 集群的，将禁⽌执⾏ greatdb_init_cluster 操作。参数 greatdb_enable_force_init_cluster=ON 会放宽限制，此时需要⽤户确保该节点可以加⼊集群。
5. 节点事先需要配置参数 group_replication_local_address，并保证配置正确。

添加新的 SqlNode 节点

• 示例

CALL `mysql`.`greatdb_add_sqlnode`('hostname', port);

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB分布式数据库的安装部署（1） <创建集群> 章节。
  万里GreatDB数据库的学习之路–GreatDB备份与恢复（4） <在 SqlNode 实例上调用接口恢复集群结构信息> 章节。
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <添加 SqlNode 计算节点> 章节。

• 注意：

1. 在已经加⼊集群并且处于 ONLINE 状态的 SqlNode 节点中执⾏该操作。
2. 如果⼀个 SqlNode 节点实例退出了 SqlNode 集群的组复制关系，故障恢复后，可以通过上述命令重新加⼊。
3. 同 greatdb_init_cluster ⼀样，需要保证指定 hostname+port 的 mysql 实例是⼀个⼲净的节点。
4. 节点事先需要配置参数 group_replication_local_address，并保证配置正确。
5. 需要保证节点的 gdb_zone_name 和 group_replication_zone_id 和集群中某⼀个机房 zone_name, zone_id 保持⼀致，否则⽆法添加成功。

删除 SqlNode 节点

• 示例

CALL `mysql`.`greatdb_drop_sqlnode`('hostname', port);

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <删除 SqlNode 计算节点> 章节。

• 注意：

1. 可以在任⼀ ONLINE 的 sqlnode 节点中执⾏，包括该 sqlnode 本⾝。
2. hostname，port 需要为 information_schema.greatdb_sqlnodes ，⽐如 sqlnode 节点所在的机器可能有多个ip，需要使⽤ add_sqlnode 时指定的 ip。

安装 clone 插件

在添加 SqlNode 计算节点时，针对已存储大量业务数据时，新初始化的实例需要从现有节点复制克隆存量数据后，才可执行 sqlnode 添加。

• 示例

call mysql.greatdb_install_clone_plugin();

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <添加 SqlNode 计算节点> 章节。

>添加 DataNode 节点

当前⽀持 NODE_MGR 和 NODE_SINGLE 两种类型，NODE_SINGLE 表⽰ shard 中只有⼀个数据节点，此时⽆法保证数据的可靠性，不推荐线上环境使⽤；NODE_MGR 类型可以包含多个数据节点，节点间使⽤ mysql group_replication 进⾏数据同步和故障切换。

• 示例

CALL `mysql`.`greatdb_add_datanode`('shard_name', 'node_name', 'hostname', port, 'node_type');

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB分布式数据库的安装部署（1） <创建集群> 章节。
  万里GreatDB数据库的学习之路–GreatDB备份与恢复（4） <添加其他 SqlNode 和 DataNode 实例> 章节。
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <添加 Shard 分片内的 DataNode 节点> 章节。

• 注意事项：

1. 添加的 DataNode 节点实例不能同时作为集群的其它节点使⽤
2. 如果是 NODE_MGR 类型，节点实例需要事先配置参数 group_replication_local_address
3. 需要保证节点的 gdb_zone_name 和 group_replication_zone_id 和集群中某⼀个机房 zone_name, zone_id 保持⼀致，否则⽆法添加成功。当然，如果节点类型为 NODE_SINGLE，⽆需配置 group_replication_zone_id。
4. 同时需要注意的是，对于 NODE_MGR 类型的节点，配置的 group_replication_member_weigth 参数值会被重新计算并替换。其计算公式为 new_weigth = 节点所在的机房权重 * 10 + old_weight % 10 ，因此会存在两个问题。⼀是，如果同⼀个机房的两个节点分配配置为45，46，替换后值会⼀样，因此原始值最好保持为10的倍数，这样可以维持原始的⼤⼩顺序。另⼀个是，如果节点添加失败，或者添加后⼜执⾏了删除操作，上述两种情况下，如果重新add_datanode，可能会使⽤上⼀次替换后的值进⾏计算，则结果可能和⽤户预期的不⼀致，这种情况下，⽤户可以⼿动重新设置该值后，再重新加⼊集群。
5. 向已存在的 shard 添加 DataNode，如果该 shard 正在做物理迁移任务，则禁⽌添加 DataNode；如果该 shard 上已经执⾏过物理迁移任务，会⽐较该 DataNode 的 gtid 和执⾏物理迁移结束的 import_gitd (即 import tablespace 对应的 gtid)⽐较，该DataNode 不包含import_gitd，新的 DataNode 默认会⾛ clone 流程。

初始化 shard

对于 NODE_MGR 类型的数据节点，操作成功后，会对 shard 组内的所有 DataNode 建⽴组复制关系，并通过 mysql 组复制的特性，保证所有节点间的数据⼀致性。
执⾏ greatdb_init_shard 命令后，仍可以添加新的 DataNode。区别在于：

1. greatdb_init_shard 前 add_node，不会建⽴ DataNode 间的组复制关系
2. greatdb_init_shard 操作本⾝会建⽴好组复制关系，因此之后再执⾏ add_node ，需要将 DataNode 加⼊到 shard 的组复制关系中，如果执⾏失败，则 add_node 会失败。

• 示例

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

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB分布式数据库的安装部署（1） <创建集群> 章节。
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <添加 Shard 分片> 章节。

• 注意事项：

1. greatdb_init_shard 前，数据节点间可以是已经建⽴好了组复制关系，但这些节点不能在多个不同的组复制关系下
2. greatdb_init_shard 时，数据节点的组复制关系，和添加 DataNode 时没有发⽣变化

删除 DataNode 节点

• ⽰例：

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

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <删除 Shard 分片内的 DataNode 节点> 章节。

• 注意事项：

1. 如果数据节点正常提供服务，会同时停⽌节点的组复制关系
2. 如果节点是 shard 组中最后⼀个数据节点，且 shard 中包含了⽤户表数据，此时，⽆法删除节点
3. 如果 shard 异常，没有任何节点可以提供读写服务，⽆法删除节点
4. 如果节点是 shard 组中最后⼀个数据节点，需要⽤户保证 binlog-server 同步完该 shard 上的数据

删除 shard

• ⽰例：

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

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <整个 Shard 分片的删除> 章节。

• 注意事项：

1. 如果该 shard 中包含⽤户表数据，则⽆法删除
2. 不会停⽌组内数据节点间的复制关系
3. 如果 binlog-server 正在获取此 shard 上的 binlog ⽇志，此操作需⽤户保证同步完该 shard 上的数据

在线更改 shard 的主节点

• ⽰例：

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

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB数据库的管理和使用（2） <启停的节点是 DataNode> 章节。
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <删除 Shard 分片内的 DataNode 节点> 章节。

后台节点管理接⼝

设置 DataNode 节点系统变量

persist：是否需要将变量修改进⾏持久化，如果设置为 true，则数据节点重启后，修改仍⽣效；否则，数据节点重启后，结果为修改前的值。

• ⽰例：

call mysql.greatdb_set_var_for_DataNode('datanode1','max_connections',2000,);

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB参数调整与系统视图（3） <GreatDB DataNode参数调整> 章节。

• 注意事项：
  该操作仅⽀持修改部分的系统变量值，当前⽀持修改的系统变量如下：
  max_connections
  table_definition_cache
  table_open_cache
  transaction_isolation
  innodb_buffer_pool_size
  innodb_flush_log_at_trx_commit
  innodb_change_buffering
  innodb_spin_wait_delay
  innodb_sync_spin_loops
  innodb_thread_concurrency
  max_prepared_stmt_count
  sync_binlog
  group_replication_consistency
  group_replication_member_weigth
  binlog_expire_logs_seconds
  如果⽤户需要修改之外的系统变量，需要直连到后端节点进⾏操作。
  注：需要特别注意的是，由于集群可以多机房部署，且机房本⾝包含权重信息。因此，设置 group_replication_member_weigth 后，实际的结果和⽤户设置的值是有出⼊的。具体的换算为 r = (m_zone_elect_weigth * 10) + v / 10 。

设置 SqlNode 节点系统变量

persist：是否需要将变量修改进⾏持久化，如果设置为 true，则数据节点重启后，修改仍⽣效；否则，数据节点重启后，结果为修改前的值。

• ⽰例：

CALL mysql.greatdb_set_var_for_all_SqlNodes('max_connections',1000,true);

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB参数调整与系统视图（3） <GreatDB SqlNode参数调整> 章节。

• 注意事项：
  该操作仅⽀持修改部分的系统变量值，当前⽀持修改的系统变量如下：
  max_connections
  table_definition_cache
  table_open_cache
  transaction_isolation
  innodb_buffer_pool_size
  innodb_flush_log_at_trx_commit
  innodb_change_buffering
  innodb_spin_wait_delay
  innodb_sync_spin_loops
  innodb_thread_concurrency
  max_prepared_stmt_count
  sync_binlog
  group_replication_consistency
  注意：该存储过程会统⼀修改所有的 SqlNode 节点的变量，如果⽤户只需要设置某⼀个 SqlNode 节点， 则直连该 SqlNode 节点，使⽤ MySQL 的 SET 语句即可。

清理 DataNode 节点 binlog

• ⽰例：

CALL mysql.greatdb_purge_binlog_before_seconds_for_datanode('datanode1',60);

• 使用参考

• 注意事项：
  调⽤该存储过程前，需要⽤户确保将 binlog 清理后不会影响数据节点的复制关系。

停⽌ DataNode 节点

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB数据库的管理和使用（2） <DataNode 关闭方式> 章节。

重启 DataNode 节点

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB数据库的管理和使用（2） <DataNode 重启方式> 章节。

• 注意事项：
  数据节点实例需要通过守护进程的⽅式启动（greatdbd_safe）

停⽌ SqlNode 节点

• ⽰例：

SELECT * FROM information_schema.greatdb_sqlnodes; 
CALL mysql.greatdb_stop_sqlnode_server('hostname', port);

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB数据库的管理和使用（2） <SqlNode 关闭方式> 章节。

重启 SqlNode 节点

• ⽰例：

SELECT * FROM information_schema.greatdb_sqlnodes; 
CALL mysql.greatdb_restart_sqlnode_server('hostname', port);

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB数据库的管理和使用（2） <SqlNode 重启方式> 章节。

• 注意事项：
  计算节点实例需要通过守护进程的⽅式启动（greatsqld_safe）

集群故障时组复制关系重启接⼝

重启 SqlNode 集群组复制

• ⽰例：

CALL `mysql`.`greatdb_restart_cluster`();

该接⼝⼀般在如下两种情况下调⽤：

1. SqlNode 节点发⽣故障，多数节点故障，导致所有的 SqlNode 均不能提供服务
2. 重新启动所有的 SqlNode 节点
   使⽤该命令，为了保证数据安全，有如下限制：
3. 必须启动半数以上的 SqlNode 节点
4. 假设在故障前⼀瞬间，有n个 SqlNode 节点是活跃状态，必须保证这些节点中半数以上的启动
   如果不满⾜以上两个条件，执⾏报错，在报错信息中会提⽰不能启动的原因。

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB数据库的管理和使用（2） <启动 GreatDB 集群所有节点> 章节。

• 说明：
  如果执⾏的 SqlNode 节点的组复制处于 ERROR 状态，需要先执⾏ STOP GROUP_REPLICATION 操作

强制重启 SqlNode 集群组复制

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

1. ⽆法通过 greatdb_restart_cluster 命令接⼝启动集群
2. 存活的 SqlNode 节点包含最新数据
3. 存活的 SqlNode 节点可能丢了数据，但业务确认这些数据的丢失是可以容忍的
4. 如果是多机房部署且发⽣⽹络分区，如果其它机房集群处于正常可⽤的状态，强制在执⾏的 SqlNode 节点所在的分区中强制重启集群，则会发⽣脑裂现象，需要业务保证故障的机房分区不能进⾏新的数据写⼊操作。

• ⽰例：

CALL `mysql`.`greatdb_force_restart_cluster`();

• 使用参考

• 说明：
  如果执⾏的 SqlNode 节点的组复制处于ERROR状态，需要先执⾏ STOP GROUP_REPLICATION 操作。

强制重启 shard 集群组复制

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

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

• ⽰例：

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

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

• 使用参考

表迁移接⼝

单表数据迁移

• ⽰例：

CALL `mysql`.`greatdb_migrate_table`('db_name', 'table_name', part_id, 'shard_name');

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB数据库的管理和使用（2） <手动执行数据重分布> 章节。
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <手动执行数据重分布> 章节。

• 注意事项：

1. 分⽚表和普通表，共享同⼀个⽤户接⼝，对于普通表，进⾏的是全表迁移，此时 part-id 参数⽆任何意义；对于分⽚表，每次迁移⼀个 parition，part_id 是该分区的id。可以通过查询 greatdb_table_distribution 查找当前表分布的规则。
2. 调⽤接⼝成功后，迁移任务将在后台运⾏，可以通过查询 greatdb_migrate_table_task 和 greatdb_migrate_table_subtask 查看具体迁移任务执⾏的状态
3. 禁⽌同⼀张表（普通表），或者同⼀个分区（分⽚表）同时运⾏多个迁移任务
4. 后台正在运⾏⾃动扩容迁移，或者⾃动缩容迁移任务，禁⽌运⾏单表迁移任务。
5. 该迁移任务受参数 greatdb_physical_migrate_table 控制，默认值为true，内部执⾏的是物理迁移；如果设置为false，内部执⾏逻辑迁移。

⾃动扩容迁移

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <添加 Shard 分片> 章节。

• 注意事项：

1. ⼀般在添加新的 shard 后执⾏
2. 该操作是幂等操作，如果上⼀次因故障执⾏失败，可以继续执⾏该命令继续迁移
3. 调⽤接⼝成功后，迁移任务将在后台运⾏，可以通过查询 greatdb_migrate_table_task 和 greatdb_migrate_table_subtask 查看具体迁移任务执⾏的状态
4. 后台有任何正在运⾏的迁移任务，禁⽌执⾏⾃动扩容迁移任务。

⾃动缩容迁移

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB 集群管理（5） <整个 Shard 分片的删除> 章节。

• 注意事项：

1. 该存储过程在对表数据迁移前，会⾃动选择需要缩容的 shard，并将这些 shard 置为 SUSPEND 状态，处于该状态的 shard，不会创建新表
2. 该存储过程本⾝并不会删除 shard，迁移完成后，需要⼿动调⽤ greatdb_drop_shard 删除处于 SUSPEND 状态的 shard
3. 同扩容迁移⼀样，操作是幂等操作，如果上⼀次因故障执⾏失败，可以继续执⾏该命令继续迁移
4. 调⽤接⼝成功后，迁移任务将在后台运⾏，可以通过查询 greatdb_migrate_table_task 和 greatdb_migrate_table_subtask 查看具体迁移任务执⾏的状态
5. 后台有任何正在运⾏的迁移任务，禁⽌执⾏⾃动扩容缩容任务。

停⽌迁移任务

• 使用参考

• 注意事项：

1. 可以通过查询 greatdb_task 获取迁移任务的 task-id
2. 只能停⽌正在运⾏的迁移任务，如果迁移任务已经完成，或者终⽌，则会报错
3. stop 命令是⼀个异步命令，执⾏成功后，可以通过 greatdb_migrate_table_task 和 greatdb_migrate_table_subtask ，查看任务状态

备份恢复管理接⼝

添加备份节点

• ⽰例：

CALL mysql.greatdb_add_backup_node('backup_node_1', '127.0.0.1', 3306);

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB备份与恢复（4） <添加 backup_node 节点> 章节。

• 注意事项：

1. 添加备份节点时，节点实例需要处于正常启动状态。
2. 备份节点不能同时作为集群的 SqlNode 或者 DataNode。
3. 可以添加多个备份节点，彼此之间独⽴，没有任何复制关系。如果备份节点间存在复制关系，会导致后续备份任务失败。
4. 集群备份采⽤ CLONE + 增量 binlog ⽇志的⽅式，添加备份节点时，会⾃动安装 CLONE 插件。
5. 备份节点需要实现配置 gdb_backup_dir 备份⽬录

删除备份节点

• ⽰例：

CALL mysql.greatdb_drop_backup_node('backup_node_1');

• 使用参考

执⾏全量备份

• ⽰例：

GreatDB Cluster[(none)]> call mysql.greatdb_start_full_backup;
+---------------------------------+
| current_backup_task_name        |
+---------------------------------+
| full_backup_20220301-032132_176 |
+---------------------------------+
1 row in set (39.90 sec)

Query OK,  rows affected (39.90 sec)

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB备份与恢复（4） <执行全量备份> 章节。

• 注意事项：

1. 备份任务执⾏时间⼀般会⽐较⻓，存储过程会等待备份执⾏成功后才返回结果。
2. 当前，受制于 CLONE 插件，每个数据库实例单次执⾏⼀个 clone 任务，因此全量数据 clone 是串⾏操作。不过可以通过添加备份节点数量的⽅式，实现并发性。

执⾏增量备份

• ⽰例：

GreatDB Cluster[test]> call mysql.greatdb_start_inc_backup('full_backup_20220301-032132_176');
+--------------------------------+
| current_backup_task_name       |
+--------------------------------+
| inc_backup_20220301-050855_183 |
+--------------------------------+
1 row in set (0.43 sec)

Query OK,  rows affected (0.44 sec)

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB备份与恢复（4） <测试增量备份> 章节。

• 注意事项：

1. 如果集群拓扑发⽣变更，⽆法执⾏增量备份，需要重新开启全量备份

停⽌备份任务

• 使用参考

• 注意事项：

1. 只能停⽌正在运⾏的备份任务，如果备份任务已经完成，或者终⽌，则会报错
2. stop 命令是⼀个异步命令，执⾏成功后，可以通过 greatdb_task 查询状态，也可以在备份节点中通过 greatdb_backup_tasks 查看任务状态

删除备份任务

• 使用参考

• 注意事项：

1. 假设执⾏备份任务A时有3个备份节点，执⾏drop命令前，移除了其中⼀个备份节点，则只会在剩 余的两个备份节点中删除备份⽂件
2. 如果执⾏任务A时有3个备份节点，在没有移除的前提下，任务⼀个备份节点故障均会提⽰错误
3. 只能删除已经完成，或者终⽌的备份任务
4. 需要特别注意的是，假设⼀个备份链路为 full_backup_1 -> inc_backup_2 -> inc_backup_3 -> inc_backup_4，假设删除 full_backup_1 或者 inc_backup_2，并不会删除后续 inc_backup_3和 inc_backup_4的备份信息和备份⽂件，新的备份任务仍可以基于inc_backup_4继续进⾏增量备份。 此时可能导致后续恢复操作的问题。因此不推荐这种操作，不过⽤户可以在确保备份⽂件安全转 移的情况下进⾏上述操作。

备份恢复后重建 SqlNode 节点

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB备份与恢复（4） <在 SqlNode 实例上调用接口恢复集群结构信息> 章节。

• 注意事项：

1. 重建后只有⼀个 SqlNode 节点，需要通过 greatdb_add_sqlnode 存储过程，添加其它的 SqlNode 节点
2. 同 greatdb_init_cluster ⼀样，会使⽤节点的参数配置初始化机房信息

备份恢复后重建 DataNode 节点

• 使用参考
  万里GreatDB数据库的学习之路–GreatDB备份与恢复（4） <在 SqlNode 实例上调用接口恢复集群结构信息> 章节。

• 注意事项：

1. 同 greatdb_restore_sqlnode_from_backup ⼀样，恢复后 shard 中只有⼀个数据节点，需要通 过 greatdb_add_datanode 添加其它节点
2. 需要保证节点的 gdb_zone_name 和 group_replication_zone_id 和集群中某⼀个机房 zone_name, zone_id 保持⼀致，否则⽆法添加成功。当然，如果节点类型为 NODE_SINGLE，⽆需配置 group_replication_zone_id。

机房管理接⼝

添加机房

需要注意的是，机房属性将影响添加新的 SqlNode 和 DataNode。添加 SqlNode 或者 DataNode 时，需要保证待 添加节点的 gdb_zone_name 参数和 group_replication_zone_id 参数和已经添加的某个机房匹配，否则会 执⾏失败。（当然，如果添加的NODE_SINGLE的datanode节点，不需要配置group_replication_zone_id 参数。）

• 使用参考

删除机房

如果该机房中还存在任何⼀个 SqlNode 或者 DataNode 节点，将⽆法删除机房。

• 使用参考

修改机房属性

该存储过程接⼝提供⼀个通⽤接⼝，⽤于修改机房的不同属性值。
当前，允许修改的属性包括（区分⼤⼩写）：

1. zone_name：修改机房名称。修改机房名称后，需要更新相应节点的gdb_zone_name系统变量值， 其中，sqlnode会在更新机房名称的同时同步修改节点的gdb_zone_name；⽽对于datanode，会通过 后台任务异步修改gdb_zone_name。
2. city：修改机房所属城市信息。
3. elect_weigth：修改机房的选举权重， 范围为[0, 9]。对于NODE_MGR类型的datanode节点，会通过 后台线程修改节点的group_replication_member_weight的系统变量值。新的变量值为 elect_weigth * 10 + (old_member_weigth % 10) 。

不允许修改的属性包括：

1. zone_id，机房id。

• 使用参考

其他

greatdb_build_group_replication
greatdb_start_group_replication
greatdb_persist_variables
greatdb_check_upgrade
greatdb_mgr_check
greatdb_plugin_check