MySQL分布式恢復實例分析

這篇“MySQL分布式恢復實例分析”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內(nèi)容，內(nèi)容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“MySQL分布式恢復實例分析”文章吧。

1. 概述

每當一個MySQLserver新加入或者重新加入一個MGR集群時，它都必須追平集群內(nèi)相差的事務，保證這個節(jié)點的數(shù)據(jù)和集群內(nèi)最新的數(shù)據(jù)是同步的。這個新加入集群的節(jié)點在追平集群中的數(shù)據(jù)或者重新加入集群的節(jié)點追評它脫離集群后到現(xiàn)在這段時間內(nèi)相差的事務數(shù)據(jù)的過程稱為分布式恢復。

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

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

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

組復制在分布式恢復期間用下述方法實現(xiàn)狀態(tài)傳輸：

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

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

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

在遠程克隆操作期間，將刪除加入節(jié)點上的現(xiàn)有數(shù)據(jù)，并用引導節(jié)點數(shù)據(jù)的副本替換。當遠程克隆操作完成并且新加入節(jié)點已重新啟動時，將繼續(xù)執(zhí)行來自引導節(jié)點二進制日志來進行狀態(tài)轉(zhuǎn)移，以獲取在進行遠程克隆操作時集群所寫入的增量數(shù)據(jù)。

在從引導節(jié)點的二進制日志進行狀態(tài)轉(zhuǎn)移期間，新加入節(jié)點從引導節(jié)點的二進制日志中復制并應用所需的事務，并在收到事務時應用事務，直到二進制日志記錄新加入節(jié)點加入了集群。（當加入節(jié)點成功加入集群時，二進制日志中會記錄對應的視圖更改event）在此過程中，加入節(jié)點將緩沖該集群應用的新事務數(shù)據(jù)。從二進制日志的狀態(tài)傳輸完成后，新加入節(jié)點將應用緩沖的事務。

當加入節(jié)點與該集群的所有事務保持最新時，該節(jié)點將在設置為online狀態(tài)并可以作為普通節(jié)點加入集群，并且分布式恢復已完成。

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

2. 分布式恢復的連接

當加入節(jié)點連接到現(xiàn)有節(jié)點中的引導節(jié)點進行分布式恢復期間的狀態(tài)轉(zhuǎn)移時，加入節(jié)點充當客戶端，而引導節(jié)點充當服務端。當通過此連接（使用異步復制通道groupreplicationrecovery）從引導節(jié)點的二進制日志進行狀態(tài)轉(zhuǎn)移時，加入節(jié)點充當副本，引導節(jié)點充當源端。通過此連接進行遠程克隆操作時，新加入節(jié)點充當全量數(shù)據(jù)接收者，引導節(jié)點充當全量數(shù)據(jù)提供者。應用于組復制上下文之外的角色的配置設置也可以應用于組復制，除非它們被特定于組復制的配置設置或行為所覆蓋。

現(xiàn)有節(jié)點提供給新加入節(jié)點以進行分布式恢復的連接與組復制用于集群內(nèi)節(jié)點之間的通信的連接是不同的。

組通信引擎用于組復制（XCom，Paxos變體），用于遠程XCom實例之間的TCP通信的連接由groupreplicationlocal_address系統(tǒng)變量指定。此連接用于集群內(nèi)online節(jié)點之間的TCP / IP消息傳遞。與本地實例的通信是通過使用內(nèi)存內(nèi)共享的傳輸通道進行的。

對于分布式恢復，直到MySQL8.0.20為止，集群內(nèi)的節(jié)點都將其標準SQL客戶端連接提供給加入節(jié)點，這由MySQL Server的主機名和端口系統(tǒng)變量指定。如果report_port系統(tǒng)變量指定了備用端口號，則改用該端口號。

從MySQL 8.0.21開始，組成員可以將分布式恢復端點的替代列表作為加入成員的專用客戶端連接，從而使得獨立于成員的常規(guī)客戶端用戶的連接可以用來控制分布式恢復?？梢允褂胓roupreplicationadvertiserecoveryendpoints系統(tǒng)變量來指定此列表，并且成員在加入組時將其分布式恢復端點的列表傳輸?shù)皆摻M。默認值為成員繼續(xù)提供與早期版本相同的標準SQL客戶端連接。

PS：

