mysql5資料庫mha集群（MySQLmha）

本文目錄一覽：

1、mysql 主從切換後 mha進程死了怎麼解決
2、組建mysql集群的幾種方案
3、java怎麼連接mysql-mha集群
4、mysql集群的幾種方案

mysql 主從切換後 mha進程死了怎麼解決

1. 主伺服器的自動監控和故障轉移

MHA監控複製架構的主伺服器，一旦檢測到主伺服器故障，就會自動進行故障轉移。即使有些從伺服器沒有收到最新的relay log，MHA自動從最新的從伺服器上識別差異的relay log並把這些日誌應用到其他從伺服器上，因此所有的從伺服器保持一致性了。MHA通常在幾秒內完成故障轉移，9-12秒可以檢測出主伺服器故障，7-10秒內關閉故障的主伺服器以避免腦裂，幾秒中內應用差異的relay log到新的主伺服器上，整個過程可以在10-30s內完成。還可以設置優先順序指定其中的一台slave作為master的候選人。由於MHA在slaves之間修復一致性，因此可以將任何slave變成新的master，而不會發生一致性的問題，從而導致複製失敗。

2. 互動式主伺服器故障轉移

可以只使用MHA的故障轉移，而不用於監控主伺服器，當主伺服器故障時，人工調用MHA來進行故障故障。

3. 非互動式的主故障轉移

不監控主伺服器，但自動實現故障轉移。這種特徵適用於已經使用其他軟體來監控主伺服器狀態，比如heartbeat來檢測主伺服器故障和虛擬IP地址接管，可以使用MHA來實現故障轉移和slave伺服器晉級為master伺服器。

4. 在線切換主從伺服器

在許多情況下，需要將現有的主伺服器遷移到另外一台伺服器上。比如主伺服器硬體故障，RAID控制卡需要重建，將主伺服器移到性能更好的伺服器上等等。維護主伺服器引起性能下降，導致停機時間至少無法寫入數據。另外，阻塞或殺掉當前運行的會話會導致主主之間數據不一致的問題發生。MHA提供快速切換和優雅的阻塞寫入，這個切換過程只需要0.5-2s的時間，這段時間內數據是無法寫入的。在很多情況下，0.5-2s的阻塞寫入是可以接受的。因此切換主伺服器不需要計劃分配維護時間窗口(呵呵，不需要你在夜黑風高時通宵達旦完成切換主伺服器的任務)。

組建mysql集群的幾種方案

但似乎很多人推薦這個）DRBD+Heartbeat+MySQL（有一台機器空餘？Heartbeat切換時間較長？有腦裂問題？）MySQL Proxy（不夠成熟與穩定？使用了Lua？是不是用了他做分表則可以不用更改客戶端邏輯？）MySQL Cluster （社區版不支持INNODB引擎？商用案例不足？穩定性欠佳？或者還有其他問題？又或者聽說現在發展不錯？）MySQL + MHA （如果配上非同步複製，似乎是不錯的選擇，又和問題？）MySQL + MMM （似乎反映有很多問題，未實踐過，誰能給個說法）淘寶的Cola(似乎現在停止開發了？)？變形蟲Amoeba（事務支持？）或者，其他方案？不管哪種方案都是有其場景限制或說規模限制，以及優缺點的。1. 首先反對大家做讀寫分離，關於這方面的原因解釋太多次數（增加技術複雜度、可能導致讀到落後的數據等），只說一點：99.8%的業務場景沒有必要做讀寫分離，只要做好資料庫設計優化和配置合適正確的主機即可。2.Keepalived+MySQL –確實有腦裂的問題，還無法做到準確判斷mysqld是否HANG的情況；3.DRBD+Heartbeat+MySQL –同樣有腦裂的問題，還無法做到準確判斷mysqld是否HANG的情況，且DRDB是不需要的，增加反而會出問題；3.MySQL Proxy — 不錯的項目，可惜官方半途夭折了，不建議用，無法高可用，是一個寫分離；4.MySQL Cluster — 社區版本不支持NDB是錯誤的言論，商用案例確實不多，主要是跟其業務場景要求有關係、這幾年發展有點亂不過現在已經上正規了、對網路要求高；5.MySQL + MHA — 可以解決腦裂的問題，需要的IP多，小集群是可以的，但是管理大的就麻煩，其次MySQL + MMM 的話且坑很多，有MHA就沒必要採用MMM建議：1.若是雙主複製的模式，不用做數據拆分，那麼就可以選擇MHA或 Keepalive 或 heartbeat2.若是雙主複製，還做了數據的拆分，則可以考慮採用Cobar；

java怎麼連接mysql-mha集群

public class Cnn { /** * 靜態連接資料庫函數 * @return Connection */ public static Connection getConn() { // String dbDriver=”sun.jdbc.odbc.JdbcOdbcDriver”; // String url=”jdbc:odbc:driver={Microsoft Access Driver (*.mdb)};DBQ=JICQ2006.mdb”; // String user=””; // String password=””; String dbDriver=”com.microsoft.jdbc.sqlserver.SQLServerDriver”; String url=”jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=chat”; String user=”yong”; String password=”yong”; Connection con=null; try { Class.forName(dbDriver).newInstance(); con=DriverManager.getConnection(url,user,password); } catch(Exception ex) { ex.printStackTrace(); } return con; } }

mysql集群的幾種方案

Asynchronous Replication Automatic failover

其原理是在一條非同步複製通道上配置多個可用複製源，當某個複製源不可用時（宕機、複製鏈路中斷），且 slave 的 IO 線程嘗試重連無效，自動根據權重選擇新的源繼續同步。

準備一個 MGR 集群和單實例，模擬複製鏈路切換，當 primary 故障，slave 自動切換到其他節點。dbdeployer deploy replication –topology=group 8.0.22 –single-primarydbdeployer deploy single 8.0.22

2. 在從機上建立指向 MGR 主節點的複製通道，

change master to master_user=’msandbox’,master_password=’msandbox’, master_host=’127.0.0.1′,master_auto_position=1,source_connection_auto_failover=1,master_port=23223,master_retry_count=6,master_connect_retry=10 for channel ‘mgr-single’;

在 master_retry_count 和 master_connect_retry 的設置上要考慮嘗試重連多久才切換複製源。

3. 在從機上配置 asynchronous connection auto failover

配置 asynchronous connection auto failover 的兩個函數：

asynchronous_connection_failover_add_source(channel-name,host,port,network-namespace,weight)

asynchronous_connection_failover_delete_source(channel-name,host,port,network-namespace)

權重值大的被優先順序選擇，可以配合MGR的選舉權重配置 asynchronous_connection_failover 的權重。當 MGR 節點切換，非同步複製也能切換到新的主節點。

SELECT asynchronous_connection_failover_add_source(‘mgr-single’,’127.0.0.1′,23223,null,100); SELECT asynchronous_connection_failover_add_source(‘mgr-single’,’127.0.0.1′,23224,null,80); SELECT asynchronous_connection_failover_add_source(‘mgr-single’,’127.0.0.1′,23225,null,50);start slave for channel ‘mgr-single’;

4. 檢查非同步複製通道是否啟用 failover。

5. 把 MGR 的 primary 節點 kill 掉，這個從節點會在嘗試幾輪重連失敗後自動切換到次權重的複製源，其日誌中會輸出切換信息。

注意：當主節點故障，一旦複製鏈路成功 failover 後，在新的複製鏈路沒有故障時，如果原主節點恢復，是不會回切的。如果當前複製鏈路發生故障，會再次選擇權重高的進行切換

原創文章，作者：R3EP3，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/130682.html