MySQL高可用方案－PXC环境部署记录

时间 2019-11-10

标签 mysql 可用方案 pxc 环境部署记录栏目 MySQL 繁體版

原文原文链接

以前梳理了Mysql+Keepalived双主热备高可用操做记录，对于mysql高可用方案，常常用到的的主要有下面三种：html

1、基于主从复制的高可用方案：双节点主从 + keepalivednode

通常来讲，中小型规模的时候，采用这种架构是最省事的。
两个节点能够采用简单的一主一从模式，或者双主模式，而且放置于同一个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方案架构示意图见下：mysql

2、基于主从复制的高可用方案：多节点主从+MHA/MMMlinux

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

MHA的优点很明显：
1）开源，用Perl开发，代码结构清晰，二次开发容易；
2）方案成熟，故障切换时，MHA会作到较严格的判断，尽可能减小数据丢失，保证数据一致性；
3)提供一个通用框架，可根据本身的状况作自定义开发，尤为是判断和切换操做步骤；
4)支持binlog server，可提升binlog传送效率，进一步减小数据丢失风险。

不过MHA也有些限制：
1）须要在各个节点间打通ssh信任，这对某些公司安全制度来讲是个挑战，由于若是某个节点被黑客攻破的话，其余节点也会跟着遭殃；
2）自带提供的脚本还须要进一步补充完善，固然了，通常的使用仍是够用的。

3、基于Galera协议的高可用方案：PXC sql

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

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

一、PXC介绍bootstrap

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

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

二、PXC特性centos

1）同步复制，事务要么在全部节点提交或不提交。
2）多主复制，能够在任意节点进行写操做。
3）在从服务器上并行应用事件，真正意义上的并行复制。
4）节点自动配置，数据一致性，再也不是异步复制。

PXC最大的优点：强一致性、无同步延迟

三、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机制。

四、PXC原理描述bash

分布式系统的CAP理论：
C：一致性，全部的节点数据一致
A：可用性，一个或者多个节点失效，不影响服务请求
P：分区容忍性，节点间的链接失效，仍然能够处理请求
其实，任何一个分布式系统，须要知足这三个中的两个。

PXC会使用大概是4个端口号
3306：数据库对外服务的端口号
4444：请求SST SST: 指数据一个镜象传输 xtrabackup , rsync ,mysqldump 
4567: 组成员之间进行沟通的一个端口号
4568: 传输IST用的。相对于SST来讲的一个增量。

一些名词介绍：
WS：write set 写数据集
IST: Incremental State Transfer 增量同步
SST：State Snapshot Transfer 全量同步 

PXC环境所涉及的端口：
#mysql实例端口
10Regular MySQL port, default 3306.   

#pxc cluster相互通信的端口
2）Port for group communication, default 4567. It can be changed by the option:  
   wsrep_provider_options ="gmcast.listen_addr=tcp://0.0.0.0:4010; "

#用于SST传送的端口
3）Port for State Transfer, default 4444. It can be changed by the option:  
   wsrep_sst_receive_address=10.11.12.205:5555

#用于IST传送的端口
4）Port for Incremental State Transfer, default port for group communication + 1 (4568). It can be changed by the option:  
   wsrep_provider_options = "ist.recv_addr=10.11.12.206:7777; "

PXC的架构示意图：

数据读写示意图

---------------------------------------下面看下传统复制流程----------------------------------

异步复制

半同步超过10秒的阀值会退化为异步

无论同步或是半同步，都存在必定的延迟，那么PXC怎么作到不延迟呢？
PXC最大的优点：强一致性、无同步延迟
每个节点均可以读写，WriteSet写的集合，用箱子推给Group里全部的成员， data page 至关于物理复制，而不是发日志，就是一个写的结果了。

PXC原理图

从上图能够看出：
当client端执行dml操做时，将操做发给server，server的native进程处理请求，client端执行commit，server将复制写数据集发给group(cluster)，cluster
中每一个动做对应一个GTID，其它server接收到并经过验证(合并数据)后，执行appyl_cb动做和commit_cb动做，若验证没经过，则会退出处理;当前server节点验证通
事后，执行commit_cb，并返回，若没经过，执行rollback_cb。

只要当前节点执行了commit_cb和其它节点验证经过后就可返回。
3306:数据库对外服务的端口号
4444:请求SST，在新节点加入时起做用
4567:组成员之间沟通的端口
4568:传输IST，节点下线，重启加入时起做用
SST:全量同步
IST:增量同步 

