Centos6下MySQL5.6高可用方案-PXC集群环境虚拟机下载

本博主配置好的Centos6下MySQL5.6高可用方案-PXC集群环境虚拟机下载,链接:https://pan.baidu.com/s/1fuTXUNMpULlSHiriw2xKEg
提取码:3897 下载后,用Vmware workstation 打开即可以正常使用。

对于mysql高可用方案,经常用到的的主要有下面三种:

一、基于主从复制的高可用方案:双节点主从 + keepalived

一般来说,中小型规模的时候,采用这种架构是最省事的。
两个节点可以采用简单的一主一从模式,或者双主模式,并且放置于同一个VLAN中,在master节点发生故障后,利用keepalived/heartbeat的高可用机制实现快速
切换到slave节点。

在这个方案里,有几个需要注意的地方:
采用keepalived作为高可用方案时,两个节点最好都设置成BACKUP模式,避免因为意外情况下(比如脑裂)相互抢占导致往两个节点写入相同数据而引发冲突;
1)把两个节点的auto_increment_increment(自增步长)和auto_increment_offset(自增起始值)设成不同值。其目的是为了避免master节点意外宕机时,
可能会有部分binlog未能及时复制到slave上被应用,从而会导致slave新写入数据的自增值和原先master上冲突了,因此一开始就使其错开;当然了,如果有合适的
容错机制能解决主从自增ID冲突的话,也可以不这么做;
2)slave节点服务器配置不要太差,否则更容易导致复制延迟。作为热备节点的slave服务器,硬件配置不能低于master节点;
3)如果对延迟问题很敏感的话,可考虑使用MariaDB分支版本,或者直接上线MySQL 5.7最新版本,利用多线程复制的方式可以很大程度降低复制延迟;
4)对复制延迟特别敏感的另一个备选方案,是采用semi sync replication(就是所谓的半同步复制)或者后面会提到的PXC方案,基本上无延迟,不过事务并发性
能会有不小程度的损失,需要综合评估再决定;
5)keepalived的检测机制需要适当完善,不能仅仅只是检查mysqld进程是否存活,或者MySQL服务端口是否可通,还应该进一步做数据写入或者运算的探测,判断响
应时间,如果超过设定的阈值,就可以启动切换机制;
6)keepalived最终确定进行切换时,还需要判断slave的延迟程度。需要事先定好规则,以便决定在延迟情况下,采取直接切换或等待何种策略。直接切换可能因为复
制延迟有些数据无法查询到而重复写入;
7)keepalived或heartbeat自身都无法解决脑裂的问题,因此在进行服务异常判断时,可以调整判断脚本,通过对第三方节点补充检测来决定是否进行切换,可降低脑
裂问题产生的风险。

双节点主从+keepalived/heartbeat方案架构示意图见下:

二、基于主从复制的高可用方案:多节点主从+MHA/MMM

多节点主从,可以采用一主多从,或者双主多从的模式。
这种模式下,可以采用MHA或MMM来管理整个集群,目前MHA应用的最多,优先推荐MHA,最新的MHA也已支持MySQL 5.6的GTID模式了,是个好消息。

MHA的优势很明显:
1)开源,用Perl开发,代码结构清晰,二次开发容易;
2)方案成熟,故障切换时,MHA会做到较严格的判断,尽量减少数据丢失,保证数据一致性;
3)提供一个通用框架,可根据自己的情况做自定义开发,尤其是判断和切换操作步骤;
4)支持binlog server,可提高binlog传送效率,进一步减少数据丢失风险。

不过MHA也有些限制:
1)需要在各个节点间打通ssh信任,这对某些公司安全制度来说是个挑战,因为如果某个节点被黑客攻破的话,其他节点也会跟着遭殃;
2)自带提供的脚本还需要进一步补充完善,当然了,一般的使用还是够用的。

