文件首頁
MySQL 9.0 參考手冊
相關文件 下載本手冊
PDF (US Ltr) - 40.0Mb
PDF (A4) - 40.1Mb
Man Pages (TGZ) - 258.2Kb
Man Pages (Zip) - 365.3Kb
Info (Gzip) - 4.0Mb
Info (Zip) - 4.0Mb


MySQL 9.0 參考手冊  /  ...  /  使用 GTID 進行容錯移轉和擴展

19.1.3.5 使用 GTID 進行容錯移轉和擴展

在使用具有全域交易識別碼 (GTID) 的 MySQL 複寫來佈建新的複本時,有許多技術可以使用,然後可以用於橫向擴展,並在需要時提升為來源以進行容錯移轉。本節描述以下技術

將全域交易識別碼新增至 MySQL 複寫,目的是簡化複寫資料流的一般管理,尤其簡化容錯移轉活動。每個識別碼唯一識別一組共同組成交易的二進制日誌事件。GTID 在將變更套用至資料庫中起著關鍵作用:伺服器會自動跳過任何具有伺服器識別為之前處理過的識別碼的交易。此行為對於自動複寫定位和正確的容錯移轉至關重要。

在二進制日誌中會記錄識別符和組成指定交易的事件集之間的映射。當使用另一個現有伺服器的資料來佈建新伺服器時,這會帶來一些挑戰。為了在新伺服器上重現識別符集,必須將識別符從舊伺服器複製到新伺服器,並保留識別符和實際事件之間的關係。這對於還原一個可立即作為容錯移轉或切換的新來源的候選副本是必要的。

簡單複製。在新伺服器上重現所有識別符和交易的最簡單方法,是將新伺服器設定為具有完整執行歷史的來源的副本,並在兩台伺服器上啟用全域交易識別符。請參閱第 19.1.3.4 節「設定使用 GTID 的複製」,以取得更多資訊。

一旦開始複製,新伺服器會從來源複製整個二進制日誌,從而取得所有關於所有 GTID 的資訊。

此方法簡單有效,但需要副本從來源讀取二進制日誌;新副本追上來源可能需要相當長的時間,因此此方法不適用於快速容錯移轉或從備份還原。本節說明如何透過將二進制日誌檔案複製到新伺服器來避免從來源提取所有執行歷史。

將資料和交易複製到副本。當來源伺服器先前已處理大量交易時,執行整個交易歷史可能會非常耗時,這可能會在新設定副本時造成主要瓶頸。為了消除此需求,可以將來源伺服器所包含的資料集、二進制日誌和全域交易資訊的快照匯入到新副本。拍攝快照的伺服器可以是來源或其副本之一,但您必須確保伺服器在複製資料之前已處理所有必要的交易。

此方法有多種變體,差異在於將資料轉儲和二進制日誌中的交易傳輸到副本的方式,如下所示

資料集
  1. 在來源伺服器上使用 mysqldump 建立轉儲檔案。將 mysqldump 選項 --source-data 設定為 1,以包含具有二進制日誌資訊的 CHANGE REPLICATION SOURCE TO 陳述式。將 --set-gtid-purged 選項設定為 AUTO (預設值) 或 ON,以包含轉儲中已執行交易的資訊。然後使用 mysql 用戶端在目標伺服器上匯入轉儲檔案。

  2. 或者,使用原始資料檔案建立來源伺服器的資料快照,然後按照第 19.1.2.5 節「選擇資料快照的方法」中的指示,將這些檔案複製到目標伺服器。如果您使用 InnoDB 表格,您可以使用 MySQL Enterprise Backup 元件中的 mysqlbackup 命令來產生一致的快照。此命令會記錄與副本上要使用的快照對應的日誌名稱和偏移量。MySQL Enterprise Backup 是一個商業產品,包含在 MySQL Enterprise 訂閱中。有關詳細資訊,請參閱第 32.1 節「MySQL Enterprise Backup 概觀」

  3. 或者,停止來源和目標伺服器,將來源的資料目錄內容複製到新副本的資料目錄,然後重新啟動副本。如果您使用此方法,則必須將副本設定為使用 GTID 的複製,也就是說,使用 gtid_mode=ON。如需此方法的指示和重要資訊,請參閱第 19.1.2.8 節「將副本新增至複製環境」

交易歷史

