MySQL分佈式恢復進階

1. 概述

每當一個MySQLserver新加入或者重新加入一個MGR集群時，它都必須追平集群內相差的事務，保證這個節點的數據和集群內最新的數據是同步的。這個新加入集群的節點在追平集群中的數據或者重新加入集群的節點追評它脫離集群後到現在這段時間內相差的事務數據的過程稱為分佈式恢復。

申請加入集群的節點首先檢查groupreplicationapplier通道中的中繼日志，檢查該節點目前尚未從集群中同步過來的事務數據。如果是重新加入集群的節點，則該節點會找到在離開集群後到現在和集群最新數據中未回放的事務數據，在這種情況下，該節點首先會應用這些未同步的事務。對於新加入集群的節點，直接從一個引導節點上進行全量數據恢復即可。

此後，新加入的節點和集群中現有的online狀態的節點（引導節點）建立連接進行狀態轉移。新加入的節點從集群中的引導節點中同步加入集群之前或者離開集群後到現在未同步過來的數據，這些相差的事務由集群中的引導節點提供。接下來，新加入的節點應用從集群中的引導節點同步過來的未進行應用的事務。此時申請加入集群的節點將應用在狀態傳輸過程中集群內新事務寫入的數據。（此時集群內新事物寫入的數據暫時存放在緩存隊列中，並未將數據寫入磁盤中）完成此過程後，新加入的節點的數據和整個集群的數據相比，處於一個追平的狀態，並且該節點設置為online狀態。

註意：新加入集群的節點，不論是之前有沒有在此集群中，都會先隨機選一個online節點先同步該節點和集群相差的事務。

組復制在分佈式恢復期間用下述方法實現狀態傳輸：

使用克隆插件的功能進行遠程克隆操作，該插件可從MySQL 8.0.17開始支持。要使用這種方法，必須在引導節點和新加入的節點上提前安裝克隆插件。組復制會自動配置所需的克隆插件設置，並管理遠程克隆操作。

從引導節點的二進制日志復制數據並在新加入的節點上應用這些事務。此方法需要在引導節點和加入節點之間建立的名為groupreplicationrecovery的標準異步復制通道。

在加入節點上執行STARTGROUP_REPLICATION後，組復制會自動選擇上述方法的最佳組合進行狀態轉移。為此，組復制將會檢查集群中哪些現有節點適合用作引導節點，加入節點需要引導節點傳輸多少事務，以及是否有事務不再存在於集群中任意節點的二進制日志文件中。如果加入節點與引導節點之間的事務差距很大，或者如果某些要求的事務不在引導節點的二進制日志文件中，則組復制將通過遠程克隆操作開始分佈式恢復。如果沒有較大的事務間隙，或者未安裝克隆插件，則組復制將直接從引導節點的二進制日志進行狀態轉移。

在遠程克隆操作期間，將刪除加入節點上的現有數據，並用引導節點數據的副本替換。當遠程克隆操作完成並且新加入節點已重新啟動時，將繼續執行來自引導節點二進制日志來進行狀態轉移，以獲取在進行遠程克隆操作時集群所寫入的增量數據。

在從引導節點的二進制日志進行狀態轉移期間，新加入節點從引導節點的二進制日志中復制並應用所需的事務，並在收到事務時應用事務，直到二進制日志記錄新加入節點加入瞭集群。（當加入節點成功加入集群時，二進制日志中會記錄對應的視圖更改event）在此過程中，加入節點將緩沖該集群應用的新事務數據。從二進制日志的狀態傳輸完成後，新加入節點將應用緩沖的事務。

當加入節點與該集群的所有事務保持最新時，該節點將在設置為online狀態並可以作為普通節點加入集群，並且分佈式恢復已完成。

ps：從二進制日志進行狀態轉移是組復制進行分佈式恢復的基本機制，並且如果未將復制組中的引導節點和加入節點設置為支持克隆。由於從二進制日志進行狀態轉移是基於經典的異步復制，因此，如果加入該集群的MySQL server根本沒有該集群的數據，或者從非常舊的備份中獲取瞭數據，則可能要花費很長時間來恢復最新數據。因此，在這種情況下，建議在將MySQL server添加到集群之前，則應通過傳輸集群中已有節點的相當近期的快照來使用集群的數據對其進行設置。這可以最大程度地減少分佈式恢復所需的時間，並減少對引導節點的影響，因為引導節點必須保留和傳輸較少的二進制日志文件。

2. 分佈式恢復的連接

