mysql主從復制延遲問題

在一般生產環境，普遍通過MySQL的主從復制進行讀寫分離，從而減輕主服務器的壓力，提高數據的讀寫效率。通常情況下，主從復制基本上能做實時同步。由于服務器實際運行過程中，客戶端的連接服務器，讀寫數據不可能是均勻，在某個時間點出現大量并發連接，主服務器不斷的有更新操作不斷的寫入，但是從服務器當某個語句在從服務器上執行的時間較長，或者某個語句要進行鎖表，就會導致主服務器的SQL語句大量積壓，未被同步到從服務器，這樣就會導致在某個時刻主從數據不一致；還有主從復制，是通過網絡進行數據傳輸，網絡的抖動、主從服務器間的網絡中斷肯定會影響數據的傳輸，同樣會造成數據的不一致。這就是主從延遲，雖說隨著時間的推移，或者主服務器不在大量更新操作，主從服務器會逐步一致（網絡中斷除外），對于某些企業寫數據時一般不做同步的查詢，數據延遲就不是問題，但是一些交易型的企業（或者要求數據要求實時一致），數據的延遲是不能被接受的。
解決方案：
1、（網友給的方案）最簡單的減少slave同步延時的方案就是在架構上做優化，盡量讓主庫的DDL快速執行。還有就是主庫是寫，對數據安全性較高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不需要這么高的數據安全，完全可以講sync_binlog設置為0或者關閉binlog，innodb_flushlog也 可以設置為0來提高sql的執行效率。另外就是使用比主庫更好的硬件設備作為slave。
2、提升主從服務器硬件性能
3、使用MySQL5.6.3以后的版本，因為mysql-5.6.3已經支持了多線程的主從復制。
雖說這些方案能一定程度上解決數據延遲，但是受MySQL主從復制的原理限制，還是會存在數據延遲的可能性的。我認為比較可行的方案還是使用MySQL Galera Cluster集群。
Mysql Galera Cluster是一套基于同步復制的多主MySQL集群解決方案,使用簡單,沒有單點故障,可用性高,能很好保證業務不斷增長時我們數據的安全和隨時的擴展。
優點：
1、同步復制,真正行級別的并發復制，各節點間無延遲且節點宕機不會導致數據丟失。
2、多主服務器的拓撲結構，可以在任意節點上進行讀寫。
3.自動加入新節點自動成員控制，故障節點自動從集群中移除，可提供 99.999% 的可用性。
4、客戶端連接跟操作單臺MySQL數據庫的體驗一致。
缺點:
1、目前僅支持InnoDB存儲引擎,任何寫入其他引擎的表，包括mysql.*表將不會復制,但是DDL語句會被復制的,因此創建用戶將會被復制,但是insert into mysql.user…將不會被復制的.
2、DELETE操作不支持沒有主鍵的表,沒有主鍵的表在不同的節點順序將不同,如果執行SELECT…LIMIT… 將出現不同的結果集.
3、在多主環境下LOCK/UNLOCK TABLES不支持,以及鎖函數GET_LOCK(), RELEASE_LOCK()…
4、查詢日志不能保存在表中。如果開啟查詢日志，只能保存到文件中。
5、允許最大的事務大小由wsrep_max_ws_rows和wsrep_max_ws_size定義。任何大型操作將被拒絕。如大型的LOAD DATA操作。
6、由于集群是樂觀的并發控制，事務commit可能在該階段中止。如果有兩個事務向在集群中不同的節點向同一行寫入并提交，失敗的節點將中止。對 于集群級別的中止，集群返回死鎖錯誤代碼(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
7、XA事務不支持，由于在提交上可能回滾。
8、整個集群的寫入吞吐量是由最弱的節點限制，如果有一個節點變得緩慢，那么整個集群將是緩慢的。為了穩定的高性能要求，所有的節點應使用統一的硬件。
9、集群節點建議最少3個，所有服務器數據完全一致，數據同步更新，占用硬件資源，越多數量的服務器，犧牲的硬件資源越大。
10、如果DDL語句有問題將破壞集群。