GTID的基本知識有哪些

這篇文章主要介紹“GTID的基本知識有哪些”，在日常操作中，相信很多人在GTID的基本知識有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”GTID的基本知識有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

一、GTID的基本知識
GTID的概念：
在源（主）服務器上提交的每個事務，將創建和其相關聯的唯一標識符的全局事物標識符。
此標識符不但是唯一的，而且在所有的復制從庫中都是唯一的。所有事物和所有GTID之間都有一對一的映射關系。
GTID的基本描述：
 GTID表示為一對坐標，用冒號（:)分隔，如下所示：
  GTID = source_id:transaction_id。
source_id標識源服務器。通常，服務器的server_uuid用于此目的。
transaction_id是一個序列號，由該服務器上的事務提交順序決定;   
例如，要提交的第一個事務具有1作為其transaction_id，并且要在同一源務器上提交的第十個事務被分配了10作為transaction_id。
一個事務在一個GTID中不能有0作為序列號。
例如，原來在server_uuid等于3E11FA47-71CA-11E1-9E33-C80AA9429562服務器上提交的第二十三個事務具有這個GTID：
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
這種格式用于表示語句的輸出中的GTID，例如SHOW SLAVE STATUS以及二進制日志
可以使用語句來查看UUID
show variables like '%UUID%';
正如在SHOW MASTER STATUS或SHOW SLAVE STATUS等語句的輸出中所寫的，源自同一服務器的GTID序列可能會被合并為單個表達式，如下所示：
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
上面顯示的示例表示源自MySQL服務器的第一個到第五個事務，其server_uuid是3E11FA47-71CA-11E1-9E33-C80AA9429562。
該格式也用于提供START SLAVE選項SQL_BEFORE_GTIDS和SQL_AFTER_GTIDS所需的參數。
GTID集以幾種方式在MySQL服務器中使用。例如，由gtid_executed和gtid_purged系統變量存儲的值表示為GTID集合。
另外，函數GTID_SUBSET（）和GTID_SUBTRACT（）需要GTID集作為輸入。當從庫變量返回GTID集合時，UUID按字母順序排列，數字區間按照升序排列。
GTID總是保存在主從之間。這意味著可以通過檢查二進制日志來確定應用于任何從庫的任何事務的來源。 另外，一旦給定GTID的事務在給定的服務器上被提交，任何具有相同GTID的后續事務都被該服務器忽略。因此，在主站上提交的事務不能在從站上應用一次，這有助于保證一致性。
當使用GTID時，從庫不需要任何非本地數據，例如主庫上文件的名稱和該文件中的位置。所有用于與主庫同步的必要信息都直接從復制數據流中獲取。 GTID替換之前所需的文件偏移對，以確定在主庫和從庫之間啟動，停止或恢復數據流的點。因此，在CHANGE MASTER TO語句中不要包含MASTER_LOG_FILE或MASTER_LOG_POS選項，該語句用于引導從庫從給定主庫復制;相反，開啟gtid之后，只需要啟用MASTER_AUTO_POSITION選項。有關使用基于GTID的復制配置和啟動主庫和從、庫所需的確切步驟。GTID的生成和生命周期由以下步驟組成：
1）事務在主服務器上執行并提交。
使用主庫的UUID和此庫上尚未使用的最小非零事務序列號為該事務分配一個GTID; GTID被寫入到master的二進制日志中（直接在日志中的事務本身之前）。
2）二進制日志數據傳輸到從庫并存儲在從庫的中繼日志中，從庫讀取GTID并將其gtid_next系統變量的值設置為此GTID。這告訴備庫，下一個事務必須使用這個GTID記錄。需要注意的是，slave在會話上下文中設置gtid_next。
3）從庫驗證這個GTID是否已經被用來在自己的二進制日志中記錄事務。 如果這個GTID沒有被使用，那么從設備寫入GTID，應用事務并將事務寫入其二進制日志。
通過首先讀取和檢查事務的GTID，在處理事務本身之前，從庫不僅保證在從庫上沒有應用具有此GTID的先前事務，而且還確保沒有其他會話已經讀取了該GTID但尚未提交相關的交易。換句話說，多個客戶端不允許同時應用相同的事務。
4）因為gtid_next不為空，所以從庫不會為這個事務生成一個GTID，而是把存儲在這個變量中的GTID，也就是從它的二進制日志中事務之前立即從主機獲得的GTID寫入。