问题：若是主节点写入过大，apply_cb时间跟不上，怎么处理？ 
Wsrep_slave_threads参数配置成cpu的个数相等或是1.5倍。

用户发起Commit，在收到Ok以前，集群每次发起一个动做，都会有一个惟一的编号，也就是PXC独有的Global Trx Id。
动做发起者是commit_cb，其它节点多了一个动做： apply_cb

上面的这些动做，是经过那个端号交互的？
4567，4568端口，IST只是在节点下线，重启加入那一个时间有用
4444端口，只会在新节点加入进来时起做用

PXC结构里面，若是主节点写入过大，apply_cb 时间会不会跟不上，那么wsrep_slave_threads参数解决apply_cb跟不上问题配置成和CPU的个数相等或是1.5倍
当前节点commit_cb 后就能够返回了，推过去以后，验证经过就好了能够返回客户端了，cb也就是commit block 提交数据块.

五、PXC启动和关闭过程

State Snapshot Transfer(SST)，每一个节点都有一份独立的数据，当用mysql bootstrap-pxc启动第一个节点，在第一个节点上把账号初始化，其它节点启动后加入进来。集群中有哪些节点是由wsrep_cluster_address = gcomm://xxxx,,xxxx,xxx参数决定。第一个节点把本身备份一下(snapshot)传给加入的新节点，第三个节点的死活是由前两个节点投票决定。

状态机变化阶段：
1）OPEN: 节点启动成功，尝试链接到集群，若是失败则根据配置退出或建立新的集群
2）PRIMARY: 节点处于集群PC中，尝试从集群中选取donor进行数据同步
3）JOINER: 节点处于等待接收/接收数据文件状态，数据传输完成后在本地加载数据
4）JOINED: 节点完成数据同步工做，尝试保持和集群进度一致
5）SYNCED：节点正常提供服务：数据的读写，集群数据的同步，新加入节点的sst请求
6）DONOR(贡献数据者)：节点处于为新节点准备或传输集群全量数据状态，对客户端不可用。

状态机变化因素：
1）新节点加入集群
2）节点故障恢复
3）节点同步失效 

传输SST有几种方法:
1）mysqldump
2）xtrabackup
3）rsync

好比有三个节点：node一、node二、node3
当node3停机重启后，经过IST来同步增量数据，来完成保证与node1和node2的数据一致，IST的实现是由wsrep_provider_options="gcache.size=1G"参数决定，
通常设置为1G大，参数大小是由什么决定的，根据停机时间，若停机一小时，须要确认1小时内产生多大的binlog来算出参数大小。
假设这三个节点都关闭了，会发生什么呢？
所有传SST，由于gcache数据没了
所有关闭须要采用滚动关闭方式：
1）关闭node1，修复完后，启动加回来;
2）关闭node2,修复完后，启动加回来;
3）......,直到最后一个节点
4）原则要保持Group里最少一个成员活着
 
数据库关闭以后，最会保存一个last Txid，因此启动时，先要启动最后一个关闭的节点，启动顺序和关闭顺序恰好相反。
wsrep_recover=on参数在启动时加入，用于从log中分析gtid。
怎样避免关闭和启动时数据丢失？
1）全部的节点中最少有一个在线，进行滚动重启;
2）利用主从的概念，把一个从节点转化成PXC里的节点。

六、PXC注意的问题

1）脑裂：任何命令执行出现unkown command ，表示出现脑裂，集群两节点间4567端口连不通，没法提供对外服务。
   SET GLOBAL wsrep_provider_options="pc.ignore_sb=true"; 
2）并发写：三个节点的自增起始值为一、二、3，步长都为3，解决了insert问题，但update同时对一行操做就会有问题，出现：
   Error： 1213  SQLSTATE: 40001，因此更新和写入在一个节点上操做。
3）DDL：引发全局锁，采用：pt-online-schema-change 
4）MyISAM引擎不能被复制，只支持innodb
5）pxc结构里面必须有主键，若是没有主建，有可能会形成集中每一个节点的Data page里的数据不同
6）不支持表级锁，不支持lock /unlock tables 
7）pxc里只能把slow log ,query log 放到File里
8）不支持XA事务
9）性能由集群中性能最差的节点决定

------------------------------------------------------------------------------------------------------------
下面记录在Centos下部署基于PXC的Mysql高可用方案操做过程

