程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> 關於MYSQL數據庫 >> MySQL 負載均衡集群結構和問題分析

MySQL 負載均衡集群結構和問題分析

編輯：關於MYSQL數據庫

== ==
我們目前的 MySQL 高可用集群，是采用4層交換機做負載均衡實現的，結構如下：[ Master]---+--->[ Slave ] <---+
|| +--->[ Slave ] <---+
|| +--->[ Slave ] <---+
|| +--->[ Slave ] <---+
|| |
|| +-----------------+
|| | L4 Switch |
|| +-----------------+
|| ||
User Write User Read
---------- ---------1. Master 和 Slave 采用 MySQL Replication 機制同步數據
2. 用戶讀數據庫時訪問多台從庫，通過4層交換機做負載均衡
3. 用戶寫數據庫時直接訪問主庫
4. 數據庫全部使用 MySQL 4.0.x 版本。目前可以通過此結構解決的問提：
============================
1. 通過多台只讀數據庫負載均衡提供了大規模的訪問能力，實現了只讀訪問的高可靠性
2. 實現了讀庫和寫庫操作的分離，主庫或者從庫任何一方負載過高都不會影響另一方這種結構存在的問題：
============================
1. 主庫存在單點故障，目前只能考慮：
- 在主庫宕機後將從庫提升到主庫，但是不能保證切換期間不丟數據，
也不能保證從庫的數據是完整的，有什麼好的辦法？
- 使用雙機的HA結構，沒有嘗試過，不知道性能會受到多大影響？ 2. 主庫存在性能瓶頸，只能通過升級硬件得到提高，或者將庫/表分到多個服務器上，
是否還有其他比較容易實現的解決方法？ 3. 主庫到從庫的數據同步有時候會出現錯誤導致 sql-thread 線程終止，這時數據庫
就不更新了。
目前我們通過健康監控處理程序可以臨時處理這種情況，實現原理也容易，使用
如下的 MySQL 命令：
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1
SLAVE START SQL_THREAD
這樣就能跳過錯誤，繼續同步，但當多次出現這樣的故障後，從庫和主庫可能會存在
很多的差異，那麼：
- 有什麼更好的解決技巧？
- 如何能快速修復這樣的差異？
- 怎麼樣配置可以避免出現這樣的故障？比如避免出現 sql-thread 線程停止的問題。
- 都會有那些原因出現這樣的故障？
- 有沒有可以實現自動錯誤修復的現成工具？自己實現的話有什麼技巧？ 4. 目前數據庫服務器供多個項目使用，一台服務器會啟動多個 MySQL 進程，
每個 MySQL 進程會提供多個中小型項目使用，一旦一個 MySQL 的復制出現
故障，會導致其中的多個項目受到影響，有什麼辦法可以降低這樣的影響？目前每個 MySQL 只能啟動一個 sql-thread 用於 replication, 所以多個
庫只能通過一個同步線程復制。 5. 這種結構是否還有其他問題？
上面的架構還可以進一步改進，思路如下：
=====================================結構如下：
========
.........................................
. .
[ Slave ]-+ +-----------+ +--->[ Slave ] <---+
[ Slave ]-+------| L4 Switch |-------+--->[ Slave ] <---+
[ Master]-+ +-----------+ +--->[ Slave ] <---+
. || +--->[ Slave ] <---+
. || . |
..................||..................... |
|| +-----------------+
|| | L4 Switch |
|| +-----------------+
|| ||
User Write User Read * 說明：Master 和 Slave 的角色可以在每台服務器上輪轉，按照上面的虛線表示。1. 讀數據庫也使用4層交換機做負載均衡，正常情況下有一台主庫提供寫的服務，
多台從數據庫作為主數據庫的備份，當主庫出現故障後，4層交換機可以自動把一台
從庫提升到主庫的角色，這樣可以解決的問題：
- 主庫的單點故障
- 提高從庫(slave) 到主庫(master)同步的高可靠性但是同樣也有前面提到問題：
- 從庫使用 VIP 訪問主庫，這樣主庫更換後，從庫不用改 IP 地址，
但是，如何保證切換成主庫的從庫數據是完整的？
而且目前也沒有進行過功能性驗證，還不知道能不能實現切換，因為不能
保證主庫停止的瞬間，主庫的備份機(從庫)的bin log和主庫一致，如果不一致
可能從庫會出現錯誤。
- 仍然不能解決主庫存在的性能瓶頸實現這個機制需要我們自己開發的程序：
- Master 的健康檢查程序
告訴 L4 Switch Master 是否正常
- Master/Slave 狀態切換程序
如果 L4 Switch 知道 Master 不能正常工作，它會把 Master 停掉，把備用的
Slave 啟用。這個切換4層交換機能實現，我們不用考慮。
而我們要考慮的是，從服務器必須能夠知道自己所處的角色的變化，從而做出一些
初始化的工作，比如檢查自己的數據是否完整，是否和主庫一致，如果都正常那麼
就完成切換；如果不正常，是否可以自動修復；如果不能修復，需要停止切換工作，
等待人工處理。
如果能夠結合 f5 BigIP 的 iControl 功能，上面的操作可以做的更高級一些，比如
當一台被選中作為主庫的服務器經過檢查發現自己也存在錯誤不能切換時，它使用
iControl 功能通知 BigIP 選擇其他服務器。
- 下線的 Master 庫的自動修復
當一個 master 出現故障而下線後，通過修復程序自動修復，完成和新的 master 的
數據一致性檢查，成功後變成一台可以供用戶訪問的 slave 庫，或者重新成為
master 的備份服務器。如果前面提到的問題能較好的解決，上面的程序也都能開發出來，那麼這個體系中的
任何一台服務器都可以作為主庫、從庫運行，而且是自動的完成切換和錯誤修復。