深入理解MySQL5.7GTID系列(七)binlog_gtid_simple_recovery引數的影響總結
想了想還是專門開了一節來總結這個問題:
5.7.6以下中預設
simplified_binlog_gtid_recovery=flase
5.7.6以上中預設
binlog_gtid_simple_recovery=true
預設值就是最合理的設定。
因為引數名更改了所以下面統稱simple_recovery來代替。
一、Gtid關閉
simple_recovery=flase
5.7.6以下:這種方式一定得到正確的Gtid集合
重啟MySQL需要掃描全部的BINLOG來獲得正確的GTID集合
purge binlog或者超過引數expire_logs_days引數設定不觸發全BINLOG掃描,由上層函式控制。因為不支援線上的GTID更改。
5.7.6以上:這種方式一定得到正確的Gtid集合
重啟MySQL掃描全部的BINLOG。
purge binlog或者超過引數expire_logs_days引數設定觸發全BINLOG掃描。
simple_recovery=true
5.7.6以下:這種情況可能得不到正確的GTID集合
重啟Mysql不掃描全部的BINLOG,只掃描第一個和最後一個BINLOG。
purge binlog或者超過引數expire_logs_days引數設定不觸發全BINLOG掃描,由上層函式控制。
5.7.6以上:由於有每個BINLOG都有Previous gtid Event的支援能夠得到正確的GTID集合。
重啟Mysql不掃描全部的BINLOG,只掃描第一個和最後一個BINLOG。
purge binlog或者超過引數expire_logs_days引數設定不觸發全BINLOG掃描,只掃描第一個和最後一個BINLOG。
二、Gtid開啟
simple_recovery=flase
5.7.6以下:這種方式一定得到正確的GTID集合。
重啟MySQL不掃描全部的BINLOG,如果是中途開啟GTID,重啟任然需要掃描多個BINLOG因為需要找到Previous gtid Event。
purge binlog或者超過引數expire_logs_days引數設定不觸發全BINLOG掃描,如果是中途開啟GTID重啟,任然需要掃描多個BINLOG因為需要找到Previous gtid Event。
5.7.6以上:這種方式一定得到正確的GTID集合
重啟Mysql不掃秒全部的BINLOG,如果是中途開啟GTID重啟任然需要掃描多個BINLOG因為需要找到GTID EVENT。
purge binlog或者超過引數expire_logs_days引數設定不觸發全BINLOG掃描,如果是中途開啟GTID重啟任然需要掃描多個BINLOG因為需要找到GTID EVENT。
simple_recovery=true
5.7.6以下:這種情況可能得不到正確的GTID集合
重啟Mysql不掃描全部的BINLOG,只掃描第一個和最後一個BINLOG。
purge binlog或者超過引數expire_logs_days引數設定不掃描全部GTID,只掃描第一個和最後一個BINLOG。
5.7.6以上:由於有每個BINLOG都有Previous gtid Event的支援能夠得到正確的GTID集合。
重啟Mysql不掃描全部的BINLOG,只掃描第一個和最後一個BINLOG。
purge binlog或者超過引數expire_logs_days引數設定不觸發全BINLOG掃描,只掃描第一個和最後一個BINLOG。
三、本節總結
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集合,也是前面討論的。
學習完本節至少能夠學習到:
binlog_gtid_simple_recovery/simplified_binlog_gtid_recovery是如何影響BINLOG檔案的掃描的的
5.7.6以下應該如何設定
5.7.6以上應該如何設定
相關文章
- Mysql 5.7 Gtid內部學習(七) 總結binlog_gtid_simple_recovery引數帶來的影響MySql
- 深入理解Java記憶體模型(七)——總結Java記憶體模型
- 深入理解mysql引數MySql
- 深入理解javascript系列(七):閉包(1)JavaScript
- JVM 引數調整對 sortx 的影響JVM
- Java教程:影響MySQL效能的配置引數JavaMySql
- 各平臺影響oracle Process數的引數(轉)Oracle
- JavaScript引數傳遞的深入理解JavaScript
- 引數修改影響 sql version_countSQL
- 深入理解JVM(三)——配置引數JVM
- 理性遊戲設計應用指南,理解“原子引數”的運作機制和影響!遊戲設計
- table_open_cache引數對mysql效能的影響MySql
- Oracle exp中compress引數的影響測試Oracle
- ASP中函式呼叫對引數的影響 (轉)函式
- Table 引數總結
- 帶你深入理解傳遞引數
- AQS系列(七)- 終篇:AQS總結AQS
- Kafka之acks引數對訊息持久化的影響Kafka持久化
- JPEG的量化引數QP如何影響壓縮質量
- mysql事務對效率的影響分析總結JILEMySql
- 深入理解RabbitMQ中的prefetch_count引數MQ
- parallel rollback引數總結Parallel
- Table 引數總結 (ZT)
- SpringMVC中的引數繫結總結SpringMVC
- 最影響Oracle系統效能的初始化引數(zt)Oracle
- Oracle Lob型別相關引數以及效能影響Oracle型別
- 引數配置 -- 最大效能模式 dataguard 不影響Production DB .模式
- 深入剖析Redis系列(七) - Redis資料結構之列表Redis資料結構
- Flink常用的配置引數總結
- Mybatis引數處理總結MyBatis
- 實用 JVM 引數總結JVM
- 引數調整案例總結
- 關於OPcache對Swoole影響的理解opcache
- <七>深入理解new和delete的原理delete
- MySQL:slave_skip_errors引數對MGR可用性的影響MySqlError
- MySQL:Innodb:innodb_flush_log_at_trx_commit引數影響的位置MySqlMIT
- 影響資料庫效能與穩定性的幾個重要引數資料庫
- 11g MEMORY_TARGET 引數對SGA 和PGA的影響