MySQL主從復制原理

　　為了減輕主庫的壓力，應該在系統應用層面做讀寫分離，寫操作走主庫，讀操作走從庫，下圖為MySQL官網給出的主從復制的原理圖，從圖中可以簡單的了解讀寫分離及主從同步的過程，分散了數據庫的訪問壓力，提升整個系統的性能和可用性，降低了大訪問量引發數據庫宕機的故障率。

　　binlog簡介

　　MySQL主從同步是基于binlog文件主從復制實現，為了更好的理解主從同步過程，這里簡單介紹一下binlog日志文件。

　　binlog日志用于記錄所有更新了數據或者已經潛在更新了數據（例如，沒有匹配任何行的一個DELETE）的所有語句。語句以“事件”的形式保存，它描述數據更改，它是以二進制的形式保存在磁盤中。我們可以通過mysql提供的查看工具mysqlbinlog查看文件中的內容，例如 mysqlbinlog mysql-bin.00001 | more，這里注意一下binlog文件的后綴名00001，binlog文件大小和個數會不斷的增加，當MySQL停止或重啟時，會產生一個新的binlog文件，后綴名會按序號遞增，例如mysql-bin.00002、mysql-bin.00003，并且當binlog文件大小超過 max_binlog_size系統變量配置時也會產生新的binlog文件。

　　1. binlog日志格式

　　（1）statement ： 記錄每一條更改數據的sql

　　優點：binlog文件較小，節約I/O，性能較高。

　　缺點：不是所有的數據更改都會寫入binlog文件中，尤其是使用MySQL中的一些特殊函數（如LOAD_FILE（）、UUID（）等）和一些不確定的語句操作，從而導致主從數據無法復制的問題。

　　（2）row ： 不記錄sql，只記錄每行數據的更改細節

　　優點：詳細的記錄了每一行數據的更改細節，這也意味著不會由于使用一些特殊函數或其他情況導致不能復制的問題。

　　缺點：由于row格式記錄了每一行數據的更改細節，會產生大量的binlog日志內容，性能不佳，并且會增大主從同步延遲出現的幾率。

　　（3）mixed：一般的語句修改使用statment格式保存binlog，如一些函數，statement無法完成主從復制的操作，則采用row格式保存binlog，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日志形式，也就是在Statement和Row之間選擇一種。