mysql 複製

三種複製技術

二進制日誌文件 Binlog有三種格式：

Statement:基於 SQL語句級別的 Binlog,每條修改數據的 SQL都會保存到 Binlog裏。

Row:基於行級別,記錄每一行數據的變化,也就是將每行數據的變化都記錄到 Binlog 裏面, 記錄得很是詳細, 可是並不記錄原始 SQL; 在複製的時候, 並不會由於存儲過程或觸發器形成主從庫數據不一致的問通, 可是記錄的日誌量較 Statement格式要大得多 。

Mixed:混合Statement和Row模式,默認狀況下采用 Statement模式記錄,某些狀況下會切換到 Row模式

同時也對應了 MysQL複製的3種技術。

在 binlog_format設置爲 Row格式時, MySQL實際上在 Binlog中逐行記錄數據的變動, Row格式比 Statement格式更能保證從庫數據的一致性(複製的是記錄,而不是單純操做 SQL)。固然, Row格式下的 Binlog的日誌量極可能會增大很是多,在設置時須要考慮到磁盤空間間題。

參數 binlog_format能夠在全局設置或者在當前 session動態設置: 在全局設置會影響全部session,而在當前 session設置則僅僅影響當前 Session。能夠經過 SET命令來實時修改二進日誌文件(Binlog)的格式。

相關命令

查看當前複製方式

show variables like '%binlog%format%';

更改複製方式

#set global binlog_format = 'ROW';

SET SESSION binlog_format = 'ROW';

#set global binlog_format = 'STATEMENT';

SET SESSION binlog_format = 'STATEMENT';

 

在 MySQL5.5以前, MySQL的複製是異步操做,主庫和從庫的數據之間存在必定的延遲,這樣存在一個隱患:當在主庫上寫人一個事務並提交成功,而從庫還沒有獲得主庫推送的 Binlog日誌時,主庫宕機了,例如主庫可能因磁盤損壞、內存故障等形成主庫上該事務 Binlog丟失,此時從庫就可能損失這個事務,從而形成主從不一致。

而半同步複製，是等待其中一個從庫也接收到Binlog事務併成功寫入Relay Log以後，才返回Commit操做成功給客戶端；如此半同步就保證了事務成功提交後至少有兩份日誌記錄，一份在主庫Binlog上，另外一份在從庫的Relay Log上，從而進一步保證數據完整性；半同步複製很大程度取決於主從網絡RTT（往返時延），以插件 semisync_master/semisync_slave 形式存在。