master將改變記錄到二進位制日誌中binlog,slave將master的binlog拷貝到自己的中繼日誌中,然後執行一遍sql語句就達到同步了

一個伺服器當主庫,另一個或多個伺服器當從庫,主庫會把對資料庫的修改操作(新增 刪除 修改)記錄在binlog日誌中,從庫連線主庫獲取主庫的binlog，並記錄在中繼日誌relay-log中，然後從上次記住的位置起執行SQL語句，一旦遇到錯誤則停止同步

步驟:

安裝相同版本mysql,

修改master配置:開啟binlog,設定server-id(必須唯一,一般ip地址後3位),

修改從伺服器slave:設定server-id

重啟兩臺伺服器的mysql

在主伺服器上建立帳戶並授權slave

檢視主資料庫狀態

配置從資料庫

啟動slave同步程序並檢視狀態

驗證主從同步

從以上mysql的Replication原理可以看出：

* 主從間的資料庫不是實時同步，就算網路連線正常，也存在瞬間主從資料不一致的情況。

* 如果主從的網路斷開，則從庫會在網路恢復正常後，批量進行同步。

* 如果對從庫進行修改資料，那麼如果此時從庫正在在執行主庫的bin-log時，則會出現錯誤而停止同步，這個是很危險的操作。所以一般情況下，我們要非常小心的修改從庫上的資料。

* 一個衍生的配置是雙主、互為主從配置，只要雙方的修改不衝突，則可以工作良好。

* 如果需要多主庫的話，可以用環形配置，這樣任意一個節點的修改都可以同步到所有節點

MySQL資料庫主從同步延遲解決方案

產生:當主庫的TPS併發較高時，產生的DDL數量超過slave一個sql執行緒所能承受的範圍，那麼延時就產生了，當然還有就是可能與slave的大型query語句產生了鎖等待

最簡單的減少slave同步延時的方案就是在架構上做優化，儘量讓主庫的DDL快速執行。還有就是主庫是寫，對資料安全性較高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設定，而slave則不需要這麼高的資料安全，完全可以講sync_binlog設定為0或者關閉binlog，innodb_flushlog也可以設定為