MySQL主從複製
一.bin log日誌
它記錄數據庫所有執行的DDL和DML等數據庫更新事件的語句，但不包含沒有修改任何數據的語句(select，show等)。
應用場景：
- 用於數據恢復：數據庫宕機，可以使用該日誌進行恢復。
- 用於數據複製：主節點發送數據到從節點。
寫入機制：事務開始的時候，先把日誌寫到binlog cache中，事務提交，再刷新到bin log文件中。
刷盤策略：參數：sync_binlog
- 0：默認，每次提交事務都會刷新到page cache中，什麼時候刷到磁盤由操作系統決定。
- 1：每次提交事務會同時刷到page cache和磁盤。
- n：每次提交事務都會write，積累到n個事務之後才fsync。
與redo log 的區別？
- redo log是物理日誌，記錄數據做了什麼修改。比如哪條數據改為多少了。
- bin log是邏輯日誌，記錄原生的SQL語句。
- redo log為了數據庫宕機恢複數據
- bin log是為了保持主從一致
兩階段提交
- 引出問題：redo log如果已經完成，寫bin log 的時候服務器宕機了(redo log在執行完SQL就寫入，而bin log是在事務結束的時候才寫入，所以就可能發生這樣的問題)，此時主庫完成數據的更新，從庫沒有獲得此次更新，就造成主從數據庫不一致。
- 為了解決上述問題，innodb使用兩階段提交，將redo log的寫入分為2個步驟：prepare和commit。
二.主從複製
分類：
- 一主一從模式
- 雙主雙從模式
mysql主從同步的原理? 主要靠3個線程,2個日誌
- 三個線程：master主節點(bin log dump thread),slave子節點(I/O thread,SQL thread)
- 兩個日誌：bin log，relay log(中繼日誌)
- 原理：數據發生變化,主節點bin log 就發生變化,bin log dump thread線程就會把bin log的 數據發送給從節點,從節點的i/o 線程就會讀取發來的數據,並寫入到relay log中,然後 sql thread線程就會執行relay log中的操作,從而保證數據的一致性。
- 注意:採用”增量同步”。從節點會使用 bin log文件+position偏移量 來定位需要開始同步的位置
數據一致性問題的解決方案：
- 引出問題：mysql的複製方法默認採用異步的,就是主節點發送了同步數據之後,就不會管從節點是否 同步成功。這樣做的弊端是,如果主節點宕機了,從節點還沒有同步成功,那麼數據就會丟失。 (因為主節點宕機,會選擇一個從節點升級未主節點,這樣剛才主節點的binlog 文件就丟失了)
- 方案一：全同步複製：只有所有的從庫同步完成,才能通知主庫繼續下面的操作。但是這樣做效率太低。
- 方案二：半同步複製：只要有一個從庫同步完成,就通知主庫繼續下面的操作。效率提高
- 方案三：組複製(MGR)：
寄語：涓滴之水終可以磨損大石，不是由於它力量強大，而是由於晝夜不舍的滴墜。
