【MyCat】mycat实现mysql读写分离

前言

        之前的博客中介绍了MySQL的主从复制和使用amoeba中间件实现的MySQL的读写分离，同时也介绍了mycat官方默认的配置文件和目录结构，今天要用mycat来实现一下读写分离，我们来对比一下这两个中间件的异同。

        mycat的读写分离同样建立在MySQL自身的replication机制之上。在MySQL自身搭建好主从集群之后，才可以通过中间件的方式进行读写分离。

准备

        系统：centos7

        jdk：1.7及1.7以上

        MySQL：版本5.6.35（测试用）

        mycat版本：1.6-RELEASE

        mycat安装地址：服务器207

        主库地址：服务器207

        从库地址：服务器218

        mycat的下载、安装、环境变量以及分配账户与amoeba类似，这里不做过多介绍。

相关标签简介

        在介绍具体操作之前，先来了解一下几个相关的标签，读写分离的配置主要是在dataHost中配置，关于这块的知识不明白的可以参考之前的一个介绍mycat配置文件的博客。

balance

        负载均衡类型

1、balance="0"，不开启读写分离机制，所有读操作都发送到当前可用的writeHost上。

2、balance="1"，全部的readHost与stand by writeHost（主备机）参与select语句的负载均衡，简单的说，当双主双从模式（M1>S1，M2>S2，并且M1和M2互为主备）这种情况下，M2,S1,S2都参与select语句的负载均衡。

3、balance="2"，所有读操作都随机的在writeHost、readHost上分发。

4、balance="3"，所有读请求随机分发到writeHost对应的readHost执行，writeHost不负担读压力。（该参数只有在1.4及之后版本存在）

writeType

        负载均衡类型

1、writeType="0"，所有写操作发送到配置的第一个writeHost，第一个挂了切到还生存的第二个writeHost，重新启动后以切换后的为准，切换记录在配置文件dnindex.properties中。

2、writeType="1"，所有写操作都随机发送到配置的writeHost，1.5后废弃。

switchType

1、switchType="-1"，表示不自动切换

2、switchType="1"，表示自动切换（缺省值）

3、switchType="2"，基于MySQL主从同步状态决定是否切换

4、switchType="3"，基于MySQL galary cluster的切换机制（适合集群），心跳语句为show status like 'wsrep%'

配置文件

        了解了以上内容之后，现在开始配置文件——schema.xml中的dataHost节点。

第一种方案——简单读写分离

        看这个配置文件，它的balance="1"，表示开启了读写分离，并且所有从机和主备机都参与select语句的分发。writeType="0"表示当第一个主宕机之后自动切换到主备，但是现在没有主备，所以这个参数在这是名存实亡的样子货。switchType="-1"表示不自动切换主机（此配置只有一个主机）。

        这么做貌似很完美了，确实可以写入主，读从，但是，它违反了高可用原则，显然不是一个好的实例，因为如果主宕机之后，从也不能读了。

        这么说，应该是有更好的解决方案的，看下面。

第二种方案——主机宕机仍可读的读写分离

        这种情况下，上面的标签参数没有更改，还是开启所有主备机和从机都参与select语句的分发，并且不自动切换主机（备机M2和主机M1之间只是主从，并没有做互为主备，所以并不能在M2<从机>进行写入）但是有一点不同了，就是218的库不再依赖在207下了，也就是说，如果现在主库207宕机了，218还是可以进行读操作的。

        但是，这样就可以了吗？如果写入不能停呢？上面两个也说了，不能写入的原因是因为没有做两个机器的互为主备，如果做了呢？

第三种方案——高可用的读写分离

        这是第三种方案，与第二种不同的就是switchType这个参数的值改为了1，为什么是1呢？因为现在两个库做的是互为主备，所以都是可以读写并且数据是同步的，所以当主库宕机之后，心跳检测语句就会发现主库死了，马上换从库，也就是M2去顶替，如果此时M1再活了，那没办法，首领都让给别人了，要不回来了了（又一个办法就是杀死M2,系统会再次更换主库的）。不过他俩的数据是保持同步的，这时候读就会在之前的主机中进行，写操作会在现在的主机，也就是M2中进行，真正实现了高可用的MySQL数据库集群。

总结

        当然，单单是这样还不够，要结合第一种和第三种方案来的话，就是非常完美的读写分离集群了，每个主库和主备下面都有从机，两个主库之间数据也同步，具体的实现我就不多做了，还请读者根据需要自行尝试。

        这篇博客大致比较了几种主从复制，也使mycat和amoeba做了一个大致的对比，相比之下，还是mycat配置读写分离的时候相对简单，之后还会对比这两个中间件横向和纵向分表的区别，他们谁会更胜一筹呢？欢迎关注。