組複制官方翻譯六、Upgrading Group Replication

https://dev.mysql.com/doc/refman/8.0/en/group-replication-upgrade.html

這個章節主要描述更新MGR的計劃

基本的更新MGR成員的方法基本跟單獨的執行個體更新一樣（可參考 Section 2.11.1, “Upgrading MySQL”）

選擇in-place，還是logical方式更新取決于資料量大小

通常in-place更新會非常的快速，是以也是官方最推薦的

由于MGR是分布式的環境，是以在更新的時候有一些考慮，比如：成員更新的順序問題等

如果你的MGR環境可以允許offline，那麼就參考下列的Group Replication Offline Upgrade 方法

如果你的MGR環境需要在online進行，參考Group Replication Online Upgrade方法（極小的downtime）

18.6.1 Group Replication Offline Upgrade

對一個MGR進行offline更新的時候，你需要将成員從group中分别移除掉，然後更新成員，然後重新開機這個group

在 multi-primary環境下，你可以按照任何順序shutdown組成員

在 single-primary環境下，先shutdown secondary成員節點，最後shutdown primary節點

如何移除成員節點，你可以參考 Section 18.6.2.3, “Upgrading a Group Replication Member”

一點group變成offline，你可以就想更新單獨的執行個體一樣更新他們，參考 Section 2.11.1, “Upgrading MySQL”

所有成員更新完畢後，在重新開機成員

18.6.2 Group Replication Online Upgrade

當你需要線上更新MGR，且不影響你的application，那麼你就需要考慮下自己的方法了

這一節主要描述online更新的一些考慮，方法，和步驟

18.6.2.1 Online Upgrade Considerations

當你需要online更新的時候，需要考慮如下幾個點：

• 不管哪種更新group的方法，對組成員停寫是至關重要的一步，直到它重新加入group
• 當一個組成員stop的時候，super_read_only 會自動設定成on，但是這個改變不會被寫入配置檔案，并不持久
• 當5.7.22或者8.0.11想要加入5.7.21或更低版本的group的時候會失敗，因為5.7.21不會發送lower_case_table_names變量的值

18.6.2.2 Combining Group Replication Versions

不同版本的MySQL組合的GROUP可能會存在着不相容性，這一章主要描述不同組合的最佳實踐

如何檢視版本

SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| member_host | member_port | member_version |
+-------------+-------------+----------------+
| example.com |       3306     |   8.0.13         |
+-------------+-------------+----------------+
           

不同大版本group中的組合成員的規則如下：

• 如果你跑着一個8.0版本的GR，你需要添加一個成員為5.7的，這樣就不行
• 如果你跑着一個5.7版本的GR，你需要添加一個8.0的成員是可以的，它必須保持read-only模式

不同小版本group中的組合成員的規則如下：

• 如果是小版本的之間的差異，是可以的随時加入進來的,且可讀可寫。如果是single-primary group，添加的成員預設是read-only模式

18.6.2.3 Upgrading a Group Replication Member

這一小節主要描述更新組成員版本的基本步驟

這裡面的步驟是Section 18.6.2.4, “Group Replication Online Upgrade Methods”. 提到步驟的一部分

更新組成員版本的步驟包括：将成員移除組，接下來選擇你要更新的方法，然後重新加入更新過成員的group

single-primary模式下的推薦更新方法是： 先更新所有的secondaries，然後再primary節點

更新一個組成員的方法：

• 連接配接一個成員，然後敲 STOP GROUP_REPLICATION. 在此之前，要确認下該成員狀态是offline 通過 replication_group_members 表
• 設定group_replication_start_on_boot=0 防止成員已啟動就自動加入，會有安全隐患（在你還沒upgrade mysql之前就自動加入了 等等情況）
• 使用 mysqladmin shutdown關閉該成員，其他成員繼續保持running
• 使用in-place方式更新該成員，由于你沒有設定group_replication_start_on_boot=1，是以重新啟動更新過的成員時，它不會自動加入MGR
• 一旦你使用mysql_upgrade更新成功後，再将 group_replication_start_on_boot 設定為1，這樣可以確定之後重新開機伺服器的時候可以自動加入進來
• 連結到更新成功過後的該成員，敲 START GROUP_REPLICATION.重新加入group。該server的中繼資料會自動重新配置，且開始追資料，一旦資料追完，它将變成online狀态

當更新成功的成員加入到group中的時候，隻要group中還有早期的的版本成員在，那麼該成員都會自動被設定成 super_read_only=on,不管它是primary還是secondary

這樣可以保證更新後的成員不會有寫，直到所有的版本全部一緻

但是如果是multi-primary模式的group，一旦确認更新成功，這個group就可以處理事務，是以該模式下人工配置哪個可以寫，哪個不可以寫是非常重要的步驟

SET GLOBAL read_only=off;           

18.6.2.4 Group Replication Online Upgrade Methods

• Rolling In-Group Upgrade

對于single-primary的group，一旦所有secondary節點都更新了，然後primary節點從group中移除出去更新的時候，一個新的primary節點會自動被選擇出來

對于multi-primary的group，直到所有成員都被更新了，你才需要手動的給所有成員設定 super_read_only=OFF

對于multi-primary的group，在上述過程中，所有primaries被降級，會降低可用性。但是在single-primary模式中，就不會有影響

• Rolling Migration Upgrade

這個方法就是：你從組成員中移除成員，然後更新，然後用他們建立第二個group

更新過程中，由于新版本的group為了追上老版本group的資料，是以在新版本的group中需要配置成老版本group中的slave角色

對于single-primary的group，該slave的角色，也必須是新版本group的primary角色

對于multi-primary的group，該slave的橘色，可以是任何一個primary角色

方法基本如下：

• 在origin group中一個個的移除成員，參考 Section 18.6.2.3, “Upgrading a Group Replication Member”
• 更新成員的版本 ， 參考 Section 2.11.1, “Upgrading MySQL”.
• 使用更新過的成員，建立一個新的group。你需要配置一個新的group name，因為老的name還在運作。
• 建立一個異步複制通道在新老group中。老的group的priamry作為master，新的group成員作為GTID-based slave

在你切換應用之前，你必須確定你的新的group有比較合适的成員數量

敲SELECT * FROM performance_schema.replication_group_members來比對新老成員數量大小

最後，如果資料都同步完了，那麼就可以停止複制，切換應用了

• Rolling Duplication Upgrade

這個方法主要描述的是，如果在不減少原來group數量的同時，建構新group

因為很多時候，multi-primary都在提供業務，是不允許減少節點的

該處理方法是：

• 部署合适數量成員的新group
• 對老group的成員進行備份
• 使用這個備份進行更新，參考 Section 18.6.2.5, “Group Replication Upgrade with mysqlbackup”
• 使用更新好server進行建構一個新的group

一旦新老group直接的資料差異越來越小，小到很快就能追上，那麼就可以重新指向業務application

18.6.2.5 Group Replication Upgrade with mysqlbackup

步驟如下：

• 使用mysqlbackup來備份老group的成員
• 部署一個跟備份一樣版本的成員執行個體
• 使用mysqlbackup來恢複一個新成員執行個體
• 在新執行個體上更新