簡書地址：
http://www.jianshu.com/p/c9888d6447c8

想了想還是專門開了一節(jié)來總結這個問題
5.7.6以下中默認

雷州ssl適用于網站、小程序/APP、API接口等需要進行數據傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)公司的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

• simplified_binlog_gtid_recovery=flase

5.7.6以上中默認

• binlog_gtid_simple_recovery=true

默認值就是最合理的設置。
因為參數名更改了所以下面統(tǒng)稱simple_recovery來代替。

一、Gtid關閉

---

• simple_recovery=flase

5.7.6以下：這種方式一定得到正確的Gtid集合

• 重啟MySQL需要掃描全部的binlog來獲得正確的Gtid集合
• purge binlog或者超過參數expire_logs_days參數設置不觸發(fā)全binlog掃描，由上層函數控制。因為不支持在線的Gtid更改。

5.7.6以上：這種方式一定得到正確的Gtid集合

• 重啟Mysql掃描全部的binlog。
• purge binlog或者超過參數expire_logs_days參數設置觸發(fā)全binlog掃描。

---

• simple_recovery=true

5.7.6以下:這種情況可能得不到正確的Gtid集合

• 重啟Mysql不掃描全部的binlog，只掃描第一個和最后一個binlog。
• purge binlog或者超過參數expire_logs_days參數設置不觸發(fā)全binlog掃描，由上層函數控制。

5.7.6以上:由于有每個binlog都有Previous gtid Event的支持能夠得到正確的Gtid集合。

• 重啟Mysql不掃描全部的binlog，只掃描第一個和最后一個binlog。
• purge binlog或者超過參數expire_logs_days參數設置不觸發(fā)全binlog掃描，只掃描第一個和最后一個binlog。

二、Gtid打開

---

• simple_recovery=flase

5.7.6以下:這種方式一定得到正確的Gtid集合。

• 重啟Mysql不掃描全部的binlog，如果是中途打開GTID，重啟任然需要掃描多個binlog因為需要找到Previous gtid Event。
• purge binlog或者超過參數expire_logs_days參數設置不觸發(fā)全binlog掃描，如果是中途打開GTID重啟，任然需要掃描多個binlog因為需要找到Previous gtid Event。

5.7.6以上:這種方式一定得到正確的Gtid集合

• 重啟Mysql不掃秒全部的binlog，如果是中途打開GTID重啟任然需要掃描多個binlog因為需要找到Gtid event。
• purge binlog或者超過參數expire_logs_days參數設置不觸發(fā)全binlog掃描，如果是中途打開GTID重啟任然需要掃描多個binlog因為需要找到Gtid event。

---

• simple_recovery=true

5.7.6以下:這種情況可能得不到正確的Gtid集合

• 重啟Mysql不掃描全部的binlog，只掃描第一個和最后一個binlog。
• purge binlog或者超過參數expire_logs_days參數設置不掃描全部binlog，只掃描第一個和最后一個binlog。

5.7.6以上:由于有每個binlog都有Previous gtid Event的支持能夠得到正確的Gtid集合。

• 重啟Mysql不掃描全部的binlog，只掃描第一個和最后一個binlog。
• purge binlog或者超過參數expire_logs_days參數設置不觸發(fā)全binlog掃描，只掃描第一個和最后一個binlog。

三、本節(jié)總結

• 5.7.6以下保持默認設置simplified_binlog_gtid_recovery=flase，但是這會導致過多的binlog掃描，況且5.6沒有mysql.gtid_executed的支持，從庫必須開啟log_slave_updates，這會帶來性能影響。所以還是少用Gtid。
• 5.7.6以上由于對每個binlog都有Previous gtid Event的支持binlog_gtid_simple_recovery=true是合理的設置，binlog掃描非常的快因為只是第一個和最后一個binlog文件而已。

可以看到Gtid也越來越成熟了。這部分的邏輯在函MYSQL_BIN_LOG::init_gtid_sets中前文已經提到過，這里就不看代碼了。

此外在5.7的官方文檔中對binlog_gtid_simple_recovery=true 有如下警告的描述：

If this option is enabled, gtid_executed and gtid_purged may be
initialized incorrectly in the following situations:
? The newest binary log was generated by MySQL 5.7.5 or older, and
gtid_mode was ON for some binary logs but OFF for the newest binary log.
? A SET GTID_PURGED statement was issued on a MySQL version
prior to 5.7.7, and the binary log that was active at the time of the SET
GTID_PURGED has not yet been purged.
If an incorrect GTID set is computed in either situation, it will remain incorrect
even if the server is later restarted, regardless of the value of this option. 

如果將參數設置為true可能在老版本中得不到正確的Gtid集合，也是前面討論的。

學習完本節(jié)至少能夠學習到：

• binlog_gtid_simple_recovery/simplified_binlog_gtid_recovery是如何影響binlog文件的掃描的的
• 5.7.6以下應該如何設置
• 5.7.6以上應該如何設置

作者微信：

本文標題：Mysql5.7Gtid內部學習(七)總結binlog_gtid_simple_recovery參數帶來的影響
URL標題：http://www.chinadenli.net/article4/ppjhoe.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供外貿建站、網站導航、響應式網站、搜索引擎優(yōu)化、做網站、網站建設

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)