如果加入節(jié)點無法使用MySQLServer的系統(tǒng)變量定義的主機名正確識別其他節(jié)點，則分布式恢復可能會失敗。建議運行MySQL的操作系統(tǒng)使用DNS或本地設置具有正確配置的唯一主機名。可以在“performanceschema”庫下的Replicationgroupmembers表的Memberhost列中驗證server用于SQL客戶端連接的主機名。如果多個組成員將操作系統(tǒng)設置的默認主機名外部化，則加入節(jié)點有可能無法將其解析為正確的地址，并且無法連接以進行分布式恢復。在這種情況下，可以使用MySQL Server的report_host系統(tǒng)變量來配置由每個server外部化的唯一主機名。

加入節(jié)點為分布式恢復建立連接的步驟如下：

當節(jié)點加入集群時，它會使用groupreplicationgroupseeds系統(tǒng)變量中列表中包含的一個種子節(jié)點進行連接，最初使用該列表中指定的groupreplicationlocaladdress連接。種子節(jié)點可能是集群數(shù)據(jù)的子集。

通過此連接，種子節(jié)點使用組復制的成員資格服務以視圖的形式向加入的節(jié)點提供集群中所有online節(jié)點的列表。成員資格信息包括每個成員為分布式恢復提供的分布式恢復端點或標準SQL客戶端連接的詳細信息。

加入節(jié)點從此列表中選擇合適的online節(jié)點作為其引導節(jié)點進行分布式恢復

加入節(jié)點嘗試使用引導節(jié)點的分布式恢復端點來連接到引導節(jié)點，并按列表中指定的順序依次嘗試連接每個端點。如果引導節(jié)點沒有提供端點，則加入節(jié)點將嘗試使用引導節(jié)點的標準SQL客戶端連接進行連接。連接的SSL要求由groupreplicationrecoveryssl *選項指定。

如果加入節(jié)點無法連接到指定的引導節(jié)點，則它將與其他合適的引導節(jié)點重試連接。如果加入節(jié)點在沒有建立連接的情況下耗盡了端點的廣播列表，則它不會回退到引導節(jié)點的標準SQL客戶端連接，而是切換到另一個引導節(jié)點嘗試重新建立連接。

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

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

groupreplicationadvertiserecoveryendpoints系統(tǒng)變量作為分布式恢復端提供的IP地址，不必為MySQL Server配置（也就是說，不必由adminaddress系統(tǒng)變量或在bindaddress系統(tǒng)變量的列表中指定）。

為MySQL Server配置為分布式恢復端提供的端口，必須由port，reportport或adminport系統(tǒng)變量指定。必須在這些端口上偵聽TCP / IP連接。如果指定adminport，則用于分布式恢復的復制用戶需要SERVICECONNECTIONADMIN權限才能連接。選擇adminport可使分布式恢復連接與常規(guī)MySQL客戶端連接分開。

加入節(jié)點按列表中指定的順序依次嘗試每個端點。如果將groupreplicationadvertiserecoveryendpoints設置為DEFAULT而不是端點列表，則將提供標準SQL客戶端連接。標準SQL客戶端連接不會自動包含在分布式恢復端點列表中，并且如果引導節(jié)點的端點列表在沒有連接的情況下被用盡，則不會將其作為備用。如果要提供標準SQL客戶端連接作為多個分布式恢復端點之一，則必須將其顯式包括在groupreplicationadvertiseadvertiserecovery_endpoints指定的列表中?？梢詫⑵浞旁谧詈?，以便作為連接的最后手段。

無需將組成員的分布式恢復終點（或標準SQL客戶端連接，如果未提供終點）添加到groupreplicationipallowlist（來自MySQL 8.0.22）或groupreplicationipwhitelist系統(tǒng)變量指定的組復制允許列表中。許可列表僅適用于由groupreplicationlocal_address為每個節(jié)點指定的地址。加入節(jié)點必須具有與允許列表允許的集群的初始連接，以便檢索一個或多個地址進行分布式恢復。

設置系統(tǒng)變量和執(zhí)行STARTGROUP_REPLICATION語句后，將驗證列出的分布式恢復端點。如果無法正確解析列表，或者由于服務未在偵聽列表而無法在主機上訪問任何端點，則組復制將記錄錯誤并且無法啟動。

2.2分布式恢復壓縮

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

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

2.3分布式恢復的用戶

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

