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