在使用帶有全域交易識別碼 (GTID) 的 MySQL 複寫來佈建新的副本時，有很多技術可以將其用於擴展，並在需要時升級為來源以進行故障轉移。本節說明下列技術

為了簡化一般複寫資料流程管理和特別是故障轉移活動，全域交易識別碼已新增至 MySQL 複寫。每個識別碼都會唯一識別構成交易的一組二進位日誌事件。GTID 在將變更套用至資料庫時扮演關鍵角色：伺服器會自動略過任何具有識別碼的交易，該識別碼是伺服器辨識為先前已處理的交易。此行為對於自動複寫定位和正確的故障轉移至關重要。

識別碼與包含指定交易的事件集之間的對應關係會擷取在二進位日誌中。這在從另一個現有伺服器佈建具有資料的新伺服器時會造成一些挑戰。若要在新伺服器上重製識別碼集，必須將識別碼從舊伺服器複製到新伺服器，並保留識別碼和實際事件之間的關係。這對於還原一個可立即作為故障轉移或切換新來源的候選副本而言是必要的。

簡單複寫。在新伺服器上重製所有識別碼和交易最簡單的方式，是讓新伺服器成為具有完整執行歷程記錄之來源的副本，並在兩個伺服器上啟用全域交易識別碼。請參閱第 19.1.3.4 節，「使用 GTID 設定複寫」，以取得更多資訊。

一旦開始複寫，新伺服器會從來源複製整個二進位日誌，因此會取得所有關於所有 GTID 的資訊。

此方法簡單有效，但需要副本從來源讀取二進位日誌；新副本趕上來源有時需要相當長的時間，因此此方法不適用於快速故障轉移或從備份還原。本節說明如何透過將二進位日誌檔複製到新伺服器，來避免從來源擷取所有執行歷程記錄。

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

此方法有幾種變體，差異在於資料轉儲和二進制日誌中的交易傳輸到副本伺服器的方式，如下所述：

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

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

注入空交易。來源伺服器的全域 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;