官方配置说明：https://www.percona.com/doc/percona-xtradb-cluster/5.5/howtos/centos_howto.html

1）环境描述（centos6.8版本）
node1  10.171.60.171  percona1
node2  10.44.183.73   percona2
node3  10.51.58.169   percona3
  
三个节点上的iptables最好关闭（不然就要开放330六、444四、456七、4568端口的访问）、关闭selinux
  
2）三个node节点都要执行如下操做。
能够选择源码或者yum，在此使用yum安装。
基础安装
[root@percona1 ~]# yum -y groupinstall Base Compatibility libraries Debugging Tools Dial-up Networking suppport Hardware monitoring utilities Performance Tools Development tools
  
组件安装
[root@percona1 ~]# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm -y
[root@percona1 ~]# yum install Percona-XtraDB-Cluster-55 -y
  
3）数据库配置
选择一个node做为名义上的master，下面就以node1为master，只须要修改mysql的配置文件－－/etc/my.cnf
  
－－－－－－－－－－－－－－－－如下是在node1节点上的配置－－－－－－－－－－－－－－－－－－－－－－
[root@percona1 ~]# cat /etc/my.cnf
[mysqld]
  
datadir=/var/lib/mysql
user=mysql
  
# Path to Galera library
wsrep_provider=/usr/lib64/libgalera_smm.so
  
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_address=gcomm://10.171.60.171,10.44.183.73,10.51.58.169
  
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
  
# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB
  
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
  
# Node #1 address
wsrep_node_address=10.171.60.171
  
# SST method
wsrep_sst_method=xtrabackup-v2
  
# Cluster name
wsrep_cluster_name=my_centos_cluster
  
# Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
  
启动数据库（三个节点都要操做）：
node1的启动方式：
[root@percona1 ~]# /etc/init.d/mysql bootstrap-pxc
.....................................................................
若是是centos7，则启动命令以下：
[root@percona1 ~]# systemctl start mysql@bootstrap.service
.....................................................................
如果重启的话，就先kill，而后删除pid文件后再执行上面的启动命令。
  
配置数据库（三个节点都要操做）
mysql> show status like 'wsrep%';
+----------------------------+--------------------------------------+
| Variable_name              | Value                                |
+----------------------------+--------------------------------------+
.........
| wsrep_local_state          | 4                                    |
| wsrep_local_state_comment  | Synced                               |
| wsrep_cert_index_size      | 0                                    |
| wsrep_causal_reads         | 0                                    |
| wsrep_incoming_addresses   | 10.171.60.171:3306                   |      //集群中目前只有一个成员的ip
| wsrep_cluster_conf_id      | 1                                    |
| wsrep_cluster_size         | 1                                    |      //主要看这里，目前node2和node3尚未加入集群，因此集群成员目前只有一个
| wsrep_cluster_state_uuid   | 5dee8d6d-455f-11e7-afd8-ca25b704d994 |
| wsrep_cluster_status       | Primary                              |
| wsrep_connected            | ON                                   |
| wsrep_local_bf_aborts      | 0                                    |
| wsrep_local_index          | 0                                    |
| wsrep_provider_name        | Galera                               |
| wsrep_provider_vendor      | Codership Oy <info@codership.com>    |
| wsrep_provider_version     | 2.12(r318911d)                       |
| wsrep_ready                | ON                                   |
| wsrep_thread_count         | 2                                    |
+----------------------------+--------------------------------------+
  
数据库用户名密码的设置
mysql> UPDATE mysql.user SET password=PASSWORD("Passw0rd") where user='root';
  
建立、受权、同步帐号
mysql> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 's3cret';
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
mysql> FLUSH PRIVILEGES;
  
................注意下面几个察看命令...............
mysql> SHOW VARIABLES LIKE 'wsrep_cluster_address';
#若是配置了指向集群地址，上面那个参数值，应该是你指定集群的IP地址
  
# 此参数查看是否开启
mysql> show status like 'wsrep_ready';
  
# 查看集群的成员数
mysql> show status like 'wsrep_cluster_size';
  
# 这个查看wsrep的相关参数
mysql> show status like 'wsrep%';
  
4）那么node2和node3只须要配置my.cnf文件中的wsrep_node_address这个参数，将其修改成本身的ip地址便可。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
node2节点的/etc/my.cnf配置
[root@percona2 ~]# cat /etc/my.cnf
[mysqld]
  
