mysql高可用解决方案

浅谈mysql主从复制的高可用解决方案

1、熟悉几个组件(部分摘自网络)
1.1、drbd
     —— DRBD(Distributed Replicated Block Device),DRBD号称是 "网络 RAID"，开源软件，由 LINBIT 公司开发。DRBD 实际上是一种块设备的实现,主要被用于Linux平台下的高可用(HA)方案之中。他是有内核 模块和相关程序而组成，通过网络通信来同步镜像整个设备，有点类似于一个网络RAID的功能。也就是说当你将数据写入本地的DRBD设备上的文件系统 时, 数据会同时被发送到网络中的另外一台主机之上，并以完全相同的形式记录在一个文件系统中（实际上文件系统的创建也是由DRBD的同步来实现的）。本地节点 （主机）与远程节点（主机）的数据可以保证实时的同步，并保证IO的一致性。所以当本地节点的主机出现故障时,远程节点的主机上还会保留有一份完全相同的 数据,可以继续使用，以达到高可用的目的。
     实际使用场景中，可以作用于mysql-master（主备）的服务器，保证数据的一致性。

1.2、hearbeat
     —— 它是Linux-HA工程的一个组成部分，它实现了一个高可用集群系统。心跳服务和集群通信是高可用集群的两个关键组件，在 Heartbeat 项目里，由 heartbeat 模块实现了这两个功能。它实现IP的自动漂移，即当一台服务器宕机后，浮动IP（整个cluster的对外IP）自动漂移到另外一台服务器，不会引起服务中断。工作原理：heartbeat （Linux-HA）的工作原理：heartbeat最核心的包括两个部分，心跳监测部分和资源接管部分，心跳监测可以通过网络链路和串口进行，而且支持冗 余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务。

1.3、MMM (MySQL Master-Master Replication Manager) 
     —— MMM利用了虚拟IP的技术：1个网卡可以同时使用多个IP。(所以使用MMM时，需要2*n+1个IP，n为mysql数据库结点个数，包括master,slave)。当有数据库结点fail时，mmmd_mon检测不到mmmd_agent的心跳或者对应的MySQL服务器的状态，mmmd_mon将进行决定，并下指令给某个正常的数据库结点的mmmd_agent，使得该mmmd_agent“篡位”使用(注)刚才fail的那个结点的虚拟IP，使得虚拟IP实际从指向fail的那个机器自动转为此时的这个正常机器。
     具体参考：http://liuyu.blog.51cto.com/183345/98867/；http://blog.longwin.com.tw/2008/10/mysql-master-replication-manager-mmm-intro-2008/

1.4、mysql的主从复制(Replication)/同步
     —— 做mysql集群的基本都会选择这个策略。工作方式：MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知下一次更新。详细内容请自行google搜索。

