MySQL 9.0 版本資訊
當群組複製的分散式復原程序正在執行二進位日誌的狀態傳輸時，為了使加入的成員與捐贈者同步到特定的時間點，加入的成員和捐贈者會使用 GTID（請參閱第 19.1.3 節「使用全域交易識別碼進行複製」）。不過，GTID 僅提供一種方法來實現加入成員遺失哪些交易。它們沒有幫助標記伺服器加入群組必須趕上的特定時間點，也沒有傳達驗證資訊。這是二進位日誌檢視標記的工作，它會標記二進位日誌串流中的檢視變更，並包含其他中繼資料資訊，為加入的成員提供遺失的與驗證相關的資料。
本主題說明檢視變更和檢視變更識別碼的角色，以及從二進位日誌執行狀態傳輸的步驟。
檢視對應於目前組態中積極參與的成員群組，換句話說，在特定的時間點。它們在群組中正常運作且在線上。
當群組組態發生修改時，例如成員加入或離開，就會發生檢視變更。任何群組成員資格變更都會導致獨立的檢視變更，在相同的邏輯時間點傳達給所有成員。
檢視識別碼會唯一識別檢視。它會在發生檢視變更時產生。
在群組通訊層級，檢視變更及其相關的檢視識別碼會標示成員加入前後交換的資料之間的界限。此概念是透過二進位日誌事件來實作：「檢視變更日誌事件」(VCLE)。記錄檢視識別碼以劃分在群組成員資格中發生變更之前和之後傳輸的交易。
檢視識別碼本身由兩個部分組成：一個隨機產生的部分，以及一個單調遞增的整數。隨機產生的部分會在建立群組時產生，並且在群組中至少有一個成員時保持不變。每次發生檢視變更時，整數都會遞增。使用這兩個不同的部分，可以讓檢視識別碼識別由成員加入或離開所造成的增量群組變更，並識別所有成員在完整群組關閉時離開群組的情況，因此不會保留群組處於哪個檢視的資訊。從頭開始啟動群組時隨機產生識別碼的一部分，可確保二進位日誌中的資料標記保持唯一，並且在完整群組關閉後不會重複使用相同的識別碼，因為這會在未來導致分散式復原的問題。
每當新成員加入群組，因此執行檢視變更時，每個線上伺服器都會將檢視變更日誌事件排入佇列以供執行。之所以排入佇列，是因為在檢視變更之前，可以在伺服器上排隊數個交易以供套用，因此，這些交易屬於舊檢視。在它們之後將檢視變更事件排入佇列，可保證正確標記此情況發生時的時間點。
同時，加入的成員會透過視圖抽象化，從成員服務所列出的線上伺服器列表中選擇一個合適的捐贈者。成員加入視圖 4，線上成員會將視圖變更事件寫入二進制日誌。
如果群組成員和加入的成員都設定了 clone 外掛程式（請參閱第 20.5.4.2 節「用於分散式復原的複製」），並且加入成員與群組之間的交易差異超過了遠端複製操作的閾值（group_replication_clone_threshold），則 Group Replication 會以遠端複製操作開始分散式復原。如果任何群組成員的二進制日誌檔案中不再存在所需的交易，也會執行遠端複製操作。在遠端複製操作期間，會移除加入成員上的現有資料，並以捐贈者的資料副本取代。當遠端複製操作完成且加入成員重新啟動後，會執行來自捐贈者二進制日誌的狀態傳輸，以取得在遠端複製操作進行時群組所套用的交易。如果交易間隔不大，或者如果未安裝 clone 外掛程式，則 Group Replication 會直接從捐贈者的二進制日誌進行狀態傳輸。
對於來自捐贈者二進制日誌的狀態傳輸，會在加入成員和捐贈者之間建立連線，並開始狀態傳輸。與捐贈者的這種互動會持續進行，直到加入群組的伺服器應用程式執行緒處理了對應於伺服器加入群組時觸發的視圖變更的視圖變更日誌事件。換句話說，加入群組的伺服器會從捐贈者複製，直到它到達與其已經存在的視圖標記相符的視圖識別碼標記為止。
由於視圖識別碼會在相同的邏輯時間傳輸給群組中的所有成員，因此加入群組的伺服器知道應該在哪個視圖識別碼停止複製。這避免了複雜的 GTID 集計算，因為視圖識別碼清楚地標記了哪些資料屬於每個群組視圖。
當加入群組的伺服器從捐贈者複製時，它也會快取來自群組的傳入交易。最終，它會停止從捐贈者複製，並切換為套用快取的交易。
當加入群組的伺服器識別出具有預期視圖識別碼的視圖變更日誌事件時，會終止與捐贈者的連線，並開始套用快取的交易。儘管它在二進制日誌中充當標記，劃分視圖變更，但視圖變更日誌事件也扮演另一個角色。它傳達了當加入群組的伺服器進入群組時，所有伺服器所感知到的認證資訊，也就是最後一次的視圖變更。如果沒有它，加入群組的伺服器將沒有必要的資訊來認證（偵測衝突）後續交易。
趕上進度的持續時間不是確定的，因為它取決於工作負載和傳入群組的交易速率。此過程是完全在線的，並且加入群組的伺服器在趕上進度的同時不會封鎖群組中的任何其他伺服器。因此，加入群組的伺服器在進入此階段時落後的交易數量可能會因此而有所不同，並根據工作負載而增加或減少。
當加入群組的伺服器達到零個已佇列交易，並且其儲存的資料與其他成員相同時，其公開狀態會變更為線上。