datadir=/var/lib/mysql
user=mysql
  
# Path to Galera library
wsrep_provider=/usr/lib64/libgalera_smm.so
  
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_address=gcomm://10.171.60.171,10.44.183.73,10.51.58.169
  
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
  
# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB
  
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
  
# Node #1 address
wsrep_node_address=10.44.183.73
  
# SST method
wsrep_sst_method=xtrabackup-v2
  
# Cluster name
wsrep_cluster_name=my_centos_cluster
  
# Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
  
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
node3节点的/etc/my.cnf配置
[root@percona3 ~]# cat /etc/my.cnf
[mysqld]
  
datadir=/var/lib/mysql
user=mysql
  
# Path to Galera library
wsrep_provider=/usr/lib64/libgalera_smm.so
  
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_address=gcomm://10.171.60.171,10.44.183.73,10.51.58.169
  
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
  
# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB
  
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
  
# Node #1 address
wsrep_node_address=10.51.58.169
  
# SST method
wsrep_sst_method=xtrabackup-v2
  
# Cluster name
wsrep_cluster_name=my_centos_cluster
  
# Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
  
node2和node3的启动方式：
[root@percona2 ~]# /etc/init.d/mysql start

..................................注意................................ 
-> 除了名义上的master以外，其它的node节点只须要启动mysql便可。
-> 节点的数据库的登录和master节点的用户名密码一致，自动同步。因此其它的节点数据库用户名密码无须从新设置。
   也就是说，如上设置，只须要在名义上的master节点（如上的node1）上设置权限，其它的节点配置好/etc/my.cnf后，只须要启动mysql就行，权限会自动同步过来。
   如上的node2，node3节点，登录mysql的权限是和node1同样的（便是用node1设置的权限登录）
.....................................................................

若是上面的node二、node3启动mysql失败，好比/var/lib/mysql下的err日志报错以下：
[ERROR] WSREP: gcs/src/gcs_group.cpp:long int gcs_group_handle_join_msg(gcs_

解决办法：
-> 查看节点上的iptables防火墙是否关闭；检查到名义上的master节点上的4567端口是否连通（telnet）
-> selinux是否关闭
-> 删除名义上的master节点上的grastate.dat后，重启名义上的master节点的数据库；固然当前节点上的grastate.dat也删除并重启数据库
.....................................................................
  
5)最后进行测试
在任意一个node上，进行添加，删除，修改操做，都会同步到其余的服务器，是如今主主的模式，固然前提是表引擎必须是innodb，由于galera目前只支持innodb的表。

mysql> show status like 'wsrep%';
........
  wsrep_local_state          | 4                                                      |
| wsrep_local_state_comment  | Synced                                                 |
| wsrep_cert_index_size      | 2                                                      |
| wsrep_causal_reads         | 0                                                      |
| wsrep_incoming_addresses   | 10.44.183.73:3306,10.51.58.169:3306,10.171.60.171:3306 |     
| wsrep_cluster_conf_id      | 9                                                      |
| wsrep_cluster_size         | 3                                                      |     //集群成员是3个
| wsrep_cluster_state_uuid   | 92e43358-456d-11e7-af61-733b6b73c72c                   |
| wsrep_cluster_status       | Primary                                                |
| wsrep_connected            | ON                                                     |
| wsrep_local_bf_aborts      | 0                                                      |
| wsrep_local_index          | 2                                                      |
| wsrep_provider_name        | Galera                                                 |
| wsrep_provider_vendor      | Codership Oy <info@codership.com>                      |
| wsrep_provider_version     | 2.12(r318911d)                                         |
| wsrep_ready                | ON                                                     |
| wsrep_thread_count         | 2                

在node3上建立一个库
mysql> create database wangshibo;
Query OK, 1 row affected (0.02 sec)

而后在node1和node2上查看，自动同步过来
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
| wangshibo          |
+--------------------+
5 rows in set (0.00 sec)

在node1上的wangshibo库下建立表，插入数据
mysql> use wangshibo;
Database changed
mysql> create table test(
    -> id int(5));
Query OK, 0 rows affected (0.11 sec)

mysql> insert into test values(1);
Query OK, 1 row affected (0.01 sec)

mysql> insert into test values(2);
Query OK, 1 row affected (0.02 sec)

一样，在其它的节点上查看，也是能自动同步过来
mysql> select * from wangshibo.test;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)