MYSQL集群方案

1. 主从复制

   mysql复制是mysql自带的功能

   **原理简介:**主从复制是通过重放binlog实现主库数据的异步复制,即当主库执行了一条sql命令,那么再从库同样的执行一遍,从而达到主从复制的效果.再这个过程中,master对数据库的写操作计入二进制日志文件中(binlog),生成一个log dump线程,用来给从库的i/o线程传递binlog.而从库的i/o线程去请求主库的binlog,将得到的binlog日志写到中继日志(relaylog)中,从库的sql线程,会读取relaylog文件中的日志,并解析成具体操作,通过主从的操作一致,而达到最终数据一致.

   

   MYSQL Replication一主多从的结构,主要目的是实现数据库的多点备份(没有故障自动转移和负载均衡).相比于单个的mysql,遗嘱多从优势如下:

   • 如果让后台读操作连接从数据库,让写操作连接主数据库,这个时候多个从数据库可以做负载均衡
   • 可以在某个从数据库中暂时中断复制进程,来备份数据,从而不影响主数据的对外服务(如果在master上执行backup,需要让master出入readOnly状态,这也意味着所有write请求需要阻塞)

   就各个集群方案来说

   其优势为:

   • 主从复制是mysql自带的,无需借助第三方
   • 数据被删除,可以从binlog中恢复
   • 配置较为简单方便

   其劣势为:

   • 从库要从binlog获取数据并重放,这肯定与主库写入数据存在时间延迟,因此从库的数据要滞后于主库
   • 对主库与从库之间的网络延迟要求较高,若网络延迟太高,将加重上述的滞后,造成最终数据的不一致
   • 单一的主节点挂了,将不能对外提供写服务

2. mysql fabirc

   mysql编织物,是mysql官方提供的

   这是在mysql replication的基础上,增加了故障检测与转移,自动数据分片功能,不过依旧是一主多从的结构,mysql fabirc只有一个主节点,却别是当该节点挂了以后,会从从节点中选择一个来当主节点,就各个集群方案来说,

   其优势为:

   • mysql官方提供的工具,无需第三方插件
   • 数据被删除,可以从binlog日志中恢复
   • 主节点挂了以后,能够自动从从节点中选择一个来当主节点,不影响持续对外提供服务

   其劣势为:

   • 从库要从binlog获取数据并重放,肯定与主库写入数据存在时间延迟,因此从库的数据总是要滞后于主库
   • 对主库与从库之间的网络延迟要求比较高,若网络延迟太高,将加重上述滞后,造成最终数据的不一致
   • 2014年5月推出的产品,数据库资历较浅,应用案例不多,网上各种资料相对较少
   • 事务及查询只支持同一个分片内,事务中更新的数据不能跨分片,查询语句返回的数据也不能跨分片
   • 节点故障恢复30秒或更长(采用InnoDB存储引擎的都这样)