三、基于Galera协议的高可用方案:PXC
本博主配置好的Centos6下MySQL5.6高可用方案-PXC集群环境虚拟机下载,链接:https://pan.baidu.com/s/1fuTXUNMpULlSHiriw2xKEg
提取码:3897 下载后,用Vmware workstation 打开即可以正常使用

Galera是Codership提供的多主数据同步复制机制,可以实现多个节点间的数据同步复制以及读写,并且可保障数据库的服务高可用及数据一致性。
基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster(简称PXC),目前PXC用的会比较多一些。
mariadb的集群原理跟PXC一样,maridb-cluster其实就是PXC,两者原理是一样的。

下面重点介绍下基于PXC的mysql高可用环境部署记录。

1、PXC介绍

Percona XtraDB Cluster(简称PXC集群)提供了MySQL高可用的一种实现方法。
1)集群是有节点组成的,推荐配置至少3个节点,但是也可以运行在2个节点上。
2)每个节点都是普通的mysql/percona服务器,可以将现有的数据库服务器组成集群,反之,也可以将集群拆分成单独的服务器。
3)每个节点都包含完整的数据副本。

PXC集群主要由两部分组成:Percona Server with XtraDB和Write Set Replication patches(使用了Galera library,一个通用的用于事务型应用的同步、多主复制插件)。

2、PXC特性

1)同步复制,事务要么在所有节点提交或不提交。
2)多主复制,可以在任意节点进行写操作。
3)在从服务器上并行应用事件,真正意义上的并行复制。
4)节点自动配置,数据一致性,不再是异步复制。

PXC最大的优势:强一致性、无同步延迟

3、PXC优缺点

PXC的优点
1)服务高可用;
2)数据同步复制(并发复制),几乎无延迟;
3)多个可同时读写节点,可实现写扩展,不过最好事先进行分库分表,让各个节点分别写不同的表或者库,避免让galera解决数据冲突;
4)新节点可以自动部署,部署操作简单;
5)数据严格一致性,尤其适合电商类应用;
6)完全兼容MySQL;

虽然PXC有这么多好处,但也有些局限性:
1)只支持InnoDB引擎;当前版本(5.6.20)的复制只支持InnoDB引擎,其他存储引擎的更改不复制。然而,DDL(Data Definition Language) 语句在statement级别
被复制,并且,对mysql.*表的更改会基于此被复制。例如CREATE USER…语句会被复制,但是 INSERT INTO mysql.user…语句则不会。
(也可以通过wsrep_replicate_myisam参数开启myisam引擎的复制,但这是一个实验性的参数)。
2)PXC集群一致性控制机制,事有可能被终止,原因如下:集群允许在两个节点上同时执行操作同一行的两个事务,但是只有一个能执行成功,另一个会被终止,集群会给被终止的
客户端返回死锁错误(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
3)写入效率取决于节点中最弱的一台,因为PXC集群采用的是强一致性原则,一个更改操作在所有节点都成功才算执行成功。
4)所有表都要有主键;
5)不支持LOCK TABLE等显式锁操作;
6)锁冲突、死锁问题相对更多;
7)不支持XA;
8)集群吞吐量/性能取决于短板;
9)新加入节点采用SST时代价高;
10)存在写扩大问题;
11)如果并发事务量很大的话,建议采用InfiniBand网络,降低网络延迟;

事实上,采用PXC的主要目的是解决数据的一致性问题,高可用是顺带实现的。因为PXC存在写扩大以及短板效应,并发效率会有较大损失,类似semi sync replication机制。

本博主配置好的Centos6下MySQL5.6高可用方案-PXC集群环境虚拟机下载,链接:https://pan.baidu.com/s/1fuTXUNMpULlSHiriw2xKEg
提取码:3897 下载后,用Vmware workstation 打开即可以正常使用

Centos6下MySQL5.6高可用架构-MHA环境 虚拟机下载

本博主配置好的Centos6下MySQL5.6高可用架构-MHA环境 虚拟机下载,链接:https://pan.baidu.com/s/1aAgcXI8RR1VteMpcQqJYNg
提取码:5aut 下载后  ,用Vmware workstation打开即可以使用。

