理解 OpenStack 高可用(HA) （5）: MySQL HA

標籤：

本系列會分析OpenStack 的高可用性（HA）概念和解決方案：

（1）OpenStack 高可用方案概述

（2）Neutron L3 Agent HA - VRRP （虛擬路由冗餘協議）

（3）Neutron L3 Agent HA - DVR （分布式虛機路由器）

（4）RabbitMQ HA

（5）MySQL HA

1. MySQL HA 方案概括

Mysql HA 方案有很多種，包括：

• mmm: http://mysql-mmm.org/
• mha: https://code.google.com/p/mysql-master-ha/
• heartbeat+brdb: http://lin128.blog.51cto.com/407924/279411 http://www.centos.bz/2012/03/achieve-drbd-high-availability-with-heartbeat/
• cluster(使用ndb引擎):http://database.51cto.com/art/201008/218326.htm
• 雙master+keeplived: http://database.51cto.com/art/201012/237204.htm，http://kb.cnblogs.com/page/83944/
• 雙master: http://yunnick.iteye.com/blog/1845301
• Oracel Fabric 方案：http://www.csdn.net/article/2014-08-20/2821300

M這些高可用方案，大多是基於以下幾種基礎來部署的：

1. 基於主從複製；
2. 基於Galera協議；
3. 基於NDB引擎；
4. 基於中介軟體/proxy；
5. 基於共用儲存；
6. 基於主機高可用；

這裡 有個各種方案的比較：

在這些可選項中，最常見的就是基於主從複製的方案，其次是基於Galera的方案。這篇文章 分享MYSQL中的各種高可用技術 全面具體地分析了 Mysql 的各種容災方案。也可見 Mysql 容災的水很深。

2 使用 Pacemaker + DRBD + CoroSync 的 A/P 方案

與 RabbitMQ HA 方案類似，OpenStack 官方推薦的 Mysql Active/Passive HA 方案也是 Pacemaker + DRBD + CoroSync。具體方案為：

• 配置 DRBD 用於 Mysql
• 配置 Mysql 的 var/lib/mysql 目錄位於 DRBD 裝置上
• 選擇和配置一個 VIP，配置 Mysql 在該 IP 上監聽
• 使用 Pacemaker 管理 Mysql 所有的資源，包括其 deamon
• 配置 OpenStack 服務使用基於 VIP 的 Mysql 串連

OpenStack 官方推薦的 Mysql HA A/P 方案 配置完成後的效果：

這個文檔 詳細闡述了具體的配置步驟。這個方案的問題是，drbd 容易出現腦裂；而且，兩個 mysql 節點只有一個能提供服務，存在資源浪費。

3. 使用 Galera 協議的 active/active 多主方案3.1 三節點方案

    OpenStack 官方的推薦是使用 Galera 來做三節點HA。這種模式下，Galera 提供多個 Mysql 節點之間的同步複製，使得多個 Mysql 節點同時對外提供服務，這時候往往需要使用負載平衡軟體比如 HAProxy 來提供一個 VIP 給各應用使用。官網 在這裡。

 

Galera 主要功能：

• 同步複製
• 真正的multi-master，即所有節點可以同時讀寫資料庫
• 自動的節點成員控制，失效節點自動被清除
• 新節點加入資料自動複製
• 真正的並行複製，行級
• 使用者可以直接連接叢集，使用感受上與MySQL完全一致 

優勢:

• 因為是多主，所以不存在延遲
• 不存在丟失交易的情況
• 同時具有讀和寫的擴充能力
• 更小的用戶端延遲
• 節點間資料是同步的,而Master/Slave模式是非同步,不同slave上的binlog可能是不同的 

技術:

• Galera 叢集的複製功能基於Galera library實現,為了讓 MySQL 與 Galera library 通訊，特別針對MySQL開發了wsrep API。

詳細配置過程可以參考 OpenStack HA Guide 和 這個文章。

3.2 兩節點 + Galera Arbitrator A/A HA 方案

 3.1 中的A/A 方案需要三個節點，因此成本比較高。本方案提供使用兩個節點情況下的 A/A 方案。相信資訊可以參考 這篇文章。

該方案使用 Arbitrator 作為第三個節點來使用，它其實是一個守護進程。它有兩個作用：

1. 當你使用偶數個節點時，它能當作一個奇數節點使用，來防止腦裂發生。
2. 它能被用作持續的系統狀態的快照，用於備份目的。

3.3 小結

    當然，MariaDB Galera Cluster 並不是適合所有需要複製的情形，你必鬚根據自己的需求來決定，比如，

• 如果你是資料一致性考慮的多，而且寫操作和更新的東西多，但寫入量不是很大，MariaDB Galera Cluster就適合你。但是，這種方案中整個叢集的寫入輸送量是由最弱的節點限制，如果有一個節點變得緩慢，那麼整個叢集將是緩慢的。為了穩定的高效能要求，所有的節點應使用統一的硬體，而且叢集節點建議最少3個。
• 如果你是查詢的多，且讀寫分離也容易實現，那就用 replication 好，簡單易用，用一個 master 保證資料的一致性，可以有多個slave用來讀去資料，分擔負載，只要能解決好資料一致性和唯一性，replication就更適合你，畢竟MariaDB Galera Cluster叢集遵循“木桶”原理，如果寫的量很大，資料同步速度是由叢集節點中IO最低的節點決定的，整體上，寫入的速度會比replication慢許多。

 

參考連結：

• http://leejia.blog.51cto.com/4356849/841084
• http://drbd.linbit.com/
• http://kafecho.github.io/presentations/introduction-to-pacemaker/#/8
• http://chuansong.me/n/412792
• http://www.gpfeng.com/?p=603
• http://fengchj.com/?p=2273
• http://imysql.com/2015/09/14/solutions-of-mysql-ha.shtml 

 

理解 OpenStack 高可用(HA) （5）: MySQL HA