MySql高可用架构

目录

• 一、低读低写并发、低数据量
  • 方案一：双机高可用方案
  • 方案二：主从结构方案
• 二、高读低写并发、低数据量
  • 方案三：一主多从 + 读写分离
• 三、高读写并发、低数据量方案
  • 方案四：MariaDB Galera Cluster方案
• 四、高读写并发、高数据量方案
  • 方案五：数据库中间件

一、低读低写并发、低数据量

方案一：双机高可用方案

场景：读和写都不高的场景（单表数据低于500万），双机高可用

优缺点：优点是一个机器故障了可以自动切换；缺点是只有一个库在工作，读写并未分离，并发有限制。

　　数据源配置中的数据库IP地址，可采用虚拟的IP地址。虚拟IP地址由两台数据库机器上的keepalive配置，并互相检测心跳。当其中一台故障后，虚拟IP地址会自动漂移到另外一台正常的库上。

　　程序代码的配置并不需要修改，数据库的主备配置、故障排除和数据补全，需要DBA和运维人员来维护。

具体配置可参考资料：

http://lizhenliang.blog.51cto.com/7876557/1362313

http://database.51cto.com/art/201012/237204.htm

http://gaoke.iteye.com/blog/2283890

方案二：主从结构方案

场景：读和写都不是非常高的场景（单表数据低于1000万），高可用。

　　要实现这种方案需借助数据库中间件Mycat来实现，Mycat的datahost配置如下（注意balance和writetype的设置）

<dataHost 
          name="localhost1" 
          maxCon="1000" 
          minCon="10" 
          balance="1" 
          writeType="0" 
          dbType="mysql" 
          dbDriver="native" 
          switchType="1" 
          slaveThreshold="100">
    
<heartbeat>select user()</heartbeat>

<!--A(主要用于写)-->
<writeHost 
           host="A" 
           url="192.168.1.135:3306" 
           user="root" 
           password="root"/>

    
<!--B(主要用于读),A库挂了，B就自动切换为主，B设置为读写都可以-->
<writeHost host="B" 
           url="192.168.1.136:3306" 
           user="root" 
           password="root"/>
</dataHost>

　　在工程代码中要配置Mycat数据源，并实现对Mycat数据源的数据操作。A与B互为主从。数据库的主从配置、故障排除和数据补全，也需要DBA和运维人员来维护。

　　优缺点：优点是比方案一并发要高很多，并且一个机器故障了可以自动切换；读写分离，并发有了很大的提升。缺点是引入了一个Mycat节点，若要高可用需要引入至少两个Mycat。常规的解决方案是引入haproxy和keepalive对mycat做集群。

二、高读低写并发、低数据量

方案三：一主多从 + 读写分离

场景：适合写并发不大、读并发大

优缺点：由于配置了多个读节点，读并发的能力有了质的提高。理论上来说，读节点可以多个，可以负载很高级别的读并发。当然，Mycat依然需要设计高可用方案。

　　项目中需要使用Mycat作为中间件，来配置主库和从库，核心配置如下：

<dataHost name="localhost1" 
          maxCon="1000" 
          minCon="10" 
          balance="1" 
          writeType="0" 
          dbType="mysql" 
          dbDriver="native" 
          switchType="1" 
          slaveThreshold="100">

<heartbeat>select user()</heartbeat>

<!--主A，写-->
<writeHost host="A" url="192.168.1.135:3306" user="root" password="root"/>

<!-- 从B，读 -->
<writeHost host="B" url="192.168.1.136:3306" user="root" password="root"/>

<!-- 从C，读-->
<writeHost host="C" url="192.168.1.137:3306" user="root" password="root"/>

<!-- 从D，读-->
<writeHost host="D" url="192.168.1.138:3306" user="root" password="root"/>
    
</dataHost>

　　主库A故障后，Mycat会自动把从B提升为写库。而C、D从库，则可以通过MHA等工具，自动修改其主库为B。进而实现自动切换的目地。

　　MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

MHA简单介绍

三、高读写并发、低数据量方案

方案四：MariaDB Galera Cluster方案

　　多个数据库，在负载均衡作用下，可同时进行写入和读取操作；各个库之间以Galera Replication的方法进行数据同步，即每个库理论上来说，数据是完全一致的。

　　数据库读写时，只需要修改数据库读写IP为keepalive的虚拟节点即可；数据库配置方面相对比较复杂，需要引入haproxy、keepalive、Galaera等各种插件和配置。

优点：

1）可以在任意节点上进行读

2）自动剔除故障节点

3）自动加入新节点

4）真正并行的复制，基于行级

5）客户端连接跟操作单数据库的体验一致。

6. 同步复制，因此具有较高的性能和可靠性。

缺点：

1. DELETE操作不支持没有主键的表，没有主键的表在不同的节点顺序将不同

2）处理事务时，会运行一个协调认证程序来保证事务的全局一致性，若该事务长时间运行，就会锁死节点中所有的相关表，导致插入卡住（这种情况和单表插入是一样的）。

2）整个集群的写入吞吐量是由最弱的节点限制，如果有一个节点变得缓慢，那么整个集群将是缓慢的。为了稳定的高性能要求，所有的节点应使用统一的硬件。

3）如果DDL语句有问题将破坏集群，建议禁用。

4. Mysql数据库5.7.6及之后的版本才支持此种方案。

四、高读写并发、高数据量方案

方案五：数据库中间件

场景： 读写并发都很大并且数据量非常大的场景

优点：终极的解决高并发高数据量的方法。

缺点：配置和维护都比较麻烦，需要的软硬件设备资源都非常大。

　　用Mycat进行分片存储，可以解决写负载均衡和数据量过大问题；每个分片配置多个读从库，可以减少单个库的读压力。

　　这种架构，需配置Haproxy、keepalive和mycat集群，每个分片上又需要配置一主多从的集群。每个分片上的完整配置，具体请参考方案三，可以简单地把方案三理解为一个分片结构。因此，配置和维护量都比较大。