複製解決的問題是讓一臺服務器的數據與其他的服務器保持同步。一臺主庫的數據可以同步到多臺備庫上去，備庫本身也可以被配置成另外一臺服務器的主庫。
從集中到分佈，最基本的一個需求不是數據存儲的瓶頸，而是在於計算的瓶頸，即SQL查詢的瓶頸，我們知道，正常情況下，Insert SQL就是幾十個毫秒的時間內寫入完成，而系統中的大多數Select SQL則要幾秒到幾分鐘纔能有結果，很多複雜的SQL，其消耗服務器CPU的能力超強，不亞於死循環的威力。我們應該儘量避免沒有主從複製機制的單節點數據庫。
複製的方案
一主多備庫
一個寫節點Master後面跟着多個讀節點，讀節點的數量取決於系統的壓力，通常是1-3個讀節點的配置
，如下所示
雙主庫
環形主庫
樹形庫
複製方式
- 基於行的複製(RBR)
- 基於語句的複製(SBR)
- 混合模式複製(MBR)
基於SQL語句的方式最古老的方式，也是目前默認的複製方式，後來的兩種是MySQL 5以後纔出現的複製方式。
基於行的複製(RBR)的優點：
- 任何情況都可以被複制，這對複製來說是最安全可靠的
- 和其他大多數數據庫系統的複製技術一樣
- 多數情況下，從服務器上的表如果有主鍵的話，複製就會快了很多
基於行的複製(RBR)的缺點：
-binlog 大了很多
- 複雜的回滾時 binlog 中會包含大量的數據
- 主服務器上執行 UPDATE 語句時，所有發生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會導致頻繁發生
- binlog 的併發寫問題
- 無法從 binlog 中看到都複製了寫什麼語句
基於語句的複製(SBR)的優點：
- 歷史悠久，技術成熟
- binlog文件較小
- binlog中包含了所有數據庫更改信息，可以據此來審覈數據庫的安全等情況
- binlog可以用於實時的還原，而不僅僅用於複製
- 主從版本可以不一樣，從服務器版本可以比主服務器版本高
SBR 的缺點：
- 不是所有的UPDATE語句都能被複制，尤其是包含不確定操作的時候。
- 複製需要進行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時，需要比 RBR 請求更多的行級鎖
- 對於一些複雜的語句，在從服務器上的耗資源情況會更嚴重，而 RBR 模式下，只會對那個發生變化的記錄產生影響
- 數據表必須幾乎和主服務器保持一致纔行，否則可能會導致複製出錯
- 執行復雜語句如果出錯的話，會消耗更多資源
選擇哪種方式複製，會影響到複製的效率以及服務器的損耗，甚以及數據一致性性問題，目前其實沒有很好的客觀手手段去評估一個系統更適合哪種方式的複製
主從複製的原理
第一步是在主庫上記錄二進制日誌（稍後介紹如何設置）。在每次準備提交事務完成數 據更新前，主庫將數據更新的事件記錄到二進制日誌中。MySQL會按事務提交的順序 而非每條語句的執行順序來記錄二進制日誌。在記錄二進制日誌後，主庫會告訴存儲引擎可以提交事務了。
下一步，備庫將主庫的二進制日誌複製到其本地的中繼日誌中。首先，備庫會啓動一個 工作線程，稱爲I/O線程，I/O線程跟主庫建立一個普通的客戶端連接，然後在主庫上啓 動一個特殊的二進制轉儲(binhg dump、線程（該線程沒有對應的SQL命令），這個二進制轉儲線程會讀取主庫上二進制日誌中的事件。它不會對事件進行輪詢。如果該線程追趕上了主庫，它將進入睡眠狀態，直到主庫發送信號量通知其有新的事件產生時纔會被喚醒，備庫I/O線程會將接收到的事件記錄到中繼日誌中。
備庫的SQL線程執行最後一步，該線程從中繼日誌中讀取事件並在備庫執行，從而實現備庫數據的更新。當SQL線程追趕上I/O線程時，中繼日誌通常已經在系統緩存中，所以中繼日誌的開銷很低。SQL線程執行的事件也可以通過配置選項來決定是否寫入其自己的二進制日誌中，它對於我們稍後提到的場景非常有用。
主從同步的監控問題
Mysql有主從同步的狀態信息，可以通過命令show slave status獲取，除了獲知當前是否主從同步正常工作，另外一個重要指標就是Seconds_Behind_Master，從字面理解，它表示當前MySQL主從數據的同步延遲，單位是秒。當主從同步停止以後，重新啓動同步，這個數值可能會是幾萬秒，取決於主從同步停止的時間長短，我們可以認爲數據此時有很多天沒有同步了，而這個數值越接近零，則說明主從同步延遲最小，我們可以採集這個指標並匯聚曲線圖，來分析我們的數據庫的同步延遲曲線，然後根據此曲線，給出一個合理的閥值，主從同步的時延小於閥值時，我們認爲從庫是同步的，此時可以安全的從從庫讀取數據。