一、MHA介绍

MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是日本的一位
MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性。是一套优秀的作为MySQL高可用性
环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上
保证数据的一致性,以达到真正意义上的高可用。

MHA是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步).该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。
1)MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。MHA Manager会定时探测集群中的node节点,当发现master
出现故障的时候,它可以自动将具有最新数据的slave提升为新的master,然后将所有其它的slave导向新的master上.整个故障转移过程对应用程序是透明的。
2)MHA Node运行在每台MySQL服务器上,它通过监控具备解析和清理logs功能的脚本来加快故障转移的。

在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度的保证数据的不丢失,但这并不总是可行的。例如,如果主服务器硬件故障或无法通过ssh访问,
MHA没法保存二进制日志,只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制,可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave
已经收到了最新的二进制日志,MHA可以将最新的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节点的数据一致性。

目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,另外一台充当从库,因为至
少需要三台服务器,出于机器成本的考虑,淘宝也在该基础上进行了改造,目前淘宝TMHA已经支持一主一从。

二、MHA工作架构说明

展示了如何通过MHA Manager管理多组主从复制。可以将MHA工作原理总结为如下:

相较于其它HA软件,MHA的目的在于维持MySQL Replication中Master库的高可用性,其最大特点是可以修复多个Slave之间的差异日志,最终使所有Slave保持数据一致,
然后从中选择一个充当新的Master,并将其它Slave指向它。工作流程主要如下:
1)从宕机崩溃的master保存二进制日志事件(binlog events);
2)识别含有最新更新的slave;
3)应用差异的中继日志(relay log)到其他的slave;
4)应用从master保存的二进制日志事件(binlog events);
5)提升一个slave为新的master;
6)使其他的slave连接新的master进行复制;

MHA工作原理

当master出现故障时,通过对比slave之间I/O线程读取master binlog的位置,选取最接近的slave做为latest slave。其它slave通过与latest slave对比生成差异中继日志。
在latest slave上应用从master保存的binlog,同时将latest slave提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。

在MHA实现Master故障切换过程中,MHA Node会试图访问故障的master(通过SSH),如果可以访问(不是硬件故障,比如InnoDB数据文件损坏等),会保存二进制文件,以最大程度
保证数据不丢失。MHA和半同步复制一起使用会大大降低数据丢失的危险。

本博主配置好的Centos6下MySQL5.6高可用架构-MHA环境 虚拟机下载,链接:https://pan.baidu.com/s/1aAgcXI8RR1VteMpcQqJYNg
提取码:5aut 下载后  ,用Vmware workstation打开即可以使用。

MHA软件的架构:由两部分组成,Manager工具包和Node工具包,具体的说明如下。
Manager工具包主要包括以下几个工具:

阅读更多

Centos6.5下安装MyCat与MYSQL5.6实现读写分离、主从切换、分库分表集群环境虚拟机下载

本博主配置好的Centos6.5下安装MyCat与MYSQL5.6实现读写分离、主从切换、分库分表集群环境虚拟机下载,链接:https://pan.baidu.com/s/1U5gMon3-jWSh_PfjQPS1Xw
提取码:vow8 下载后,用Vmware workstation 打开,即可以使用。

系统开发中,数据库是非常重要的一个点。除了程序的本身的优化,如:SQL语句优化、代码优化,数据库的处理本身优化也是非常重要的。主从、热备、分表分库等都是系统发展迟早会遇到的技术问题问题。Mycat是一个广受好评的数据库中间件,已经在很多产品上进行使用了。下面就针对Mycat的基础知识和应用做一总结性梳理,这些内容有的是从网上收集的,有的是自己做的测试验证信息,如有错误,烦请谅解和指出!

一、MyCat简单介绍
MyCat是一个开源的分布式数据库系统,是一个实现了MySQL协议的服务器,前端用户可以把它看作是一个数据库代理(类似于Mysql Proxy),用MySQL客户端工具和命令行访问,而其后端可以用MySQL原生协议与多个MySQL服务器通信,也可以用JDBC协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为N个小表,存储在后端MySQL服务器里或者其他数据库里。

