mysql主從復制延遲問題

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