mysql.gtid_executed表
從MySQL 5.7.5開始，GTID被存儲在mysql數據庫中名為gtid_executed的表中。
對于每個GTID或其代表的一組GTID，該表中的一行包含源服務器的UUID以及該組的起始和結束事務ID; 對于僅引用單個GTID的行，這兩個值是相同的。
當安裝或升級MySQL服務器時，會使用CREATE TABLE語句創建mysql.gtid_executed表（如果它尚不存在）
WARNING：與其他MySQL系統表一樣，不要試圖自己創建或修改這個表。
mysql.gtid_executed表允許在從庫上禁用二進制日志記錄時使用GTID，并且在二進制日志丟失時保留GTID歷史記錄。
只有當gtid_mode為ON或ON_PERMISSIVE時，GTID才存儲在mysql.gtid_executed表中。GTID的存儲點取決于是否啟用二進制日志記錄：
1）如果禁用二進制日志記錄（log_bin為OFF），或者如果log_slave_updates被禁用，則服務器將屬于每個事務的GTID與事務一起存儲在表中。
另外，表以用戶可配置的速率周期性壓縮;這種情況只適用于禁用二進制日志記錄或從庫更新日志記錄的復制從庫。
它不適用于復制主庫，因為在主庫上，必須啟用二進制日志記錄才能進行復制。
2）如果啟用了二進制日志記錄（log_bin為ON），則無論何時二進制日志被輪換或服務器關閉，服務器都將寫入前一個二進制日志的所有事務的GTID寫入mysql.gtid_executed表。
這種情況適用于啟用二進制日志記錄的復制主節點或復制從節點。
在服務器意外停止的情況下，當前二進制日志中的GTID集不會保存在mysql.gtid_executed表中。在這種情況下，這些GTID將在恢復過程中添加到表中，并添加到gtid_executed系統變量中的一組GTID中。
啟用二進制日志記錄時，mysql.gtid_executed表不會為所有已執行的事務提供完整的GTID記錄。該信息由gtid_executed系統變量的全局值提供。
mysql.gtid_executed表由RESET MASTER歸零。

mysql.gtid_executed表壓縮
隨著時間的推移，mysql.gtid_executed表可能會被許多行填充，這些行涉及到來自同一臺服務器的單個GTID，并且其事務ID構成一個序列
如果通過用跨越事務標識符的整個間隔的單個行替換每個這樣的行集合來周期性地壓縮該表格，則可以節省相當大的空間
啟用GTID時，服務器會定期在mysql.gtid_executed表上執行這種類型的壓縮。您可以通過設置execution_gtids_compression_period系統變量來控制在表壓縮之前允許經過的事務數，從而控制壓縮率。
這個變量的默認值是1000; 這意味著，默認情況下，表格的壓縮在每1000個事務之后執行。將execution_gtid_compression_period設置為0將阻止完全執行壓縮; 但是，如果執行此操作，則應該為gtid_executed表可能需要的磁盤空間大量增加做好準備。
對mysql.gtid_executed表的壓縮由名為thread/sql/compress_gtid_table的專用前臺線程執行。此線程未在SHOW PROCESSLIST的輸出中列出，但可以在線程表中查看該行，如下所示：
SELECT * FROM performance_schema.threads WHERE NAME LIKE '%gtid%'\G
thread/sql/compress_gtid_table線程通常會休眠，直到execution_gtids_compression_period事務被執行，然后喚醒以執行前面所述的對mysql.gtid_executed表的壓縮。 然后休眠，直到另一個execution_gtids_compression_period事務發生，然后醒來再次執行壓縮，無限期地重復這個循環。 禁用二進制日志記錄時將此值設置為0意味著線程始終處于睡眠狀態，永遠不會喚醒。

