架構(gòu)篇（1） 讀書筆記 1.Scale（擴展):從數(shù)據(jù)庫來看,就是讓數(shù)據(jù)庫能夠提供更強的服務(wù)能力 ScaleOut: 是通過增加處理節(jié)點的方式來提高整體處理能力 ScaleUp: 是通過增加當前處理節(jié)點的處理能力來提高整體的處理能力 2.事務(wù)最小化原則: 避免分布式事務(wù)的解決方案 a)進行ScaleOut 設(shè)計的時候合理設(shè)計切分規(guī)則，盡可能保證事務(wù)所需數(shù)據(jù)在同一個MySQLServer 上，避免分布式事務(wù)。大多數(shù)時候也只能兼顧到一些大部分的核心事務(wù)，不是一個很完美的解決方案。 b)大事務(wù)切分成多個小事務(wù)，數(shù)據(jù)庫保證各個小事務(wù)的完整性，應(yīng)用控制各個小事務(wù)之間的整體事務(wù)完整性。 c)結(jié)合上述兩種解決方案，整合各自的優(yōu)勢，避免各自的弊端。核心業(yè)務(wù)的事務(wù)用a)方案保證,其他的用b)保證,要仔細分析,是否需要事務(wù),如果不需要的話,就不要引入事務(wù). 3.數(shù)據(jù)一致性原則. 如何在ScaleOut 的同時又較好的保證數(shù)據(jù)一致性呢？ ==>BASE模型,即：基本可用，柔性狀態(tài)，基本一致和最終一致。這幾個詞看著挺復(fù)雜挺深奧，其實大家可以簡單的理解為非實時的一致性原則。也就是說，應(yīng)用系統(tǒng)通過相關(guān)的技術(shù)實現(xiàn)，讓整個系統(tǒng)在滿足用戶使用的基礎(chǔ)上，允許數(shù)據(jù)短時間內(nèi)處于非實時狀態(tài)，而通過后續(xù)技術(shù)來保證數(shù)據(jù)在最終保證處于一致狀態(tài)。 但也有問題: 第一個問題就是我們需要讓所有數(shù)據(jù)都是非實時一致嗎？ ==>如果不是所有的數(shù)據(jù)都是非實時一致，那我們又該如何來確定哪些數(shù)據(jù)需要實時一致哪些數(shù)據(jù)又只需要非實時的最終一致呢？其實這基本可以說是一個各模塊業(yè)務(wù)優(yōu)先級的劃分，對于優(yōu)先級高的自然是規(guī)屬于保證數(shù)據(jù)實時一致性的陣營，而優(yōu)先級略低的應(yīng)用，則可以考慮劃分到允許短時間端內(nèi)不一致而最終一致的陣營。這是一個非常棘手的問題。需要通過非常詳細的分析和仔細的評估才能作出決定。因為不是所有數(shù)據(jù)都可以出現(xiàn)在系統(tǒng)能不短時間段內(nèi)不一致狀態(tài)，也不是所有數(shù)據(jù)都可以通過后期處理的使數(shù)據(jù)最終達到一致的狀態(tài)，所以之少這兩類數(shù)據(jù)就是需要實時一致的。 如何讓系統(tǒng)中的不一致數(shù)據(jù)達到最終一致？ ==>一般來說，我們必須將這類數(shù)據(jù)所設(shè)計到的業(yè)務(wù)模塊和需要實時一致數(shù)據(jù)的業(yè)務(wù)模塊明確的劃分開來。然后通過相關(guān)的異步機制技術(shù)，利用相應(yīng)的后臺進程，通過系統(tǒng)中的數(shù)據(jù)，日志等信息將當前并不一致的數(shù)據(jù)進行進一步處理，使最終數(shù)據(jù)處于完全一致狀態(tài)。對于不同的模塊，使用不同的后臺進程，既可以避免數(shù)據(jù)出現(xiàn)紊亂，也可以并發(fā)執(zhí)行，提高處理效率。 避免實時一致與最終一致兩類數(shù)據(jù)的前臺在線交互。 ==>由于兩類數(shù)據(jù)狀態(tài)的不一致性，很可能會導(dǎo)致兩類數(shù)據(jù)在交互過程中出現(xiàn)紊亂，應(yīng)該盡量讓所有非實時一致的數(shù)據(jù)和實時一致數(shù)據(jù)在應(yīng)用程序中得到有效的隔離。甚至在有些特別的場景下，記錄在不同的MySQLServer中來進行物理隔離都是有必要的。 4.高可用以及數(shù)據(jù)安全原則: 經(jīng)過ScaleOut設(shè)計之后，系統(tǒng)整體可擴展性確實是會得到很大的提高，整體性能自然也很容易得到較大的改善。但是，系統(tǒng)整體的可用性維護方面卻是變得比以前更為困難。因為系統(tǒng)整體架構(gòu)復(fù)雜了，不論是應(yīng)用程序還是數(shù)據(jù)庫環(huán)境方面都會比原來更為龐大，更為復(fù)雜。這樣所帶來的最直接影響就是維護難度更大，系統(tǒng)監(jiān)控更難。 ScaleOut 設(shè)計過程中另一個原則，也就是高可用性的原則。不論如何調(diào)整設(shè)計系統(tǒng)的架構(gòu)，系統(tǒng)的整體可用性不能被降低。 數(shù)據(jù)安全: ==>我們必須保證在出現(xiàn)軟/硬件故障的時候，能夠保證我們的數(shù)據(jù)不會出現(xiàn)丟失。數(shù)據(jù)一旦丟失，根本就無可用性可言了。 ==>最好的辦法就是通過冗余機制來保證。所有軟硬件設(shè)備都去除單點隱患，所有數(shù)據(jù)都存在多份拷貝?？梢酝ㄟ^MySQLReplication，MySQLCluster 等技術(shù)來實現(xiàn)。 架構(gòu)篇（2） 讀書筆記 mysqlreplication: 原理: Mysql的Replication是一個異步的復(fù)制過程，在Master與Slave之間的實現(xiàn)整個復(fù)制過程主要由三個線程來完成，其中兩個線程（Sql線程和IO線程）在Slave端，另外一個線程（IO線程）在Master端。 要實現(xiàn)MySQL的Replication，首先必須打開Master端的BinaryLog（mysqlbin.xxxxxx）功能，否則無法實現(xiàn)。因為整個復(fù)制過程實際上就是Slave從Master端獲取該日志然后再在自己身上完全順序的執(zhí)行日志中所記錄的各種操作。 復(fù)制的過程: 1.Slave 上面的IO線程連接上Master，并請求從指定日志文件的指定位置（或者從最開始的日志）之后的日志內(nèi)容； 2.Master 接收到來自Slave的IO線程的請求后，通過負責復(fù)制的IO線程根據(jù)請求信息讀取指定日志指定位置之后的日志信息，返回給Slave端的IO線程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息在Master端的BinaryLog文件的名稱以及在BinaryLog 中的位置； 3.Slave 的IO線程接收到信息后，將接收到的日志內(nèi)容依次寫入到Slave端的RelayLog 文件(mysql-relay-bin.xxxxxx)的最末端，并將讀取到的Master端的binlog的文件名和位置記錄到master-info文件中，以便在下一次讀取的時候能夠清楚的高速Master“我需要從某個bin-log的哪個位置開始往后的日志內(nèi)容，請發(fā)給我” 4.Slave 的SQL線程檢測到RelayLog 中新增加了內(nèi)容后，會馬上解析該Log文件中的內(nèi)容成為在Master端真實執(zhí)行時候的那些可執(zhí)行的Query語句，并在自身執(zhí)行這些Query。這樣，實際上就是在Master端和Slave端執(zhí)行了同樣的Query，所以兩端的數(shù)據(jù)是完全一樣的。 復(fù)制的級別:可以基于語句的/也可以基于一條記錄的 記錄級別:為每一行都生成sql,信息量大. 語句級別:性能高.但是bug多.盡量少使用存儲過程. 常用復(fù)制架構(gòu): Master-Slaves: 90%的場合都是這種一個master,多個slave的架構(gòu)模式.主要用于讀壓力比較大的應(yīng)用.對于對于數(shù)據(jù)實時性要求不是太高的系統(tǒng),只要通過廉價的pcserver就可以擴展slave的數(shù)量.將讀壓力分散到多臺slave機器上.架構(gòu)圖: w repl r client---> master -----> slave <----client |---> salve <----client |---> salve <----client dualmaster 復(fù)制架構(gòu): 為了解決主機down機,從機迅速切換成主機的架構(gòu)方式. 實際上就是兩個MySQLServer 互相將對方作為自己的Master，自己作為對方的Slave來進行復(fù)制。這樣，任何一方所做的變更，都會通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫中。 不會造成循環(huán)復(fù)制:在MySQL的BinaryLog 中記錄了當前MySQL的server-id，而且這個參數(shù)也是我們搭建MySQLReplication 的時候必須明確指定，而且Master和Slave的server-id參數(shù)值比需要不一致才能使MySQLReplication搭建成功 r/w client------> master | | REPL (相互) | r/w client------> master 通過DualMaster 復(fù)制架構(gòu)，我們不僅能夠避免因為正常的常規(guī)維護操作需要的停機所帶來的重新搭建Replication環(huán)境的操作.Dual Master 復(fù)制架構(gòu)和一些第三方的HA管理軟件結(jié)合，還可以在我們當前正在使用的Master出現(xiàn)異常無法提供服務(wù)之后，非常迅速的自動切換另外一端來提供相應(yīng)的服務(wù)，減少異常情況下帶來的停機時間，并且完全不需要人工干預(yù)。 搭建成一個DualMaster環(huán)境，并不是為了讓兩端都提供寫的服務(wù)。在正常情況下，我們都只會將其中一端開啟寫服務(wù)，另外一端僅僅只是提供讀服務(wù)，或者完全不提供任何服務(wù)，僅僅只是作為一個備用的機器存在。 級聯(lián)復(fù)制架構(gòu)(Master- Slaves - Slaves: 在某些場合讀的壓力特別大,一個master可能需要10臺或者更多的slave才鞥支撐住讀的壓力.這樣的話,master的壓力比較大,因為光是slave的io線程就比較多,這樣寫的壓力稍微大一點,就容易造成復(fù)制的延時. 解決==> 以利用MySQL可以在Slave端記錄復(fù)制所產(chǎn)生變更的BinaryLog 信息的功能，也就是打開—log-slave-update選項。然后，通過二級（或者是更多級別）復(fù)制來減少Master端因為復(fù)制所帶來的壓力。 w repl repl client--->master -----> slave -----------> slave | repl |-->slave ----------> slave |repl |------> slave 所有的slave都是對客戶只讀 風險:級聯(lián)過多,容易產(chǎn)生延時較長. dualmaster 與級聯(lián)復(fù)制結(jié)合: w repl repl client--->master <------> master ----------> slave |repl |-------->slave |repl |-------->slave 最大的好處就是既可以避免主Master的寫入操作不會受到Slave集群的復(fù)制所帶來的影響，同時主Master需要切換的時候也基本上不會出現(xiàn)重搭Replication的情況. 搭建實現(xiàn): 1.Master端準備工作 在搭建Replication環(huán)境之前，首先要保證Master端MySQL記錄BinaryLog 的選項打開.使用log-bin[=pathfor binary log]參數(shù)選項。 還需要準備一個用于復(fù)制的MySQL用戶。 mysql>CREATEUSER 'repl'@'192.168.0.2' ->IDENTIFIED BY 'password'; mysql>GRANTREPLICATION SLAVE ON *.* ->TO 'repl'@'192.168.0.2'; 2.獲取Master端的備份“快照” 快照:所有數(shù)據(jù)均是基于某一特定時刻的，數(shù)據(jù)完整性和一致性都可以得到保證的備份集.同時還需要取得該備份集時刻所對應(yīng)的Master端BinaryLog 的準確LogPosition，因為在后面配置Slave的時候會用到 方法: a)通過數(shù)據(jù)庫全庫冷備份: 冷備份. 如在Master剛剛啟動之后，還沒有應(yīng)用程序連接上Master之前，通過執(zhí)行SHOWMaster STATUS 命令從Master端獲取到我們可以使用的LogPosition。如果我們無法在Master啟動之后控制應(yīng)用程序的連接，那么可能在我們還沒有來得及執(zhí)行SHOWMaster STATUS 命令之前就已經(jīng)有數(shù)據(jù)寫進來了，這時候我們可以通過mysqlbinlog客戶端程序分析Master最新的一個BinaryLog 來獲取其第一個有效的LogPosition。 b)通過LVM或者ZFS等具有snapshot功能的軟件進行"熱備份" 文件系統(tǒng)運行在LVM上面，那么我們都可以通過相關(guān)的命令對MySQL的數(shù)據(jù)文件和日志文件所在的目錄就做一個Snapshot，這樣就可以得到了一個基本和全庫冷備差不多的備份集。為了保證我們的備份集數(shù)據(jù)能夠完整且一致，我們需要在進行Snapshot過程中通過相關(guān)命令（FLUSHTABLES WITH READ LOCK）來鎖住所有表的寫操作，在做完Snapshot之后，我們就可以UNLOCKTABLES 了 因為加了鎖,所以更容易獲得logposition : SHOW MASTER STATUS c)mysqldump 客戶端程序 如果不能停機冷備份,而且也沒有運行在b)上的文件系統(tǒng),就需要使用mysqldump客戶端程序. 可以鎖定表(不支持事務(wù),FLUSH TABLES WITH READ LOCK), 或者—single-transaction選項(支持事務(wù))來保持數(shù)據(jù)的完整性. 獲得logposition: 使用mysqldump的 --master-data d)通過現(xiàn)有某一個Slave端進行“熱備份” 如果現(xiàn)在已經(jīng)有Slave從我們需要搭建Replication環(huán)境的Master上進行復(fù)制的話，那我們這個備份集就非常容易取得了。。我們可以暫時性的停掉現(xiàn)有Slave（如果有多臺則僅僅只需要停止其中的一臺）.同時執(zhí)行一次FLUSHTABLES 命令來刷新所有表和索引的數(shù)據(jù)。這時候在該Slave上面就不會再有任何的寫入操作了，我們既可以通過copy所有的數(shù)據(jù)文件和日志文件來做一個全備份，同時也可以通過Snapshot（如果支持）來進行備份。 通過現(xiàn)有Slave來獲取備份集的方式，不僅僅得到數(shù)據(jù)庫備份的方式很簡單，連所需要LogPosition，甚至是新Slave后期的配置等相關(guān)動作都可以省略掉，只需要新的Slave完全基于這個備份集來啟動，就可以正常從Master進行復(fù)制了。 整個過程中我們僅僅只是在短暫時間內(nèi)停止了某臺現(xiàn)有Slave的復(fù)制線程，對系統(tǒng)的正常服務(wù)影響很小，所以這種方式也基本可以稱之為“熱備份”。 3.Slave端恢復(fù)"快照" a)恢復(fù)全庫冷備份集 由于這個備份集是一個完整的數(shù)據(jù)庫物理備份，我們僅僅只需要將這個備份集通過FTP或者是SCP之類的網(wǎng)絡(luò)傳輸軟件復(fù)制到Slave所在的主機，根據(jù)Slave上my.cnf配置文件的設(shè)置，將文件存放在相應(yīng)的目錄，覆蓋現(xiàn)有所有的數(shù)據(jù)和日志等相關(guān)文件，然后再啟動Slave端的MySQL，就完成了整個恢復(fù)過程。 b)恢復(fù)對Master進行Snapshot得到的備份集 對于通過對Master進行Snapshot所得到的備份集，實際上和全庫冷備的恢復(fù)方法基本一樣，唯一的差別只是首先需要將該Snapshot通過相應(yīng)的文件系統(tǒng)mount到某個目錄下，然后才能進行后續(xù)的文件拷貝操作。之后的相關(guān)操作和恢復(fù)全庫冷備份集基本一致，就不再累述。 c)恢復(fù)mysqldump得到的備份集 通過mysqldump客戶端程序所得到的備份集，和前面兩種備份集的恢復(fù)方式有較大的差別。因為前面兩種備份集的都屬于物理備份，而通過mysqldump客戶端程序所做的備份屬于邏輯備份?；謴?fù)mysqldump備份集的方式是通過mysql客戶端程序來執(zhí)行備份文件中的所有SQL語句。 恢復(fù)之前，注銷掉CHANGEMASTER TO 命令部分， d)恢復(fù)通過現(xiàn)有Slave所得到的熱備份 通過現(xiàn)有Slave所得到的備份集和上面第一種或者第二種備份集也差不多。如果是通過直接拷貝數(shù)據(jù)和日志文件所得到的備份集，那么就和全庫冷備一樣的備份方式，如果是通過Snapshot得到的備份集，就和第二種備份恢復(fù)方式完全一致。 4.配置并啟動Slave: 通過CHANGEMASTER TO 命令來配置然后再啟動Slave root@localhost: mysql 08:32:38> CHANGE MASTER TO ->MASTER_HOST='192.168.0.1', ->MASTER_USER='repl', ->MASTER_PASSWORD='password', ->MASTER_LOG_FILE='mysql-bin.000035', ->MASTER_LOG_POS=399; root@localhost: mysql 08:33:49> START SLAVE; 成功! 架構(gòu)篇（3） 讀書筆記 replication的限制: 一旦數(shù)據(jù)庫過于龐大，尤其是當寫入過于頻繁，很難由一臺主機支撐的時候，我們還是會面臨到擴展瓶頸。 數(shù)據(jù)切分(sharding):通過某種特定的條件，將我們存放在同一個數(shù)據(jù)庫中的數(shù)據(jù)分散存放到多個數(shù)據(jù)庫（主機）上面，以達到分散單臺設(shè)備負載的效果。。數(shù)據(jù)的切分同時還可以提高系統(tǒng)的總體可用性，因為單臺設(shè)備Crash之后，只有總體數(shù)據(jù)的某部分不可用，而不是所有的數(shù)據(jù)。 數(shù)據(jù)的切分（Sharding）模式: 一種是按照不同的表（或者Schema）來切分到不同的數(shù)據(jù)庫（主機）之上，這種切可以稱之為數(shù)據(jù)的垂直（縱向）切分； 另外一種則是根據(jù)表中的數(shù)據(jù)的邏輯關(guān)系，將同一個表中的數(shù)據(jù)按照某種條件拆分到多臺數(shù)據(jù)庫（主機）上面，這種切分稱之為數(shù)據(jù)的水平（橫向）切分。 垂直切分: 一個架構(gòu)設(shè)計較好的應(yīng)用系統(tǒng)，其總體功能肯定是由很多個功能模塊所組成的，而每一個功能模塊所需要的數(shù)據(jù)對應(yīng)到數(shù)據(jù)庫中就是一個或者多個表。而在架構(gòu)設(shè)計中，各個功能模塊相互之間的交互點越統(tǒng)一越少，系統(tǒng)的耦合度就越低，系統(tǒng)各個模塊的維護性以及擴展性也就越好。這樣的系統(tǒng)，實現(xiàn)數(shù)據(jù)的垂直切分也就越容易。 一般來說，如果是一個負載相對不是很大的系統(tǒng)，而且表關(guān)聯(lián)又非常的頻繁，那可能數(shù)據(jù)庫讓步，將幾個相關(guān)模塊合并在一起減少應(yīng)用程序的工作的方案可以減少較多的工作量，這是一個可行的方案。 一個垂直拆分的例子: 1.用戶模塊表：user,user_profile,user_group,user_photo_album 2.群組討論表：groups,group_message,group_message_content,top_message 3.相冊相關(guān)表：photo,photo_album,photo_album_relation,photo_comment 4.事件信息表：event 拆分: ◆群組討論模塊和用戶模塊之間主要存在通過用戶或者是群組關(guān)系來進行關(guān)聯(lián)。一般關(guān)聯(lián)的時候都會是通過用戶的id或者nick_name以及group的id來進行關(guān)聯(lián)，通過模塊之間的接口實現(xiàn)不會帶來太多麻煩； ◆相冊模塊僅僅與用戶模塊存在通過用戶的關(guān)聯(lián)。這兩個模塊之間的關(guān)聯(lián)基本就有通過用戶id關(guān)聯(lián)的內(nèi)容，簡單清晰，接口明確； ◆ 事件模塊與各個模塊可能都有關(guān)聯(lián)，但是都只關(guān)注其各個模塊中對象的ID信息，同樣可以做到很容易分拆。 app====> [users]database ====>[group message]database ====>[photto albums]database ====>[events]database 所以,通過拆分,把以前的一個db存儲這些表,分成了4個db寫入,這樣就減輕了壓力. 垂直切分的優(yōu)點 ◆ 數(shù)據(jù)庫的拆分簡單明了，拆分規(guī)則明確； ◆ 應(yīng)用程序模塊清晰明確，整合容易； ◆ 數(shù)據(jù)維護方便易行，容易定位； 垂直切分的缺點 ◆ 部分表關(guān)聯(lián)無法在數(shù)據(jù)庫級別完成，需要在程序中完成； ◆ 對于訪問極其頻繁且數(shù)據(jù)量超大的表仍然存在性能瓶頸，不一定能滿足要求； ◆ 事務(wù)處理相對更為復(fù)雜； ◆ 切分達到一定程度之后，擴展性會遇到限制； ◆ 過讀切分可能會帶來系統(tǒng)過渡復(fù)雜而難以維護。 水平切分 將某個訪問極其頻繁的表再按照某個字段的某種規(guī)則來分散到多個表之中，每個表中包含一部分數(shù)據(jù)。 對于上面的例子: 所有數(shù)據(jù)都是和用戶關(guān)聯(lián)的，那么我們就可以根據(jù)用戶來進行水平拆分，將不同用戶的數(shù)據(jù)切分到不同的數(shù)據(jù)庫中。 現(xiàn)在互聯(lián)網(wǎng)非常火爆的Web2.0類型的網(wǎng)站，基本上大部分數(shù)據(jù)都能夠通過會員用戶信息關(guān)聯(lián)上，可能很多核心表都非常適合通過會員ID來進行數(shù)據(jù)的水平切分。而像論壇社區(qū)討論系統(tǒng)，就更容易切分了，非常容易按照論壇編號來進行數(shù)據(jù)的水平切分。切分之后基本上不會出現(xiàn)各個庫之間的交互。 水平切分的優(yōu)點 ◆ 表關(guān)聯(lián)基本能夠在數(shù)據(jù)庫端全部完成； ◆ 不會存在某些超大型數(shù)據(jù)量和高負載的表遇到瓶頸的問題； ◆ 應(yīng)用程序端整體架構(gòu)改動相對較少； ◆ 事務(wù)處理相對簡單； ◆ 只要切分規(guī)則能夠定義好，基本上較難遇到擴展性限制； 水平切分的缺點 ◆ 切分規(guī)則相對更為復(fù)雜，很難抽象出一個能夠滿足整個數(shù)據(jù)庫的切分規(guī)則； ◆ 后期數(shù)據(jù)的維護難度有所增加，人為手工定位數(shù)據(jù)更困難； ◆ 應(yīng)用系統(tǒng)各模塊耦合度較高，可能會對后面數(shù)據(jù)的遷移拆分造成一定的困難。 兩種切分結(jié)合用: 一般來說，我們數(shù)據(jù)庫中的所有表很難通過某一個（或少數(shù)幾個）字段全部關(guān)聯(lián)起來，所以很難簡單的僅僅通過數(shù)據(jù)的水平切分來解決所有問題。而垂直切分也只能解決部分問題，對于那些負載非常高的系統(tǒng)，即使僅僅只是單個表都無法通過單臺數(shù)據(jù)庫主機來承擔其負載。我們必須結(jié)合“垂直”和“水平”兩種切分方式同時使用 每一個應(yīng)用系統(tǒng)的負載都是一步一步增長上來的，在開始遇到性能瓶頸的時候，大多數(shù)架構(gòu)師和DBA都會選擇先進行數(shù)據(jù)的垂直拆分，因為這樣的成本最先，最符合這個時期所追求的最大投入產(chǎn)出比。然而，隨著業(yè)務(wù)的不斷擴張，系統(tǒng)負載的持續(xù)增長，在系統(tǒng)穩(wěn)定一段時期之后，經(jīng)過了垂直拆分之后的數(shù)據(jù)庫集群可能又再一次不堪重負，遇到了性能瓶頸。 ==>如果我們再一次像最開始那樣繼續(xù)細分模塊，進行數(shù)據(jù)的垂直切分，那我們可能在不久的將來，又會遇到現(xiàn)在所面對的同樣的問題。而且隨著模塊的不斷的細化，應(yīng)用系統(tǒng)的架構(gòu)也會越來越復(fù)雜，整個系統(tǒng)很可能會出現(xiàn)失控的局面。 ==>這時候我們就必須要通過數(shù)據(jù)的水平切分的優(yōu)勢，來解決這里所遇到的問題。而且，我們完全不必要在使用數(shù)據(jù)水平切分的時候，推倒之前進行數(shù)據(jù)垂直切分的成果，而是在其基礎(chǔ)上利用水平切分的優(yōu)勢來避開垂直切分的弊端，解決系統(tǒng)復(fù)雜性不斷擴大的問題。而水平拆分的弊端（規(guī)則難以統(tǒng)一）也已經(jīng)被之前的垂直切分解決掉了，讓水平拆分可以進行的得心應(yīng)手。 示例數(shù)據(jù)庫: 假設(shè)在最開始，我們進行了數(shù)據(jù)的垂直切分，然而隨著業(yè)務(wù)的不斷增長，數(shù)據(jù)庫系統(tǒng)遇到了瓶頸，我們選擇重構(gòu)數(shù)據(jù)庫集群的架構(gòu)。如何重構(gòu)？考慮到之前已經(jīng)做好了數(shù)據(jù)的垂直切分，而且模塊結(jié)構(gòu)清晰明確。而業(yè)務(wù)增長的勢頭越來越猛，即使現(xiàn)在進一步再次拆分模塊，也堅持不了太久。 ==>選擇了在垂直切分的基礎(chǔ)上再進行水平拆分。 ==>在經(jīng)歷過垂直拆分后的各個數(shù)據(jù)庫集群中的每一個都只有一個功能模塊，而每個功能模塊中的所有表基本上都會與某個字段進行關(guān)聯(lián)。如用戶模塊全部都可以通過用戶ID進行切分，群組討論模塊則都通過群組ID來切分，相冊模塊則根據(jù)相冊ID來進切分，最后的事件通知信息表考慮到數(shù)據(jù)的時限性（僅僅只會訪問最近某個事件段的信息），則考慮按時間來切分。 數(shù)據(jù)切分以及整合方案. 數(shù)據(jù)庫中的數(shù)據(jù)在經(jīng)過垂直和（或）水平切分被存放在不同的數(shù)據(jù)庫主機之后，應(yīng)用系統(tǒng)面臨的最大問題就是如何來讓這些數(shù)據(jù)源得到較好的整合 存在兩種解決思路： 1.在每個應(yīng)用程序模塊中配置管理自己需要的一個（或者多個）數(shù)據(jù)源，直接訪問各個數(shù)據(jù)庫，在模塊內(nèi)完成數(shù)據(jù)的整合； 2.通過中間代理層來統(tǒng)一管理所有的數(shù)據(jù)源，后端數(shù)據(jù)庫集群對前端應(yīng)用程序透明； 第二種方案,雖然短期內(nèi)需要付出的成本可能會相對更大一些，但是對整個系統(tǒng)的擴展性來說，是非常有幫助的。 針對第二種方案: 1.利用MySQLProxy 實現(xiàn)數(shù)據(jù)切分及整合. 可用來監(jiān)視、分析或者傳輸他們之間的通訊信息。他的靈活性允許你最大限度的使用它，目前具備的功能主要有連接路由，Query分析，Query過濾和修改，負載均衡，以及基本的HA機制等。 MySQLProxy 本身并不具有上述所有的這些功能，而是提供了實現(xiàn)上述功能的基礎(chǔ)。要實現(xiàn)這些功能，還需要通過我們自行編寫LUA腳本來實現(xiàn)。 原理: MySQLProxy 實際上是在客戶端請求與MySQLServer 之間建立了一個連接池。所有客戶端請求都是發(fā)向MySQLProxy，然后經(jīng)由MySQLProxy 進行相應(yīng)的分析，判斷出是讀操作還是寫操作，分發(fā)至對應(yīng)的MySQLServer 上。對于多節(jié)點Slave集群，也可以起做到負載均衡的效果。 2.利用Amoeba實現(xiàn)數(shù)據(jù)切分及整合 Amoeba是一個基于Java開發(fā)的，專注于解決分布式數(shù)據(jù)庫數(shù)據(jù)源整合Proxy程序的開源框架 Amoeba已經(jīng)具有Query路由，Query過濾，讀寫分離，負載均衡以及HA機制等相關(guān)內(nèi)容。 Amoeba主要解決的以下幾個問題： a)數(shù)據(jù)切分后復(fù)雜數(shù)據(jù)源整合； b)提供數(shù)據(jù)切分規(guī)則并降低數(shù)據(jù)切分規(guī)則給數(shù)據(jù)庫帶來的影響； c)降低數(shù)據(jù)庫與客戶端的連接數(shù)； d)讀寫分離路由； AmoebaFor MySQL 主要是專門針對MySQL數(shù)據(jù)庫的解決方案，前端應(yīng)用程序請求的協(xié)議以及后端連接的數(shù)據(jù)源數(shù)據(jù)庫都必須是MySQL。對于客戶端的任何應(yīng)用程序來說，AmoebaForMySQL 和一個MySQL數(shù)據(jù)庫沒有什么區(qū)別，任何使用MySQL協(xié)議的客戶端請求，都可以被AmoebaFor MySQL 解析并進行相應(yīng)的處理。 AmoebaFor MySQL 的使用非常簡單，所有的配置文件都是標準的XML文件，總共有四個配置文件。分別為： ◆ amoeba.xml：主配置文件，配置所有數(shù)據(jù)源以及Amoeba自身的參數(shù)設(shè)置； ◆ rule.xml：配置所有Query路由規(guī)則的信息； ◆ functionMap.xml：配置用于解析Query中的函數(shù)所對應(yīng)的Java實現(xiàn)類； ◆rullFunctionMap.xml：配置路由規(guī)則中需要使用到的特定函數(shù)的實現(xiàn)類； Proxy程序常用的功能如讀寫分離，負載均衡等配置都在amoeba.xml中進行。Amoeba已經(jīng)支持了實現(xiàn)數(shù)據(jù)的垂直切分和水平切分的自動路由，路由規(guī)則可以在rule.xml進行設(shè)置。 3.利用HiveDB實現(xiàn)數(shù)據(jù)切分及整合 HiveDB同樣是一個基于Java針對MySQL數(shù)據(jù)庫的提供數(shù)據(jù)切分及整合的開源框架，只是目前的HiveDB僅僅支持數(shù)據(jù)的水平切分。主要解決大數(shù)據(jù)量下數(shù)據(jù)庫的擴展性及數(shù)據(jù)的高性能訪問問題，同時支持數(shù)據(jù)的冗余及基本的HA機制。 HiveDB的實現(xiàn)機制與MySQLProxy 和Amoeba有一定的差異，他并不是借助MySQL的Replication功能來實現(xiàn)數(shù)據(jù)的冗余，而是自行實現(xiàn)了數(shù)據(jù)冗余機制，而其底層主要是基于HibernateShards 來實現(xiàn)的數(shù)據(jù)切分工作。 數(shù)據(jù)切分與整合中可能存在的問題 ◆ 引入分布式事務(wù)的問題； ◆ 跨節(jié)點Join的問題； ◆ 跨節(jié)點合并排序分頁問題； 引入分布式事務(wù)的問題? 一旦數(shù)據(jù)進行切分被分別存放在多個MySQLServer中之后，不管我們的切分規(guī)則設(shè)計的多么的完美（實際上并不存在完美的切分規(guī)則），都可能造成之前的某些事務(wù)所涉及到的數(shù)據(jù)已經(jīng)不在同一個MySQLServer 中了。 ==>將一個跨多個數(shù)據(jù)庫的分布式事務(wù)分拆成多個僅處于單個數(shù)據(jù)庫上面的小事務(wù)，并通過應(yīng)用程序來總控各個小事務(wù)。 跨節(jié)點Join的問題? ==>先從一個節(jié)點取出數(shù)據(jù),然后根據(jù)這些數(shù)據(jù),再到另一個表中取數(shù)據(jù). ==>使用Federated存儲引擎,問題是:乎如果遠端的表結(jié)構(gòu)發(fā)生了變更，本地的表定義信息是不會跟著發(fā)生相應(yīng)變化的。 跨節(jié)點合并排序分頁問題? ==>Join本身涉及到的多個表之間的數(shù)據(jù)讀取一般都會存在一個順序關(guān)系。但是排序分頁就不太一樣了，排序分頁的數(shù)據(jù)源基本上可以說是一個表（或者一個結(jié)果集），本身并不存在一個順序關(guān)系，所以在從多個數(shù)據(jù)源取數(shù)據(jù)的過程是完全可以并行的。這樣，排序分頁數(shù)據(jù)的取數(shù)效率我們可以做的比跨庫Join更高，所以帶來的性能損失相對的要更小。 架構(gòu)篇（4） 讀書筆記 分布式內(nèi)存Cache軟件Memcached: 1.作為提升系統(tǒng)性能的Cache工具: 如果我們將Memcached作為應(yīng)用系統(tǒng)的一個數(shù)據(jù)Cache服務(wù)，那么對于MySQL數(shù)據(jù)庫來說基本上不用做任何改造，僅僅通過應(yīng)用程序自己來對這個Cache進行維護更新。這樣作最大的好處就在于可以做到完全不用動數(shù)據(jù)庫相關(guān)的架構(gòu)，但是同時也會有一個弊端，那就是如果需要Cache的數(shù)據(jù)對象較多的時候，應(yīng)用程序所需要增加的代碼量就會增加很多，同時系統(tǒng)復(fù)雜度以及維護成本也會直線上升。 架構(gòu)圖: appserver ---> ds proxy layer ---> db master --> db slave1 | |--> db slave2 | |---> memcached1 |---> memcached2 整體來看: 所有數(shù)據(jù)都會寫入MySQLMaster 中，包括數(shù)據(jù)第一次寫入時候的INSERT，同時也包括對已有數(shù)據(jù)的UPDATE和DELETE。 如果是對已經(jīng)存在的數(shù)據(jù)，則需要在UPDATE或者DELETEMySQL 中數(shù)據(jù)的同時，刪除Memcached中的數(shù)據(jù)，以此保證整體數(shù)據(jù)的一致性。 所有的讀請求首先會發(fā)往Memcached中，如果讀取到數(shù)據(jù)則直接返回，如果沒有讀取到數(shù)據(jù)，則再到MySQLSlaves 中讀取數(shù)據(jù)，并將讀取得到的數(shù)據(jù)寫入到Memcached中進行Cache。 這種使用方式一般來說比較適用于需要緩存對象類型少，而需要緩存的數(shù)據(jù)量又比較大的環(huán)境，是一個快速有效的完全針對性能問題的解決方案。 2.和MySQL整合為數(shù)據(jù)服務(wù)層 有兩種方式將Memcached和MySQL數(shù)據(jù)庫整合成一個整體來對外提供數(shù)據(jù)服務(wù): 直接利用Memcached的內(nèi)存容量作為MySQL數(shù)據(jù)庫的二級緩存，提升MySQLServer的緩存大小， 通過MySQL的UDF來和Memcached進行數(shù)據(jù)通信，維護和更新Memcached中的數(shù)據(jù)，而應(yīng)用端則直接通過Memcached來讀取數(shù)據(jù)。 第一種方式，主要用于業(yè)務(wù)要求非常特殊，實在難以進行數(shù)據(jù)切分，而且有很難通過對應(yīng)用程序進行改造利用上數(shù)據(jù)庫之外的Cache的場景。 ==>通過開源項目WaffleGrid實現(xiàn),將Memcached成功實現(xiàn)成為MySQL主機的外部“二級緩存”，目前僅支持用于Innodb的BufferPool。 架構(gòu)圖: appserver ---> ds proxy layer ---->Waffle Grid --->memcached1 |---> memcached2 |---> memcached3 |---> memcached4 |---> memcached5 這里面所有的memcached都是innodb的外部bufferpool, 而memcached和mysql之間一定要使用具有高帶寬的私有網(wǎng)絡(luò). 第二種方案: 是通過MySQL所提供的UDF功能，自行編寫相應(yīng)的程序來實現(xiàn)MySQL與Memcached的數(shù)據(jù)通信更新操作。 原理: 這種方式和WaffleGrid 不一樣的是Memcached中的數(shù)據(jù)并不完全由MySQL來控制維護，而是由應(yīng)用程序和MySQL一起來維護數(shù)據(jù)。每次應(yīng)用程序從Memcached讀取數(shù)據(jù)的時候，如果發(fā)現(xiàn)找不到自己需要的數(shù)據(jù)，則再轉(zhuǎn)為從數(shù)據(jù)庫中讀取數(shù)據(jù)，然后將讀取到的數(shù)據(jù)寫入Memcached中。而MySQL則控制Memcached中數(shù)據(jù)的失效清理工作，每次數(shù)據(jù)庫中有數(shù)據(jù)被更新或者被刪除的時候，MySQL則通過用戶自行編寫的UDF(user define unction) 來調(diào)用Memcached的API來通知Memcached某些數(shù)據(jù)已經(jīng)失效并刪除該數(shù)據(jù)。 對于使用Memcached等感到成本高,可以考慮使用BerkeleyDB, TokyoTyrant 使用Search: 使用搜索引擎來提供全文檢索.主要是基于Lucene. 把數(shù)據(jù)庫的數(shù)據(jù)通過應(yīng)用程序調(diào)用Lucene的相關(guān)API寫入，并利用Lucene創(chuàng)建好索引，然后就可以通過調(diào)用Lucene所提供的數(shù)據(jù)檢索API得到需要訪問的數(shù)據(jù)，而且可以進行全模糊匹配 雖然Lucene的數(shù)據(jù)也是存放在磁盤上而不是內(nèi)存中，但是由于高效的分詞算法和索引結(jié)構(gòu)，其效率也是非常的好。?？吹胶芏嗑W(wǎng)友在網(wǎng)上討論，當數(shù)據(jù)量稍微大一些如幾十個G之后Lucene的效率會下降的非?？欤鋵嵾@是不科學的說法，就從我親眼所見的場景中，就有好幾百G的數(shù)據(jù)在Lucene中，性能仍然很出色。這幾年性能優(yōu)化的工作經(jīng)歷及經(jīng)驗中我有一個很深的體會，那就是一個軟件性能的好壞，實際上并不僅僅只由其本身所決定，很多時候一個非常高效的軟件不同的人使用會有截然不同效果。所以，很多時候當我們使用的第三方軟件性能出現(xiàn)問題的時候，不要急著下結(jié)論認為是這個軟件的問題，更多的是先從自身找找看我們是否真的正確使用了他。 除了使用第三方的Search軟件如Lucene之外，我們也可以自行研發(fā)更適用于我們自身應(yīng)用場景的Search軟件。比如:自行研發(fā)了一套純內(nèi)存存儲的更適合于自身應(yīng)用場景的高性能分布式Search軟件 自行實現(xiàn)Cache服務(wù): 如果目前的第三方軟件已經(jīng)基本解決了我們系統(tǒng)當前遇到的80%以上的問題，可能就需要考慮是否有必要完全自主研發(fā)了。 利用分布式用分布式并行計算實現(xiàn)大數(shù)據(jù)量的高性能運算: MapReduce(任務(wù)分解和任務(wù)合并功能)+ HDFS(分布式文件系統(tǒng))+ Hbase(高性能的分布式數(shù)據(jù)庫) 架構(gòu)篇（5） 讀書筆記 任何設(shè)備（或服務(wù)），只要是單點，就存在著很大的安全隱患。因為一旦這臺設(shè)備（或服務(wù)）crash之后，在短時間內(nèi)就很難有備用設(shè)備（或服務(wù)）來頂替其功能。所以稍微重要一些的服務(wù)器或者應(yīng)用系統(tǒng)，都會存在至少一個備份以供出現(xiàn)異常的時候能夠很快的頂替上來提供服務(wù)。 對于數(shù)據(jù)庫來說，主備配置是非常常見的設(shè)計思路。而對于MySQL來說，其Replication功能在實際應(yīng)用中被廣泛的用來實現(xiàn)主備配置的功能。 常規(guī)的Master- Slave 解決基本的主備設(shè)計: 在普通的一個Master后面復(fù)制一個或者多個Slave的架構(gòu)設(shè)計中，當我們的某一臺Slave出現(xiàn)故障不能提供服務(wù)之后，我們還有至少一臺MySQL服務(wù)器（Master）可以提供服務(wù)，不至于所有和數(shù)據(jù)庫相關(guān)的業(yè)務(wù)都不能運行下去。如果Slave超過一臺，那么剩下的Slave也仍然能夠不受任何干擾的繼續(xù)提供服務(wù)。 這種架構(gòu)方式很容易解決Slave出現(xiàn)故障的情況，而且不需要進行任何調(diào)整就能繼續(xù)提供服務(wù)。 Master單點問題的解決: 兩種解決方案: a)將Slave中的某一臺切換成Master對外提供服務(wù)，同時將其他所有的Slave都以通過CHANGEMASTER 命令來將通過新的Master進行復(fù)制。 b)新增一臺Master，也就是DualMaster 的解決方案。 c)方案最大的一個弊端就是切換步驟比較多，實現(xiàn)比較復(fù)雜。而且，在Master出現(xiàn)故障crash的那個時刻，我們的所有Slave的復(fù)制進度并不一定完全一致，有可能有少量的差異。這時候，選擇哪一個Slave作為Master也是一個比較頭疼的問題。所以這個方案的可控性并不是特別的高。 b)方案實際上就是通過DualMaster 來解決Master單點問題 通過兩臺MySQLServer 搭建成DualMaster 環(huán)境，正常情況下，所有客戶端的Write請求都寫往MasterA，然后通過Replication將MasterA 復(fù)制到MasterB。一旦MasterA 出現(xiàn)問題之后，所有的Write請求都轉(zhuǎn)向MasterB。而在正常情況下，當MasterB 出現(xiàn)問題的時候，實際上不論是數(shù)據(jù)庫還是客戶端的請求，都不會受到實質(zhì)性的影響。 當我們的MasterA 出現(xiàn)問題的時候，應(yīng)用如何做到自動將請求轉(zhuǎn)向到MasterB 呢？ ==>只需要通過相應(yīng)的硬件設(shè)備如F5或者Cluster管理軟件如Heartbeat來設(shè)置一個VIP，正常情況下該VIP指向MasterA，而一旦MasterA 出現(xiàn)異常crash之后，則自動切換指向到MasterB，前端所的應(yīng)用都通過這個VIP來訪問Master。 DualMaster 與級聯(lián)復(fù)制結(jié)合解決異常故障下的高可用: 通過前面的架構(gòu)分析，我們分別得到了Slave出現(xiàn)故障后的解決方案，也解決了Master的單點問題?，F(xiàn)在我們再通過DualMaster 與級聯(lián)復(fù)制結(jié)合的架構(gòu)，來得到一個整體的解決方案，解決系統(tǒng)整體可靠性的問題。 首先考慮Slave出現(xiàn)異常的情況。 在這個架構(gòu)中，Slave出現(xiàn)異常后的處理情況和普通的Master- Slave 架構(gòu)的處理方式完全一樣，僅僅需要在應(yīng)用訪問Slave集群的訪問配置中去掉一個Slave節(jié)點即可解決，不論是通過應(yīng)用程序自己判斷，還是通過硬件解決方案如F5都可以很容易的實現(xiàn)。 當MasterA 出現(xiàn)故障crash之后，MasterA 與MasterB 之間的復(fù)制將中斷，所有客戶端向MasterA 的Write請求都必須轉(zhuǎn)向MasterB。這個轉(zhuǎn)向動作的實現(xiàn)，可以通過上面介紹的第二中方案中所介紹的通過VIP的方式實現(xiàn)。由于之前所有的Slave就都是從MasterB 來實現(xiàn)復(fù)制，所以Slave集群不會受到任何的影響，客戶端的所有Read請求也就不會受到任何的影響，整個過程可以完全自動進行，不需要任何的人為干預(yù)。不過這里有一個隱患就是當MasterA crash 的時候如果MasterB 作為Slave的IO線程如果還沒有讀取完MasterA 的二進制日志的話，就會出現(xiàn)數(shù)據(jù)丟失的問題。要完全解決這個問題，我們只能通過第三方patch（google開發(fā)）來鏡像MySQL的二進制日志到MasterB上面，才能完全避免不丟失任何數(shù)據(jù)。 那么當MasterB 出現(xiàn)故障crash之后的情況又如何呢？ 首先可以確定的是我們的所有Write請求都不會受到任何影響，而且所有的Read請求也都還是能夠正常訪問。但所有Slave的復(fù)制都會中斷，Slave上面的數(shù)據(jù)會開始出現(xiàn)滯后的現(xiàn)象。這時候我們需要做的就是將所有的Slave進行CHANGEMASTER TO 操作，改為從MasterA 進行復(fù)制。由于所有Slave的復(fù)制都不可能超前最初的數(shù)據(jù)源，所以可以根據(jù)Slave上面的RelayLog中的時間戳信息與MasterA 中的時間戳信息進行對照來找到準確的復(fù)制起始點，不會造成任何的數(shù)據(jù)丟失。 DualMaster 與級聯(lián)復(fù)制結(jié)合解決在線DDL變更問題: 使用DualMaster 加級聯(lián)復(fù)制的組合架構(gòu)的時候，對于MySQL的一個致命傷也就是在線DDL變更來說，也可以得到一定的解決。如當我們需要給某個表tab增加一個字段，可以通過如下在上述架構(gòu)中來實現(xiàn)： 1、在Slave集群中抽出一臺暫時停止提供服務(wù)，然后對其進行變更，完成后再放回集群繼續(xù)提供服務(wù)； 2、重復(fù)第一步的操作完成所有Slave的變更； 3、暫停MasterB 的復(fù)制，同時關(guān)閉當前session記錄二進制日志的功能，對其進行變更，完成后再啟動復(fù)制； 4、通過VIP切換，將應(yīng)用所有對MasterA 的請求切換至MasterB； 5、關(guān)閉MasterA 當前session記錄二進制日志的功能，然后進行變更； 6、最后再將VIP從MasterB 切換回MasterA，至此，所有變更完成。 變更過程中有幾點需要注意的： 1、整個Slave集群需要能夠承受在少一臺MySQL的時候仍然能夠支撐所有業(yè)務(wù)； 2、Slave集群中增加或者減少一臺MySQL的操作簡單，可通過在線調(diào)整應(yīng)用配置來實現(xiàn)； 3、DualMaster 之間的VIP切換簡單，且切換時間較短，因為這個切換過程會造成短時間段內(nèi)應(yīng)用無法訪問Master數(shù)據(jù)庫。 4、在變更MasterB 的時候，會出現(xiàn)短時間段內(nèi)Slave集群數(shù)據(jù)的延時，所以如果單臺主機的變更時間較長的話，需要在業(yè)務(wù)量較低的凌晨進行變更。如果有必要，甚至可能需要變更MasterB 之前將所有Slave切換為以MasterB 作為Master。 使用DRBD保證數(shù)據(jù)的高可靠: 在MySQL的官方文檔手冊的HighAvailability and Scalability 這一章中將DRBD作為MySQL實現(xiàn)高可用性的一個非常重要的方式來介紹的。 DRBD其實就是通過網(wǎng)絡(luò)來實現(xiàn)塊設(shè)備的數(shù)據(jù)鏡像同步的一款開源Cluster軟件，也被俗稱為網(wǎng)絡(luò)RAID1。 DRBD介于文件系統(tǒng)與磁盤介質(zhì)之間，通過捕獲上層文件系統(tǒng)的所有IO操作，然后調(diào)用內(nèi)核中的IO模塊來讀寫底層的磁盤介質(zhì)。當DRBD捕獲到文件系統(tǒng)的寫操作之后，會在進行本地的磁盤寫操作的同時，以TCP/IP協(xié)議將，通過本地主機的網(wǎng)絡(luò)設(shè)備（NIC）將IO傳遞至遠程主機的網(wǎng)絡(luò)設(shè)備。當遠程主機的DRBD監(jiān)聽到傳遞過來的IO信息之后，會立即將該數(shù)據(jù)寫入到該DRBD所維護的磁盤設(shè)備。至此，整個IO才做完成。 DRBD在處理遠程數(shù)據(jù)寫入的時候有三種復(fù)制模式（或者稱為級別）可以選擇，不同的復(fù)制模式保證了遠程數(shù)據(jù)寫入的三種可靠性。三種級別的選擇可以通過DRBD的通用配置部分的protocal。不同的復(fù)制模式，實際上是影響了一個IO完成所代表的實際含義。因為當我們使用DRBD的時候，一個IO完成的標識（DRBD返回IO完成）是本地寫入和遠程寫入這兩個并發(fā)進程都返回完成標識。下面我來詳細介紹一下這三種復(fù)制模式所代表的含義： ProtocolA：這種模式是可靠性最低的模式，而且是一個異步的模式。當我們使用這個模式來配置的時候，寫遠程數(shù)據(jù)的進程將數(shù)據(jù)通過TCP/IP協(xié)議發(fā)送進入本地主機的TCPsendbuffer 中，即返回完成。 ProtocolB：這種模式相對于ProtocolA 來說，可靠性要更高一些。因為寫入遠程的線程會等待網(wǎng)絡(luò)信息傳輸完成，也就是數(shù)據(jù)已經(jīng)被遠程的DRBD接受到之后返回完成。 ProtocolC：ProtocolC 復(fù)制模式是真正完全的同步復(fù)制模式，只有當遠程的DRBD將數(shù)據(jù)完全寫入磁盤成功后，才會返回完成。 其他高可用方案: RaiDB:其全稱為RedundantArrays of Inexpensive Databases。也就是通過Raid理念來管理數(shù)據(jù)庫的數(shù)據(jù) raiddb-0: sqlrequest --> raidb controller --> table 1 --> table 2 --> table 3 raiddb-1: sqlrequest --> raidb controller --> db full --> db full --> db full raiddb-2: sqlrequest --> raidb controller --> db full --> table 1 --> table 2 raiddb-0-1: sqlrequest --> raidb controller 0 --->raidb-1 controler -->table1 --> table1 --->raidb-1 controler --> table2 --> table2 --->raidb-1 controler --> table3 --> table3 raiddb-1-0: sqlrequest --> raidb controller 1 --> raidb controller 0 -->table 1 --> table 2 --> table 3 --> raidb controller 0 --> table 1 --> table 2 --> table 3 --> raidb controller 0 --> table 1 --> table 2 --> table 3 方案比較: 1、MySQLReplication 優(yōu)勢：部署簡單，實施方便，維護也不復(fù)雜，是MySQL天生就支持的功能。且主備機之間切換方便，可以通過第三方軟件或者自行編寫簡單的腳本即可自動完成主備切換。 劣勢：如果Master主機硬件故障且無法恢復(fù)，則可能造成部分未傳送到Slave端的數(shù)據(jù)丟失； 2、MySQLCluster 優(yōu)勢：可用性非常高，性能非常好。每一分數(shù)據(jù)至少在不同主機上面存在一份拷貝，且冗余數(shù)據(jù)拷貝實時同步。 劣勢：維護較為復(fù)雜，產(chǎn)品還比較新，存在部分bug，目前還不一定適用于比較核心的線上系統(tǒng)。 3、DRBD磁盤網(wǎng)絡(luò)鏡像方案 優(yōu)勢：軟件功能強大，數(shù)據(jù)在底層快設(shè)備級別跨物理主機鏡像，且可根據(jù)性能和可靠性要求配置不同級別的同步。IO操作保持順序，可滿足數(shù)據(jù)庫對數(shù)據(jù)一致性的苛刻要求。 劣勢：非分布式文件系統(tǒng)環(huán)境無法支持鏡像數(shù)據(jù)同時可見，性能和可靠性兩者相互矛盾，無法適用于性能和可靠性要求都比較苛刻的環(huán)境。維護成本高于MySQLReplication。 一個經(jīng)過高可用可擴展設(shè)計的MySQL數(shù)據(jù)庫集群，如果沒有一個足夠精細足夠強大的監(jiān)控系統(tǒng)，同樣可能會讓之前在高可用設(shè)計方面所做的努力功虧一簣。 MySQL分布式集群的監(jiān)控系統(tǒng)整體架構(gòu)體系: mysqldb--->| mysqldb--->| |-->報警 mysqldb--->|---->信息采集 --->信息存儲 --->|-->狀態(tài) mysqldb--->| |-->趨勢 mysqldb--->| 信息采集: 一般來說，較小規(guī)模的監(jiān)控點可以采用輪詢的方式主動采集數(shù)據(jù)，但是當監(jiān)控點達到一定規(guī)模以后，輪詢的主動采集方式可能就會遇到一定的性能瓶頸和信息延時問題，尤其是當需要采集的數(shù)據(jù)比較多的時候尤為突出。而如果要采用從各個MySQL節(jié)點進行被動的推送，則可能需要開發(fā)能夠支持網(wǎng)絡(luò)通信的監(jiān)控程序，使采集的信息能夠順利的到達信息分析模塊以即時得到分析，成本會稍微高一些。 不論是采用主動還是被動的方式來進行數(shù)據(jù)采集，我們都需要在監(jiān)控主機上面部署采集相關(guān)信息的程序或腳本，包括主機信息和數(shù)據(jù)庫信息。 主機健康狀態(tài)監(jiān)控: ●網(wǎng)絡(luò)通信：網(wǎng)絡(luò)通信基本上可以說是最容易檢測的了，基本上只需要通過網(wǎng)絡(luò)ping就可以獲知是否正常。 ●系統(tǒng)軟硬件錯誤：系統(tǒng)軟硬件錯誤，一般使用文本監(jiān)控軟件，如sec、logwatch等日志監(jiān)控專用軟件，通過配置相應(yīng)的匹配規(guī)則，從日志文件中捕獲滿足條件的錯誤信息，再發(fā)送給信息分析模塊。 ● 磁盤空間：對于磁盤空間的使用狀況監(jiān)控，我們通過最簡單的shell腳本就可以輕松搞定 ●內(nèi)存使用：系統(tǒng)物理內(nèi)存使用量的信息采集同樣非常簡單，只需要一個基本的系統(tǒng)命令“free”，就可以獲得當前系統(tǒng)內(nèi)存總量，剩余使用量，以及文件系統(tǒng)的buffer和cache兩者使用量。 ●進程數(shù)量：系統(tǒng)進程總數(shù)，或者某個用戶下的進程數(shù)，都可以通過“ps”命令經(jīng)過簡單的處理來獲得。 數(shù)據(jù)庫健康狀態(tài)信息 服務(wù)端口（3306）服務(wù)端口狀態(tài)的監(jiān)控和主機網(wǎng)絡(luò)連接的監(jiān)控同樣非常簡單，只需要對3306端口進行telnet嘗試即可。 mysqld和mysqld_safe進程：mysqld進程是MySQLServer 最核心的進程。mysqld進程crash或者出現(xiàn)異常，MySQLServer 基本上也就無法正常提供服務(wù)了。當然，如果我們是通過mysqld_safe來啟動MySQLServer，則mysqld_safe會幫助我們來監(jiān)控mysqld進程的狀態(tài)，當mysqld進程crash之后，mysqld_safe會馬上幫助我們重啟mysqld進程。 Errorlog：Errorlog 的監(jiān)控目的主要是即時檢測MySQLServer 運行過程中發(fā)生的各種錯誤，如連接異常，系統(tǒng)bug等。 復(fù)制狀態(tài)：如果我們的MySQL數(shù)據(jù)庫環(huán)境使用了MySQLReplication，就必須增加對Slave復(fù)制狀態(tài)的監(jiān)控。對Slave的復(fù)制狀態(tài)的監(jiān)控包括對IO線程和SQL線程二者的運行狀態(tài)的監(jiān)控。當然，如果希望能夠監(jiān)控Replication更多的信息，如兩個線程各自運行的進度等，同樣可以在Slave節(jié)點上執(zhí)行相應(yīng)命令輕松得到 sky@localhost: (none) 04:30:38> show slave status\G 性能狀態(tài)監(jiān)控: 系統(tǒng)load值：系統(tǒng)load所包含的最關(guān)鍵含義是CPU運行等待的數(shù)量， sky@sky:~$uptime 17:27:44up 4:12, 3 users, load average: 0.87, 0.66, 0.61 “l(fā)oadaverage: 0.87, 0.66, 0.61”中的三個數(shù)字，分別代表了1秒、5秒和15秒的load平均值。 CPU使用率:最為常用的方法是使用命令top和vmstat來獲取。 磁盤IO量：可以通過vmstat, iostat來獲取 swap進出量:swap 的使用主要表現(xiàn)了系統(tǒng)在物理內(nèi)存不夠的情況下使用虛擬內(nèi)存的情況。 free命令只能獲得當前系統(tǒng)swap的總體使用量。如果希望獲得實時的swap使用變化，還是得依賴vmstat來得到 網(wǎng)絡(luò)流量：第三方軟件如ifstat、iftop和nload 數(shù)據(jù)庫性能狀態(tài): MySQL數(shù)據(jù)庫的性能狀態(tài)監(jiān)控點非常之多，其中很多量都是我們不能忽視的必須監(jiān)控的量，且90%以上的內(nèi)容可以在連接上MySQLServer 后執(zhí)行“SHOW/*!50000 GLOBAL */STATUS” 以及“SHOW/*!50000 GLOBAL */ VARIABLES”的輸出值獲得。需要注意的是上述命令所獲得狀態(tài)值實際上是累計值，所以如果要計算(單位/某個)時間段內(nèi)的變化量還需要稍加處理，可以在附錄中找到兩個命令輸出值的詳細說明。下面看看幾項需要重點關(guān)注的性能狀態(tài)： QPS（每秒Query量）： QPS= Questions(or Queries) / Seconds 獲取所需狀態(tài)變量值： SHOW/*!50000 GLOBAL */ STATUS LIKE 'Questions' SHOW/*!50000 GLOBAL */ STATUS LIKE 'Queries' TPS（每秒事務(wù)量）：在MySQLServer 中并沒有直接事務(wù)計數(shù)器，我們只能通過回滾和提交計數(shù)器來計算出系統(tǒng)的事務(wù)量。 TPS= (Com_commit + Com_rollback) / Seconds KeyBuffer 命中率：KeyBuffer 命中率代表了MyISAM類型表的索引的Cache命中率。該命中率的大小將直接影響MyISAM類型表的讀寫性能。 key_buffer_read_hits= (1 - Key_reads / Key_read_requests) * 100% key_buffer_write_hits=(1 - Key_writes / Key_write_requests) * 100% mysq>SHOW/*!50000 GLOBAL */ STATUS ->LIKE 'Key%'; ----------------------------------- |Key_read_requests | 10 | |Key_reads | 4 | |Key_write_requests | 0 | |Key_writes | 0 | +------------------------+-------+ InnodbBuffer 命中率: 這里InnodbBuffer 所指的是innodb_buffer_pool，也就是用來緩存Innodb類型表的數(shù)據(jù)和索引的內(nèi)存空間。 innodb_buffer_read_hits=(1-Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests)* 100% mysql> SHOW /*!50000 GLOBAL*/ STATUS ->LIKE 'Innodb_buffer_pool_read%'; |Innodb_buffer_pool_read_requests | 5367 | |Innodb_buffer_pool_reads | 507 | +-----------------------------------+-------+ QueryCache 命中率： Query_cache_hits=(Qcache_hits / (Qcache_hits + Qcache_inserts)) * 100% mysql> SHOW /*!50000 GLOBAL*/ STATUS ->LIKE 'Qcache%'; |Qcache_hits | 0 | |Qcache_inserts | 0 | TableCache 狀態(tài)量: 判斷系統(tǒng)參數(shù)table_open_cache的設(shè)置是否合理。Open_tables與Opened_tables之間的比率過低，則代表TableCache 設(shè)置過小，個人認為該值處于80%左右比較合適。 mysql>SHOW /*!50000 GLOBAL*/ STATUS ->LIKE 'Open%'; |Open_tables | 51 | Opened_tables| 61 | ThreadCache 命中率： ThreadCache 命中率能夠直接反應(yīng)出我們的系統(tǒng)參數(shù)thread_cache_size設(shè)置的是否合理.一個合理的thread_cache_size參數(shù)能夠節(jié)約大量創(chuàng)建新連接時所需要消耗的資源。 Thread_cache_hits= (1 - Threads_created / Connections) * 100% mysql> SHOW /*!50000 GLOBAL*/ STATUS ->LIKE 'Thread%'; |Threads_created | 3 | mysql> SHOW /*!50000 GLOBAL*/ STATUS ->LIKE 'Connections'; Connections| 11 | 鎖定狀態(tài)：鎖定狀態(tài)包括表鎖和行鎖兩種 mysql> SHOW /*!50000 GLOBAL*/ STATUS ->LIKE '%lock%'; |Innodb_row_lock_current_waits | 0 | |Innodb_row_lock_time | 0 | |Innodb_row_lock_time_avg | 0 | |Innodb_row_lock_time_max | 0 | |Innodb_row_lock_waits | 0 | |Table_locks_immediate | 44 | |Table_locks_waited | 0 | 如當Table_locks_waited與Table_locks_immediate的比值較大，則說明我們的表鎖造成的阻塞比較嚴重 Innodb_row_lock_waits較大，則說明Innodb的行鎖也比較嚴重，且影響了其他線程的正常處理 復(fù)制延時量：復(fù)制延時量將直接影響了Slave數(shù)據(jù)庫處于不一致狀態(tài)的時間長短。如果我們是通過Slave來提供讀服務(wù)，就不得不重視這個延時量?？梢酝ㄟ^在Slave節(jié)點上執(zhí)行“SHOWSLAVE STATUS”命令，取Seconds_Behind_Master項的值來了解Slave當前的延時量（單位：秒） Tmptable 狀況： TmpTable 的狀況主要是用于監(jiān)控MySQL使用臨時表的量是否過多，是否有臨時表過大而不得不從內(nèi)存中換出到磁盤文件上。 mysql> SHOW /*!50000 GLOBAL*/ STATUS ->LIKE 'Created_tmp%'; Created_tmp_disk_tables| 1 | Created_tmp_tables | 46 | 從上面可以看出系統(tǒng)使用了46次臨時表，其中有1次臨時表比較大，無法在內(nèi)存中完成，而不得不使用到磁盤文件 BinlogCache 使用狀況：BinlogCache 用于存放還未寫入磁盤的Binlog信息。 mysql> SHOW /*!50000 GLOBAL*/ STATUS ->LIKE 'Binlog_cache%'; |Binlog_cache_disk_use | 0 | |Binlog_cache_use | 0 | 如果Binlog_cache_disk_use值不為0，則說明BinlogCache 大小可能不夠 Innodb_log_waits量： Innodb_log_waits狀態(tài)變量直接反應(yīng)出InnodbLog Buffer 空間不足造成等待的次數(shù)。 mysql> SHOW /*!50000 GLOBAL*/ STATUS ->LIKE 'Innodb_log_waits'; Innodb_log_waits| 0 常用開源監(jiān)控軟件: RRDTool。RRDTool全稱為RoundRobinDatabase Tool，也就是環(huán)狀循環(huán)數(shù)據(jù)庫工具 Nagios:Nagois 是一個非常著名的運行在Linux/Unix上的對IT設(shè)備或服務(wù)的運行狀態(tài)進行監(jiān)控的軟件。 MRTG MRTG應(yīng)該算是一款比較老牌的監(jiān)控軟件了，功能比較簡單，最初是為了監(jiān)控網(wǎng)絡(luò)鏈路流量而產(chǎn)生的。 Cacti Cacti和Nagios最大的區(qū)別在于前者具有非常強大的數(shù)據(jù)采集、存儲以及展現(xiàn)功能 |
