mysql主從延遲

1. 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數據庫主從同步延遲解決方案。
丁奇的transefer是一個不錯的方案，不過通常公司受限於對mysql的代碼修改能力的限制和對mysql的掌控能力，仍是不太適合。
最 簡單的減小slave同步延時的方案就是在架構上作優化，儘可能讓主庫的DDL快速執行。還有就是主庫是寫，對數據安全性較高，好比 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不須要這麼高的數據安全，徹底能夠講sync_binlog設置爲0或者關閉binlog，innodb_flushlog也 能夠設置爲0來提升sql的執行效率。另外就是使用比主庫更好的硬件設備做爲slave。
mysql-5.6.3已經支持了多線程的主從複製。原理和丁奇的相似，丁奇的是以表作多線程，oracle使用的是以數據庫(schema)爲單位作多線程，不一樣的庫可使用不一樣的複製線程。

sync_binlog=1 o
     This makes MySQL synchronize the binary log's contents to disk each time it commits a transaction
     默認狀況下，並非每次寫入時都將binlog與硬盤同步。所以若是操做系統或機器(不只僅是MySQL服務器)崩潰，有可能binlog中最後的語句丟 失了。要想防止這種狀況，你可使用sync_binlog全局變量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog寫入後與硬盤 同步。即便sync_binlog設置爲1,出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。若是使用InnoDB表，MySQL服務器 處理COMMIT語句，它將整個事務寫入binlog並將事務提交到InnoDB中。若是在兩次操做之間出現崩潰，重啓時，事務被InnoDB回滾，但仍 然存在binlog中。能夠用--innodb-safe-binlog選項來增長InnoDB表內容和binlog之間的一致性。(註釋：在MySQL 5.1中不須要--innodb-safe-binlog；因爲引入了XA事務支持，該選項做廢了），該選項能夠提供更大程度的安全，使每一個事務的 binlog(sync_binlog =1)和(默認狀況爲真)InnoDB日誌與硬盤同步，該選項的效果是崩潰後重啓時，在滾回事務後，MySQL服務器從binlog剪切回滾的 InnoDB事務。這樣能夠確保binlog反饋InnoDB表的確切數據等，並使從服務器保持與主服務器保持同步(不接收 回滾的語句)。

innodb_flush_log_at_trx_commit （這個很管用）
抱 怨Innodb比MyISAM慢 100倍？那麼你大概是忘了調整這個值。默認值1的意思是每一次事務提交或事務外的指令都須要把日誌寫入（flush）硬盤，這是很費時的。特別是使用電 池供電緩存（Battery backed up cache）時。設成2對於不少運用，特別是從MyISAM錶轉過來的是能夠的，它的意思是不寫入硬盤而是寫入系統緩存。日誌仍然會每秒flush到硬 盤，因此你通常不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即便MySQL掛了也可能會丟失事務的數據。而值2只會在整個操做系統 掛了時纔可能丟數據。

 

像Facebook、開心00一、人人網、優酷、豆瓣、淘寶等高流量、高併發的網站，單點數據庫很難支撐得住，WEB2.0類型的網站中使用MySQL的 居多，要麼用MySQL自帶的MySQL NDB Cluster(MySQL5.0及以上版本支持MySQL NDB Cluster功能)，或者用MySQL自帶的分區功能(MySQL5.1及以上版本支持分區功能)，我所知道的使用這兩種方案的不多，通常使用主從復 制，再加上MySQL Proxy實現負載均衡、讀寫分離等功能，在使用主從複製的基礎上，再使用垂直切分及水平切分;或者不使用主從複製，徹底使用垂直切分加上水平切分再加上 相似Memcached的系統也能夠解決問題。

1.優酷的經驗
數據庫採用水平擴展，主從複製，隨着從數據庫的增多，複製延遲愈來愈厲害，最終沒法忍受。
最終仍是採用數據庫的sharding，把一組用戶相關的表和數據放到一組數據庫上。
使用SSD來優化mysql的I／O，性能提高明顯，每塊16G，6塊SSD作RAID。
數據庫的類型選用MYISAM
數據庫的拆分策略，先縱向按照業務或者模塊拆分。對於一些特別大的表，再採用垂直拆分
根據用戶進行分片，儘量不要跨篇查詢。若是確實要跨片查詢，能夠考慮搜索的方案，先索引再搜索。
分佈式的數據庫方案太複雜，否掉。

優酷使用的是數據庫分片技術，而拋棄了因爲數據量的愈來愈多致使複製延遲的問題。按照user_id進行分片，這樣必須有一個全局的表來管理用戶與shard的關係,根據user_id能夠獲得share_id，而後根據share_id去指定的分片查詢指定的數據。

假 如此表的表名爲sharding_manager，若是網站的用戶數太多，好比千萬級的或甚至更大好比億級的用戶，此時此表也許也會成爲一個瓶頸，由於查 詢會很是頻繁，全部的動態請求都要讀此表，這時能夠用其它的解決方案，好比用Memcached、Tokyo Cabinet、Berkeley DB或其它的性能更高的方案來解決。

具體怎麼定位到哪臺db服務器，定位到哪一個數據庫，定位到哪一個shard(就是userN,msgN,videoN)，優酷網的架構文檔中說得不是很仔細，這裏只能猜想一下了。

根據優酷的架構圖，一共有2臺db服務器，每臺db服務器有2個數據庫，每一個數據庫有3個shard，這樣一共是2 * 2 * 3 = 12個shard。

user_id 通常是自增型字段，用戶註冊的時候能夠自動生成，而後看有幾臺db服務器，假若有m臺db服務器，則用 user_id % m即可以分配一臺db服務器(例如0對應100,1對應101，以此類推,字段mysql_server_ip的值肯定)，假設每臺服務器有n個數據庫， 則用user_id % n能夠定位到哪一個數據庫(字段database_name的值肯定)，假設每一個數據庫有i個shard，則用user_id % i能夠定位到哪一個shard(字段shard_id的值肯定)，這樣就能夠進行具體的數據庫操做了。

user_id share_id mysql_server_ip database_name
101      2           192.168.1.100   shard_db1
105      0           192.168.1.100   shard_db2
108      0           192.168.1.101   shard_db3(或shard_db1)
110      1           192.168.1.101   shard_db4(或shard_db2)

如上述user_id爲101的用戶，鏈接數據庫服務器192.168.1.100，使用其中的數據庫爲shard_db1，使用其中的表系列爲user2,msg2,video2

若是上述的m,n,i發生變化，好比網站的用戶不斷增加，須要增長db服務器，此時則須要進行數據庫遷移，關於遷移，參見這兒。

由於表位於不一樣的數據庫中，因此不一樣的數據庫中表名能夠相同
server1(192.168.1.100)
shard_db1
user0
msg0
video0
user1
msg1
video1
...
userN
msgN
videoN
shard_db2
user0
msg0
video0
user1
msg1
video1
...
userN
msgN
videoN

由於表位於不一樣的數據庫服務器中，因此不一樣的數據庫服務器中的數據庫名能夠相同
server2(192.168.1.101)
shard_db3(這裏也能夠用shard_db1)
user0
msg0
video0
user1
msg1
video1
...
userN
msgN
videoN
shard_db4(這裏也能夠用shard_db2)
user0
msg0
video0
user1
msg1
video1
...
userN
msgN
videoN

2.豆瓣的經驗
因爲從主庫到輔庫的複製須要時間
更新主庫後，下一個請求每每就是要讀數據（更新數據後刷新頁面）
從輔庫讀會致使cache裏存放的是舊數據(不知道這個cache具體指的是什麼，若是是Memcached的話，若是更新的數據的量很大，難道把全部更新過的數據都保存在Memcached裏面嗎？)
解決方法：更新數據庫後，在預期可能會立刻用到的狀況下，主動刷新緩存
不完美，but it works

豆瓣後來改成雙MySQL Master+Slave說是能解決Replication Delay的問題，不知道是怎麼解決的，具體不太清楚。

3.Facebook的經驗

下面一段內容引用自www.dbanotes.net
大量的 MySQL + Memcached 服務器，佈署簡示：
California (主 Write/Read)............. Virginia (Read Only)
主 數據中心在 California ，遠程中心在 Virginia 。這兩個中心網絡延遲就有 70ms，MySQL 數據複製延遲有的時候會達到 20ms. 若是要讓只讀的信息從 Virginia 端發起，Memcached 的 Cache 數據一致性就是個問題。

1 用戶發起更新操做，改名 "Jason" 到 "Monkey" ；
2 主數據庫寫入 "Monkey"，刪除主端 Memcached 中的名字值，但Virginia 端 Memcached 不刪；(這地方在 SQL 解析上做了一點手腳，把更新的操做"示意"給遠程)；
3 在 Virginia 有人查看該用戶 Profile ；
4 在 Memcached 中找到鍵值，返回值 "Jason"；
5 複製追上更新 Slave 數據庫用戶名字爲 "Monkey"，刪除 Virginia Memcached 中的鍵值；
6 在 Virginia 有人查看該用戶 Profile ；
7 Memcache 中沒找到鍵值，因此從 Slave 中讀取，而後獲得正確的 "Monkey" 。
Via

從上面3能夠看出，也仍然存在數據延遲的問題。同時master中數據庫更新的時候不更新slave中的memcached,只是給slave發個通知，說數據已經改變了。

那是否是能夠這樣，當主服務器有數據更新時，當即更新從服務器中的Memcached中的數據，這樣即便有延遲，但延遲的時間應該更短了，基本上能夠忽略不計了。

4.Netlog的經驗

對 於比較重要且必須實時的數據，好比用戶剛換密碼（密碼寫入 Master），而後用新密碼登陸（從 Slaves 讀取密碼），會形成密碼不一致，致使用戶短期內登陸出錯。因此在這種須要讀取實時數據的時候最好從 Master 直接讀取，避免 Slaves 數據滯後現象發生。還好，須要讀取實時數據的時候很少，好比用戶更改了郵件地址，就不必立刻讀取，因此這種 Master-Slaves 架構在多數狀況下仍是有效的。

 

 

 = = =

 

http://blogold.chinaunix.net/u3/116107/showart_2364757.html

 

 = = =

 

 

0_php_whc 17:28:20 http://koda.javaeye.com/blog/682547 0_php_whc 17:29:51 http://blog.csdn.net/MPU/archive/2010/06/23/5689225.aspx 0_php_whc 17:29:58 http://apps.hi.baidu.com/share/detail/17180907 0_php_whc 17:32:19 咱們如今採用的是 4.Netlog的經驗對 於比較重要且必須實時的數據，好比用戶剛換密碼（密碼寫入 Master），而後用新密碼登陸（從 Slaves 讀取密碼），會形成密碼不一致，致使用戶短期內登陸出錯。因此在這種須要讀取實時數據的時候最好從 Master 直接讀取，避免 Slaves 數據滯後現象發生。還好，須要讀取實時數據的時候很少，好比用戶更改了郵件地址，就不必立刻讀取，因此這種 Master-Slaves 架構在多數狀況下仍是有效的。