普通復制模式切換為gtid模式，在5.6環境只能冷操作，5.7環境可在線操作
二.1、在主從復制中使用GTID（5.6環境冷操作）
最簡單的GTID復制拓撲的啟動過程中的關鍵步驟（由一個主庫和一個從庫組成）如下所示：
1）如果復制已經在運行，則通過將它們設置為只讀來同步這兩個服務器。
2）停止兩臺服務器。
3）重新啟動兩臺服務器并啟用GTID并配置正確的選項。
4）指示從服務器使用主服務器作為復制數據源并使用自動定位。完成這一步所需的SQL語句在本節后面的例子中描述。
5）采取新的備份。包含沒有GTID的交易的二進制日志不能在啟用了GTID的服務器上使用，因此在此點之前進行的備份不能用于新配置。
6）啟動從服務器，然后在兩臺服務器上再次禁用只讀模式，以便他們可以接受更新。
具體過程：
1，主庫設置為read_only，使從庫追上主庫
2，主從都關閉MySQL服務
3，主從都在my.cnf文件中配置gtid的啟動參數
gtid_mode=ON
enforce-gtid-consistency=true
4，從庫使用skip-slave-start啟動MySQL服務
從庫使用MASTER_AUTO_POSITION = 1。配置主從
CHANGE MASTER TO
    MASTER_HOST = 'host',
    MASTER_PORT = port,
    MASTER_USER = 'user',
    MASTER_PASSWORD = 'password',
    MASTER_AUTO_POSITION = 1;
MASTER_LOG_FILE選項和MASTER_LOG_POS選項都不能與MASTER_AUTO_POSITION設置為1一起使用
5，采取gtid之后，需要做一個新的備份，因為開啟gtid之前做的備份不可用了
例如，您可以在執行備份的服務器上執行FLUSH LOGS。 然后，明確地進行備份，或者等待您可能已經設置的任何定期備份例程的下一次迭代。
6，從庫開啟主從
主庫關閉
Using GTIDs for Failover and Scaleout
將全局事務標識符（GTID）用于MySQL復制時，有許多技術用于配置新的從站，然后可用于擴展，并根據故障轉移的需要提升為主站。本節介紹以下技術：
簡單的復制
     將數據和事務復制到從站
     注入空的交易
     排除與gtid_purged的交易
     恢復GTID模式從站
全局事務標識符被添加到MySQL復制中，以便簡化對復制數據流和特別是故障轉移活動的一般管理。 每個標識符唯一標識一組構成一個事務的二進制日志事件。 GTID在對數據庫進行更改時扮演著重要的角色：服務器會自動跳過任何具有服務器識別為之前處理過的標識符的事務。 此行為對于自動復制定位和正確的故障轉移至關重要。
在二進制日志中捕獲標識符和包含給定事務的事件集合之間的映射。 使用來自其他現有服務器的數據供應新服務器時，這帶來了一些挑戰。 為了再現在新服務器上設置的標識符，需要將標識符從舊服務器復制到新服務器，并保持標識符與實際事件之間的關系。 這對于恢復作為候選者立即可用的從站成為故障切換或切換的新主站是必要的。
簡單的復制。在新服務器上重現所有標識符和事務的最簡單方法是將新服務器變為具有全部執行歷史記錄的主服務器的從服務器，并在兩臺服務器上啟用全局事務標識符。
一旦復制啟動，新的服務器將從主服務器復制整個二進制日志，從而獲得有關所有GTID的所有信息。
該方法簡單有效，但要求從機從主機讀取二進制日志; 有時需要較長的時間才能使新的從機跟上主機，所以這種方法不適用于快速故障切換或備份恢復。 本節介紹如何通過將二進制日志文件復制到新服務器來避免從主服務器獲取所有執行歷史記錄。
將數據和事務復制到從站。 當源服務器先前已經處理了大量的事務時，執行整個事務歷史可能是耗時的，而這可能是設置新復制從服務器時的主要瓶頸。 為了消除這種需求，可以將源服務器包含的數據集，二進制日志和全局事務信息的快照導入到新的從服務器。 源服務器可以是主服務器，也可以是從服務器，您必須確保源在復制數據之前處理了所有必需的事務。

二.2  在主從復制中使用GTID（5.7環境在線操作）
1.在每臺服務器上執行:
 SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;
2.在每臺服務器上執行:
 SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
