MYSQL5.7-GTID概要翻譯

18.1.3.1 GTID concept

1.GTID的生命週期

GTID當事務在coomit flush 階段的時候會生產一個 GTID event，enent寫入binlog，flush階段最後會將整個事務的event提交給非同步的dump執行緒，從庫IO執行緒負責接受事務event，commit sync階段進行OS sync寫入binlog檔案中。從庫SQL apply這些事務event應用到從庫，GTID寫入從庫binlog並落盤

2.譯文
 

  global transaction identifier 
  每一個事務提交的回收都會在主庫上對應生成一個GTID，這個標識是唯一的，不僅是在主庫唯一，是在所有的複製集間都是唯一的。
  GTID = source_id:transaction_id
  mysqlbinlog --base64-output=DECODE-ROWS 或則在 SHOW BINLOG EVENTS的輸出內容中可以看得到。
  一旦使用了GTID我們不再需要從主庫上獲取任何本地資訊，都是直接從複製資料流中獲得。
  GTID的生命週期包括以下幾點：
  1.事務在主庫上執行然後提交
  2.在二進位制檔案傳到備庫並寫入備庫的relay日誌之後，備庫讀到gtid的值然後將它傳給gtid_next，這即是告訴備庫下一個事務需要使用這個gtid被記錄到日誌中。
  3.備庫會辨認這個gtid之前在自己記錄事務日誌的時候沒有使用過，如果沒有被使用過，slave會寫下這個gtid，應用這個事務，然後寫二進位制日誌。透過在處理事務之前首先檢查事務的gtid，
  這個不只確保了沒有相同的gtid的事務被應用過，同時也確認了沒有其他的會話已經讀取了這個gtid只是沒有提交關聯的事務而已。換句話說，多個客戶端是同時不允許應用相同的事務日誌的。
  4.因為gtid_next不為空，備庫並不嘗試為這個事務分配一個gtid而是寫已經存好的值，這樣的話，可以保證在主庫獲取gtid之後立即處理二進位制日誌中的事務。
    
     
   如果二進位制日誌是disable，gtid會和對應的transaction一起儲存到gtid_executed表裡面去
   如果log_bin=on，無論是日誌切換或則資料庫shutdown ，伺服器都會將之前二進位制日誌鮮紅的所有事務的gtid寫進新的二進位制日誌。
   如果伺服器意外停止了，之前日誌中的gtid沒有被儲存到gtid_executed中，這種情況下，恢復的時候會將其加入到表中以及系統引數gtid_executed中的。
   gtid_executed會在reset master之後被重置
     
   可以透過定期壓縮幾個事務記錄到一條記錄。透過設定 executed_gtids_compression_period 這個系統引數，可以控制幾個事務寫一次表，預設1000.
   如果二進位制日誌開啟了的話，這個引數是不生效的，每次日誌切換的時候就會壓縮這個表。
   壓縮表的執行緒是一個獨立的前臺執行緒，可以透過SELECT * FROM PERFORMANCE_SCHEMA.THREADS WHERE NAME LIKE '%gtid%'\G檢視到。
   
  18.1.3.2 使用GTID建立複製 
     1.如果已經開啟了複製，先改成read-only狀態，同步資料
     2.停止所有的伺服器
     3.在GTID模式下重啟所有的伺服器，並配置好相應的配置。server_uuid必須存在以保證正確的執行
     4.使用auto-positioning指定slave的master資料來源，然後啟動。
     5.再次在所有伺服器上開啟讀模式，讓他們可以接受更新。
     具體的步驟：
     1、ysql> SET @@global.read_only = ON;
     2、mysqladmin -uusername -p shutdown
     3、shell> mysqld --gtid-mode=ON --enforce-gtid-consistency & （ --enforce-gtid-consistency這個選項是為了保證只有對GTID模式安全的語句才會被記錄到日誌中）
     4、mysql> CHANGE MASTER TO MASTER_HOST = host, MASTER_PORT = port, MASTER_USER = user, MASTER_PASSWORD = password, MASTER_AUTO_POSITION = 1;
     5、mysql> START SLAVE;
     6、mysql> SET @@global.read_only = OFF;18.1.3.1 GTID concept
   global transaction identifier 
   每一個事務提交的回收都會在主庫上對應生成一個GTID，這個標識是唯一的，不僅是在主庫唯一，是在所有的複製集間都是唯一的。
   GTID = source_id:transaction_id
   mysqlbinlog --base64-output=DECODE-ROWS 或則在 SHOW BINLOG EVENTS的輸出內容中可以看得到。
   一旦使用了GTID我們不再需要從主庫上獲取任何本地資訊，都是直接從複製資料流中獲得。
   GTID的生命週期包括以下幾點：
   1.事務在主庫上執行然後提交
   2.在二進位制檔案傳到備庫並寫入備庫的relay日誌之後，備庫讀到gtid的值然後將它傳給gtid_next，這即是告訴備庫下一個事務需要使用這個gtid被記錄到日誌中。
   3.備庫會辨認這個gtid之前在自己記錄事務日誌的時候沒有使用過，如果沒有被使用過，slave會寫下這個gtid，應用這個事務，然後寫二進位制日誌。透過在處理事務之前首先檢查事務的gtid，
   這個不只確保了沒有相同的gtid的事務被應用過，同時也確認了沒有其他的會話已經讀取了這個gtid只是沒有提交關聯的事務而已。換句話說，多個客戶端是同時不允許應用相同的事務日誌的。
   4.因為gtid_next不為空，備庫並不嘗試為這個事務分配一個gtid而是寫已經存好的值，這樣的話，可以保證在主庫獲取gtid之後立即處理二進位制日誌中的事務。
    
     
    如果二進位制日誌是disable，gtid會和對應的transaction一起儲存到gtid_executed表裡面去
    如果log_bin=on，無論是日誌切換或則資料庫shutdown ，伺服器都會將之前二進位制日誌鮮紅的所有事務的gtid寫進新的二進位制日誌。
    如果伺服器意外停止了，之前日誌中的gtid沒有被儲存到gtid_executed中，這種情況下，恢復的時候會將其加入到表中以及系統引數gtid_executed中的。
    gtid_executed會在reset master之後被重置
     
    可以透過定期壓縮幾個事務記錄到一條記錄。透過設定 executed_gtids_compression_period 這個系統引數，可以控制幾個事務寫一次表，預設1000.
    如果二進位制日誌開啟了的話，這個引數是不生效的，每次日誌切換的時候就會壓縮這個表。
    壓縮表的執行緒是一個獨立的前臺執行緒，可以透過SELECT * FROM PERFORMANCE_SCHEMA.THREADS WHERE NAME LIKE '%gtid%'\G檢視到。
   
    18.1.3.2 使用GTID建立複製 
     1.如果已經開啟了複製，先改成read-only狀態，同步資料
     2.停止所有的伺服器
     3.在GTID模式下重啟所有的伺服器，並配置好相應的配置。server_uuid必須存在以保證正確的執行
     4.使用auto-positioning指定slave的master資料來源，然後啟動。
     5.再次在所有伺服器上開啟讀模式，讓他們可以接受更新。
     具體的步驟：
     1、mysql> SET @@global.read_only = ON;
     2、mysqladmin -uusername -p shutdown
     3、shell> mysqld --gtid-mode=ON --enforce-gtid-consistency & （ --enforce-gtid-consistency這個選項是為了保證只有對GTID模式安全的語句才會被記錄到日誌中）
     4、mysql> CHANGE MASTER TO MASTER_HOST = host, MASTER_PORT = port, MASTER_USER = user, MASTER_PASSWORD = password, MASTER_AUTO_POSITION = 1;
     5、mysql> START SLAVE;
     6、mysql> SET @@global.read_only = OFF;
     
    18.1.3.3 使用GTID實現故障切換以及擴充套件
    幾種不同的技術使用GTID 複製一個slave來實現擴充套件：
    簡單複製
    複製資料以及事務到從庫上
    注入空事務
    用gtid_purged排除事務
    恢復GTID模式的slave
    
    全域性唯一標示加到mysql複製中為了實現簡化資料流複製的日常管理以及特殊情況下的故障切換。
    每個標示都唯一標示了部分組成一個二進位制日誌事件的事務，GTID在應用改變到資料庫的過程中扮演了一個重要的角色。
    伺服器會自動跳過任何有已經被處理過的標示，這樣對自動化的複製以及準確的故障切換很關鍵。
    
    標示和構成事務的events的對應關係會記錄在二進位制日誌中，這樣會給從一個已有的伺服器中拷取資料至一個新的伺服器的過程中帶來挑戰。
    為了在新的伺服器上覆制這些標示資訊，在保持原有標示與實際的events之間的對應關係的情況下，從舊伺服器上複製標示資訊至新的伺服器上顯得至關重要了。
    這對於恢復一個可以立即用於master角色的slave很有必要。
    
    簡單複製：最簡單的複製所有的標示和事務的方法是建立一個主庫的slave，然後再所有的伺服器上都開啟全域性事務標示
    
    一旦複製開始了，新的伺服器會複製全部的主庫所有的二進位制日誌，這樣就可以獲取到所有的關係gtid的資訊。
    
    這種方式是簡單而有效的，但是要求slave去讀取master的二進位制日誌，這個步驟有時候會很長一段時間使得備庫追上主庫，
    所以這種方式不是很合適需要實現快速故障切換或則是快速恢復的場景。
   
   
    複製資料和事務至slave上：回放所有的事務會比較消耗時間，會在建立slave的時候造成瓶頸。為了解決這個，資料的快照集，主庫的二進位制日誌和全域性事務資訊對主庫來說都很重要，
    二進位制日誌是為了回放，回訪完畢之後複製便可以開始了，使得slave成為剩下事務的當前映象。
    
    使用mysqldump的時候幾個比較重要的引數列舉如下：
    --master-data
    --set-gtid-purged
    --gtid-mode=ON 
    
    
    這種方法的優勢在於基本上可以立即使用新的server，除了部分在建立快照或則恢復dump檔案的時候還在提交事務需要從主庫上獲取外。
    這意味著slave不是立即可用的，只是需要很短的一段時間以供備庫追上主庫的那一部分剩餘的事務。
    
    複製整個二進位制日誌一般會比從主庫上讀取整個事務歷史執行記錄要快。但是，由於檔案大小以及其他的一些情景，不是所有情況下都能將這些檔案複製至備庫，
    
    注入空事務：全域性引數 gtid_executed  包括一套所有在主庫上執行的事務。你可以在伺服器上標記gtid_executed而不是在建立快照的時候複製二進位制日誌。在新增新的伺服器至複製鏈上的時候，
    為每個事務標示簡單的提交一個空事務，像這樣：
    SET GTID_NEXT='aaa-bbb-ccc-ddd:N';
    BEGIN;
    COMMIT;
    SET GTID_NEXT='AUTOMATIC';
    
    一旦所有的事務標示都透過這種方式得以恢復，你必須flush和pruge備庫的二進位制日誌，向這裡這樣，只是N是一個非0字首的二進位制檔名。
    FLUSH LOGS;
    PURGE BINARY LOGS TO 'master-bin.00000N';
    
    你應該做這個操作為了阻止這臺伺服器執行錯誤的待會才會在主庫上應用的事務，flush logs語句強制建立一個新的二進位制日誌檔案，purge binary logs清除了空的事務，但是保留了他們的標示。
    
    排除gtid_purge的事務：基於在建立了快照的伺服器上的gtid_executed，你可以在備庫上設定gtid_purge
    恢復gtid模式下的slave：使用mysqlbinlog找到下一個event，也許是下一個日誌檔案的第一個event。
    mysql> DELIMITER ;
    Restart replication from the correct position automatically: 
    mysql> SET GTID_NEXT=automatic; 
    mysql> RESET SLAVE; 
    mysql> START SLAVE;