只要執行較新版本的伺服器在群組中仍有較舊版本的伺服器時，不會對群組產生工作負載，就支援此方法。換句話說，執行較新版本的伺服器只能以次要身分加入群組。在此方法中，只會有一個群組，而且每個伺服器執行個體都會從群組中移除、升級，然後重新加入群組。

此方法非常適合單主群組。當群組在單主模式下運作時，如果您需要主伺服器在整個過程中保持不變（除非主伺服器本身正在升級），則它應該是最後一個升級的成員。除非主伺服器在群組中執行最低的 MySQL 伺服器版本，否則它無法保持為主伺服器。升級主伺服器後，您可以使用 group_replication_set_as_primary() 函數重新指定其為主伺服器。如果您不介意哪個成員是主伺服器，則可以依照任何順序升級成員。群組會在必要時，從執行最低 MySQL 伺服器版本的成員中選出新的主伺服器，並遵循 第 20.1.3.1 節，「單主模式」中所述的選取原則。

對於在多主模式下運作的群組，在群組內滾動升級期間，主伺服器的數量會減少，導致寫入可用性降低。這是因為如果成員加入群組時，其執行的 MySQL 伺服器版本高於現有群組成員執行的最低版本，則它會自動保持在唯讀模式 (super_read_only=ON)。

如需群組中版本相容性的完整資訊，以及這在升級過程中如何影響群組的行為，請參閱 第 20.8.1 節，「在群組中結合不同的成員版本」。

在此方法中，您會從群組中移除成員、升級它們，然後使用升級後的成員建立第二個群組。對於在多主模式下運作的群組，在此過程中，主伺服器的數量會減少，導致寫入可用性降低。這不會影響在單主模式下運作的群組。

因為在您升級成員時，執行較舊版本的群組在線上，所以您需要執行較新版本的群組來趕上在升級成員時執行的任何交易。因此，新群組中的其中一個伺服器會設定為較舊群組中主伺服器的複本。這可確保新群組趕上較舊群組。由於此方法依賴用於將資料從一個群組複寫到另一個群組的非同步複寫通道，因此它在非同步來源複本複寫的相同假設和需求下受到支援，請參閱 第 19 章，《複寫》。對於在單主模式下運作的群組，與舊群組的非同步複寫連線必須將資料傳送至新群組中的主伺服器，對於多主群組，非同步複寫通道可以連線到任何主伺服器。

流程如下

在將應用程式重新導向至新群組之前，您必須確保新群組具有適當數量的成員，例如，以便群組可以處理成員的故障。發出 SELECT * FROM performance_schema.replication_group_members 並比較初始群組大小和新群組大小。等待直到舊群組的所有資料都傳播到新群組，然後捨棄非同步複寫連線並升級任何遺失的成員。

在此方法中，您會建立第二個群組，其中包含執行較新版本的成員，並且將舊群組中遺失的資料複寫到較新的群組。這假設您有足夠的伺服器可以同時執行兩個群組。由於在此過程中，主要節點的數量並未減少，因此對於以多主要模式運作的群組而言，寫入可用性不會降低。這使得滾動複製升級非常適合以多主要模式運作的群組。這不會影響以單一主要模式運作的群組。

由於執行舊版本的群組在您佈建新群組中的成員時仍然在線，因此您需要讓執行較新版本的群組趕上在佈建成員時執行的任何交易。因此，新群組中的其中一台伺服器會被設定為舊群組中主要節點的複本。這確保新群組趕上舊群組。由於此方法依賴於非同步複寫通道來將資料從一個群組複寫到另一個群組，因此它在與非同步來源-複本複寫相同的假設和要求下受到支援，請參閱第 19 章，複寫。對於以單一主要模式運作的群組，與舊群組的非同步複寫連線必須將資料傳送到新群組中的主要節點；對於多主要群組，非同步複寫通道可以連接到任何主要節點。

流程如下

一旦從較新群組遺失的持續資料小到足以快速傳輸時，您必須將寫入操作重新導向到新群組。等待直到舊群組的所有資料都傳播到新群組，然後丟棄非同步複寫連線。