MySQL5.6新特性之crash-safe
2024-07-24 13:00:23
供稿：網友
一 介紹 MySQL 5.6 針對復制功能提供了新特性: slave支持crash-safe. 該功能可以解決之前版本中系統(tǒng)異常斷電可能導致的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負責執(zhí)行relay-log.兩個線程的執(zhí)行進度(偏移量)都保存在文件中.IO thread的執(zhí)行狀態(tài)信息保存在master.info文件,SQL thread的執(zhí)行狀態(tài)信息保存在relay-log.info文件。系統(tǒng)運行正常的情況下，這種模式到目前為止還沒有問題。需要注意的是這些文件被修改后不是同步寫入磁盤的,每當系統(tǒng)發(fā)生crash,存儲的偏移量可能都不準確.MySQL 5.5通過兩個參數修復了該問題,使用sync_master_info=1和sync_replay_log_info=1 來保證Slave 的兩個線程每次寫一個事務就分別向兩個文件同步一次 IO thread和SQL thread當前執(zhí)行的信息。當然同步操作不是免費的,頻繁更新磁盤文件需要消耗性能,如果你的RAID設備的IO策略設置為WRITEBACK 模式,那么這種方法便可以接受的。 但是,即使設置了sync_master_info=1和sync_relay_info=1, 問題還是會出現，因為復制信息是在transactions提交后寫入的,如果crash發(fā)生在事務提交和OS寫文件之間，那么relay-log.info就可能是錯誤的。當slave從新啟動的時候,最后那個事務可能會被執(zhí)行兩次.具體的影響取決于事務的具體操作.復制可能會繼續(xù)運行比如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線程執(zhí)行事務和更新mysql.slave_replay_log_info的語句看成一個事務處理,這樣就會一直同步的.我們可以通過偽代碼來了解crash-safe 的原理crash-unsafe情況下 SQL_thread 的 的工作模式START TRANSACTION; Statement 1 ... Statement N COMMIT;Update replication info filescrash-safe情況下 SQL_thread 的 的工作模式START TRANSACTION; Statement 1 ... Statement N Update replication infoCOMMITcrash-safe就是將relay-info.log的信息保存在InnoDB的事務表中，這時執(zhí)行relay log中的事務和寫relay info在一個事務中，就能得到原子性保證。從而避免已執(zhí)行的binlog位點和寫入relay log info 的位點信息不一致的情況發(fā)生。看到這里也請各位讀者思考一下 ，現在的這種方案是否完美，有哪些問題？ 從上面的改變解決了SQL thread記錄執(zhí)行狀態(tài)可能導致不一致的風險，但是對于IO thread 依然存在問題 。IO thread 從master上拷貝binlog寫入 relay log中,每個二進制日志由多個log event組成，所以每接收到一個log event就需要更新master-info.log而且該是寫入操作系統(tǒng)緩存。從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發(fā)生crash后重啟之后重連master時，slave不根據master-info.log的信息進行重連，而是根據relay-info中執(zhí)行到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的穩(wěn)定性做出了很多改進，這點值得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
