升级原因     5.7版本的MGR多主模式存在比较严重的问题，无法预知和监控的认证故障，会导致部分行数据无法修改，故急需升级至8.0   升级流程     原集群有5个节点，首先扩容一个5.7.24的节点，将其升级为8.0.20的实例（注意参数的变化，如果数据量比较小，可以采用导出导入的方式，由于mysql8升级非常方便，内部会自动执行upgrade），然后将8.0.20的节点加入原集群，START GROUP_REPLICATION未报错， SELECT * FROM performance_schema.replication_group_members;查看状态正在recovering。如下图所示， 从图中可以看到 相对于5.7.24版本多了 member_role 和 member_version列，在5.7.24实例上看还是没有这两列的。   等待同步完成。。。。。   同步完成后，所有的6个节点都是online状态，此时将8.0.20的节点上线，用于测试是否有可以正常提供服务（此处应当先测试，由于是内部集群直接上线了，不该如此） 一段时间后，业务的提案操作偶发报错， 报错如下： update table_attribute error: update table_attribute set table_has_no_partition = 'system_approved' where id= 196853 (1290, 'The MySQL server is running with the --super-read-only option so it cannot execute this statement') 看这个报错里出现了 super-read-only ，印象里mgr的节点退出集群时会将自己置为 super-read-only，这是为了防止有写入导致数据不一致，所以猜测时8.0.20的节点有问题导致自动退出集群将自己置为super-read-only 查询报警后没有找到mgr的报警，于是去线上看参数，发现8.0,20的super-read-only确实是on，看来问题找到了。 但是这里不确定是为何为on，所以没有做任何修改，以免破坏现场，先将问题节点下线，解决问题，然后查看该节点的error log，如果是由于故障退出集群error能看到信息，但是error log中没有输出。 于是推测是由于节点加入集群是就是super-read-only状态，这可能是8.0.20的新特性。确认没有报错后，将super-read-only置为off。 为了进行对比，将5.7.24节点STOP GROUP_REPLICATION && START GROUP_REPLICATION;想看看super-read-only参数会变化么，结果发现根本无法加入集群，error log中的报错如下  

 
2021-06-29T15:25:10.833093+08:00 0 [Note] Plugin group_replication reported: 'XCom protocol version: 3'
2021-06-29T15:25:10.833123+08:00 0 [Note] Plugin group_replication reported: 'XCom initialized and ready to accept incoming connections on port 15562'
2021-06-29T15:25:13.088685+08:00 58520294 [Note] Aborted connection 58520294 to db: 'unconnected' user: 'mysqlha_common' host: '10.73.9.73' (Got an error reading communication packets)
2021-06-29T15:25:13.480498+08:00 0 [ERROR] Plugin group_replication reported: 'Member version is incompatible with the group'
2021-06-29T15:25:13.480555+08:00 0 [Note] Plugin group_replication reported: 'Group membership changed to 10.190.1.78:5562, 10.182.1.236:5562, 10.185.1.129:5562, 10.41.14.184:5562, 10.13.43.33:5562, 10.41.23.21:5562 on view 16238265148777711:20.'
2021-06-29T15:25:13.480558+08:00 58517616 [Note] Plugin group_replication reported: 'Going to wait for view modification'
2021-06-29T15:25:13.480566+08:00 0 [ERROR] Plugin group_replication reported: 'Message received while the plugin is not ready, message discarded'
2021-06-29T15:25:13.480585+08:00 0 [ERROR] Plugin group_replication reported: 'Message received while the plugin is not ready, message discarded'
2021-06-29T15:25:13.480591+08:00 0 [ERROR] Plugin group_replication reported: 'Message received while the plugin is not ready, message discarded'
2021-06-29T15:25:13.480596+08:00 0 [ERROR] Plugin group_replication reported: 'Message received while the plugin is not ready, message discarded'
2021-06-29T15:25:13.480601+08:00 0 [ERROR] Plugin group_replication reported: 'Message received while the plugin is not ready, message discarded'

  通过报错信息[ERROR] Plugin group_replication reported: 'Member version is incompatible with the group 合理猜测是由于版本问题，猜测高版本节点可以加入低版本集群，低版本节点不可加入高版本集群（取最高版本）。   下面结合官方文档和腾讯云博客（https://cloud.tencent.com/developer/article/1444077）描述下mgr 5.7.24升级为8.0.20的过程以及注意点。   1，首先在8.0.16版本之后，mgr集群存在通信协议的概念，可以直接管理MGR通信协议版本，并将其设置为适应你希望MGR成员支持的哪个MySQL服务器版本。从而实现同一个MGR可用组中可以由不同MySQL服务器版本的成员组成。这也是我们可以进行在线的滚动升级的基础。 　　1. group_replication_get_communication_protocol 用于获取该MGR成员中最早的MySQL版本的通信协议 　　2. group_replication_set_communication_protocol 需要更改MGR的通信协议版本以便早期版本的成员可以加入，需要具有GROUP_REPLICATION_ADMIN 权限哦   这是在不同版本的节点上看通信协议的结果，首先5.7.24不支持这个命令，显然这个是8.0.16新增的功能，其次在8.0.20节点上的支持协议版本是5.7.14，是个很早的版本，这意味这个8.0.20最低可以加入5.7.14版本的MGR集群。那是否意味这5.7.14节点可以加入8.0.20的集群呢，不行，5.7.24都不能直接加入8.0.20集群。 将复制组的所有成员升级到新版本后，通信协议版本不会自动升级，以防仍然需要允许早期版本的成员加入。如果不需要支持老版本，升级后可以使用 group_replication_set_communication_protocol() 功能升级通讯协议。   mgr单主模式的升级很简单，类似主从架构升级，先滚动升级从节点，然后切换主，再升级主节点 mgr多主模式升级有些要注意的事， 1，高版本的节点加入集群后会自动变成只读（ super-read-only），在8.0.17版本之后，等集群里的节点都升级后，所有节点会自动取消只读模式，8.0.17版本一下就需要手动改参数了。由于我们的集群读写量比较大，为了均摊流量，每升级一个节点，都主动改下参数。 2，紧急情况下 可以使用 group_replication_allow_local_lower_version_join参数将低于最低版本的节点加入集群，无视兼容性，无保护，慎用~ 3，MySQL 5.7.22 或 MySQL 8.0.11 尝试加入运行 MySQL 5.7.21 或更低版本的集群时，无法加入，因为 MySQL 5.7.21 没有lower_case_table_names. 4，mgr集群内的通信协议版本必须一致，即使版本不同，也应该使用所有节点能理解的信息 5，为什么低版本不能加入高版本集群（通信协议满足的条件下），比如5.7.24无法加入只有一个8.0.20节点的5.7.24集群，这个原因没有找到。