mysql共享存儲ha

『壹』 詳解Mysql 高可用方案 之 Failover mha

在分布式系統中，高可用性（High Availability，HA）是確保服務不中斷的關鍵因素，尤其是在數據密集型應用中，資料庫的高可用性尤為重要。當系統發生故障或意外中斷時，保持資料庫的可用性，確保業務連續性，是設計高可用性方案的核心目標。本文將詳細探討如何構建MySQL的高可用方案，特別是Failover（故障轉移）機制，以及如何利用MHA（MySQL High Availability）工具實現這一目標。

MySQL官方社區版本在早期（如5.7及以前版本）在分布式和系統可用性方面的支持相對有限。因此，設計高可用性方案時，需要考慮如何在主伺服器（Master）失效時，自動切換到備用伺服器（Slave）或備份庫，確保數據一致性，並最小化數據丟失。

Failover機制的實現依賴於數據復制。在分布式資料庫系統中，數據復制是實現數據一致性、高可用性和容錯性的關鍵。MySQL支持多種復制方式，包括同步復制、非同步復制和半同步復制等，每種方式都有其優缺點。同步復制保證數據一致性，但可能影響主伺服器的寫入性能；非同步復制則能保持較高的性能，但數據一致性無法得到保證；半同步復制在提供性能和一致性之間找到了平衡。

在MySQL中，實現Failover的關鍵是使用MHA（MySQL High Availability）工具。MHA能夠自動在0到30秒內完成資料庫故障切換，並在切換過程中最大程度地保證數據一致性。MHA通過檢測主伺服器狀態並自動提升候選的從伺服器為新的主伺服器，同時通知其他從伺服器連接新的主伺服器進行復制，實現系統的平滑過渡。

MHA實現故障切換的邏輯包括以下幾個步驟：
1. 從宕機崩潰的主伺服器保存二進制日誌事件（binlog events）。
2. 識別並選擇具有最新更新的從伺服器作為新的主伺服器。
3. 將差異的日誌應用到其他從伺服器上。
4. 將從主伺服器保存的二進制日誌事件應用到新的主伺服器。
5. 使其他從伺服器連接新的主伺服器進行復制。
6. 使其他從伺服器連接新的主伺服器進行復制。

MHA在實現高可用性方案時，通過網路分區檢測和二次檢測機制解決網路問題，確保系統在面對網路故障時能夠正確判斷主伺服器狀態，並避免誤切換。此外，MHA還支持客戶端自動恢復，確保分布式系統能夠自我恢復服務。

為實現客戶端的自動恢復，可以採用代理（Proxy）的方式。代理可以解析MySQL協議，根據不同的庫、表和請求類型，將請求路由到後端合適的MySQL伺服器。這種架構能夠提供讀寫分離，提高性能並簡化客戶端的連接邏輯。在使用代理時，可以配置VIP（Virtual IP）和腳本，以便在主伺服器故障時，自動切換到備用伺服器，確保客戶端無感知。

總結而言，通過MHA和代理工具的結合，可以構建出一種成本低、變更少、性能影響小的MySQL高可用性方案。該方案能夠確保在主伺服器故障時，系統能夠快速切換到備用伺服器，同時保持數據一致性，保證業務連續性。隨著MySQL官方對分布式協議的支持加強，如MySQL Group Replication的推出，未來有望出現更多優化高可用性和數據一致性的解決方案。

『貳』 五大常見的MySQL高可用方案(最全)

1. 概述

我們在考慮MySQL資料庫的高可用的架構時，主要要考慮如下幾方面：

如果資料庫發生了宕機或者意外中斷等故障，能盡快恢復資料庫的可用性，盡可能的減少停機時間，保證業務不會因為資料庫的故障而中斷。

用作備份、只讀副本等功能的非主節點的數據應該和主節點的數據實時或者最終保持一致。

當業務發生資料庫切換時，切換前後的資料庫內容應當一致，不會因為數據缺失或者數據不一致而影響業務。

關於對高可用的分級在這里我們不做詳細的討論，這里只討論常用高可用方案的優缺點以及高可用方案的選型。

2. 高可用方案

2.1. 主從或主主半同步復制

使用雙節點資料庫，搭建單向或者雙向的半同步復制。在5.7以後的版本中，由於lossless replication、logical多線程復制等一些列新特性的引入，使得MySQL原生半同步復制更加可靠。

