MySQL中的 binlog
記錄mysql的數據更新或者潛在更新（delete from table where id=x）
主從復制就是依靠binlog
Slave 端，里面有兩個線程，一個是IO線程，另一個是SQL線程；IO線程負責從Master上讀取信息然后返回，（slave什么時候讀取，master會有一個事件通知slave ）
slave收到通知后使用IO Thread主動去master讀取binlog日志,然后異步寫入relay日志(中轉日志),然后使 SQL Thread完成對`relay日志 的解析然后入庫操作,完成同步
Binlog模式分三種Row、Statement、Mixed
Row模式存儲的是數據修改后的結果，binlog中可以不記錄執行的sql語句的上下文相關的信息，僅僅只需要記錄那一條記錄被修改了，修改成什么樣了。對於update mytable set col1=’abc’ where col2=’c’在row模式下可能產生大量的數據，因為語句雖然是一條，但實際影響的數據記錄卻可能很多。而對於alter table、drop table、create table等信息在Row模式下則不會產生大量的log條目，因為它還是記錄的語句，而不是單行數據的變化情況。
優點：在row level模式下，bin-log中可以不記錄執行的sql語句的上下文相關的信息，僅僅只需要記錄那一條被修改。所以rowlevel的日志內容會非常清楚的記錄下每一行數據修改的細節。不會出現某些特定的情況下的存儲過程或function，以及trigger的調用和觸發無法被正確復制的問題
缺點：row level，所有的執行的語句當記錄到日志中的時候，都將以每行記錄的修改來記錄，會產生大量的日志內容。
Statemnet模式每一條會修改數據的sql都會記錄到 master的binlog中。slave在復制的時候sql進程會解析成和原來master端執行過的相同的sql來再次執行。由於他是記錄的執行語句，所以，為了讓這些語句在slave端也能正確執行，那么他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，以保證所有語句在slave端杯執行的時候能夠得到和在master端執行時候相同的結果。
優點：statement level下的優點首先就是解決了row level下的缺點，不需要記錄每一行數據的變化，減少bin-log日志量，節約IO，提高性能，因為它只需要在Master上鎖執行的語句的細節，以及執行語句的上下文的信息。
缺點：由於只記錄語句，所以，在statement level下 已經發現了有不少情況會造成MySQL的復制出現問題，主要是修改數據的時候使用了某些定的函數或者功能的時候會出現。
Mixed模式則是前兩種的混合，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日志形式，也就是在Statement和Row之間選擇一種。選擇性的使用面向行數據變化的Row方式記錄，主要是面對一些未決語句（nondeterministic），考慮到安全問題，避免主從庫之間數據出現不一致，比如語句面向多行插入，其中又有auto-increment的字段，數據庫存儲引擎不同，可能帶來插入順序
mysql主從同步延遲原理
要了解MySQL數據庫主從同步延遲原理，我們先從MySQL的數據庫主從復制原理說起：
主從復制就是依靠binlog
Slave 端，里面有兩個線程，一個是IO線程，另一個是SQL線程；IO線程負責從Master上讀取信息然后返回，（slave什么時候讀取，master會有一個事件通知slave ）
slave收到通知后使用IO Thread主動去master讀取binlog日志,然后異步寫入relay日志(中轉日志),然后使 SQL Thread完成對`relay日志 的解析然后入庫操作,完成同步
Mysql 中的binlog底層原理分析
記錄mysql 數據更新或潛在更新（delete from table where id =x）
主從復制就是依靠binlog
Master-slave
binlog日志里面內容格式有三種
Statement 基於sql語句 insert （Master執行完增刪改操作后都會記錄binlog日志）
Row 基於行模式。Update table set value=x; 10000條 記錄10000條變更的數據
Mixed 混合模式
解碼binglog 二進制文件
mysqlbinglog --base64-output=decode-row -v mysqlbin.00001
show variables like ‘%log%’