2.4分布式恢復和SSL認證

用于分布式恢復的SSL與用于普通組通信的SSL分開配置，這由server的SSL設置和groupreplicationssl_mode系統(tǒng)變量確定。對于分布式恢復連接，可以使用專用的組復制分布式恢復SSL系統(tǒng)變量來配置專門用于分布式恢復的證書和密鑰的使用。

默認情況下，SSL不用于分布式恢復連接。設置groupreplicationrecoveryusessl= ON啟用，然后配置組復制分布式恢復SSL系統(tǒng)變量，將復制用戶設置為使用SSL。

將分布式恢復配置為使用SSL時，組復制會將此設置應用于遠程克隆操作以及從引導節(jié)點的二進制日志進行狀態(tài)轉(zhuǎn)移。組復制會自動配置克隆SSL選項（clonesslca，clonesslcert和clonesslkey），以匹配相應組復制分布式恢復選項（groupreplicationrecoverysslca，groupreplicationrecoverysslcert和groupreplicationrecoverysslkey）的設置。

如果未使用SSL進行分布式恢復（groupreplicationrecoveryusessl設置為OFF），并且組復制的復制用戶帳戶使用cachingsha2password插件（MySQL 8.0中的默認設置）或sha256password插件進行身份驗證，則RSA密鑰對為用于密碼交換。在這種情況下，使用groupreplicationrecoverypublickeypath系統(tǒng)變量指定RSA公共密鑰文件，或者使用groupreplicationrecoverygetpublic_key系統(tǒng)變量請求公共密鑰。否則整個分布式回復會因為報錯導致恢復失敗。

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

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

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

在從引導節(jié)點向加入節(jié)點傳輸數(shù)據(jù)之前，遠程克隆操作會刪除加入節(jié)點中用戶創(chuàng)建的表空間和數(shù)據(jù)。如果在中途意外終止操作，則加入節(jié)點可能只剩下部分數(shù)據(jù)或沒有數(shù)據(jù)?？梢酝ㄟ^重新執(zhí)行組復制自動執(zhí)行的遠程克隆操作來修復此問題。

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

3.1克隆的基本條件

對于組復制，使用克隆插件進行分布式恢復需要注意以下要點和區(qū)別：

現(xiàn)有集群節(jié)點和加入節(jié)點必須已安裝克隆插件并處于激活狀態(tài)。

引導節(jié)點和加入節(jié)點必須在相同的操作系統(tǒng)上運行，并且必須具有相同的MySQL Server版本（必須為MySQL 8.0.17或更高版本才能支持克隆插件）。因此，克隆不適用于成員運行不同MySQL版本的集群。

引導節(jié)點和加入節(jié)點必須已安裝并激活了“組復制”插件，引導節(jié)點上所有激活的其他插件（例如，密鑰環(huán)插件）也必須在加入節(jié)點上處于激活狀態(tài)。

如果將分布式恢復配置為使用SSL（groupreplicationrecoveryusessl= ON），則組復制會將此設置應用于遠程克隆操作。組復制會自動配置克隆SSL選項（clonesslca，clonesslcert和clonesslkey）的設置，以匹配相應組復制分布式恢復選項（groupreplicationrecoverysslca，groupreplicationrecoverysslcert和groupreplicationrecoverysslkey）的設置。

不需要在加入節(jié)點上為加入集群而在clonevaliddonor_list系統(tǒng)變量中設置有效引導節(jié)點列表。MGR自動從現(xiàn)有的集群節(jié)點中選擇引導節(jié)點后，組復制會自動配置此設置。注意，遠程克隆操作使用server的SQL協(xié)議主機名和端口，而非集群成員之間內(nèi)部通訊的地址和端口。

克隆插件具有許多系統(tǒng)變量，可管理遠程克隆操作的網(wǎng)絡負載和性能影響。組復制未配置這些設置，因此可以查看它們并根據(jù)需要進行設置，也可以將其設置為默認設置，當使用遠程克隆操作進行分布式恢復時，克隆插件的cloneenablecompression設置將應用于該操作，而不會影響現(xiàn)有配置好的組復制壓縮設置。

為了對加入節(jié)點調(diào)用遠程克隆操作，組復制使用內(nèi)部mysql.session用戶，該用戶已經(jīng)具有CLONE_ADMIN特權，因此無需進行特別設置。

