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 打开即可以正常使用