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