2、mysql的集群
mysql通过主从复制可以很简单的搭建一个集群服务器，并且配置也很简单。主服务器开启二进制日志系统(bin-log)，设置可以复制的权限用户等，从服务器设置主服务器的serverid，host等即可实现同步(详细步骤参考http://my.oschina.net/guol/blog/100179) 。简单的示意图如下：

 
问题：当主服务器宕机后，整个集群瘫痪(单点故障)。

3、构建mysql高可用集群方案
基于上面的问题，目前可有以下几种方案供选择：
3.1、master-master架构
     两台服务器装mysql，各自作为对方的从机接受对方发来的数据，做到数据的同步备份，感觉和master-slave基本实现原理是一样的。这样保证了数据的一致性，如何保证其中一台服务器故障，自动切换到另外的一个master上呢，使用MMM(MySQL Master-Master Replication Manager)来管理。
   详细配置参考：http://liuyu.blog.51cto.com/183345/98867/

3.2、heartbeat+drbd+mysql主从复制
      基本原理与3.1相似，这里需要做一个master库的冗余备份，使用drbd来保证不同服务器中两个master库的数据一致性。利用heartbeat来完成其中一台服务器发生故障后的自动切换。结构如下图：

 据了解，一般大型网站日pv达到1-2000w以上，都会在主备mysql上层加上一个负载均衡器，如：LVS或者硬件产品F5、Array等。 考虑到成本一般用Lvs/DR+keepalived或hearbeat来完成负载。

分享MYSQL中的各种高可用技术（源自姜承尧大牛）

图片和资料来源于MYSQL大牛姜承尧老师（MYSQL技术内幕作者）

姜承尧： 网易杭州研究院 技术经理 主导INNOSQL的开发

mysql高可用各个技术的比较

数据库的可靠指的是数据可靠

数据库可用指的是数据库服务可用

可靠的是数据：例如工商银行，数据不能丢失

可用的是服务：服务器不能宕机

灵活运用MYSQL的各种高可用技术来达到下面各种级别的高可用要求

要达到99.9%：使用MYSQL复制技术

要达到99.99%：使用MYSQL NDB 集群和虚拟化技术

要达到99.999%：使用shared-nothing架构的GEO-REPLICATION和NDB集群技术

Gluster Geo-replication是什麼？

Gluster Geo-replication(简称geo-replication)是一种异地灾备技术，

它主要应用于把集群中的一个存储，近乎即时地(near real-time)透过公网（wan）备份到远端的机房

各种高可用级别允许的宕机时间

DRBD：网络磁盘的RAID1

---

方案一：MYSQL主从复制（单活）

投票选举机制，较复杂

MySQL本身没有提供replication failover的解决方案，自动切换需要依赖MHA脚本

可以有多台从库，从库可以做报表和备份

---

方案二：双主（单活），failover比单主简单

同样，自动切换需要MMM脚本

缺点是某个主挂掉了，他下面的slave同样挂掉

---

方案三：双主配SAN存储（单活）

这个架构跟方案二是一样的，只不过两个master之间不需要同步数据，因为他们用的是共享磁盘

这个方案是有钱人方案，无论哪个主挂掉都不会引起其他的slave挂掉，但是SAN存储死贵。。

像通信行业中国联通这些公司有用到

某个主挂掉了，下面的slave不会挂掉

注意：failover之后不会预热，数据没有预先加载到内存中，切换之后一段时间内存储会有一定的性能影响

---

方案四：DRBD 双主配DRBD （单活）

结构跟方案三一样，唯一不同的是没有使用SAN网络存储 ，而是使用local disk

由于是实时复制磁盘数据，性能会有影响

人们把DRBD称为“屌丝的SAN”

POOR MAN'S SAN：穷人的SAN

---

方案五：NDB CLUSTER

国内用NDB集群的公司非常少，貌似有些银行有用

NDB集群不需要依赖第三方组件，全部都使用官方组件，能保证数据的一致性

某个数据节点挂掉，其他数据节点依然可以提供服务

管理节点需要做冗余以防挂掉

缺点是：管理和配置都很复杂，而且某些SQL语句例如join语句需要避免

---

方案六：第三方的Tungsten软件

使用java编写，不是MYSQL内置的

同样是MYSQL数据库复制，不过他不是用MYSQL内置的组件来做的

不但支持MYSQL数据库复制也支持异构数据库的复制，而且对异构数据库复制支持较好，例如MYSQL复制到ORACLE

---

方案七：网易的INNOSQL

类似于SQLSERVER的镜像高安全模式

High Safety 模式 （也就是同步模式）没有 witness服务器

数据库在Principle的事务，需要马上得到mirror的确认，才能完成。这种情况下，Mirror和Principle的数据是同步的。

但是因为所有的事务需要mirror的确认，所以性能可能会有所影响。

区别：innosql的slave可以读，镜像的slave（从库）不可读

保证数据不会丢失，数据的高可靠性

mysql5.7开始支持这种模式

---

总结

每种方案都有不同的特点，配置和应用场景也各有不同

有些偏向于成本低的，有些偏向于成本高的，有些偏向于数据的可靠性，有些则偏向于数据库的可用性

反正各个方案都各有优缺点，DBA要结合自己公司的业务情况进行选择合适自己业务情况的高可用方案

更多参考资料：

读写分离：Amoeba

Ubuntu10下MySQL搭建Amoeba系列（文章索引）

集群技术：数据库集群技术漫谈

Gluster Geo-replication工作原理