在實(shí)例存活的情況，可以在實(shí)例狀態(tài)中查詢ALL_GTID。

在實(shí)例崩潰的情況，無法在實(shí)例狀態(tài)中查詢ALL_GTID。可以通過查詢BINLOG中的Previous-GTIDs計(jì)算來獲得ALL_GTID。

下面列舉與ALL_GTID相關(guān)的變量。

與ALL_GTID相關(guān)的變量

Previous-GTIDs

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

查看新輪轉(zhuǎn)出的BINLOG：

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

請點(diǎn)擊輸入圖片描述

然后再次flush binary logs:

請點(diǎn)擊輸入圖片描述

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

請點(diǎn)擊輸入圖片描述

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

請點(diǎn)擊輸入圖片描述

全局變量中的GTID相關(guān)的變量

請點(diǎn)擊輸入圖片描述

變量解釋:

gtid_executed?代表著server上所有事務(wù)執(zhí)行產(chǎn)生的GTID(包含已經(jīng)被purge的BINLOG中的GTID或者是手動(dòng)set gtid_purged的GTID)。

gtid_purged?代表著已經(jīng)被purge到的GTID。gtid_purged是gtid_executed的子集。

gtid_retrieved?是從機(jī)上relay_log中的GTID。

ALL_GTID 的計(jì)算

了解了GTID相關(guān)的變量之后，可以得到獲得實(shí)例的All_GTID的集合的方法：

對象

方法

存活的Master實(shí)例 ? ?gtid_executed

存活的Slave實(shí)例 ? ?gtid_executed和gtid_retrieved的并集

非存活Master實(shí)例 ? ?最后一個(gè)BINLOG文件的Previous-GTIDs + 最后一個(gè)BINLOG文件中所有的GTID

非存活Slave實(shí)例 ? ?最后一個(gè)BINLOG文件的Previous-GTIDs + 最后一個(gè)BINLOG文件中所有的GTID

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

生產(chǎn)中我們使用Xtrabackup來產(chǎn)生一個(gè) 從實(shí)例 的流程如下：

拉取備份，進(jìn)行還原

change master to

set @@global.gtid_purged='xxx';

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

將 從實(shí)例 的ALL_GTID手工置為xxx, 在通過GTID方式建立復(fù)制時(shí)不會(huì)出錯(cuò).

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

MySQL 5.7中set gtid_purged的行為變更

問題描述

回顧一下備份恢復(fù)的流程:

拉取備份，進(jìn)行還原

change master to

set @@global.gtid_purged='xxx';

現(xiàn)象: 發(fā)現(xiàn)有一臺(tái)MySQL 5.7的Slave服務(wù)器恢復(fù)后沒有產(chǎn)生 正確的Previous-GTIDs。

分析

分析整個(gè)過程，解決問題應(yīng)該分階段進(jìn)行手動(dòng)模擬發(fā)現(xiàn)問題。以下為詳細(xì)步驟：

手工還原備份

環(huán)境

BINLOG數(shù)量，Previous-GTIDs狀態(tài)

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，空

可見: 恢復(fù)過程不會(huì)輪轉(zhuǎn)BINLOG。

驗(yàn)證change master和set gtid_purged在不同的MySQL版本中執(zhí)行的差異

環(huán)境

BINLOG數(shù)量，Previous-GTIDs狀態(tài)

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，空

可見: 執(zhí)行set gtid_purged時(shí)不同版本的MySQL產(chǎn)生了差異

驗(yàn)證

對不同版本MySQL單獨(dú)執(zhí)行set @@global.gtid_purged='';語句。檢查結(jié)果

環(huán)境

進(jìn)行的操作

BINLOG數(shù)量，Previous-GTIDs狀態(tài)

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

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

結(jié)論

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

官方解釋: 在5.7版本中，執(zhí)行SET GTID_PURGED語句后binlog_simple_gtid_recovery會(huì)給GTID_PURGED計(jì)算出一個(gè)錯(cuò)誤的值。

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

而5.6版本中會(huì)進(jìn)行BINLOG輪轉(zhuǎn)和向Previous_gtids_log_event中添加GTID。如果5.7需要產(chǎn)生和5.6相同結(jié)果的話，可以在SET GTID_PURGED語句后手動(dòng)執(zhí)行flush binary logs語句。

與50位技術(shù)專家面對面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的mysql数据库备份出错_mysql数据库备份成功，再还原却失败，什么原的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。