通常MySQLMGR要求各节点之间版本保持一致，这样能够保证MGR最大的性能和兼容性。但是在某些场景下，比如滚动升级，MGR各节点版本在某个时间段内会出现不同，如果节点出现版本不一致，可能会导致节点之间不兼容，比如某个高版本的节点支持的函数和特性，在其他低版本的节点上不支持。从MySQL8.0.17版本开始，MGR的兼容性策略将从小版本号考虑，而之前则是从主版本号考虑。
一、主节点选举：
MGR单主模式，主节点宕机后，新的主节点将被选出，选举新主节点的算法如下：
如果所有节点都是MySQL8.0.17及以上版本：
优先低版本节点如果版本一样，优先权重大的节点如果版本与权重一样，按照serveruuid的字母顺序选主举几个例子：
例一：剩下3个节点，版本分别为：
8.0..0..0.20那么8.0.19版本的那个节点将会被选举为新主节点，因为它的版本最低。
例二：剩下4个节点，并且每个节点有权重设置，如下：
8.0.19weight:.0.19weight.0.20weight.0.20weight95那么8.0.19weight:90这个节点将被选举为新主节点，因为它是版本最低的节点中，权重最高的。
例三：剩下3个节点，并且每个节点的版本和权重一样
8.0.19weight90uuid:5a5d0f6e-6ad1-11e7-9aee-f48cab0c8.0.19weight90uuid:5a67adc9-6ad1-11e7-9b1f-f48cab0c8.0.19weight50uuid:5a6e-6ad1-11e7-9bce-f48cab0c节点5a5d0f6e-6ad1-11e7-9aee-f48cab0c将被选举为新主，因为当节点版本、权重一样时，那么uuid的字母顺序靠前的将优先被选举为新主。
如果MGR节点中至少有一个是8.0.16或者以下的版本
举个例子：
5.7..0..0.20那么5.7.22这个节点将会被选举为新的主节点。
二、UDF函数兼容性
对于用户使用的UDF函数，比如在单主模式中，使用group_replication_set_as_primary(server_uuid)函数，或者多主模式中，使用group_replication_switch_to_single_primary_mode([server_uuid])函数变为单主模式，如果节点中的版本不同，并且使用上述函数指定的server_uuid，其版本与兼容性策略有冲突，那么将会报错。
如果所有节点都是MySQL8.0.17及以上版本：
如果上述UDF函数中指定的server_uuid，其版本不是所有节点中最低的，那么该函数将会报错。如果上述UDF函数中没有指定server_uuid，那么将会自动从所有节点中，选择版本最低的作为主节点。举个例子，MGR多主模式转换为单主模式：
8.0.19weight.0.20weight.0.20weight95那么8.0.19weight50节点将会被选举为主节点。
如果MGR节点中至少有一个是8.0.16或者以下的版本
如果节点中有任何一个版本为5.7，或者低于8.0.13，UDF函数将不会起作用。如果UDF函数指定的server_uuid，其主版本为8.0，那么该节点将会成为主节点，否则报错。如果UDF函数没有指定server_uuid，那么选主将只考虑主版本举个例子，MGR多主模式转换为单主模式：
8.0.14weight.0.20weight.0.20weight.0.20weight95那么8.0.20weight95这个节点将成为新的主节点。
三、写入版本兼容性
从8.0.17版本开始，如果一个新的节点，其版本比其他节点中最小版本大，那么这个节点将会变成只读模式。如果使用UDF函数group_replication_switch_to_multi_primary_mode，从单主变为多主模式，那么节点中只有最低版本的节点可写，其他节点只读。如果一个节点，其版本是8.0.16或小于8.0.16，它加入到一个组中，如果组里面有节点为5.7版本，那么该节点在加入组后也会变成只读。举个例子：
例一，多主模式：
8.0..0..0.19节点可写，8.0.20只读。
例二，多主模式：
5.7..0..7.21节点可写，8.0.15只读
例三，单主模式切换为多主模式：
8.0.19(Primary)8.0.19(Secondary)8.0.20(Secondary)8.0.21(Secondary)单主模式切换成多主模式完成后，8.0.19节点可写，8.0.20和8.0.21节点只读。
例四，单主模式切换为多主模式：
8.0.14(Secondary)8.0.15(Secondary)8.0.20(Secondary)8.0.21(Primary)8.0.14和8.0.15可写，8.0.20和8.0.21只读。
四、低版本兼容性
从8.0.17版本开始，如果一个节点的版本比组中其他节点的版本都低，那么该节点将不允许加入组。一个5.7的节点，不允许加入到一个全是8.0的组中。一个8.0.16或者低于8.0.16的8.0版本，可以加入到任何组中，因为只考虑主版本。举个例子：
8.0..0..0..0.17或者8.0.18不允许加入到组中。
另一个例子：
8.0..0..7.27版本不允许加入到组中。
五、Donor版本兼容性
MGR中新加入的节点，其在恢复阶段，需要找到一个Donor节点，能成为Donor节点的版本必须满足以下规则：
如果新节点版本大于等于8.0.17，那么Donor节点的版本必须小于等于新加入节点的版本。如果新节点版本小于8.0.17，那么所有的ONLINE状态的节点，都可以成为Donor节点。举个例子：
5.7..0..0.21一个新节点8.0.20，只能使用5.7.22或者8.0.20版本的节点作为其Donor节点。
另外一个例子：
5.7..0..0.21一个新节点5.7.22，能够使用5.7.22或8.0.20或8.0.21作为其Donor节点。
六、升级版本兼容性
单主模式，in-place方式升级，先升级非主节点，最后升级主节点，使用group_replication_set_as_primary函数指定新的主节点。另外一个方法，在升级前，给想要成为新主节点的权重设置大一点，先升级这个权重大的节点，最后升级主节点，那么那个权重大的节点自然会成为新主节点。多主模式，in-place方式升级，节点升级顺序任意。在所有节点都升级完成之前，已经升级到高版本的节点，将变成只读，等到所有节点都升级完成，所有节点才会变成可写。例一，单主模式升级：
M1:8.0.20(oldprimary)M2:8.0.20(newprimary)M3:8.0.20DBA想要把所有节点升级到8.0.21，先把M2的权重设置的高一点，先升级M2，然后依次升级M3，M1，完成之后，M2自动变为新主节点。
例二，单主模式升级：
M1:8.0.20(primary)M2:8.0.20M3:8.0.20DBA想要把所有节点升级到8.0.21，先升级M2，M3，最后升级M1，完成之后，再使用group_replication_set_as_primary把M1设置为主节点。
例三，多主模式升级：
M1:8.0.20M2:8.0.20DBA想要把所有节点升级到8.0.21，先升级M1，这时M1变为只读，再升级M2，当M2升级完成时，所有节点都变为可写。
七、总结：
MySQL8.0.17版本在组复制方面做了较大的改进，尤其是不同版本之间的兼容性，虽然有点复杂，但是更加安全。