溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇“MySQL分布式恢復實例分析”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“MySQL分布式恢復實例分析”文章吧。
每當一個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插件進行身份驗證，則RSA密鑰對為用于密碼交換。在這種情況下，使用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分布式恢復實例分析”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
