作者：jaideep.karande
背景
以前，只考虑过主要版本。使用维护版本（8.0.17）意味着组复制可以在组重新配置和升级过程中更好地维护混合版本组的复制安全性。
1. 主成员选项
A.主成员选举算法
具有 8.0.17 或更高版本成员的组
具有至少一个 8.0.16 或更低成员版本的组
B.用户触发主切换
具有 8.0.17 或更高版本成员的组
具有至少一个 8.0.16 或更低成员版本的组
2. 写版本兼容性 3. 最低版本兼容性 4. 捐赠者版本兼容性 5. 升级 6. 结论
在主成员的故障转移期间，基于以下算法选择新的主成员：
3. 服务器 uuid 的词法排序在相同成员权重的组内是最低的
例3：主成员退出后的小组：
8.0.19 权重：90 uuid：5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c
8.0.19 权重：90 uuid：5a67adc9-6ad1-11e7-9b1f-f48c5048ab0c
8.0.19 权重：50 uuid：5a6e5078-6ad1-11e7-9bce-f48c5048ab0c
具有至少一个 8.0.16 或更低成员版本的组
该组中至少有 1 名成员，版本低于 8.0.17。
1. 考虑主要版本的该组的最低成员版本
2. 根据步骤-1，该组中最低成员的成员权重较高
例子
例1：主成员退出后的小组：
5.7.22 / 8.0.20 / 8.0.20
5.7.22 版本的服务器将从其最低版本的组中被选为主服务器。
用户触发主切换
如果主成员被修改为使用UDF，group_replication_set_as_primary（server_uuid）或 group_replication_switch_to_single_primary_mode（[server_uuid]），则还会采取一些预防措施以确保所有成员兼容并可以执行所需的更改。算法如下：
具有 8.0.17 或更高版本成员的组
该组中的所有成员都具有 8.0.17 或更高版本。
1. 如果提供了 server_uuid，则该服务器将成为主成员，如果其版本在组中最低（考虑补丁级别），否则将引发错误。
例1：多主模式到单主模式切换时的组成员：
8.0.19 权重：50 / 8.0.20 权重：90 / 8.0.20 权重：95
具有至少一个 8.0.16 或更低成员版本的组
该组中至少有 1 名成员，版本低于8.0.17。
1. 如果组中的任何成员的版本为 5.7 或版本低于 8.0.13，则该函数不会对主成员进行任何更改。
2. 如果主要版本 8 提供的 server_uuid，那么该服务器将成为主成员，否则将抛出错误。
3. 如果未提供 server_uuid，则考虑到组成员版本的唯一主版本，将进行选举。
注意：对于 UDF group_replication_set_as_primary，server_uuid 是必需的。如果未提供 server_uuid，UDF 将失败。
例子
例1：多主模式到单主模式切换时的组成员：
8.0.14 权重：90 / 8.0.20 权重：50 / 8.0.20 权重：90 / 8.0.20 权重：95
“版本 8.0.20 权重：95”的服务器将被选为主服务器，因为该组的最低主要版本（由于组中存在 8.0.14 而忽略了维护版本）。
写版本兼容性
从 8.0.17 开始，如果新成员版本高于组的最低成员版本（考虑补丁级别），则新成员将处于只读模式。
如果该组通过执行 UDF group_replication_switch_to_multi_primary_mode 进入多主模式，则该组的最低成员版本将是可写的，而其他成员将处于只读状态。
版本为 8.0.16 或更低版本的成员，如果组中的任何成员具有 5.7 版本，则以只读模式加入组。版本 5.7 的成员始终可写，因为 5.7 仅考虑主要版本。在 MySQL 5.7 和 8.0 中，直到补丁级别 16，当低版本成员离开组时，用户必须手动重新配置只读模式。
例子
例1：多主模式的组成员：
8.0.19 / 8.0.20
版本 8.0.19 的服务器将是可写的，而 8.0.20 将是只读的。
例2：组成员在单主模式到多主模式切换期间：
8.0.19（主）/ 8.0.19（副）/ 8.0.20（副）/ 8.0.21（副）
版本 8.0.19 的服务器将是可写的，而 8.0.20 和 8.0.21 将是只读的多主模式开关。
例3：多主模式的组成员：
5.7.21 / 8.0.15
版本为 5.7.21 的服务器是可写的，而 8.0.15 将是只读的。
例4：组成员在单主模式到多主模式切换期间：8.0.14（副）/ 8.0.15（副）/ 8.0.20（副）/ 8.0.21（主）
版本 8.0.14 和 8.0.15 的服务器是可写的（旧版本），而 8.0.20 和 8.0.21 将是只读的。Server 8.0.21 将启用只读模式。
最低版本兼容性
从 8.0.17 开始，如果新成员版本低于该组的最低成员版本（考虑补丁级别），则新成员将不加入该组。
例子
例1：小组成员：
8.0.19 / 8.0.20 / 8.0.20
版本为 8.0.17 或 8.0.18 的服务器将无法加入该组。
例2：小组成员：
8.0.15 / 8.0.16
版本为 5.7.27 的服务器将无法加入该组。
捐赠者版本兼容性
从 8.0.17 开始，在形成可能的捐赠者组列表的同时，具有与新成员相同或更低版本的 ONLINE 成员被视为有效捐赠者。但是，如果设置了 allow_local_lower_version_join，则该组的所有 ONLINE 成员都可以充当有效的捐赠者，因为没有相同或更低版本的成员。
例子
例1：组成员：
5.7.22 / 8.0.20 / 8.0.21
新成员 8.0.20 可以使用 5.7.22 或 8.0.20 作为捐赠者。
例2：组成员：
5.7.22 / 8.0.20 / 8.0.21
新成员 5.7.22 可以使用 5.7.22, 8.0.20 或 8.0.20 作为捐赠者。
升级
对于单主升级，用户可以先更新每个副成员，然后再更新主成员。
以后的用户可以使用 UDF group_replication_set_as_primary 使所需的成员成为主成员。或者用户可以将更高的成员权重分配给所需的成员和升级组，首先升级所需的主成员。
对于多主升级，可以按任何顺序升级成员。在完成组升级的过程中，由于版本较高，升级后的成员将处于只读模式。一旦该组的所有成员升级到相同的补丁级别，所有成员都将变为可写。
关于不期望升级的一些注意事项：
如果其版本低于该组的最低成员版本，则成员将不会加入该组（考虑补丁级别）
∘ 如果升级后，版本不会是相同的补丁级别，则应首先启动新的最低成员版本。
如果组中的所有成员的版本都大于 8.0.16，则只有当成员是组中的最低版本（包括修补程序级别）时，才允许该成员成为主要成员。
∘ 如果主要升级后必须保持相同的升级，则主要升级（包括补丁级别）可能不会通过此 WL。应将组的辅助成员升级到高于或等于主要成员版本的版本。
例子
例1（单主升级）
M1：8.0.20（旧主）/ M2：8.0.20（新主）/ M3：8.0.20
1. DBA 希望将所有组成员升级到 8.0.21
2. 在 M2 上设置更高的成员权重并升级 M2
3. 立即升级 M3 和 M1
4. M1 和 M3 升级后， M2 将成为主要
例2（单主升级）
M1：8.0.20（主）/ M2：8.0.20 / M3：8.0.20
1. DBA 希望将所有组成员升级到 8.0.21
2. 将 M2 和 M3 升级到 8.0.21 或更高版本
3. 在 M2 和 M3 升级后，M1 可以升级到 8.0.21
4. 使用 UDF group_replication_set_as_primary M1 可以成为主
例3：（多主升级）
M1：8.0.20 / M2：8.0.20
1. DBA 希望将所有组成员升级到 8.0.21
2. 升级 M1
3. M1 升级后，M1 将是只读的，直到 M2 升级到 8.0.21
4. 一旦 M2 升级到 8.0.21，M1 将变为可写
结论
MySQL 8.0.17 是公开可用的，随之而来的是对组复制的改进。现在，组复制可以增加安全性，并确保成员生成的事务与组中的每个成员兼容。
阅读原文：https://mysqlhighavailability.com/improved-handling-of-different-member-versions-in-group-replication/
近期社区动态
