理解 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

标签：

原文地址：http://www.cnblogs.com/sammyliu/p/4995868.html