mysql主從同步原理

爲何要作主從複製？
一、在業務複雜的系統中，有這麼一個情景，有一句sql語句須要鎖表，致使暫時不能使用讀的服務，那麼就很影響運行中的業務，使用主從複製，讓主庫負責寫，從庫負責讀，這樣，即便主庫出現了鎖表的情景，經過讀從庫也能夠保證業務的正常運做。

二、作數據的熱備

三、架構的擴展。業務量愈來愈大，I/O訪問頻率太高，單機沒法知足，此時作多庫的存儲，下降磁盤I/O訪問的頻率，提升單個機器的I/O性能。

---

基本構建思路
–確保數據相同：從庫必需要有主庫上的數據
–配置主服務器：啓用binlog日誌，受權用戶，查看當前正使用的Binlog日誌（從庫IO線程取SQL命令的地方）
–配置從服務器：設置server_id（標識本身的身份），指定主庫信息
–測試配置： 客戶端鏈接主庫寫入數據，在從庫上也能查詢到

mysql主從複製用途
實時災備，用於故障切換
讀寫分離，提供查詢服務
備份，避免影響業務

Master,記錄數據更改操做
啓用binglog日誌
設置binlog日誌格式
設置server_id

slave運行2個線程
slave_io線程：複製master主機 binlog日誌文件裏的sql到本機的relay-log文件裏。
slave_sql線程：執行本機relay-log文件裏的sql語句，重現Master的數據操做。

binlog(二進制文件)
relay-log(中繼日誌)

異步複製：
主庫執行一次事務後，當即將結果返回給客戶端，並不關心從庫是否已經接收並處理

全同步複製：
當主庫執行完一次事物，並全部從庫都執行了該事務後才返回給客戶端

半同步複製：
介於異步和全同步之間
主庫在執行完一次事務後，等待至少一個從庫接受到並寫到中繼日誌中才返回客戶端

---

問題及解決方法

mysql主從複製存在的問題：
主庫宕機後，數據可能丟失
從庫只有一個sql Thread，主庫寫壓力大，複製極可能延時

解決方法：
半同步複製---解決數據丟失的問題
並行複製----解決從庫複製延遲的問題

1. MySQL數據庫主從同步延遲原理。

答：談到MySQL數據庫主從同步延遲原理，得從mysql的數據庫主從複製原理提及，mysql的主從複製都是單線程的操做，主庫對全部DDL和 DML產生binlog，binlog是順序寫，因此效率很高，slave的Slave_IO_Running線程到主庫取日誌，效率很比較高，下一步， 問題來了，slave的Slave_SQL_Running線程將主庫的DDL和DML操做在slave實施。DML和DDL的IO操做是隨即的，不是順 序的，成本高不少，還可能可slave上的其餘查詢產生lock爭用，因爲Slave_SQL_Running也是單線程的，因此一個DDL卡主了，須要 執行10分鐘，那麼全部以後的DDL會等待這個DDL執行完纔會繼續執行，這就致使了延時。有朋友會問：「主庫上那個相同的DDL也須要執行10分，爲什 麼slave會延時？」，答案是master能夠併發，Slave_SQL_Running線程卻不能夠。

2. MySQL數據庫主從同步延遲是怎麼產生的。

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

3. MySQL數據庫主從同步延遲解決方案

答：最簡單的減小slave同步延時的方案就是在架構上作優化，儘可能讓主庫的DDL快速執行。還有就是主庫是寫，對數據安全性較高，好比 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不須要這麼高的數據安全，徹底能夠講sync_binlog設置爲0或者關閉binlog，innodb_flushlog也 能夠設置爲0來提升sql的執行效率。另外就是使用比主庫更好的硬件設備做爲slave。