本篇內容包括：MySQL 主從復制簡介、主從復制的原理以及主從搭建
一、MySQL 主從復制簡介
在實際的生產中，為了解決Mysql的單點故障已經提高MySQL的整體服務性能，一般都會采用**「主從復制」**。
比如：在復雜的業務系統中，有一句sql執行后導致鎖表，并且這條sql的的執行時間有比較長，那么此sql執行的期間導致服務不可用，這樣就會嚴重影響用戶的體驗度。
主從復制中分為「主服務器（master）「和」從服務器（slave）」，「主服務器負責寫，而從服務器負責讀」，Mysql的主從復制的過程是一個**「異步的過程」**。
這樣讀寫分離的過程能夠是整體的服務性能提高，即使寫操作時間比較長，也不影響讀操作的進行。
mysql主從同步的過程：
- master提交完事務后，寫入binlog
- slave連接到master，獲取binlog
- master創建dump線程，推送binglog到slave
- slave啟動一個IO線程讀取同步過來的master的binlog，記錄到relay log中繼日志中
- slave再開啟一個sql線程讀取relay log事件并在slave執行，完成同步
- slave記錄自己的binglog
二、主從復制的原理
首先放一張Mysql主從復制的原理圖，總的來說Mysql的主從復制原理還是比較好理解的，原理非常的簡單。
Mysql的主從復制中主要有三個線程：master（binlog dump thread）、slave（I/O thread 、SQL thread），Master一條線程和Slave中的兩條線程。
master（binlog dump thread）主要負責Master庫中有數據更新的時候，會按照binlog格式，將更新的事件類型寫入到主庫的binlog文件中。
并且，Master會創建log dump線程通知Slave主庫中存在數據更新，這就是為什么主庫的binlog日志一定要開啟的原因。
I/O thread線程在Slave中創建，該線程用于請求Master，Master會返回binlog的名稱以及當前數據更新的位置、binlog文件位置的副本。
然后，將binlog保存在 「relay log（中繼日志）」 中，中繼日志也是記錄數據更新的信息。
SQL線程也是在Slave中創建的，當Slave檢測到中繼日志有更新，就會將更新的內容同步到Slave數據庫中，這樣就保證了主從的數據的同步。
以上就是主從復制的過程，當然，主從復制的過程有不同的策略方式進行數據的同步，主要包含以下幾種：
- 「同步策略」：Master會等待所有的Slave都回應后才會提交，這個主從的同步的性能會嚴重的影響。****
- 「半同步策略」：Master至少會等待一個Slave回應后提交。
- 「異步策略」：Master不用等待Slave回應就可以提交。
- 「延遲策略」：Slave要落后于Master指定的時間。
對于不同的業務需求，有不同的策略方案，但是一般都會采用最終一致性，不會要求強一致性，畢竟強一致性會嚴重影響性能。
三、主從搭建
待完善…