常見架構如下：

通常會和proxy、keepalived等第三方軟體同時使用，即可以用來監控資料庫的 健康 ，又可以執行一系列管理命令。如果主庫發生故障，切換到備庫後仍然可以繼續使用資料庫。

優點：

架構比較簡單，使用原生半同步復製作為數據同步的依據；

雙節點，沒有主機宕機後的選主問題，直接切換即可；

雙節點，需求資源少，部署簡單；

缺點：

完全依賴於半同步復制，如果半同步復制退化為非同步復制，數據一致性無法得到保證；

需要額外考慮haproxy、keepalived的高可用機制。

2.2. 半同步復制優化

半同步復制機制是可靠的。如果半同步復制一直是生效的，那麼便可以認為數據是一致的。但是由於網路波動等一些客觀原因，導致半同步復制發生超時而切換為非同步復制，那麼這時便不能保證數據的一致性。所以盡可能的保證半同步復制，便可提高數據的一致性。

該方案同樣使用雙節點架構，但是在原有半同復制的基礎上做了功能上的優化，使半同步復制的機制變得更加可靠。

可參考的優化方案如下：

2.2.1. 雙通道復制

半同步復制由於發生超時後，復制斷開，當再次建立起復制時，同時建立兩條通道，其中一條半同步復制通道從當前位置開始復制，保證從機知道當前主機執行的進度。另外一條非同步復制通道開始追補從機落後的數據。當非同步復制通道追趕到半同步復制的起始位置時，恢復半同步復制。

2.2.2. binlog文件伺服器

搭建兩條半同步復制通道，其中連接文件伺服器的半同步通道正常情況下不啟用，當主從的半同步復制發生網路問題退化後，啟動與文件伺服器的半同步復制通道。當主從半同步復制恢復後，關閉與文件伺服器的半同步復制通道。

優點：

雙節點，需求資源少，部署簡單；

架構簡單，沒有選主的問題，直接切換即可;

相比於原生復制，優化後的半同步復制更能保證數據的一致性。

缺點：

需要修改內核源碼或者使用mysql通信協議。需要對源碼有一定的了解，並能做一定程度的二次開發。

依舊依賴於半同步復制，沒有從根本上解決數據一致性問題。

2.3. 高可用架構優化

將雙節點資料庫擴展到多節點資料庫，或者多節點資料庫集群。可以根據自己的需要選擇一主兩從、一主多從或者多主多從的集群。

由於半同步復制，存在接收到一個從機的成功應答即認為半同步復製成功的特性，所以多從半同步復制的可靠性要優於單從半同步復制的可靠性。並且多節點同時宕機的幾率也要小於單節點宕機的幾率，所以多節點架構在一定程度上可以認為高可用性是好於雙節點架構。

但是由於資料庫數量較多，所以需要資料庫管理軟體來保證資料庫的可維護性。可以選擇MMM、MHA或者各個版本的proxy等等。常見方案如下：

2.3.1. MHA+多節點集群

MHA Manager會定時探測集群中的master節點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。

MHA Node運行在每台MySQL伺服器上，主要作用是切換時處理二進制日誌，確保切換盡量少丟數據。

MHA也可以擴展到如下的多節點集群：

優點：

可以進行故障的自動檢測和轉移;

可擴展性較好，可以根據需要擴展MySQL的節點數量和結構;

相比於雙節點的MySQL復制，三節點/多節點的MySQL發生不可用的概率更低

缺點：

至少需要三節點，相對於雙節點需要更多的資源;

邏輯較為復雜，發生故障後排查問題，定位問題更加困難;

數據一致性仍然靠原生半同步復制保證，仍然存在數據不一致的風險;

可能因為網路分區發生腦裂現象;

2.3.2. zookeeper+proxy

Zookeeper使用分布式演算法保證集群數據的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網路分區現象的產生。

優點：

較好的保證了整個系統的高可用性，包括proxy、MySQL;

擴展性較好，可以擴展為大規模集群;

缺點：

數據一致性仍然依賴於原生的mysql半同步復制;

引入zk，整個系統的邏輯變得更加復雜;

2.4. 共享存儲

共享存儲實現了資料庫伺服器和存儲設備的解耦，不同資料庫之間的數據同步不再依賴於MySQL的原生復制功能，而是通過磁碟數據同步的手段，來保證數據的一致性。