當加入節點連接到現有節點中的引導節點進行分佈式恢復期間的狀態轉移時，加入節點充當客戶端，而引導節點充當服務端。當通過此連接（使用異步復制通道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客戶端連接，而是切換到另一個引導節點嘗試重新建立連接。

加入節點與引導節點建立分佈式恢復連接時，它將使用該連接進行狀態轉移，加入節點的日志中顯示瞭所使用的連接的主機和端口。如果使用遠程克隆操作，則在操作結束時重新啟動加入節點時，它將與新的引導節點建立連接，從引導節點的二進制日志進行狀態轉移。這可能是與用於遠程克隆操作的引導節點不同的連接，也可能是與引導節點建立相同的連接。無論如何，分佈式恢復將以相同的方式與引導節點建立連接。

2.1分佈式恢復端地址的查找

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語句後，將驗證列出的分佈式恢復端點。如果無法正確解析列表，或者由於服務未在偵聽列表而無法在主機上訪問任何端點，則組復制將記錄錯誤並且無法啟動。

2.2分佈式恢復壓縮

在MySQL 8.0.18中，可以選擇使用引導節點二進制日志中的狀態轉移方法為分佈式恢復配置壓縮。在網絡帶寬有限的情況下，壓縮可以使分佈式恢復受益，而引導節點必須將許多事務傳輸給加入節點。groupreplicationrecoverycompressionalgorithm和groupreplicationrecoveryzstdcompression_level系統變量配置允許的壓縮算法以及zstd壓縮級別，這些級別用於從引導節點的二進制日志執行狀態轉移時使用。

這些壓縮設置不適用於遠程克隆操作。當遠程克隆操作用於分佈式恢復時，將應用克隆插件的cloneenablecompression設置。

2.3分佈式恢復的用戶

分佈式恢復需要具有正確權限的復制用戶，以便組復制可以建立直接的節點到節點的復制通道。復制用戶還必須具有正確的權限，如果該復制用戶還同充當遠程克隆操作中的克隆用戶，則在引導節點中該復制用戶還必須具有遠程克隆相關的權限（BACKUP_ADMIN權限）才能充當引導節點上的克隆用戶以進行遠程克隆操作。除此之外，必須將同一復制用戶用於集群內每個節點上的分佈式恢復。

2.4分佈式恢復和SSL認證

用於分佈式恢復的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插件進行身份驗證，則RSA密鑰對為用於密碼交換。在這種情況下，使用groupreplicationrecoverypublickeypath系統變量指定RSA公共密鑰文件，或者使用groupreplicationrecoverygetpublic_key系統變量請求公共密鑰。否則整個分佈式回復會因為報錯導致恢復失敗。

3. 利用克隆插件進行分佈式恢復

MySQLServer的克隆插件可從MySQL8.0.17獲得。如果要將遠程克隆操作用於集群中的分佈式恢復，則必須預先設置現有節點和加入節點才能支持此功能。如果不想在集群中使用此功能，請不要進行設置，在這種情況下，組復制僅使用二進制日志中的狀態傳輸。

要使用克隆插件，必須預先設置至少一個現有的集群節點和加入節點支持遠程克隆操作。至少，必須在引導節點和加入節點上安裝克隆插件，將BACKUPADMIN權限授予復制用戶以進行分佈式恢復，並將groupreplicationclonethreshold系統變量設置為適當的級別。（默認情況下為GTID序列允許的最大值，表示正常情況下，始終優先使用基於二進制日志的狀態傳輸，除非joiner節點所請求的事務在組中任意成員中都不存在，這個時候，如果設置好瞭克隆功能，則無論該系統變量的值設置為多少，都會觸發通過克隆的方式進行分佈式恢復，例如：全新初始化的Server申請加入組時。如果不希望使用克隆功能，則不要對其進行安裝與配置）為瞭確保引導節點的最大可用性，建議設置所有當前和將來的集群節點支持遠程克隆操作。以便後續有Server加入集群時能夠使用遠程克隆操作來快速追趕集群中的最新數據。

在從引導節點向加入節點傳輸數據之前，遠程克隆操作會刪除加入節點中用戶創建的表空間和數據。如果在中途意外終止操作，則加入節點可能隻剩下部分數據或沒有數據。可以通過重新執行組復制自動執行的遠程克隆操作來修復此問題。

