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_statusG
*************************** 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分散式恢復內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！