2.4.1. SAN共享儲存

SAN的概念是允許存儲設備和處理器（伺服器）之間建立直接的高速網路（與LAN相比）連接，通過這種連接實現數據的集中式存儲。常用架構如下：

使用共享存儲時，MySQL伺服器能夠正常掛載文件系統並操作，如果主庫發生宕機，備庫可以掛載相同的文件系統，保證主庫和備庫使用相同的數據。

優點：

兩節點即可，部署簡單，切換邏輯簡單；

很好的保證數據的強一致性；

不會因為MySQL的邏輯錯誤發生數據不一致的情況；

缺點：

需要考慮共享存儲的高可用；

價格昂貴；

2.4.2. DRBD磁碟復制

DRBD是一種基於軟體、基於網路的塊復制存儲解決方案，主要用於對伺服器之間的磁碟、分區、邏輯卷等進行數據鏡像，當用戶將數據寫入本地磁碟時，還會將數據發送到網路中另一台主機的磁碟上，這樣的本地主機(主節點)與遠程主機(備節點)的數據就可以保證實時同步。常用架構如下：

當本地主機出現問題，遠程主機上還保留著一份相同的數據，可以繼續使用，保證了數據的安全。

DRBD是linux內核模塊實現的快級別的同步復制技術，可以與SAN達到相同的共享存儲效果。

優點：

兩節點即可，部署簡單，切換邏輯簡單；

相比於SAN儲存網路，價格低廉；

保證數據的強一致性；

缺點：

對io性能影響較大；

從庫不提供讀操作；

2.5. 分布式協議

分布式協議可以很好解決數據一致性問題。比較常見的方案如下：

2.5.1. MySQL cluster

MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗餘數據，實現資料庫的高可用性和數據一致性。

優點：

全部使用官方組件，不依賴於第三方軟體；

可以實現數據的強一致性；

缺點：

國內使用的較少；

配置較復雜，需要使用NDB儲存引擎，與MySQL常規引擎存在一定差異；

至少三節點；

2.5.2. Galera

基於Galera的MySQL高可用集群， 是多主數據同步的MySQL集群解決方案，使用簡單，沒有單點故障，可用性高。常見架構如下：

優點：

多主寫入，無延遲復制，能保證數據強一致性；

有成熟的社區，有互聯網公司在大規模的使用；

自動故障轉移，自動添加、剔除節點；

缺點：

需要為原生MySQL節點打wsrep補丁

只支持innodb儲存引擎

至少三節點；

2.5.3. POAXS

Paxos 演算法解決的問題是一個分布式系統如何就某個值（決議）達成一致。這個演算法被認為是同類演算法中最有效的。Paxos與MySQL相結合可以實現在分布式的MySQL數據的強一致性。常見架構如下：

優點：

多主寫入，無延遲復制，能保證數據強一致性；

有成熟理論基礎；

自動故障轉移，自動添加、剔除節點；

缺點：

只支持innodb儲存引擎

至少三節點；

3. 總結

隨著人們對數據一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數據一致性的問題，如MySQL自身的優化、MySQL集群架構的優化、Paxos、Raft、2PC演算法的引入等等。

而使用分布式演算法用來解決MySQL資料庫數據一致性的問題的方法，也越來越被人們所接受，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規模使用。

隨著官方MySQL Group Replication的GA，使用分布式協議來解決數據一致性問題已經成為了主流的方向。期望越來越多優秀的解決方案被提出，MySQL高可用問題可以被更好的解決。

『叄』 MySQL表同步方法詳解實現不同表數據自動同步mysql不同表數據同步

