在實例存活的情況，可以在實例狀態中查詢ALL_GTID。

在實例崩潰的情況，無法在實例狀態中查詢ALL_GTID。可以通過查詢BINLOG中的Previous-GTIDs計算來獲得ALL_GTID。

下面列舉與ALL_GTID相關的變量。

與ALL_GTID相關的變量

Previous-GTIDs

Previous-GTIDs格式如下(環境為MySQL5.7，日志手動flush binary logs獲得)：

查看新輪轉出的BINLOG：

下面為mysql-bin.00001中包含的GTID：

請點擊輸入圖片描述

然后再次flush binary logs:

請點擊輸入圖片描述

mysql-bin.00002中是沒有任何GTID的。

請點擊輸入圖片描述

綜上Previous-GTIDs是本身這個BINLOG文件前面的所有BINLOG的集合。

請點擊輸入圖片描述

全局變量中的GTID相關的變量

請點擊輸入圖片描述

變量解釋:

gtid_executed?代表著server上所有事務執行產生的GTID(包含已經被purge的BINLOG中的GTID或者是手動set gtid_purged的GTID)。

gtid_purged?代表著已經被purge到的GTID。gtid_purged是gtid_executed的子集。

gtid_retrieved?是從機上relay_log中的GTID。

ALL_GTID 的計算

了解了GTID相關的變量之后，可以得到獲得實例的All_GTID的集合的方法：

對象

方法

存活的Master實例 ? ?gtid_executed

存活的Slave實例 ? ?gtid_executed和gtid_retrieved的并集

非存活Master實例 ? ?最后一個BINLOG文件的Previous-GTIDs + 最后一個BINLOG文件中所有的GTID

非存活Slave實例 ? ?最后一個BINLOG文件的Previous-GTIDs + 最后一個BINLOG文件中所有的GTID

在獲得非存活實例中的ALL_GTID時，最后一個BINLOG文件中的GTID可能不連續(比如事務同時來自于本實例客戶端和復制回放)，所以需要掃描最后一個BINLOG文件。

生產中我們使用Xtrabackup來產生一個 從實例 的流程如下：

拉取備份，進行還原

change master to

set @@global.gtid_purged='xxx';

set @@global.gtid_purged='xxx';?的影響:

將 從實例 的ALL_GTID手工置為xxx, 在通過GTID方式建立復制時不會出錯.

將更新Binlog中記錄的Previous-GTIDs (由于Binlog不可改變, 將產生新的Binlog, 記錄新的Previous-GTIDs).

MySQL 5.7中set gtid_purged的行為變更

問題描述

回顧一下備份恢復的流程:

拉取備份，進行還原

change master to

set @@global.gtid_purged='xxx';

現象: 發現有一臺MySQL 5.7的Slave服務器恢復后沒有產生 正確的Previous-GTIDs。

分析

分析整個過程，解決問題應該分階段進行手動模擬發現問題。以下為詳細步驟：

手工還原備份

環境

BINLOG數量，Previous-GTIDs狀態

Xtrabackup 2.4.2 & MySQL 5.6 ? ?1，空

Xtrabackup 2.4.2 & MySQL 5.7 ? ?1，空

Xtrabackup 2.2.9 & MySQL 5.6 ? ?1，空

Xtrabackup 2.2.9 & MySQL 5.7 ? ?1，空

可見: 恢復過程不會輪轉BINLOG。

驗證change master和set gtid_purged在不同的MySQL版本中執行的差異

環境

BINLOG數量，Previous-GTIDs狀態

change master?& MySQL 5.6 ? ?1，空

change master?& MySQL 5.7 ? ?1，空

set gtid_purged?& MySQL 5.6 ? ?2，正常

set gtid_purged?& MySQL 5.7 ? ?1，空

可見: 執行set gtid_purged時不同版本的MySQL產生了差異

驗證

對不同版本MySQL單獨執行set @@global.gtid_purged='';語句。檢查結果

環境

進行的操作

BINLOG數量，Previous-GTIDs狀態

MySQL 5.7 ? ?reset master; set @@global.gtid_purged=”; ? ?1，空

MySQL 5.6 ? ?reset master; set @@global.gtid_purged=”; ? ?2，正常

結論

參考: http://bugs.mysql.com/bug.php?id=75767

官方解釋: 在5.7版本中，執行SET GTID_PURGED語句后binlog_simple_gtid_recovery會給GTID_PURGED計算出一個錯誤的值。

由于5.7中新增了存儲GTID的表。所以5.7版本中set @@global.gtid_purged='';語句被改成只修改存放GTID的表。

而5.6版本中會進行BINLOG輪轉和向Previous_gtids_log_event中添加GTID。如果5.7需要產生和5.6相同結果的話，可以在SET GTID_PURGED語句后手動執行flush binary logs語句。

總結

以上是生活随笔為你收集整理的mysql gtid 备份恢复_MYSQL数据库备份恢复的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。