每當一個MySQLserver新加入或重新加入一個MGR叢集時，它都必須追平叢集內相差的事務，保證這個節點的資料和叢集內最新的資料是同步的。這個新加入叢集的節點在追平叢集中的資料或重新加入叢集的節點追評它脫離叢集後到現在這段時間內相差的事務資料的過程稱為分散式復原。
申請加入叢集的節點先檢查groupreplicationapplier通道中的中繼日誌，檢查該節點目前尚未從叢集中同步過來的交易資料。如果是重新加入叢集的節點，則該節點會找到在離開叢集後到現在和叢集最新資料中未回放的事務數據，在這種情況下，該節點首先會應用這些未同步的事務。對於新加入叢集的節點，直接從一個引導節點上進行全量資料復原即可。
此後，新加入的節點和叢集中現有的online狀態的節點（引導節點）建立連線進行狀態轉移。新加入的節點從叢集中的引導節點中同步加入叢集之前或離開叢集後到現在未同步過來的數據，這些相差的事務由叢集中的引導節點提供。接下來，新加入的節點應用從叢集中的引導節點同步過來的未進行應用的事務。此時申請加入叢集的節點將套用在狀態傳輸過程中叢集內新事務寫入的資料。 （此時叢集內新事物寫入的資料暫時存放在快取佇列中，並未將資料寫入磁碟）完成此程序後，新加入的節點的資料和整個叢集的資料相比，處於一個追平的狀態，並且該節點設定為online狀態。
注意：新加入叢集的節點，不論是之前有沒有在此叢集中，都會先隨機選一個online節點先同步該節點和叢集相差的事務。
群組複製在分散式復原期間以下述方法實現狀態傳輸：
使用複製外掛程式的功能進行遠端複製操作，該外掛程式可從MySQL 8.0.17開始支援。要使用這種方法，必須在引導節點和新加入的節點上提前安裝克隆插件。群組複製會自動配置所需的克隆插件設置，並管理遠端克隆操作。
從引導節點的二進位日誌複製資料並在新加入的節點上套用這些交易。此方法需要在引導節點和加入節點之間建立的名為groupreplicationrecovery的標準非同步複製通道。
在加入節點上執行STARTGROUP_REPLICATION後，群組複製會自動選擇上述方法的最佳組合進行狀態轉移。為此，群組複製將會檢查叢集中哪些現有節點適合用作引導節點，加入節點需要引導節點傳輸多少事務，以及是否有事務不再存在於叢集中任意節點的二進位日誌檔案中。如果加入節點與引導節點之間的交易差距很大，或者如果某些要求的事務不在引導節點的二進位日誌檔案中，則群組複製將透過遠端複製作業開始分散式復原。如果沒有較大的交易間隙，或未安裝複製插件，則群組複製將直接從引導節點的二進位日誌進行狀態轉移。
在遠端複製作業期間，將刪除加入節點上的現有數據，並以引導節點資料的副本取代。當遠端複製作業完成且新加入節點已重新啟動時，將繼續執行來自引導節點二進位日誌來進行狀態轉移，以取得在進行遠端複製操作時叢集所寫入的增量資料。
在從引導節點的二進位日誌進行狀態轉移期間，新加入節點從引導節點的二進位日誌複製並套用所需的事務，並在收到交易時套用事務，直到二進位日誌記錄新加入節點加入了叢集。 （當加入節點成功加入叢集時，二進位日誌中會記錄對應的檢視變更event）在此過程中，加入節點將緩衝該叢集應用程式的新交易資料。從二進位日誌的狀態傳輸完成後，新加入節點將會套用緩衝的交易。
當加入節點與該集群的所有事務保持最新時，該節點將在設定為online狀態並可以作為普通節點加入集群，並且分佈式恢復已完成。
ps：從二進位日誌進行狀態轉移是群組複製進行分散式復原的基本機制，並且如果未將複製群組中的引導節點和加入節點設定為支援複製。由於從二進位日誌進行狀態轉移是基於經典的非同步複製，因此，如果加入該叢集的MySQL server根本沒有該叢集的數據，或者從非常舊的備份中獲取了數據，則可能要花費很長時間來恢復最新數據。因此，在這種情況下，建議在將MySQL server新增至叢集之前，則應透過傳輸叢集中已有節點的相當近期的快照來使用叢集的資料對其進行設定。這可以最大程度地減少分散式復原所需的時間，並減少對引導節點的影響，因為引導節點必須保留和傳輸較少的二進位日誌檔案。
當加入節點連接到現有節點中的引導節點進行分散式復原期間的狀態轉移時，加入節點充當客戶端，而引導節點充當服務端。當透過此連線（使用非同步複製通道groupreplicationrecovery）從引導節點的二進位日誌進行狀態轉移時，加入節點充當副本，引導節點充當來源端。透過此連接進行遠端克隆操作時，新加入節點充當全量資料接收者，引導節點充當全量資料提供者。應用於群組複製上下文之外的角色的配置設定也可以應用於群組複製，除非它們被特定於群組複製的配置設定或行為所覆蓋。
現有節點提供給新加入節點以進行分散式復原的連接與群組複製用於叢集內節點之間的通訊的連接是不同的。
群組通訊引擎用於群組複製（XCom，Paxos變體），用於遠端XCom實例之間的TCP通訊的連線由groupreplicationlocal_address系統變數指定。此連線用於叢集內online節點之間的TCP / IP訊息傳遞。與本地實例的通訊是透過使用記憶體內共享的傳輸通道進行的。
對於分散式恢復，直到MySQL8.0.20為止，叢集內的節點都將其標準SQL用戶端連線提供給加入節點，這由MySQL Server的主機名稱和連接埠系統變數指定。如果report_port系統變數指定了備用連接埠號，則改用該連接埠號碼。
從MySQL 8.0.21開始，群組成員可以將分散式復原端點的替代清單作為加入成員的專用客戶端連接，從而使得獨立於成員的常規客戶端使用者的連接可以用來控制分佈式恢復。可以使用groupreplicationadvertiserecoveryendpoints系統變數來指定此列表，並且成員在加入群組時將其分散式恢復端點的列表傳輸到該群組。預設值為成員繼續提供與早期版本相同的標準SQL客戶端連線。
PS：
如果加入節點無法使用MySQLServer的系統變數定義的主機名稱正確識別其他節點，則分散式復原可能會失敗。建議執行MySQL的作業系統使用DNS或本機設定具有正確配置的唯一主機名稱。可以在「performanceschema」庫下的Replicationgroupmembers表的Memberhost欄位中驗證server用於SQL客戶端連線的主機名稱。如果多個群組成員將作業系統設定的預設主機名稱外部化，則加入節點有可能無法解析為正確的位址，且無法連線以進行分散式復原。在這種情況下，可以使用MySQL Server的report_host系統變數來配置由每個server外部化的唯一主機名稱。
加入節點為分散式復原建立連線的步驟如下：
當節點加入叢集時，它會使用groupreplicationgroupseeds系統變數中清單中包含的種子節點進行連接，最初使用該清單中指定的groupreplicationlocaladdress連接。種子節點可能是叢集資料的子集。
透過此連接，種子節點使用群組複製的成員資格服務以視圖的形式向加入的節點提供叢集中所有online節點的清單。成員資格資訊包括每個成員為分散式復原提供的分散式復原端點或標準SQL用戶端連線的詳細資訊。
加入節點從此列表中選擇合適的online節點作為其引導節點進行分佈式恢復
加入節點嘗試使用引導節點的分佈式恢復端點來連接到引導節點，並按列表中指定的順序依序嘗試連接每個端點。如果引導節點沒有提供端點，則加入節點將嘗試使用引導節點的標準SQL用戶端連線進行連線。連線的SSL要求由groupreplicationrecoveryssl *選項指定。
如果加入節點無法連接到指定的引導節點，則它將與其他適當的引導節點重試連接。如果加入節點在沒有建立連接的情況下耗盡了端點的廣播列表，則它不會回退到引導節點的標準SQL用戶端連接，而是切換到另一個引導節點嘗試重新建立連接。
加入節點與引導節點建立分散式復原連線時，它將使用該連線進行狀態轉移，加入節點的日誌中顯示了所使用的連線的主機和連接埠。如果使用遠端複製操作，則在操作結束時重新啟動加入節點時，它將與新的引導節點建立連接，從引導節點的二進位日誌進行狀態轉移。這可能是與用於遠端克隆操作的引導節點不同的連接，也可能是與引導節點建立相同的連接。無論如何，分散式復原將以相同的方式與引導節點建立連線。
groupreplicationadvertiserecoveryendpoints系統變數作為分散式復原端提供的IP位址，不必為MySQL Server配置（也就是說，不必由adminaddress系統變數或在bindaddress系統變數的清單中指定）。
為MySQL Server配置為分散式復原端提供的端口，必須由port，reportport或adminport系統變數指定。必須在這些連接埠上偵聽TCP / IP連線。如果指定adminport，則用於分散式復原的複製使用者需要SERVICECONNECTIONADMIN權限才能連線。選擇adminport可使分散式恢復連線與常規MySQL客戶端連線分開。
加入節點依清單中指定的順序依序嘗試每個端點。如果將groupreplicationadvertiserecoveryendpoints設定為DEFAULT而不是端點列表，則將提供標準SQL用戶端連線。標準SQL用戶端連線不會自動包含在分散式復原端點清單中，並且如果引導節點的端點清單在沒有連線的情況下被用盡，則不會將其作為備用。如果要提供標準SQL用戶端連線作為多個分散式復原端點之一，則必須將其明確納入groupreplicationadvertiseadvertiserecovery_endpoints指定的清單中。可以將其放在最後，以便作為連接的最後手段。
無需將群組成員的分散式復原終點（或標準SQL客戶端連接，如果未提供終點）新增至groupreplicationipallowlist（來自MySQL 8.0.22）或groupreplicationipwhitelist系統變數指定的群組複製允許清單中。許可證清單僅適用於由groupreplicationlocal_address為每個節點指定的位址。加入節點必須具有與允許清單允許的叢集的初始連接，以便檢索一個或多個位址進行分散式復原。
設定係統變數和執行STARTGROUP_REPLICATION語句後，將驗證列出的分散式復原端點。如果無法正確解析列表，或者由於服務未在偵聽列表而無法在主機上存取任何端點，則群組複製將記錄錯誤並且無法啟動。
在MySQL 8.0.18中，可以選擇使用引導節點二進位日誌中的狀態轉移方法為分散式復原配置壓縮。在網路頻寬有限的情況下，壓縮可以使分散式復原受益，而引導節點必須將許多交易傳輸給加入節點。 groupreplicationrecoverycompressionalgorithm和groupreplicationrecoveryzstdcompression_level系統變數配置允許的壓縮演算法以及zstd壓縮級別，這些等級用於從引導節點的二進位日誌執行狀態轉移時使用。
這些壓縮設定不適用於遠端複製操作。當遠端複製操作用於分散式復原時，將套用複製插件的cloneenablecompression設定。
分散式復原需要具有正確權限的複製用戶，以便群組複製可以建立直接的節點到節點的複製通道。複製用戶還必須具有正確的權限，如果該複製用戶也同充當遠端克隆操作中的克隆用戶，則在引導節點中該複製用戶還必須具有遠端克隆相關的權限（BACKUP_ADMIN權限）才能充當引導節點上的克隆使用者以進行遠端克隆操作。除此之外，必須將相同複製使用者用於叢集內每個節點上的分散式復原。
用於分散式復原的SSL與用於普通群組通訊的SSL分開配置，這由server的SSL設定和groupreplicationssl_mode系統變數決定。對於分散式恢復連接，可以使用專用的群組複製分散式恢復SSL系統變數來配置專門用於分散式恢復的憑證和金鑰的使用。
預設情況下，SSL不用於分散式恢復連線。設定groupreplicationrecoveryusessl= ON啟用，然後設定群組複製分散式恢復SSL系統變量，將複製使用者設定為使用SSL。
將分散式復原配置為使用SSL時，群組複製會將此設定應用於遠端複製操作以及從引導節點的二進位日誌進行狀態轉移。群組複製會自動設定複製SSL選項（clonesslca，clonesslcert和clonesslkey），以符合對應群組複製分散式復原選項（groupreplicationrecoverysslca，groupreplicationrecoverysslcert和groupreplicationrecoverysslkey）的設定。
如果未使用SSL進行分散式復原（groupreplicationrecoveryusessl設定為OFF），且群組複製的複製使用者帳戶使用cachingsha2password外掛程式（MySQL 8.0中的預設設定）或sha256password外掛程式進行驗證，則可按鍵對為用於密碼交換。在這種情況下，使用groupreplicationrecoverypublickeypath系統變數指定RSA公用金鑰文件，或使用groupreplicationrecoverygetpublic_key系統變數請求公用金鑰。否則整個分散式回復會因為報錯導致恢復失敗。
MySQLServer的複製外掛程式可從MySQL8.0.17取得。如果要將遠端克隆作業用於叢集中的分散式恢復，則必須預先設定現有節點和加入節點才能支援此功能。如果不想在叢集中使用此功能，請不要進行設置，在這種情況下，群組複製僅使用二進位日誌中的狀態傳輸。
要使用克隆插件，必須預先設定至少一個現有的叢集節點和加入節點支援遠端克隆操作。至少，必須在引導節點和加入節點上安裝複製插件，將BACKUPADMIN權限授予複製使用者以進行分散式恢復，並將groupreplicationclonethreshold系統變數設定為適當的層級。 （預設為GTID序列允許的最大值，表示正常情況下，始終優先使用基於二進位日誌的狀態傳輸，除非joiner節點所要求的事務在群組中任意成員中都不存在，這個時候，如果設定好了克隆功能，則無論該系統變數的值設定為多少，都會觸發透過複製的方式進行分散式恢復，例如：全新初始化的Server申請加入群組時。如果不希望使用複製功能，則不要對其進行安裝與配置）為了確保引導節點的最大可用性，建議設定所有當前和將來的叢集節點支援遠端克隆操作。以便後續有Server加入叢集時能夠使用遠端克隆操作來快速追趕叢集中的最新資料。
在從引導節點傳送資料到加入節點之前，遠端複製操作會刪除加入節點中使用者建立的表空間和資料。如果在中途意外終止操作，則加入節點可能只剩下部分資料或沒有資料。可以透過重新執行群組複製自動執行的遠端克隆操作來修復此問題。
這裡主要針對遠端複製時使用DATADIRECTORY子選項指定了一個資料保存路徑的情況，指定路徑時，資料會保存在指定的目錄下，即克隆之後的資料與操作克隆的實例沒有關聯，需要手動啟動實例並指定datadir到保存克隆資料的目錄進行啟動，當然，MGR插件可以自動執行遠端克隆的重試操作（需要保證克隆操作不指定DATA DIRECTORY子選項，在這種情況下，遠端克隆數據會覆寫操作遠端複製的Server數據，完成遠端克隆操之後，操作遠端複製的Server會基於複製數據自動重新啟動）。另外，克隆插件雖然與群組複製配合使用對群組複製的管理維護來說更加自動化，但是，克隆插件不要求必須在叢集中運行（但MGR插件必須安裝）。
對於群組複製，使用複製外掛程式進行分散式復原需要注意以下要點和差異：
現有集群節點和加入節點必須已安裝克隆插件並處於啟動狀態。
引導節點和加入節點必須在相同的作業系統上執行，並且必須具有相同的MySQL Server版本（必須為MySQL 8.0.17或更高版本才能支援複製外掛程式）。因此，克隆不適用於成員運行不同MySQL版本的叢集。
引導節點和加入節點必須已安裝並啟動了「群組複製」插件，引導節點上所有啟動的其他插件（例如，金鑰環插件）也必須在加入節點上處於啟動狀態。
如果將分散式復原配置為使用SSL（groupreplicationrecoveryusessl= ON），則群組複製會將此設定套用於遠端複製作業。群組複製會自動配置複製SSL選項（clonesslca，clonesslcert和clonesslkey）的設置，以匹配對應群組複製分散式復原選項（groupreplicationrecoverysslca，groupreplicationrecoverysslcert和groupreplicationrecoverysslkey）的設定。
不需要在加入節點上為加入叢集而在clonevaliddonor_list系統變數中設定有效引導節點清單。 MGR自動從現有的叢集節點中選擇引導節點後，群組複製會自動配置此設定。注意，遠端複製操作使用server的SQL協定主機名稱和端口，而非叢集成員之間內部通訊的位址和連接埠。
克隆外掛程式具有許多系統變量，可管理遠端克隆操作的網路負載和效能影響。群組複製未配置這些設置，因此可以查看它們並根據需要進行設置，也可以將其設置為預設設置，當使用遠端克隆操作進行分散式恢復時，克隆插件的cloneenablecompression設定將應用於該操作，而不會影響現有配置好的群組複製壓縮設定。
為了對加入節點呼叫遠端複製操作，群組複製使用內部mysql.session用戶，該用戶已經具有CLONE_ADMIN特權，因此無需進行特別設定。
作為遠端複製操作的引導節點上的克隆用戶，群組複製使用為分散式復原設定的複製用戶。因此，必須在所有支援克隆的叢集節點上將此複製使用者賦予BACKUP_ADMIN特權。在為節點配置群組複製時，如果有加入節點，也應向該節點上的複製使用者授予此權限，因為加入節點加入叢集後，他們可以充當其他加入節點的引導節點。同一複製使用者用於每個叢集節點上的分散式復原。若要將此權限授予現有節點上的複製用戶，可以在停用二進位日誌記錄的情況下在每個叢集節點上單獨執行此語句，或在啟用二進位日誌記錄的情況下在一個叢集的primary節點上執行如下語句：
GRANT BACKUP_ADMIN ON *.* TO *rpl_user*@'%';
如果在使用STARTGROUPREPLICATION以前在提供使用者憑證的server上使用CHANGE MASTER TO指定複製使用者憑證，請確保在進行任何遠端複製操作之前，從複製元資料儲存庫中刪除該使用者憑證。也要確保在加入成員上設定了groupreplicationstartonboot =OFF。如果未取消設定使用者憑證，則在遠端複製操作期間會將它們轉移到加入成員。然後，可能會在原始成員或從其複製的成員上意外地使用儲存的憑證啟動groupreplicationrecovery通道。 server啟動時（包括在遠端複製操作之後）自動啟動群組複製將使用儲存的使用者憑證，並且如果未在START GROUPREPLICATION指令上指定分散式復原憑證，也將使用它們。
設定群組成員支援複製後，groupreplicationclonethreshold系統變數將指定一個閾值，表示為多少個事務，以便在分散式復原中使用遠端複製操作。如果引導節點上的交易與加入節點上的交易之間的數量大於此數目，則在技術上可行時，將使用遠端複製操作將狀態轉移到加入節點。群組複製基於現有群組成員的gtidexecuted集來計算是否已超過閾值。在交易間隙較大的情況下使用遠端克隆操作，可以將新成員新增至叢集中，而無需事先將叢集的資料手動傳輸到伺服器，還可以使落後的節點更有效地進行資料追趕。
groupreplicationclone_threshold群組複製系統變數的預設設定非常高（GTID中交易的最大允許序號），因此，只要有可能從二進位日誌轉移狀態，它都會有效地停用複製。若要使群組複製能夠選擇更適合狀態傳輸的遠端複製操作，設定係統變量，以指定多少個交易作為要進行複製的交易間隔。
PS：
不要在活躍的叢集中為groupreplicationclone_threshold使用較低的設定。如果在進行遠端複製操作的同時叢集中發生了超過閾值的事務，則加入成員在重新啟動後會再次觸發遠端複製操作，並且可以無限期地繼續進行。為避免這種情況，請確保將閾值設為一個可靠的數字，該閾值應大於在遠端克隆操作所花費的時間段內集群中預期發生的事務數。
當無法從引導節點的二進位日誌進行狀態轉移時，群組複製嘗試執行遠端複製操作，而不管此時的閾值如何，例如，因為加入成員所需的交易在任何現有群組成員的二進位日誌中均不可用。群組複製基於現有群組成員的gtidpurged集對此進行識別。當所需的交易在任何成員的二進位日誌檔案中不可用時，不能使用groupreplicationclonethreshold系統變數來停用克隆，因為在這種情況下，克隆是手動將資料傳輸到加入節點的唯一選項
設定叢集節點和加入節點進行複製後，群組複製將管理遠端複製作業。遠端克隆操作需要一些時間才能完成，具體取決於資料的大小。
performanceschema.cloneprogress表中記錄了整個克隆操作的每一個階段及其對應的階段信息，每一個階段會產生一行記錄（注意，該表中只記錄一次克隆操作的過程信息，下一次執行複製操作時，上一次的資訊會被覆寫）
select * from clone_progress; +------+-----------+-----------+---------------------------- +----------------------------+---------+------------+-------- ----+------------+------------+---------------+ | ID | STAGE | STATE | BEGIN_TIME | END_TIME | THREADS | ESTIMATE | DATA | NETWORK | DATA_SPEED | NETWORK_SPEED | +------+-----------+-----------+---------------------------- +----------------------------+---------+------------+------- -----+------------+------------+---------------+ | 1 | DROP DATA | Completed | 2019-10-08 16:46:58.757964 | 2019-10-08 16:46:59.128436 | 1 | 0 | 0 | 0 | 0 | 0 | | 1 | FILE COPY | Completed | 2019-10-08 16:46:59.128766 | 2019-10-08 16:47:16.857536 | 8 | 8429731840 | 8429731840 | 8430190882 | 0 | 0 | | 1 | PAGE COPY | Completed | 2019-10-08 16:47:16.857737 | 2019-10-08 16:47:17.159531 | 8 | 0 | 0 | 785 | 0 | 0 | | 1 | REDO COPY | Completed | 2019-10-08 16:47:17.159748 | 2019-10-08 16:47:17.460516 | 8 | 2560 | 2560 | 3717 | 0 | 0 | | 1 | FILE SYNC | Completed | 2019-10-08 16:47:17.460788 | 2019-10-08 16:47:20.926184 | 8 | 0 | 0 | 0 | 0 | 0 | | 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 |
| 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 | 2019-10-08 16:47:28.623732 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | RECOVERY | Completed | 2019-10-08 16:47:28.623732 | 2019-10-08 16:47:34.898453 | 0 | 0 | 0 | 0 | 0 | 0 | +------+-----------+-----------+---------------------------- +----------------------------+---------+------------+------- -----+------------+------------+---------------+ 7 rows in set (0.00 sec) select * from clone_status\G *************************** 1. row *************************** ID: 1 PID: 0 STATE: Completed BEGIN_TIME: 2019-10-08 16:46:58.758 END_TIME: 2019-10-08 16:47:34.898 SOURCE: 10.10.30.162:3306 DESTINATION: LOCAL INSTANCE ERROR_NO: 0 ERROR_MESSAGE: BINLOG_FILE: mysql-bin.000022 BINLOG_POSITION: 222104704 GTID_EXECUTED: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4, aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494 1 row in set (0.01 sec)
PS：
狀態轉移完成後，群組複製將重新啟動加入節點以完成該過程。如果在加入節點上設定了groupreplicationstartonboot = OFF，例如，因為在START GROUPREPLICATION語句上指定了複製使用者憑證，則在重新啟動後必須再次手動發布START GROUPREPLICATION。如果在設定檔中或使用SET PERSIST語句設定了groupreplicationstartonboot = ON以及啟動群組複製所需的其他設置，則無需幹預，該過程會自動繼續使加入節點設定為online狀態。
遠端複製作業會將引導節點的資料目錄下的各種資料檔案複製到加入節點中（表中可能包含了一些設定資訊及其使用者資料等）。但儲存在設定檔（如群組複製本機位址設定等）中的群組複製成員設定不會被克隆，也不會在加入節點上做任何變更。即，群組複製相關的配置需要自行配置好，不能跟集群中的現有成員衝突，遠端克隆操作只負責克隆資料文件，不會克隆配置資訊（當然，如果某些配置資訊保存在表裡，對於克隆操作來說，也會被當作資料進行克隆）。
如果远程克隆过程花费很长时间，则在MySQL 8.0.22之前的发行版中，在该时间段内为该集群累积的一组认证信息可能会变得太大而无法传输给加入成员。在这种情况下，加入成员会记录一条错误消息，并且不会加入该集群。从MySQL 8.0.22开始，组复制以不同的方式管理应用事务的垃圾收集过程，以避免发生这种情况。在早期版本中，如果确实看到此错误，则在远程克隆操作完成之后，请等待两分钟，以允许进行一轮垃圾收集，以减小集群的认证信息的大小。然后在加入成员上发出以下声明，以使其停止尝试应用先前的认证信息集：
RESET SLAVE FORCHANNEL group_replication_recovery; RESET REPLICA FOR CHANNEL group_replication_recovery;（从8.0.22开始）
引导节点中用于组复制专用通道groupreplicationrecovery的用户凭证（复制用户和密码），在克隆操作完成之后，会被新成员使用，所以，该用户和密码及其权限必须在新成员中也有效。因此，所有组成员才能够使用相同的复制用户和密码通过远程克隆操作接收状态传输进行分布式恢复。但是，组复制会保留与使用SSL相关的组复制通道设置，这些设置对单个成员来说可以是惟一的（即，每个组成员使用不同的复制用户和密码）。如果使用了PRIVILEGECHECKSUSER帐户来帮助保护复制应用线程（从MySQL8.0.18开始，可以创建一个具有特定权限的用户账号，然后将其指定为PRIVILEGECHECKSUSER帐户，这样可以防止将未经授权或意外将具有特权的账号用于组复制通道），则在克隆操作完成之后新加入成员不会使用该用户帐户作为组复制通道的用户。此时必须为组复制通道手工指定合适的复制用户。
如果引导节点用于groupreplicationrecovery复制通道的复制用户凭据已使用CHANGE MASTER TO语句存储在复制元数据存储库中，则在克隆后将它们转移到加入成员并由其使用，并且它们在此处必须有效。因此，使用存储的凭据，所有通过远程克隆操作接收状态转移的组成员都会自动接收复制用户和密码，进行分布式恢复。如果在START GROUPREPLICATION语句上指定了复制用户凭据，则这些凭据将用于启动远程克隆操作，但是在克隆后它们不会传输到加入节点并由其使用。如果不希望将凭据转移到新的server上并记录在那里，确保在进行远程克隆操作之前取消设置它们，并使用START GROUPREPLICATION代替提供它们。
ps:如果已使用PRIVILEGECHECKSUSER帐户来帮助保护复制应用程序，则从MySQL 8.0.19开始，会将PRIVILEGECHECKSUSER帐户以及来自引导节点的相关设置克隆出来。如果将加入节点设置为在启动时启动组复制，它将自动使用该帐户在相应的复制通道上进行权限检查。（在MySQL 8.0.18中，由于许多限制，建议不要将PRIVILEGECHECKSUSER帐户用于组复制通道。）
组复制启动并管理用于分布式恢复的克隆操作。设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。例如，可能希望通过从组成员作为引导节点来进行克隆来创建新的MySQL实例，但是不希望新的服务器实例立即加入或可能永远不会加入该集群。
在所有支持克隆的发行版中，可以手动启动涉及停止了组复制的组成员的克隆操作。由于克隆要求引导节点和接收数据的节点上的克隆插件必须匹配，因此即使不希望该实例加入集群，也必须在另一个实例上安装并激活组复制插件。可以通过发出以下语句来安装插件：
INSTALL PLUGIN group_replication SONAME'group_replication.so';
在MySQL 8.0.20之前的发行版中，如果操作涉及正在运行“组复制”的组成员，则无法手动启动克隆操作。从MySQL8.0.20开始，只要克隆操作不会删除和替换接收者上的数据，就可以执行此操作。因此，如果正在运行组复制，则用于启动克隆操作的语句必须包含DATA DIRECTORY子句。
以上是MySQL分散式復原實例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！