如果來源伺服器的二進制日誌中具有完整的交易歷史 (也就是說,GTID 集 @@GLOBAL.gtid_purged 為空),則可以使用這些方法。

  1. 使用 mysqlbinlog,以及 --read-from-remote-server--read-from-remote-source 選項,將二進制日誌從來源伺服器匯入到新副本。

  2. 或者,將來源伺服器的二進制日誌檔案複製到副本。您可以使用 mysqlbinlog,以及 --read-from-remote-server--raw 選項,從副本製作複本。這些可以使用 mysqlbinlog > file (沒有 --raw 選項) 讀取到副本中,以將二進制日誌檔案匯出到 SQL 檔案,然後將這些檔案傳遞給 mysql 用戶端進行處理。確保使用單個 mysql 程序處理所有二進制日誌檔案,而不是多個連線。例如

    $> mysqlbinlog copied-binlog.000001 copied-binlog.000002 | mysql -u root -p

    有關更多資訊,請參閱第 6.6.9.3 節「使用 mysqlbinlog 備份二進制日誌檔案」

此方法的優點是新伺服器幾乎可以立即使用;只有在重新執行快照或轉儲檔案時提交的交易,仍然需要從現有來源取得。這表示副本的可用性並非立即,但副本追上這些剩餘的少量交易應該只需要相對較短的時間。

提前將二進制日誌複製到目標伺服器通常比從來源即時讀取整個交易執行歷史更快。但是,由於大小或其他考量,可能不總是可行在需要時將這些檔案移動到目標。本節中討論的其餘兩種佈建新副本的方法使用其他方式將關於交易的資訊傳輸到新副本。

注入空的交易。來源的全域 gtid_executed 變數包含來源上執行的所有交易集。在拍攝快照以佈建新伺服器時,您可以記下拍攝快照的伺服器上的 gtid_executed 的內容,而不是複製二進制日誌。在將新伺服器新增至複製鏈之前,只需在新伺服器上針對來源的 gtid_executed 中包含的每個交易識別符提交一個空的交易,如下所示

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';

BEGIN;
COMMIT;

SET GTID_NEXT='AUTOMATIC';

一旦使用空的交易以這種方式還原所有交易識別符,您必須刷新並清除副本的二進制日誌,如下所示,其中 N 是目前二進制日誌檔案名稱的非零後綴

FLUSH LOGS;
PURGE BINARY LOGS TO 'source-bin.00000N';

您應該這樣做,以防止此伺服器在稍後升級為來源時,用虛假交易淹沒複製串流。( FLUSH LOGS 陳述式會強制建立新的二進制日誌檔案;PURGE BINARY LOGS 會清除空的交易,但保留其識別符。)

此方法會建立一個本質上是快照的伺服器,但在時間上能夠成為來源,因為其二進制日誌歷史與複製串流的歷史收斂 (也就是說,當它追上來源或多個來源時)。此結果與使用其餘佈建方法獲得的結果在效果上相似,我們將在接下來的幾段中討論。

使用 gtid_purged 排除交易。來源的全域 gtid_purged 變數包含已從來源的二進制日誌中清除的所有交易集。與先前討論的方法一樣 (請參閱注入空的交易),您可以記錄拍攝快照的伺服器上的 gtid_executed 的值 (而不是將二進制日誌複製到新伺服器)。與先前的方法不同,不需要提交空的交易 (或發出 PURGE BINARY LOGS);相反地,您可以根據拍攝備份或快照的伺服器上的 gtid_executed 的值,直接在副本上設定 gtid_purged

如同使用空交易的方法,此方法會建立一個在功能上為快照的伺服器,但隨著其二進制日誌歷史與來源和其他副本的二進制日誌歷史收斂,在時間上能夠成為來源。

還原 GTID 模式副本。 當還原基於 GTID 的複製設定中遇到錯誤的副本時,注入空交易可能無法解決問題,因為事件沒有 GTID。

使用 mysqlbinlog 尋找下一個交易,這可能是事件之後下一個日誌檔案中的第一個交易。複製到該交易的 COMMIT 為止的所有內容,請務必包含 SET @@SESSION.gtid_next。即使您未使用基於行的複製,您仍然可以在命令行客戶端中執行二進制日誌行事件。

停止副本並執行您複製的交易。mysqlbinlog 輸出將分隔符號設定為 /*!*/;,因此將其設定回預設值,如下所示

mysql> DELIMITER ;

從正確的位置自動重新啟動複製

mysql> SET gtid_next=AUTOMATIC;
mysql> RESET REPLICA;
mysql> START REPLICA;