3.在每臺服務器上執行:
 SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
4.在每臺服務器上執行:
 SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
5.在每臺服務器上,等到狀態變量ONGOING_ANONYMOUS_TRANSACTION_COUNT為零，可以使用下面的語句查詢:
 SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
在復制從屬設備上，理論上可能的是，它顯示為零，然后再次為非零。這不是問題，只要一次顯示零即可。
6. 等到第5步生成的所有事務復制到所有服務器，您可以在不停止更新的情況下執行此操作：唯一重要的是所有匿名事務都被復制。
7.如果您使用二進制日志來進行復制以外的任何其他操作（例如，即時備份和還原），請等到您不需要具有沒有GTID的事務的舊的二進制日志。
例如，在步驟6完成之后，您可以在執行備份的服務器上執行FLUSH LOGS。 然后，明確地進行備份，或者等待您設置的任何定期備份例程的下一次迭代。
理想情況下，等待服務器清除第6步完成時存在的所有二進制日志。 還等待在步驟6之前進行的任何備份過期。
Important--沒回頭路了
這是第二重要的一點。 理解包含匿名事務的二進制日志，而不使用GTIDs在下一步之后不能使用是非常重要的。 完成此步驟之后，您必須確保沒有GTID的事務不存在于拓撲中的任何位置。
8.在每臺服務器上執行:
SET @@GLOBAL.GTID_MODE = ON;
9.在每臺服務器上, 在my.cnf參數文件中添加gtid-mode=ON
gtid_mode=ON
#log_slave_updates=1
enforce-gtid-consistency=1
10.change master-從庫
STOP SLAVE [FOR CHANNEL 'channel'];
CHANGE MASTER TO MASTER_AUTO_POSITION = 1 [FOR CHANNEL 'channel'];
START SLAVE [FOR CHANNEL 'channel'];

二.3 在主從復制中關閉GTID（MySQL 5.7.6或更高版本 環境在線操作）
1.在每個從站上執行以下操作，如果使用多源復制，請為每個通道執行此操作，并包含FOR CHANNEL通道子句
語法：
STOP SLAVE [FOR CHANNEL 'channel'];
CHANGE MASTER TO MASTER_AUTO_POSITION = 0, MASTER_LOG_FILE = file, MASTER_LOG_POS = position [FOR CHANNEL 'channel'];
START SLAVE [FOR CHANNEL 'channel'];
使用MASTER_LOG_FILE和MASTER_LOG_POS開啟主從
CHANGE MASTER TO
MASTER_AUTO_POSITION = 0,
MASTER_LOG_FILE = 'mysql-bin.000008',
MASTER_LOG_POS = 677786318;
2.在每臺服務器上執行:
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
3.在每臺服務器上執行:
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
4.在每個服務器上，等待變量@@ GLOBAL.GTID_OWNED等于空字符串。 這可以使用以下方法檢查：
SELECT @@GLOBAL.GTID_OWNED;
在復制從機上，理論上可能這是空的，然后又是非空的。 這不是一個問題，只要它是空的就足夠了。
5.等待任何二進制日志中當前存在的所有事務復制到所有從站。 有關檢查所有匿名事務已復制到所有服務器的方法。
6.如果您將二進制日志用于除復制以外的其他任何操作，例如執行時間點備份或還原：請等到您不需要具有GTID事務的舊的二進制日志。
例如，在步驟5完成之后，您可以在要備份的服務器上執行FLUSH LOGS。然后，明確地進行備份，或者等待您設置的任何定期備份例程的下一次迭代。
理想情況下，等待服務器清除第5步完成時存在的所有二進制日志。等待第5步之前的備份過期。
重要
這是這個程序中的一個重點。理解包含GTID事務的日志在下一步之后不能使用是很重要的。在繼續之前，您必須確定GTID事務不存在于拓撲中的任何地方。
7.在每臺服務器上執行:
SET @@GLOBAL.GTID_MODE = OFF;
8.在每臺服務器上, 在my.cnf參數文件中注釋掉gtid-mode相關的參數
#gtid_mode=ON
#log_slave_updates=1
#enforce-gtid-consistency=1

到此，關于“GTID的基本知識有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！