如何安全地保存資料一直是IT管理的重要項目，而勤做資料備份絕對是最重要的例行工作。本文將以MySQL資料庫為例，實際示範幾種資料備份的機制，包括以mysqlpump進行備份、透過XtraBackup備份資料庫，以及使用MySQL內建的GTID機制來同步主資料庫與從資料庫內的資料。
如果想要達到當主資料庫發生異動時，就能將異動的資訊同時備份到從資料庫上的要求，則必須使用資料庫伺服器上的複製（Replication）機制來完成此類要求。
何謂MySQL複製機制
為了避免增加主資料庫的負擔，複製（Replication）功能並非由主資料庫在發現資料庫異動時，將資料備份到從資料庫（如此的架構在主資料庫上需有即時監控的機制，但會大大地增加負擔），而是由從資料庫所發起，利用輪詢的方式定時地詢問主資料庫是否有異動，並將異動的資料備份到從資料庫上，複製架構的相關流程如圖5所示，詳細流程說明如下：。
 |
| ▲圖5 複製架構的相關流程。 |
(1) 當主資料庫執行相關的SQL指令時，而造成資料庫異動時，便會將相關的SQL指令，包含DDL（Data Definition Language）和DML（Data Manipulation Language），儲存在Bin Log格式的二進位日誌檔中。
(2) 從資料庫定時地發起要求，將主資料庫的Bin Log檔案內容傳遞到從資料庫的中繼日誌（Relay Log）檔案內，而後從資料庫再執行中繼日誌檔案內的SQL指令來完成與主資料庫同步的目的。
由於之前文章內容已詳盡解說過此種複製類型的做法，就不再贅述。
但是，過去所介紹的半同步複製（Semisynchronous Replication）做法有一個最大問題，那就是當複製架構失效（例如主資料庫伺服器無預警的當機），而需要重新進行失敗回復（Fail Over）時，必須得知主資料庫上在中斷前的所使用的二進位日誌檔的檔名（MASTER_LOG_FILE）以及相關偏移位置（MASTER_LOG_POS）等資訊才可正常地重新啟動複製功能。
因此，這裡將說明利用GTID（Global Transaction ID）機制的複製方法來改善上述的缺點。
GTID機制介紹
MySQL在5.6版本之後提出了一種基於交易（Transaction）基礎的複製架構。利用GTID（Global Transaction ID）機制，就能夠在不需要知道二進位日誌檔的檔名及相關偏移位置資訊時進行複製。
GTID是一個獨一無二的總體變數，由UUID+TID組成，其中UUID是資料庫伺服器的唯一代碼，可在登入資料庫伺服器後，利用「SHOW GLOBAL VARIABLES LIKE 'server_uuid';」指令來取得UUID的資訊，如圖6所示。
 |
| ▲圖6 查詢UUID的資訊。 |
而TID代表了該伺服器上已經提交（Commit）的交易數量，並且隨著交易的提交而遞增。如圖7所示，為在開啟GTID模式，並新增一筆記錄，可以發現到GTID值的變化（TID數字會累計）。
 |
| ▲圖7 開啟GTID模式，並新增一筆記錄。 |
由於GTID是基於交易基礎來進行複製，因此在MySQL官方網頁上有說明，在使用GTID進行複製時，並不建議使用非交易基礎的儲存引擎（例如myISAM），而是使用像InnoDB型式的資料庫引擎。另外，也不支援create table..select的SQL指令，以及有關於暫存表（Temporary Tables）的操作，例如create temporary。
GTID常用組態選項
在簡單的說明GTID後，接下來繼續說明GTID常用的組態選項，如下所述：
ENFORCE_GTID_CONSISTENCY
設定是否要檢查違反GTID限制的功能，提供如下的選項：
ON：開啟檢查是否違反GTID限制的功能，建議開啟此選項。
OFF：不開啟檢查是否違反GTID限制的功能。
WARN：在發現有違反GTID限制的情形時，就記錄相關的資訊。
gtid_mode
設定如何產生GTID的值，提供了如下的參數：
ON：開啟GTID模式，針對每個執行SQL指令的動作產生GTID，且設定從資料庫只會接受帶有GTID資訊的記錄。
OFF：關閉GTID模式。