MyCat发展到目前的版本,已经不是一个单纯的MySQL代理了,它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库,也支持MongoDB这种新型NoSQL方式的存储,未来还会支持更多类型的存储。而在最终用户看来,无论是那种存储方式,在MyCat里,都是一个传统的数据库表,支持标准的SQL语句进行数据的操作,这样一来,对前端业务系统来说,可以大幅降低开发难度,提升开发速度。

Mycat可以简单概括为
–  一个彻底开源的,面向企业应用开发的大数据库集群
–  支持事务、ACID、可以替代MySQL的加强版数据库
–  一个可以视为MySQL集群的企业级数据库,用来替代昂贵的Oracle集群
–  一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server
–  结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
–  一个新颖的数据库中间件产品

Mycat关键特性
–  支持SQL92标准
–  遵守Mysql原生协议,跨语言,跨平台,跨数据库的通用中间件代理
–  基于心跳的自动故障切换,支持读写分离,支持MySQL主从,以及galera cluster集群
–  支持Galera for MySQL集群,Percona Cluster或者MariaDB cluster
–  基于Nio实现,有效管理线程,高并发问题
–  支持数据的多片自动路由与聚合,支持sum,count,max等常用的聚合函数,支持跨库分页
–  支持单库内部任意join,支持跨库2表join,甚至基于caltlet的多表join
–  支持通过全局表,ER关系的分片策略,实现了高效的多表join查询
–  支持多租户方案
–  支持分布式事务(弱xa)
–  支持全局序列号,解决分布式下的主键生成问题
–  分片规则丰富,插件化开发,易于扩展
–  强大的web,命令行监控
–  支持前端作为mysq通用代理,后端JDBC方式支持Oracle、DB2、SQL Server 、 mongodb 、巨杉
–  支持密码加密
–  支持服务降级
–  支持IP白名单
–  支持SQL黑名单、sql注入攻击拦截
–  支持分表(1.6)
–  集群基于ZooKeeper管理,在线升级,扩容,智能优化,大数据处理(2.0开发版)

本博主配置好的Centos6.5下安装MyCat与MYSQL5.6实现读写分离、主从切换、分库分表集群环境虚拟机下载,链接:https://pan.baidu.com/s/1U5gMon3-jWSh_PfjQPS1Xw
提取码:vow8 下载后,用Vmware workstation 打开,即可以使用。

二、为什么要用MyCat
这里要先搞清楚Mycat和MySQL的区别(Mycat的核心作用)。我们可以把上层看作是对下层的抽象,例如操作系统是对各类计算机硬件的抽象。那么我们什么时候需要抽象?假如只有一种硬件的时候,我们需要开发一个操作系统吗?再比如一个项目只需要一个人完成的时候不需要leader,但是当需要几十人完成时,就应该有一个管理者,发挥沟通协调等作用,而这个管理者对于他的上层来说就是对项目组的抽象。

同样的,当我们的应用只需要一台数据库服务器的时候我们并不需要Mycat,而如果你需要分库甚至分表,这时候应用要面对很多个数据库的时候,这个时候就需要对数据库层做一个抽象,来管理这些数据库,而最上面的应用只需要面对一个数据库层的抽象或者说数据库中间件就好了,这就是Mycat的核心作用。所以可以这样理解:数据库是对底层存储文件的抽象,而Mycat是对数据库的抽象。

三、Mycat工作原理
Mycat的原理并不复杂,复杂的是代码。Mycat的原理中最重要的一个动词是“拦截”,它拦截了用户发送过来的SQL语句,首先对SQL语句做了一些特定的分析:如分
片分析、路由分析、读写分离分析、缓存分析等,然后将此SQL发往后端的真实数据库,并将返回的结果做适当的处理,最终再返回给用户。

阅读更多