作為遠程克隆操作的引導節(jié)點上的克隆用戶，組復制使用為分布式恢復設置的復制用戶。因此，必須在所有支持克隆的集群節(jié)點上將此復制用戶賦予BACKUP_ADMIN特權。在為節(jié)點配置組復制時，如果有加入節(jié)點，還應向該節(jié)點上的復制用戶授予此權限，因為加入節(jié)點加入集群后，他們可以充當其他加入節(jié)點的引導節(jié)點。同一復制用戶用于每個集群節(jié)點上的分布式恢復。要將此權限授予現(xiàn)有節(jié)點上的復制用戶，可以在禁用二進制日志記錄的情況下在每個集群節(jié)點上單獨執(zhí)行此語句，或者在啟用二進制日志記錄的情況下在一個集群的primary節(jié)點上執(zhí)行如下語句：

GRANT BACKUP_ADMIN ON *.* TO *rpl_user*@'%';

如果在使用STARTGROUPREPLICATION以前在提供用戶憑據(jù)的server上使用CHANGE MASTER TO指定復制用戶憑據(jù)，請確保在進行任何遠程克隆操作之前，從復制元數(shù)據(jù)存儲庫中刪除該用戶憑據(jù)。還要確保在加入成員上設置了groupreplicationstartonboot =OFF。如果未取消設置用戶憑據(jù)，則在遠程克隆操作期間會將它們轉(zhuǎn)移到加入成員。然后，可能會在原始成員或從其克隆的成員上意外地使用存儲的憑據(jù)啟動groupreplicationrecovery通道。server啟動時（包括在遠程克隆操作之后）自動啟動組復制將使用存儲的用戶憑據(jù)，并且如果未在START GROUPREPLICATION命令上指定分布式恢復憑據(jù)，也將使用它們。

3.2克隆的閾值

設置組成員支持克隆后，groupreplicationclonethreshold系統(tǒng)變量將指定一個閾值，表示為多少個事務，以便在分布式恢復中使用遠程克隆操作。如果引導節(jié)點上的事務與加入節(jié)點上的事務之間的數(shù)量大于此數(shù)目，則在技術上可行時，將使用遠程克隆操作將狀態(tài)轉(zhuǎn)移到加入節(jié)點。組復制基于現(xiàn)有組成員的gtidexecuted集來計算是否已超過閾值。在事務間隙較大的情況下使用遠程克隆操作，可以將新成員添加到集群中，而無需事先將集群的數(shù)據(jù)手動傳輸?shù)?a title="服務器" target="_blank" href="http://www.kemok4.com/">服務器，還可以使落后的節(jié)點更有效地進行數(shù)據(jù)追趕。

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

PS：

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

當無法從引導節(jié)點的二進制日志進行狀態(tài)轉(zhuǎn)移時，組復制嘗試執(zhí)行遠程克隆操作，而不管此時的閾值如何，例如，因為加入成員所需的事務在任何現(xiàn)有組成員的二進制日志中均不可用。組復制基于現(xiàn)有組成員的gtidpurged集對此進行標識。當所需的事務在任何成員的二進制日志文件中不可用時，不能使用groupreplicationclonethreshold系統(tǒng)變量來停用克隆，因為在這種情況下，克隆是手動將數(shù)據(jù)傳輸?shù)郊尤牍?jié)點的唯一選

3.3克隆操作

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

performanceschema.cloneprogress表中記錄了整個克隆操作的每一個階段及其對應的階段信息，每一個階段會生成一行記錄（注意，該表中只記錄一次克隆操作的過程信息，下一次執(zhí)行克隆操作時，上一次的信息會被覆蓋）

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：

狀態(tài)轉(zhuǎn)移完成后，組復制將重新啟動加入節(jié)點以完成該過程。如果在加入節(jié)點上設置了groupreplicationstartonboot = OFF，例如，因為在START GROUPREPLICATION語句上指定了復制用戶憑據(jù)，則在重新啟動后必須再次手動發(fā)布START GROUPREPLICATION。如果在配置文件中或使用SET PERSIST語句設置了groupreplicationstartonboot = ON以及啟動組復制所需的其他設置，則無需干預，該過程會自動繼續(xù)使加入節(jié)點設置為online狀態(tài)。

