【MySQL】MySQL5.6新特性之crash-safe
一 介紹
MySQL 5.6 針對複製功能提供了新特性: slave支援crash-safe. 該功能可以解決之前版本中系統異常斷電可能導致的SQL thread 資訊不準確的問題。本文從原理方面對該特性進行介紹。
二 原理
在瞭解crash-safe slave 之前,我們先分析一下MySQL 5.6 之前的版本出現 crash-unsafe 的原因。在slave上,複製包含兩個執行緒:即replication中的IO thread和SQL thread。
IO thread負責從master複製binlog檔案並儲存到本地,複製過來的binlog稱為relay-log.
SQL thread負責執行relay-log.
兩個執行緒的執行進度(偏移量)都儲存在檔案中.IO thread的執行狀態資訊儲存在master.info檔案,SQL thread的執行狀態資訊儲存在relay-log.info檔案。系統執行正常的情況下,這種模式到目前為止還沒有問題。需要注意的是這些檔案被修改後不是同步寫入磁碟的,每當系統發生crash,儲存的偏移量可能都不準確.MySQL 5.5透過兩個引數修復了該問題,使用sync_master_info=1和sync_replay_log_info=1 來保證Slave 的兩個執行緒每次寫一個事務就分別向兩個檔案同步一次 IO thread和SQL thread當前執行的資訊。當然同步操作不是免費的,頻繁更新磁碟檔案需要消耗效能,如果你的RAID裝置的IO策略設定為WRITEBACK 模式,那麼這種方法便可以接受的。
但是,即使設定了sync_master_info=1和sync_relay_info=1, 問題還是會出現,因為複製資訊是在transactions提交後寫入的,如果crash發生在事務提交和OS寫檔案之間,那麼relay-log.info就可能是錯誤的。當slave從新啟動的時候,最後那個事務可能會被執行兩次.具體的影響取決於事務的具體操作.複製可能會繼續執行比如update/delete,或者報錯 比如insert操作,此時主從資料的一致性可能會被破壞。
MySQL 5.6版本透過將複製資訊存放到表中來解決此問題.透過配置兩個引數 relay_log_info_repository=TABLE,master_info_repository=TABLE,relay log info 會存放到 mysql.slave_relay_log_info表中,master info 會存放mysql.slave_master_info表中。就是把SQL執行緒執行事務和更新mysql.slave_replay_log_info的語句看成一個事務處理,這樣就會一直同步的.
我們可以透過虛擬碼來了解crash-safe 的原理
crash-unsafe情況下 SQL_thread 的 的工作模式
crash-safe情況下 SQL_thread 的 的工作模式
crash-safe就是將relay-info.log的資訊儲存在InnoDB的事務表中,這時執行relay log中的事務和寫relay info在一個事務中,就能得到原子性保證。從而避免已執行的binlog位點和寫入relay log info 的位點資訊不一致的情況發生。看到這裡也請各位讀者思考一下 ,現在的這種方案是否完美,有哪些問題?
從上面的改變解決了SQL thread記錄執行狀態可能導致不一致的風險,但是對於IO thread 依然存在問題 。IO thread 從master上複製binlog寫入 relay log中,每個二進位制日誌由多個log event組成,所以每接收到一個log event就需要更新master-info.log而且該是寫入作業系統快取。從IO thread的工作原理來看,它沒有辦法 將寫入master info和拉取binlog放到同一個事務中而保持原子操作,因此IO thread 的行為是會對資料一致性會產生影響,設想一個log event傳送到了relay log中兩次的情形。如何解決呢?
方案一 透過引數sync_master_info可以控制fdatasync的時間。預設值是10000,表示IO執行緒的偏移量每10000個事務更新一次 ,透過設定其為1,每寫一次事務便同步到master.info 。
方案二 透過MySQL 5.5版本開始提供的引數relay_log_recovery ,當slave發生crash後重啟之後重連master時,slave不根據master-info.log的資訊進行重連,而是根據relay-info中執行到master的位置資訊重新開始拉master上的日誌資料。
三 如何使用
1 停止slave的mysql例項
2 my.cnf檔案中新增
master-info-repository=TABLE
relay-log-info-repository=TABLE
relay-log-recovery
3 重啟slave的mysql例項
注意:
如果是MySQL 5.6.5 或者更早期。slave_master_info 和 slave_relay_log_info 表預設使用MyISAM 引擎。所以還得修改成innodb,如下:
四 小結
MySQL 5.6 版本為MySQL的穩定性做出了很多改進,這點值得MySQL DBA 去關注,也值得大家去思考,這些改善點還有那些不足之處?有如何解決?
五 參考文章
1 MySQL 5.6 Manual --slave logs
2 MySQL crash-safe replication
3 Enabling crash-safe slaves with MySQL 5.6
4 MySQL5.6 crash-safe replication一個坑
5 Crash-safe Replication --推薦
6 Better Crash-safe replication for MySQL
如果您覺得從這篇文章受益,可以贊助 北在南方 一瓶飲料 ^_^
MySQL 5.6 針對複製功能提供了新特性: slave支援crash-safe. 該功能可以解決之前版本中系統異常斷電可能導致的SQL thread 資訊不準確的問題。本文從原理方面對該特性進行介紹。
二 原理
在瞭解crash-safe slave 之前,我們先分析一下MySQL 5.6 之前的版本出現 crash-unsafe 的原因。在slave上,複製包含兩個執行緒:即replication中的IO thread和SQL thread。
IO thread負責從master複製binlog檔案並儲存到本地,複製過來的binlog稱為relay-log.
SQL thread負責執行relay-log.
兩個執行緒的執行進度(偏移量)都儲存在檔案中.IO thread的執行狀態資訊儲存在master.info檔案,SQL thread的執行狀態資訊儲存在relay-log.info檔案。系統執行正常的情況下,這種模式到目前為止還沒有問題。需要注意的是這些檔案被修改後不是同步寫入磁碟的,每當系統發生crash,儲存的偏移量可能都不準確.MySQL 5.5透過兩個引數修復了該問題,使用sync_master_info=1和sync_replay_log_info=1 來保證Slave 的兩個執行緒每次寫一個事務就分別向兩個檔案同步一次 IO thread和SQL thread當前執行的資訊。當然同步操作不是免費的,頻繁更新磁碟檔案需要消耗效能,如果你的RAID裝置的IO策略設定為WRITEBACK 模式,那麼這種方法便可以接受的。
但是,即使設定了sync_master_info=1和sync_relay_info=1, 問題還是會出現,因為複製資訊是在transactions提交後寫入的,如果crash發生在事務提交和OS寫檔案之間,那麼relay-log.info就可能是錯誤的。當slave從新啟動的時候,最後那個事務可能會被執行兩次.具體的影響取決於事務的具體操作.複製可能會繼續執行比如update/delete,或者報錯 比如insert操作,此時主從資料的一致性可能會被破壞。
MySQL 5.6版本透過將複製資訊存放到表中來解決此問題.透過配置兩個引數 relay_log_info_repository=TABLE,master_info_repository=TABLE,relay log info 會存放到 mysql.slave_relay_log_info表中,master info 會存放mysql.slave_master_info表中。就是把SQL執行緒執行事務和更新mysql.slave_replay_log_info的語句看成一個事務處理,這樣就會一直同步的.
我們可以透過虛擬碼來了解crash-safe 的原理
crash-unsafe情況下 SQL_thread 的 的工作模式
-
START TRANSACTION;
-
Statement 1
-
...
-
Statement N
-
COMMIT;
- Update replication info files
-
START TRANSACTION;
-
Statement 1
-
...
-
Statement N
-
Update replication info
- COMMIT
從上面的改變解決了SQL thread記錄執行狀態可能導致不一致的風險,但是對於IO thread 依然存在問題 。IO thread 從master上複製binlog寫入 relay log中,每個二進位制日誌由多個log event組成,所以每接收到一個log event就需要更新master-info.log而且該是寫入作業系統快取。從IO thread的工作原理來看,它沒有辦法 將寫入master info和拉取binlog放到同一個事務中而保持原子操作,因此IO thread 的行為是會對資料一致性會產生影響,設想一個log event傳送到了relay log中兩次的情形。如何解決呢?
方案一 透過引數sync_master_info可以控制fdatasync的時間。預設值是10000,表示IO執行緒的偏移量每10000個事務更新一次 ,透過設定其為1,每寫一次事務便同步到master.info 。
方案二 透過MySQL 5.5版本開始提供的引數relay_log_recovery ,當slave發生crash後重啟之後重連master時,slave不根據master-info.log的資訊進行重連,而是根據relay-info中執行到master的位置資訊重新開始拉master上的日誌資料。
三 如何使用
1 停止slave的mysql例項
2 my.cnf檔案中新增
master-info-repository=TABLE
relay-log-info-repository=TABLE
relay-log-recovery
3 重啟slave的mysql例項
注意:
如果是MySQL 5.6.5 或者更早期。slave_master_info 和 slave_relay_log_info 表預設使用MyISAM 引擎。所以還得修改成innodb,如下:
-
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
- ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB
MySQL 5.6 版本為MySQL的穩定性做出了很多改進,這點值得MySQL DBA 去關注,也值得大家去思考,這些改善點還有那些不足之處?有如何解決?
五 參考文章
1 MySQL 5.6 Manual --slave logs
2 MySQL crash-safe replication
3 Enabling crash-safe slaves with MySQL 5.6
4 MySQL5.6 crash-safe replication一個坑
5 Crash-safe Replication --推薦
6 Better Crash-safe replication for MySQL
如果您覺得從這篇文章受益,可以贊助 北在南方 一瓶飲料 ^_^
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22664653/viewspace-1752588/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL5.6新特性之Multi-Range ReadMySql
- MySQL 8 新特性之Clone PluginMySqlPlugin
- MySQL 8 新特性之Invisible IndexesMySqlIndex
- MySQL 的 crash-safe 原理解析MySql
- #MySQL# mysql5.7新特性之半同步複製MySql
- MySQL 8.0 新特性MySql
- Linux安裝Mysql5.6LinuxMySql
- MySQL 8 新特性之自增主鍵的持久化MySql持久化
- MySQL5.7新特性之備份工具mysqlpump的使用MySql
- mysql5.1的新特性MySql
- MySQL8.0-新特性-DescendingIndexMySqlIndex
- Mysql5.6 自動化部署MySql
- MySQL5.6 create table原理分析MySql
- MySQL-18 MySQL8其他新特性MySql
- MySQL 8 新特性之持久化全域性變數的修改MySql持久化變數
- MySQL 5.7新特性之線上收縮undo表空間MySql
- MySQL 8.0 新特性梳理彙總MySql
- MySQL8.0-新特性彙總MySql
- mysql8.0.11新特性測試MySql
- Linux上yum安裝mysql5.6LinuxMySql
- mysql5.6 mysqldump備份報錯MySql
- MySQL5.6 PERFORMANCE_SCHEMA 說明MySqlORM
- Java 10 新特性之 AppCDSJavaAPP
- MySQL9的3個新特性MySql
- 一文看完MySQL 9.0新特性!MySql
- MySQL 8部分新特性(8.0.17)MySql
- mysql8.0新特性--隱藏索引MySql索引
- Mysql8.0部分新特性MySql
- MySQL8.0 新特性 top10MySql
- mysql5.6生成排序欄位MySql排序
- centos7 mysql5.6升級5.7CentOSMySql
- HTML5 新特性之 WebsocketHTMLWeb
- JDK8新特性之stream()JDK
- Java8新特性之:OptionalJava
- Java 8 新特性之方法引用Java
- IOS11新特性之maskedCornersiOS
- iOS 8 之後UINavigationController新特性iOSUINavigationController
- ES6 新特性之SymbolSymbol
- MySQL 8.0新特性-倒敘索引 desc indexMySql索引Index