分布式mysql數據庫異常處理（按分布式事務數據庫發生故障）

本文目錄一覽：

• 1、MySQL如何實現高可用？
• 2、MySQL數據庫問題，the ‘max_connections_per_hour’ resource (current value: 2)
• 3、mysql數據庫千萬級得表一下查詢超時怎麼優化？
• 4、MYSQL分布式數據庫操作 急~~~~~~“
• 5、mysql分布式數據庫問題

MySQL如何實現高可用？

1. 概述

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

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

2. 高可用方案

2.1. 主從或主主半同步複製

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

常見架構如下：

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

優點：

缺點：

2.2. 半同步複製優化

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

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

可參考的優化方案如下：

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

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

優點：

缺點：

2.3. 高可用架構優化

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

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

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

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

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

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

優點：

缺點：

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

優點：

缺點：

2.4. 共享存儲

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

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

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

優點：

缺點：

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

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

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

優點：

缺點：

2.5. 分布式協議

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

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

優點：

缺點：

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

優點：

缺點：

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

優點：

缺點：

3. 總結

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

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

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

分布式解決方案 tidb

多主 多備 master lvs做vip 讀寫分離中間件

MySQL數據庫問題，the ‘max_connections_per_hour’ resource (current value: 2)

是的，只允許同時2個人鏈接數據庫

應該是license的問題，可能你給的價錢就只給了你2個鏈接的license

對於分布式的系統來說，系統連接數與數據庫連接數的確不是一個概念，主機商這麼說也可以，不過數據庫鏈接只能有2個這個明顯不夠用，建議你查一下你買的時候主機商的條款，如果裡面明確了那就沒有辦法了，沒有明確可以再和他們協商

mysql數據庫千萬級得表一下查詢超時怎麼優化？

第一優化你的sql和索引；

第二加緩存，memcached,redis；

第三以上都做了後，還是慢，就做主從複製或主主複製，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護；

第四如果以上都做了還是慢，不要想着去做切分，mysql自帶分區表，先試試這個，對你的應用是透明的，無需更改代碼,但是sql語句是需要針對分區表做優化的，sql條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，另外分區表還有一些坑，在這裡就不多說了；

第五如果以上都做了，那就先做垂直拆分，其實就是根據你模塊的耦合度，將一個大的系統分為多個小的系統，也就是分布式系統；

第六才是水平切分，針對數據量大的表，這一步最麻煩，最能考驗技術水平，要選擇一個合理的sharding key,為了有好的查詢效率，表結構也要改動，做一定的冗餘，應用也要改，sql中盡量帶sharding key，將數據定位到限定的表上去查，而不是掃描全部的表；

mysql數據庫一般都是按照這個步驟去演化的，成本也是由低到高；

MYSQL分布式數據庫操作 急~~~~~~“

可以參考”訂閱服務器和分發” 使數據庫表同步。

就是從本地數據庫表更新到遠程數據庫表是同步進行的

打開企業管理器→工具→複製→創建和管理髮布→創建發布→下步選要發布的數據庫→選否，定義選項和屬性→（根據情況選發布類型）事務發布→下步選擇你要發布的數據表→編輯名稱（隨便）→否，根據指定方式創建發布→完成

*創建完成了發布在開始訂閱遠程的數據庫

企業管理器→工具→複製→創建和管理髮布→展開你所創建發布的數據庫選擇

發布的表→強制新訂閱→下一步→選擇遠程服務器（如果沒有就先到企業管理器上連接）→*編要訂閱的數據庫名（這裡是很多新手會搞錯的地方：是需訂閱的遠程數據庫名）→是，初始化（這項是沒做過複製的數據庫可選，如果以前做過的選擇此項就會導至以前訂閱的數據丟失。*做過複製的數據庫可選”否”）→完成

遠程也同上。

可以找兩台PC試一下。

mysql分布式數據庫問題

要數據同步就做雙機熱備，要僅僅為了異地訪問，就在防火牆上把3306端口映射出來，然後給相應的用戶開遠程登錄數據庫的權限