MySQL表同步方法詳解：實現不同表數據自動同步！
在資料庫中，有時需要將一個表的數據自動同步到另一個表中，這個過程通常稱為表同步。MySQL提供了多種表同步方法，可以根據實際需求選擇合適的方法。本文將詳細介紹MySQL表同步方法及其實現步驟。
一、基於觸發器的表同步方法
觸發器是MySQL中的一種特殊的存儲過程，它可以在表上或資料庫上設置，當滿足一定條件時自動執行。基於觸發器的表同步方法，即通過在源表和目標表上設置相應的觸發器，實現數據的自動同步。
示例代碼：
/**
* 在源表上設置觸發器，當有新的數據插入時將數據同步到目標表中
*/
CREATE TRIGGER trigger_insert AFTER INSERT ON source_table FOR EACH ROW
BEGIN
INSERT INTO target_table (col1, col2, col3) VALUES (NEW.col1, NEW.col2, NEW.col3);
END;
/**
* 在源表上設置觸發器，當有數據更新時將數據同步到目標表中
*/
CREATE TRIGGER trigger_update AFTER UPDATE ON source_table FOR EACH ROW
BEGIN
UPDATE target_table SET col1 = NEW.col1, col2 = NEW.col2, col3 = NEW.col3 WHERE id = NEW.id;
END;
/**
* 在源表上設置觸發器，當有數據刪除時將數據從目標表中刪除
*/
CREATE TRIGGER trigger_delete AFTER DELETE ON source_table FOR EACH ROW
BEGIN
DELETE FROM target_table WHERE id = OLD.id;
END;
優點：基於觸發器實現的表同步方法具有數據一致性強、實時性高的優點。
缺點：觸發器的執行會帶來一定的性能開銷，當數據量較大時，可能會影響伺服器的性能。
二、基於存儲過程的表同步方法
存儲過程是MySQL中的一種特殊程序，可以接受輸入參數並返回多個輸出結果。基於存儲過程的表同步方法，即通過在資料庫中設置一個存儲過程，定期執行存儲過程，將源表數據同步到目標表中。
示例代碼：
/**
* 創建存儲過程，將源表數據同步到目標表中
*/
CREATE PROCEDURE sync_table()
BEGIN
INSERT INTO target_table (col1, col2, col3)
SELECT col1, col2, col3 FROM source_table;
END;
/**
* 定期執行存儲過程，將數據同步到目標表中
*/
CREATE EVENT sync_event
ON SCHEDULE EVERY 1 MINUTE
DO CALL sync_table();
優點：基於存儲過程實現的表同步方法具有數據處理能力強、可定製性高的優點。
缺點：基於存儲過程實現的表同步方法需要定期執行，存在一定的延遲。
三、基於插件的表同步方法
插件是MySQL中的一種可插拔式存儲引擎，它可以實現自定義的數據存儲處理操作。基於插件的表同步方法，即通過自定義插件的方式，實現源表數據到目標表的同步。
示例代碼：
/**
* 創建插件，將源表數據同步到目標表中
*/
class SyncPlugin : public mysql_storage_engine
{
public:
SyncPlugin(handlerton *hton, const char *name, int flags) : mysql_storage_engine(hton, name, flags) {}
virtual int open(const char *name, const char *mode, uint *flag, ha_create_info *create_info, int create_flags, ha_table_option *option);
virtual int close(void);
virtual int create(const char *name, int mode, ha_create_info *create_info, ha_table_option *option, const st_mysql_const_lex_string *db);
virtual int drop(const char *name);
virtual int rename(const char *from, const char *to, ha_table_option *option);
virtual int write_row(uchar *buf);
virtual int update_row(const uchar *old_data, uchar *new_data);
virtual int delete_row(const uchar *buf);
virtual int create_index(uint key_number, ha_keydef *key_info, const char *name);
virtual int delete_index(const char *name);
virtual int rename_index(const char *from, const char *to);
};
int SyncPlugin::write_row(uchar *buf)
{
int ret = mysql_storage_engine::write_row(buf);
if (ret == HA_ERR_END_OF_FILE) {
// 同步數據到目標表中
insert_into_target_table(buf);
}
return ret;
}
/**
* 注冊插件
*/
mysql_declare_plugin(sync_plugin)
{
MYSQL_STORAGE_ENGINE_PLUGIN,
&SyncPlugin::descriptor,
“SyncPlugin”,
“1.0”,
“Yifei Wang”,
“”,
0x01,
nullptr,
nullptr
}
mysql_declare_plugin_end;
優點：基於插件的表同步方法具有可擴展性強、自定義性高的優點。
缺點：基於插件的表同步方法需要編寫自定義插件，需要對MySQL存儲引擎有較深的了解。
總結：
不同的表同步方法各有優缺點，根據實際需求選擇合適的方法可提高數據的一致性和效率。除此之外，還可以通過第三方工具或高可用中間件等方式實現MySQL表數據的自動同步，幫助企業更好地管理數據。