遠程克隆操作會將引導節(jié)點的數(shù)據(jù)目錄下的各種數(shù)據(jù)文件克隆到加入節(jié)點中（表中可能包含了一些配置信息及其用戶數(shù)據(jù)等）。但保存在配置文件（如組復制本地地址配置等）中的組復制成員設置不會被克隆，也不會在加入節(jié)點上做任何更改。即，組復制相關的配置需要自行配置好，不能跟集群中的現(xiàn)有成員沖突，遠程克隆操作只負責克隆數(shù)據(jù)文件，不會克隆配置信息（當然，如果某些配置信息保存在表里，對于克隆操作來說，也會被當做數(shù)據(jù)進行克隆）。

如果遠程克隆過程花費很長時間，則在MySQL 8.0.22之前的發(fā)行版中，在該時間段內(nèi)為該集群累積的一組認證信息可能會變得太大而無法傳輸給加入成員。在這種情況下，加入成員會記錄一條錯誤消息，并且不會加入該集群。從MySQL 8.0.22開始，組復制以不同的方式管理應用事務的垃圾收集過程，以避免發(fā)生這種情況。在早期版本中，如果確實看到此錯誤，則在遠程克隆操作完成之后，請等待兩分鐘，以允許進行一輪垃圾收集，以減小集群的認證信息的大小。然后在加入成員上發(fā)出以下聲明，以使其停止嘗試應用先前的認證信息集：

RESET SLAVE FORCHANNEL group_replication_recovery;
RESET REPLICA FOR CHANNEL group_replication_recovery;（從8.0.22開始）

引導節(jié)點中用于組復制專用通道groupreplicationrecovery的用戶憑證（復制用戶和密碼），在克隆操作完成之后，會被新成員使用，所以，該用戶和密碼及其權限必須在新成員中也有效。因此，所有組成員才能夠使用相同的復制用戶和密碼通過遠程克隆操作接收狀態(tài)傳輸進行分布式恢復。但是，組復制會保留與使用SSL相關的組復制通道設置，這些設置對單個成員來說可以是惟一的（即，每個組成員使用不同的復制用戶和密碼）。如果使用了PRIVILEGECHECKSUSER帳戶來幫助保護復制應用線程（從MySQL8.0.18開始，可以創(chuàng)建一個具有特定權限的用戶賬號，然后將其指定為PRIVILEGECHECKSUSER帳戶，這樣可以防止將未經(jīng)授權或意外將具有特權的賬號用于組復制通道），則在克隆操作完成之后新加入成員不會使用該用戶帳戶作為組復制通道的用戶。此時必須為組復制通道手工指定合適的復制用戶。

如果引導節(jié)點用于groupreplicationrecovery復制通道的復制用戶憑據(jù)已使用CHANGE MASTER TO語句存儲在復制元數(shù)據(jù)存儲庫中，則在克隆后將它們轉(zhuǎn)移到加入成員并由其使用，并且它們在此處必須有效。因此，使用存儲的憑據(jù)，所有通過遠程克隆操作接收狀態(tài)轉(zhuǎn)移的組成員都會自動接收復制用戶和密碼，進行分布式恢復。如果在START GROUPREPLICATION語句上指定了復制用戶憑據(jù)，則這些憑據(jù)將用于啟動遠程克隆操作，但是在克隆后它們不會傳輸?shù)郊尤牍?jié)點并由其使用。如果不希望將憑據(jù)轉(zhuǎn)移到新的server上并記錄在那里，確保在進行遠程克隆操作之前取消設置它們，并使用START GROUPREPLICATION代替提供它們。

ps:如果已使用PRIVILEGECHECKSUSER帳戶來幫助保護復制應用程序，則從MySQL 8.0.19開始，會將PRIVILEGECHECKSUSER帳戶以及來自引導節(jié)點的相關設置克隆出來。如果將加入節(jié)點設置為在啟動時啟動組復制，它將自動使用該帳戶在相應的復制通道上進行權限檢查。（在MySQL 8.0.18中，由于許多限制，建議不要將PRIVILEGECHECKSUSER帳戶用于組復制通道。）

3.4克隆的其他用處

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

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

INSTALL PLUGIN group_replication SONAME'group_replication.so';

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

以上就是關于“MySQL分布式恢復實例分析”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對大家有幫助，若想了解更多相關的知識內(nèi)容，請關注億速云行業(yè)資訊頻道。