這裡主要針對遠程克隆時使用DATADIRECTORY子選項指定瞭一個數據保存路徑的情況，指定路徑時，數據會保存在指定的目錄下，即克隆之後的數據與操作克隆的實例沒有關聯，需要手動啟動實例並指定datadir到保存克隆數據的目錄進行啟動，當然，MGR插件可以自動執行遠程克隆的重試操作（需要保證克隆操作不指定DATA DIRECTORY子選項，在這種情況下，遠程克隆數據會覆蓋掉操作遠程克隆的Server數據，完成遠程克隆操之後，操作遠程克隆的Server會基於克隆數據自動重新啟動）。另外，克隆插件雖然與組復制配合使用對組復制的管理維護來說更加自動化，但是，克隆插件不要求必須在集群中運行（但MGR插件必須要安裝）。

3.1克隆的基本條件

對於組復制，使用克隆插件進行分佈式恢復需要註意以下要點和區別：

現有集群節點和加入節點必須已安裝克隆插件並處於激活狀態。

引導節點和加入節點必須在相同的操作系統上運行，並且必須具有相同的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命令上指定分佈式恢復憑據，也將使用它們。

3.2克隆的閾值

設置組成員支持克隆後，groupreplicationclonethreshold系統變量將指定一個閾值，表示為多少個事務，以便在分佈式恢復中使用遠程克隆操作。如果引導節點上的事務與加入節點上的事務之間的數量大於此數目，則在技術上可行時，將使用遠程克隆操作將狀態轉移到加入節點。組復制基於現有組成員的gtidexecuted集來計算是否已超過閾值。在事務間隙較大的情況下使用遠程克隆操作，可以將新成員添加到集群中，而無需事先將集群的數據手動傳輸到服務器，還可以使落後的節點更有效地進行數據追趕。

groupreplicationclone_threshold組復制系統變量的默認設置非常高（GTID中事務的最大允許序列號），因此，隻要有可能從二進制日志轉移狀態，它都會有效地禁用克隆。要使組復制能夠選擇更適合狀態傳輸的遠程克隆操作，設置系統變量，以指定多少個事務作為要進行克隆的事務間隔。

PS：

不要在活躍的集群中為groupreplicationclone_threshold使用較低的設置。如果在進行遠程克隆操作的同時集群中發生瞭超過閾值的事務，則加入成員在重新啟動後會再次觸發遠程克隆操作，並且可以無限期地繼續進行。為避免這種情況，確保將閾值設置為一個可靠的數字，該閾值應大於在遠程克隆操作所花費的時間段內集群中預期發生的事務數。

當無法從引導節點的二進制日志進行狀態轉移時，組復制嘗試執行遠程克隆操作，而不管此時的閾值如何，例如，因為加入成員所需的事務在任何現有組成員的二進制日志中均不可用。組復制基於現有組成員的gtidpurged集對此進行標識。當所需的事務在任何成員的二進制日志文件中不可用時，不能使用groupreplicationclonethreshold系統變量來停用克隆，因為在這種情況下，克隆是手動將數據傳輸到加入節點的唯一選

3.3克隆操作

設置集群節點和加入節點進行克隆後，組復制將管理遠程克隆操作。遠程克隆操作需要一些時間才能完成，具體取決於數據的大小。

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帳戶用於組復制通道。）

3.4克隆的其他用處

組復制啟動並管理用於分佈式恢復的克隆操作。設置為支持克隆的組成員也可以參與用戶手動啟動的克隆操作。例如，可能希望通過從組成員作為引導節點來進行克隆來創建新的MySQL實例，但是不希望新的服務器實例立即加入或可能永遠不會加入該集群。

在所有支持克隆的發行版中，可以手動啟動涉及停止瞭組復制的組成員的克隆操作。由於克隆要求引導節點和接收數據的節點上的克隆插件必須匹配，因此即使不希望該實例加入集群，也必須在另一個實例上安裝並激活組復制插件。可以通過發出以下語句來安裝插件：

INSTALL PLUGIN group_replication SONAME'group_replication.so';

在MySQL 8.0.20之前的發行版中，如果操作涉及正在運行“組復制”的組成員，則無法手動啟動克隆操作。從MySQL8.0.20開始，隻要克隆操作不會刪除和替換接收者上的數據，就可以執行此操作。因此，如果正在運行組復制，則用於啟動克隆操作的語句必須包含DATA DIRECTORY子句。

到此這篇關於MySQL分佈式恢復進階的文章就介紹到這瞭,更多相關SQL分佈式恢復內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：

• shell腳本實現mysql數據庫雙機定時備份的方法
• MySQL基於GTID主從搭建
• MySQL DDL 引發的同步延遲該如何解決
• MySQL同步數據Replication的實現步驟
• Docker部署mysql一主一從的操作方法