mysql group replication自动主从切换吗
*************************** 1. row ***************************
Id: 3
User: system user
Host:
db: NULL
Command: Connect
Time: 2601
State: Slave has read all relay log; waiting for the slave I/O thread to update it
Info: NULL
*************************** 2. row ***************************
Id: 4
User: root
Host: localhost
db: NULL
Command: Query
背景
为获得最佳兼容性和性能，组的所有成员为了 Group Replication，应运行相同版本的 MySQL Server。但是，在某些情况下，可能需要组内有不同版本的服务器运行共存。例如，在滚动升级期间。当组中存在不同的版本时，某些成员可能与其他成员不兼容，因为它们支持其他人没有或缺乏其他人所具有的功能。因此，组复制需实现兼容性策略以防止运行到不兼容的版本组合方案。在 MySQL 8.0.17 中，组复制为组中的成员版本实现的兼容性策略考虑了成员的 MySQL Server 版本的补丁版本。
以前，只考虑过主要版本。使用维护版本（8.0.17）意味着组复制可以在组重新配置和升级过程中更好地维护混合版本组的复制安全性。
内容大纲
1. 主成员选项
A.主成员选举算法
具有 8.0.17 或更高版本成员的组
具有至少一个 8.0.16 或更低成员版本的组
B.用户触发主切换
具有 8.0.17 或更高版本成员的组
具有至少一个 8.0.16 或更低成员版本的组
主成员选项选择新的主节点时的参数之一是用于复制安全性的成员版本。从 8.0.17 开始，在选择新主时也考虑补丁级别。因此，基于组配置的下一个主要内容存在细微差别。
主成员选举算法
具有 8.0.17 或更高版本成员的组该组中的所有成员都具有 8.0.17 或更高版本。1. 该组的最低成员版本，包括补丁级别2. 根据步骤-1，该组中版本最低成员的成员权重较高
例子例1：主成员退出后的小组：8.0.19 / 8.0.20 / 8.0.208.0.19 将因其最低版本，开始被选为主服务器。例2：主成员退出后的小组：8.0.19 权重：90 / 8.0.19 权重：50 / 8.0.20 权重：90 / 8.0.20 权重：95“版本 8.0.19 权重：90”的服务器将被选为主要服务器，因为它是组内的最低版本且有较高的权重。
“8.0.19 权重：90 uuid：5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c”的服务器将被选为主，因为其具有较高成员权重和最低服务器 uuid。
3. 服务器 uuid 的词法排序在相同成员权重的组内是最低的
2. 如果未提供 server_uuid，则考虑组成员版本直到补丁级别进行选举。例子
“版本 8.0.19 权重：50”的服务器将被选为主服务器，因为它的补丁是该组的最低版本。
注意：这仅适用于多主模式。
版本 5.7 的成员无法加入仅包含 8.0+ 成员的组。8.0.16 或更低版本的成员可以加入任何组，因为它只考虑主要版本。
5.7 级别或 MySQL 8.0 至 8.0.16 的组复制版本将所有 ONLINE 成员视为恢复的主动捐助者。
如果其版本低于该组的最低成员版本，则成员将不会加入该组（考虑补丁级别）
∘ 如果升级后，版本不会是相同的补丁级别，则应首先启动新的最低成员版本。
如果组中的所有成员的版本都大于 8.0.16，则只有当成员是组中的最低版本（包括修补程序级别）时，才允许该成员成为主要成员。
∘ 如果主要升级后必须保持相同的升级，则主要升级（包括补丁级别）可能不会通过此 WL。应将组的辅助成员升级到高于或等于主要成员版本的版本。
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 使所需的成员成为主成员。或者用户可以将更高的成员权重分配给所需的成员和升级组，首先升级所需的主成员。
对于多主升级，可以按任何顺序升级成员。在完成组升级的过程中，由于版本较高，升级后的成员将处于只读模式。一旦该组的所有成员升级到相同的补丁级别，所有成员都将变为可写。
关于不期望升级的一些注意事项：
例子
例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 是公开可用的，随之而来的是对组复制的改进。现在，组复制可以增加安全性，并确保成员生成的事务与组中的每个成员兼容。
|
广告 您可能关注的内容 |
