升級原因 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叢集，這個原因沒有找到。