3. mysql cluster

   mysql集群(mysql cluster)也是mysql官方提供的

   mysql cluster是多主多从结构

   就各个集群方案来说

   其优势为:

   • mysql官方提供工具,无需第三方插件
   • 高可用性优秀,99.999%的可用性,可以自动切分数据,能跨界点冗余数据(其数据集并不是存储在某个特定的mysql实例上,而是被分布在多个Data Nodes中,即一个table的数据可能被分散在多个物理节点上,任何数据都会在多个Data Nodes上冗余备份.任何一个数据的变更操作,都将在一组Data Nodes上同步,以保证数据的一致性)
   • 可伸缩性优秀,能自动切分数据,方便数据库的水品拓展
   • 负载均衡优秀,可同时用于读操作,写操作都密集的应用,也可以使用SQL和NOSQL接口访问数据
   • 多个主节点,没有单个节点故障的问题,节点故障恢复通常小于1秒.

   其劣势为:

   • 架构模式和原理很复杂
   • 智能使用存储引擎NDB,与平常使用的InnoDB有明显差距.比如在事务(其事务隔离级别只支持Read Committed,即一个事务在提交前,查询不到所在事务内的修改),外键(虽然最新的NDB存储引擎已经支持外键,但性能有问题,因为外键锁关联的记录可能在别的分片节点),表限制上的不同,可能会导致日常开发出现意外
   • 作为分布式的数据库系统,各个节点之间存在大量的数据通信,比如所有访问都需要经过超过一个节点(至少一个SQL Node和一个NDB Node)才能完成,因此对节点之间的内部互联网宽带哟球高
   • Data Node数据会被尽量存放在内存中,对内存要求大,而且重启的时候,数据节点将数据load到内存中需要很长时间

   官方三兄弟的区别如下图所示:

   

   MYSQL的第三方优化

   1. MMM

      MMM是在mysql Replication的基础上,对其进行优化

      MMM(Master Replication Manager For Mysql)是双主多从结构,这是Google的开源项目,使用Perl语言来对Mysql Replication做扩展,提供一套支持双主故障切换和双主日常管理的脚本程序,主要用来监控mysql主主复制并作失败转移.

      

      注意:这里的双主节点,最然叫做双主复制,在是业务上同一时刻只允许对一个主进行写入,另一台备选主上提供部分读服务,以加速在主主切换时刻备选主的预热.

      就各个集群方案来说,

      其优势为:

      • 自动的主主failover切换,一般3S以内切换备机
      • 多个从节点读的负载均衡

      其劣势为:

      • 无法完全保证数据的一致性,如主1挂了,MMM monitor已经切换到主2上来了,而若此时双主复制中,主2数据落后于主1(即还未完全复制完毕),那么此时的主2已经成为主节点,对外提供写服务,从而导致数据不一致
      • 由于是使用虚拟IP浮动技术,类似keepalived,故RIP(真实ip)要和VIP(虚拟IP)在同一网段,如果实在不同网段也可以,需要使用虚拟路由技术,但是绝对在同一个IDC机房,不可跨IDC机房组建集群

   2. MHA

      MHA是在MYSQL Replicaton基础上进行的优化

      MHA(MYSQL High Availability)是多主多从结构,这是日本DeNa公司的youshimaton开发,主要提供更多的主节点,但是缺少VIP(虚拟IP),需要配合keepalived一起使用

      要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二从

      

      就各个集群方案来说,其优势为:

      • 可以进行故障的自动检测和转移
      • 具备自动数据补偿能力,在主库异常崩溃时能够最大程度的保证数据的一致性

      其劣势为:

      • MHA架构实现读写分离,最佳实践是在应用开发设计时提前规划读写分离事宜,在使用时设置两个连接池,即读连接池和写连接池,也可以选择这种方案引入SQL Proxy,但无论如何都需要修改代码
      • 关于读负载均衡可以使用F5,LVS,HAPROXY或者SQL Proxy等工具,只要能实现负载均衡,故障检查以及备升级为主后的读写剥离功能即可,建议使用LVS

   3. Galera Cluster

   Galera Cluster是由Codership开发的MYSQL多主结构集群,这些主节点互为其它节点的从节点,不同于MYSQL原生的主从异步复制,Galera采取的时多主同步复制,并针对同步复制过程,会大概率出现事务冲突和死锁进行优化,就是复制不基于官方的binlog而是Galera复制插件,重写了swrep api

   • 异步复制中,主库将数据更新传播从库后立即提交事务,而不论从库是否成功读取或重放数据变化,这种情况下,在主库事务提交后的短时间内,主从库数据不一致.
   • 同步复制中,主库的单个更新事务需要在所有从库上同步更新,换句话说,当主库提交事务时,集群中所有节点的数据保持一致性.

   对于读操作而言,从每个节点读取到的数据都是相同的,对于写操作而言,当数据写入某一节点后,集群会将其同步到其它节点

   

   就各个集群方案来说，其优势为：

   • 多主多活下，可对任一节点进行读写操作，就算某个节点挂了，也不影响其它的节点的读写，都不需要做故障切换操作，也不会中断整个集群对外提供的服务。
   • 拓展性优秀，新增节点会自动拉取在线节点的数据（当有新节点加入时，集群会选择出一个Donor Node为新节点提供数据），最终集群所有节点数据一致，而不需要手动备份恢复。

   其劣势为：

   • 能做到数据的强一致性，毫无疑问，也是以牺牲性能为代价。