作者 罗小波 · 数据库技术专家
出品 沃趣科技
组复制处于运行状态时，可以使用一组依赖于组操作协调器的UDF自定义函数来对组做一些在线变更操作。这些UDF 由8.0.13或更高版本的MGR插件提供。本节描述如何使用这些UDF自定义函数来对组进行在线进行一些变更操作。
注意：要使协调器能够在运行中的组中有效执行组范围内的配置变更操作，所有成员必须运行在MySQL 8.0.13或更高版本中，且配置安装好了UDF（加载好了MGR插件）。
要使用UDF，使用客户端程序连接到组中的任意成员，并使用SELECT语句执行UDF调用。MGR插件会处理该操作及其相关的参数调整，协调器会将此操作发送给组中所有成员（执行此操作能够看到的所有组成员）。如果该操作被接受，所有成员都将执行该操作。一旦所有成员都声明操作已完成时，调用UDF的成员会将执行结果返回给客户端。
在配置整个组时，操作的分布式特性意味着它们与MGR插件有许多进程交互，因此需要注意以下几点：
您可以在任何地方执行配置操作：假设您想让组成员A成为新的主要节点，在组成员A上执行UDF的调用操作不是必须的。因为，操作会以协调的方式在所有组成员上发送和执行，因此，在任意一个组成员中执行调用都可以。此外，因为操作是分布式的，所以执行的状态在某一时刻可能在每个组成员中不相同（有不同的状态分支），例如：如果执行调用UDF的组成员宕机，则任何已经执行的配置操作将继续在其他组成员上执行。因此，即使在执行UDF调用的组成员宕机的情况下，仍然可以使用相关的监控功能来查看并确保其他组成员成功完成调用操作。
所有组成员必须在线：为了简化迁移或选举的过程，并确保它们尽可能快地执行完成，组不能包含正处于分布恢复过程中的任何成员，否则组成员将直接拒绝执行UDF来更改组的配置。
在配置变更期间，不能有任何Server正在申请加入组：在协调配置变更期间尝试申请加入组的任何Server都会被拒绝，并终止其加入组的过程。
同一时间内只允许执行一个配置变更操作：正在执行配置变更的组不能接受任何其他的组配置变更操作，因为并发配置操作可能导致组中的成员出现分裂。
组中的所有成员必须运行MySQL 8.0.13或更高版本：由于配置操作的分布式特性，组中的所有成员必须识别（支持）配置操作。因此，如果组中存在运行MySQL 8.0.12或更低版本的成员时，则会拒绝执行配置操作。
4.1.1. 修改组的主要节点
本节介绍在单主模式的组中如何使用UDF自定义函数来更改主要节点。用于更改组中主要节点的函数可以在任何成员上运行。
通过使用group_replication_set_as_primary() UDF来更改单主模式的组中的主要节点（如果组运行在多主模式下，则执行该函数不会有任何影响）。单主模式的组中，只有主要节点才允许数据写入（其他成员为辅助节点，只能接受只读请求），因此，如果在该成员（主要节点）上正在运行异步通道（这里指的是主要节点还同时作为主从复制拓扑中的从库），则在停止异步通道之前不允许切换主要节点。
如果在MySQL 8.0.17或以上版本的组成员上执行UDF调用，且组中所有成员都运行在MySQL 8.0.17或以上版本，那么只能基于补丁版本（次要版本，例如：MySQL 8.0.17中，8.0是主要版本，17是次要版本）指定一个组中版本号最低的MySQL服务器作为新的主要节点。此保护措施用于确保组中新功能特性的兼容性。但，如果任何成员运行在MySQL 8.0.13和MySQL 8.0.16之间的版本，则不会对组强制执行此保护措施，可以指定任何成员为主要节点，但为了避免出现一些不兼容的意外发生，建议选择组中版本号最低的成员作为主要节点。
修改组中的主要节点时，使用group_replication_set_as_primary函数并指定将要切换为主要节点的成员server_uuid，如下：
# 查询组成员的状态信息，可以看到当前node1为主要节点（MEMBER_ROLE列值为PRIMARY）
root@localhost : performance_schema:55: > select * from replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.01 sec)
# 指定node2为新的主要节点
root@localhost : performance_schema:55: > SELECT group_replication_set_as_primary('2d283e92-de7b-11e9-a14d-525400c33752');
+--------------------------------------------------------------------------+
| group_replication_set_as_primary('2d283e92-de7b-11e9-a14d-525400c33752') |
+--------------------------------------------------------------------------+
| Primary server switched to: 2d283e92-de7b-11e9-a14d-525400c33752 |
+--------------------------------------------------------------------------+
1 row in set (0.03 sec)
# 再次查看组成员状态信息，可以发现node2已经被切换为了主要节点
root@localhost : performance_schema:56: > select * from replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | PRIMARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | SECONDARY | 8.0.17 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
当操作运行时，您可以通过执行以下语句来检查其进度。
# 注：events_stages_current表是记录线程当前正在执行的事件信息，所以只有线程正在执行某个语句时才能够查询到事件信息，一旦线程执行完成，事件信息就会被清除
root@localhost : performance_schema:58: > SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%";
+----------------------------------------------------------------------------------+----------------+----------------+
| event_name | work_completed | work_estimated |
+----------------------------------------------------------------------------------+----------------+----------------+
| stage/group_rpl/Primary Election: Waiting for members to turn on super_read_only | 3 | 5 |
+----------------------------------------------------------------------------------+----------------+----------------+
4.1.2. 修改组的运行模式
本节介绍了如何修改组的运行模式，无论是单主模式还是多主模式。用于修改组运行模式的函数可以在组中任何成员上运行。但是。
如果组已经处于单主模式，虽然可以调用group_replication_switch_to_single_primary_mode() UDF，但是没有任何作用，会返回提示信息："Already in single-primary mode. Did you mean to use group_replication_set_as_primary?"
如果组已经处于多主模式，虽然可以调用group_replication_switch_to_multi_primary_mode() UDF，但是仍然没有任何作用，会返回提示信息："The group is already on multi-primary mode. "
4.1.2.1. 切换到多主模式
假设组已经处于单主模式，使用group_replication_switch_to_multi_primary_mode() UDF执行如下语句，将单主模式下运行的组修改为多主模式：
# 查查看组成员的状态信息，可以发现目前组处于单主模式（有一个PRIMARY成员，2个SECONDARY成员）
root@localhost : performance_schema:30: > select * from replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | PRIMARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | SECONDARY | 8.0.17 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
# 查看组模式系统变量值，发现已经被启用，组处于单主模式下
root@localhost : performance_schema:12: > show variables like '%group_replication_single_primary_mode%';
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| group_replication_single_primary_mode | ON |
+---------------------------------------+-------+
1 row in set (0.01 sec)
# 执行如下语句切换到多主模式（不能指定组成员的系统变量server_uuid值作为参数，否则报错："ERROR 1123 (HY000): Can't initialize function 'group_replication_switch_to_multi_primary_mode'; Wrong arguments: This function takes no arguments."）
root@localhost : performance_schema:38: > SELECT group_replication_switch_to_multi_primary_mode();
+--------------------------------------------------+
| group_replication_switch_to_multi_primary_mode() |
+--------------------------------------------------+
| Mode switched to multi-primary successfully. |
+--------------------------------------------------+
1 row in set (1.02 sec)
# 再次查看组成员状态信息，可以发现3个成员的MEMBER_ROLE列值都为PRIMARY，表示此时3个组成员都可读写
root@localhost : performance_schema:39: > select * from replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | PRIMARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | PRIMARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.01 sec)
# 再次查看组模式系统变量，发现已经被关闭，组处于多主模式下
root@localhost : performance_schema:10: > show variables like '%group_replication_single_primary_mode%';
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| group_replication_single_primary_mode | OFF |
+---------------------------------------+-------+
1 row in set (0.00 sec)
上述步骤中，调用group_replication_switch_to_multi_primary_mode() 函数之后，组内经过一些能够确保数据的安全性和一致性的协调操作之后，组中所有的成员都成为了主要节点。
PS：当将单主模式运行的组更改为以多主模式运行时，如果组中存在MySQL 8.0.17或更高版本的成员，且高于组中所有成员的最低版本时，会自动将MySQL 8.0.17或更高版本的成员置于只读模式。运行在MySQL 8.0.16或更低版本的成员不执行此检查，且始终处于读写模式。所以，在MySQL 8.0.17或更高版本中，多主模式下不一定是所有成员都会处于读写模式，如果你的组中使用了多个版本的MySQL Server，则需要留意。
当函数运行过程中（未执行完成），您可以通过执行如下语句来检查其执行进度。
root@localhost : (none):48: > SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%";
+----------------------------------------------------------------------+----------------+----------------+
| event_name | work_completed | work_estimated |
+----------------------------------------------------------------------+----------------+----------------+
| stage/group_rpl/Multi-primary Switch: applying buffered transactions | 0 | 1 |
+----------------------------------------------------------------------+----------------+----------------+4.1.2.2. 切换到单主模式
假设组已经处于多主模式，使用group_replication_switch_to_single_primary_mode() UDF将运行在多主模式的组更改为单主模式，当切换到单主模式时，同时还会禁用所有组成员上的严格一致性检查(group_replication_mandatory _update_everywhere_check =OFF)，因为单主模式要求组关闭严格一致性检查。
在调用group_replication_switch_to_single_primary_mode() UDF时，可以为其指定一个成员的server_uuid字符串作为参数，这样指定的成员将成为新的主要节点，如果未指定，则将自动根据选举策略选出新的主要节点。示例如下：
# 先查看一下组成员的状态信息，可以发现此时3个成员都为主要节点
root@localhost : performance_schema:40: > select * from replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | PRIMARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | PRIMARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
# 查看组模式系统变量，发现此时单主模式被关闭，组处于多主模式下
root@localhost : performance_schema:10: > show variables like '%group_replication_single_primary_mode%';
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| group_replication_single_primary_mode | OFF |
+---------------------------------------+-------+
1 row in set (0.00 sec)
# 执行模式切换，指定一个组成员的server_uuid作为group_replication_switch_to_single_primary_mode() UDF的参数
root@localhost : performance_schema:07: > SELECT group_replication_switch_to_single_primary_mode('320675e6-de7b-11e9-b3a9-5254002a54f2');
+-----------------------------------------------------------------------------------------+
| group_replication_switch_to_single_primary_mode('320675e6-de7b-11e9-b3a9-5254002a54f2') |
+-----------------------------------------------------------------------------------------+
| Mode switched to single-primary successfully. |
+-----------------------------------------------------------------------------------------+
1 row in set (0.02 sec)
# 再次查看组成员的状态信息，可以发现指定的server_uuid(mode1)成员成为了主要节点
root@localhost : performance_schema:08: > select * from replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
# 再次查看组模式系统变量值，发现已经被启用，组处于单主模式下
root@localhost : performance_schema:12: > show variables like '%group_replication_single_primary_mode%';
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| group_replication_single_primary_mode | ON |
+---------------------------------------+-------+
1 row in set (0.01 sec)
如果在运行MySQL 8.0.17及其更高版本的组成员上调用UDF，且所有成员都运行在MySQL 8.0.17或更高版本中，且组中存在不同版本的组成员时，则，只能基于补丁版本指定组中最低MySQL Server版本的成员做为主要节点。此保护措施用于确保组与新功能保持兼容性。如果没有为UDF指定新的主要节点，则选举过程中将会考虑组成员的补丁版本（自动选举组中最低版本的成员作为主要节点）。
如果任何成员正在运行MySQL 8.0.13和MySQL 8.0.16之间的MySQL Server版本，则不会对组强制执行此保护，可以指定任何新的组成员作为主要节点，但建议选择组中最低MySQL Server版本的成员作为主要节点。如果没有指定新的主要节点，则选举过程只考虑组成员的主要版本（选举最低主版本的成员作为主要节点）。
当函数运行过程中（未执行完成），您可以通过执行如下语句来检查其执行进度。
root@localhost : performance_schema:24: > SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%";
+----------------------------------------------------------------------------+----------------+----------------+
| event_name | work_completed | work_estimated |
+----------------------------------------------------------------------------+----------------+----------------+
| stage/group_rpl/Primary Switch: waiting for pending transactions to finish | 4 | 20 |
+----------------------------------------------------------------------------+----------------+----------------+4.1.3. 设置组并发可写实例数
本节介绍如何检查和配置一个组中的最大并行可写实例数（即，并行在组成员之间广播传输的最大并发可写实例数）。这个最大值称为组的事件范围，可以通过调整该值来优化组复制的性能。例如：默认值10适用于在LAN上运行的组，但是对于在WAN等速度较慢的网络上运行的组，可以通过增加这个数字来提高性能。
检查组的写并发性：使用group_replication_get_write_concurrency() UDF在运行时检查组的事件范围值（注：该函数不需要传入参数），如下：
root@localhost : performance_schema:04: > select group_replication_get_write_concurrency();
+-------------------------------------------+
| group_replication_get_write_concurrency() |
+-------------------------------------------+
| 10 |
+-------------------------------------------+
1 row in set (0.00 sec)
配置组的写并发性：使用group_replication_set_write_concurrency() UDF设置组可以并行执行的可写实例的最大数量，如下：
root@localhost : performance_schema:04: > select group_replication_set_write_concurrency(100);
+-----------------------------------------------------------------------------------+
| group_replication_set_write_concurrency(100) |
+-----------------------------------------------------------------------------------+
| UDF is asynchronous, check log or call group_replication_get_write_concurrency(). |
+-----------------------------------------------------------------------------------+
1 row in set (0.00 sec)
PS：
使用该UDF自定义函数配置组的写并发性（修改组中允许并行执行的可写实例的最大数量）需要用户具有GROUP_REPLICATION_ADMIN权限。
默认的最大并发读写实例数为10，该函数的有效参数值为10~200。
4.1.4. 设置组的通信协议版本
从MySQL 8.0.16开始，组复制就有了组通信协议的概念。可以显式地管理组复制通信协议的版本，并将其设置为你希望组支持的最老的MySQL Server版本号。这使得组允许由运行在不同MySQL Server版本的成员组成，同时确保向后兼容性。MySQL 5.7.14的版本允许压缩消息（这里的消息可以简单理解为MySQL通讯协议中对客户端与服务端之间按照不同的协议传输的数据的一种抽象概念），MySQL 8.0.16的版本也允许消息分段。组的所有成员必须使用相同的通信协议版本，这样使用不同MySQL Server版本的组成员之间才能够发送与接收相互都能理解的消息。
假如一个MySQL Server的版本为X，则它只能加入通讯协议版本小于等于X的组。当有新的Server申请加入组时，它将检查组中声明的现有通讯协议版本，如果新加入成员支持该版本（符合版本规则），则该成员加入组且使用组中已声明的通讯协议版本（即使新加入组的成员版本更高，支持更多的额外功能也是如此，因为需要保证组中成员之间的兼容性），如果新加入成员不支持组声明的通讯协议版本，则加入组将会失败。
只有新加入组的成员的通讯协议版本与组中声明的通讯协议版本兼容时，才允许加入组。如果存在多个成员同时加入组时，且他们的通讯协议版本与组中声明的通讯协议版本相同，则允许同时加入组，否则，他们只能串行加入组，具体的判断规则如下：
一个MySQL 8.0.16版本的Server可以成功加入使用通信协议版本为5.7.24的组，因为组的通讯协议版本为5.7.24，小于新加入成员的版本8.0.16。
一个MySQL 5.7.24版本的Server无法成功加入使用通讯协议版本为8.0.16的组，因为组的通讯协议版本为8.0.16，大于新加入成员的版本5.7.24。
两个MySQL 8.0.16版本的Server不能同时加入使用通讯协议版本为5.7.24的组，因为组的通讯协议版本为5.7.24，小于（不等于）新加入成员的版本8.0.16。
两个MySQL 8.0.16版本的Server可以同时加入使用通讯协议版本为8.0.16的组，因为组的通讯协议版本为8.0.16，等于新加入成员的版本8.0.16。
PS：
* 为什么会存在这种版本限制呢？在单主模式下，组中最小版本的成员通常会被选举为主要节点，相当于主从复制拓扑中的主库，而其他更高版本的成员通常会置为辅助节点，相当于主从复制拓扑中的从库。在主从复制拓扑中，为了保证从库回放主库的二进制日志时能够向下兼容主库，所以从库的版本必须大于等于主库的版本。在一个正常运行的组中，一定存在着一个已经选举成功的写节点，而写节点通常是版本最低的（组中的通讯协议版本通常是以组中最低版本的成员为准），新加入一个成员就相当于在主从复制拓扑中新加入一个从库，所以，同理，在组复制拓扑中，辅助节点为了保证版本能够向下兼容主要节点，新加入的成员版本必须大于等于组中的通讯协议版本（组中所有成员中最低的MySQL Server版本） 。
* 注意：通讯协议版本不意味着组中存在该版本的成员，例如：默认情况下，MySQL 版本为8.0.17的Server使用的是8.0.16的通讯协议版本，该协议版本表示该组当前声明的所能支持的最低MySQL Server版本号（即，小于该版本号的MySQL Server无法加入组·）。
使用group_replication_get_communication_protocol() UDF检查组使用的通信协议，UDF返回组支持的最老的MySQL Server版本。组中所有现有成员中执行该UDF都会返回相同的通信协议版本。如下：
root@localhost : (none):56: > SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.16 |
+------------------------------------------------+
1 row in set (0.00 sec)
如果需要更改组的通信协议版本，以便使用更早期版本的成员可以加入组，可以使用group_replication_set_communication_protocol() UDF指定你希望允许加入组的最老的MySQL Server版本。如果指定的旧版本成员成功加入组，则将使组退回到兼容的通信协议版本（最低版本的成员支持的通讯协议版本）。使用该UDF需要用户具有GROUP_REPLICATION_ADMIN权限，当执行该语句时，所有组中的现有成员都必须在线（组可用），如下：
# 注意：group_replication_get_communication_protocol () UDF返回的是组中支持的最低MySQL Server版本（组中声明的通讯协议版本），这可能与使用group_replication_set_communication_protocol () UDF设置组的通讯协议版本时传递给它的版本不同、也可能与组中的最低成员的MySQL Server版本不同（这一点上文中已经提到过了）
root@localhost : (none):32: > SELECT group_replication_set_communication_protocol("5.7.25");
+-----------------------------------------------------------------------------------+
| group_replication_set_communication_protocol("5.7.25") |
+-----------------------------------------------------------------------------------+
| The operation group_replication_set_communication_protocol completed successfully |
+-----------------------------------------------------------------------------------+
1 row in set (0.00 sec)
root@localhost : (none):32: > SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 5.7.14 |
+------------------------------------------------+
1 row in set (0.00 sec)
如果将组中所有成员都升级到新的MySQL Server版本，则组不会自动将该组的通信协议版本升级到匹配最新的版本。必须使用group_replication_set_communication_protocol() UDF将通信协议版本设置为最新MySQL Server版本。如下：
root@localhost : (none):32: > select version();
+-----------+
| version() |
+-----------+
| 8.0.17 |
+-----------+
1 row in set (0.00 sec)
root@localhost : (none):35: > SELECT group_replication_set_communication_protocol("8.0.17");
+-----------------------------------------------------------------------------------+
| group_replication_set_communication_protocol("8.0.17") |
+-----------------------------------------------------------------------------------+
| The operation group_replication_set_communication_protocol completed successfully |
+-----------------------------------------------------------------------------------+
1 row in set (0.01 sec)
root@localhost : (none):35: > SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.16 |
+------------------------------------------------+
1 row in set (0.00 sec)
group_replication_set_communication_protocol() UDF作为一个组操作实现，因此它同时在组的所有成员上执行。执行该函数过程中，组操作会缓冲消息并等待通讯协议版本修改完成之后再将缓冲的消息发送出去。如果某个Server在更改通信协议版本后尝试加入组，则组中的成员将使用最新的通讯协议版本来决定是否允许该Server加入组。
| 作者简介
罗小波·数据库技术专家
《千金良方——MySQL性能优化金字塔法则》作者之一。熟悉MySQL体系结构，擅长数据库的整体调优，喜好专研开源技术，并热衷于开源技术的推广，在线上线下做过多次公开的数据库专题分享，发表过近100篇数据库相关的研究文章。
延伸阅读
全文完。
Enjoy MySQL 8.0 :)
叶老师的「MySQL核心优化」大课已升级到MySQL 8.0，扫码开启MySQL 8.0修行之旅吧
扫一扫
8676
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
