Mysql之所以可以實現主從服務器之間的同步，是因為主服務器端的事件(events)寫到了 binary log 中，然後在從服務器上再次執行這些事件。
事件寫入BINLOG中，主要有以下三種格式：
1、基於語句的記錄(Statement-Based Replication)
就是將主服務器上執行的語句記錄下來，在從服務器上再次執行一遍。在MYSQL 5.1.4之前，只有這一種方式；
這種類型的優點包括：
A、從3.23版本以來，MYSQL只有這一種類型，所以這種類型已經被實踐所證實；
B、寫入BINLOG的數據相對來說少一些，特別是更新很多行的語句，不用把每行的變化記錄下來；
C、所有更改數據庫的語句都會被記錄下來，可以用來監督數據庫。
這種類型的缺點也很明顯，是一種不“安全”的記錄方式：
A、不能更新不缺定地行；比如UPDATE語句中有不加ORDER的LIMIT；
B、
LOAD_FILE()
UUID(), UUID_SHORT()
USER()
FOUND_ROWS()
SYSDATE() (unless both the master and the slave are started with the --sysdate-is-now option)
GET_LOCK()
IS_FREE_LOCK()
IS_USED_LOCK()
MASTER_POS_WAIT()
RAND()
RELEASE_LOCK()
SLEEP()
VERSION()
比如，使用SBR（STATEMENT-BASED REPLICATION）同步這條語句：
update table set column=uuid() limit 2更新後，這兩條記錄主服務器端該字段的值為：
45734358-9df1-11e3-b0fd-782bcb74f37e
從服務器端的值：
3fa4171e-9df0-11e3-a0e5-782bcb74f37e
C、比基於行的方式需要更多地行級鎖；
2、基於行的記錄（Row-Based Replication）
就是將主服務器上對每一行的修改記錄下來，然後在從服務器上實現之；
這個類型的優勢：
A、是一種安全的方式，也就是說能夠准確無誤地同步主服務器的內容，比如上面那個例子使用RBR（ROW-BASED REPLICATION）的結果：
主服務器和從服務器端均為：
b290f3a0-9df5-11e3-b0fd-782bcb74f37e
B、需要鎖行的數量很少
這個類型的缺點就是：
A、需要記錄的內容太多，如果一條語句更新了一個幾千萬條數據的，那就會記錄幾千萬條BINLOG……
B、如果一些生成的變量很龐大，比如BLOB類型，會使得記錄很龐大
C、無法知道當前哪條語句在執行，無法監督主從進度
3、混合類型記錄（Row-Based Replication）
就是上述兩種都有，系統會實時選擇合適的類型來記錄主服務器的記錄。
