一、mysql 主主同步 (不使用共享存储,数据保存本地存储)
1. mysql1 192.168.122.10: [root@mysql1 ~]# vim /etc/my.cnf log-bin=mysql-bin server-id = 4 [root@mysql1 ~]# service mysqld start [root@mysql1 ~]# mysql mysql> reset master; mysql> grant replication slave, replication client on *.* -> to admin@‘%‘ identified by ‘123‘; mysql> flush privileges; mysql> change master to -> master_host=‘192.168.122.20‘, -> master_user=‘admin‘, -> master_password=‘123‘, -> master_log_file=‘mysql-bin.000001‘, //根据个人实际修改 -> master_log_pos=0; //根据个人 Query OK, 0 rows affected (0.02 sec) mysql> show slave statusG
2. mysql2192.168.122.20: [root@mysql2 ~]# vim /etc/my.cnf log-bin=mysql-bin server-id = 251 [root@mysql2 ~]# service mysqld start [root@mysql2 ~]# mysql mysql> reset master; mysql> grant replication slave, replication client on *.* -> to admin@‘%‘ identified by ‘123‘; mysql> flush privileges; mysql> change master to -> master_host=‘192.168.122.10‘, -> master_user=‘admin‘, -> master_password=‘123‘, -> master_log_file=‘mysql-bin.000001‘, -> master_log_pos=0; Query OK, 0 rows affected (0.02 sec) mysql> show slave statusG
二、安装keepalived
[root@root ~]# yum -y install ipvsadm kernel-headers kernel-devel openssl-devel popt-devel方法一:源码安装keepalived[root@root ~]# wget http://www.keepalived.org/software/keepalived-1.2.2.tar.gz[root@root ~]# tar zxvf keepalived-1.2.2.tar.gz[root@root ~]# cd keepalived-1.2.2[root@root ~]# ./configure --prefix=/ //安装到根下,防止目录太深[root@root ~]# make [root@root ~]# make install方法二:[root@root ~]# yum -y install keepalived
三、keepalived 主备配置文件
192.168.122.10 Master配置 [root@root ~]# vim /etc/keepalived/keepalived.conf=====================================================================! Configuration File for keepalivedglobal_defs { router_id mysql1}vrrp_script check_run { script "/root/keepalived_check_mysql.sh" interval 5}vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 88 priority 100 advert_int 1 authentication { auth_type PASS auth_pass root } track_script { check_run } virtual_ipaddress { 192.168.122.100 }}
192.168.122.20 Slave配置 [root@root ~]# vim /etc/keepalived/keepalived.conf=====================================================================! Configuration File for keepalivedglobal_defs { router_id mysql2}vrrp_script check_run { script "/root/keepalived_check_mysql.sh" interval 5}vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 88 priority 50 advert_int 1 authentication { auth_type PASS auth_pass root } track_script { check_run } virtual_ipaddress { 192.168.122.100 }}
1. 注意空格2. 日志查看脚本是否被执行[root@xen2 ~]# tail -f /var/log/messages Jun 19 15:20:19 xen1 Keepalived_vrrp[6341]: Using LinkWatch kernel netlink reflector...Jun 19 15:20:19 xen1 Keepalived_vrrp[6341]: VRRP sockpool: [ifindex(2), proto(112), fd(11,12)]Jun 19 15:20:19 xen1 Keepalived_vrrp[6341]: VRRP_Script(check_run) succeeded
四、mysql状态检测脚本/root/bin/keepalived_check_mysql.sh
[root@root ~]# vim /root/keepalived_check_mysql.sh#!/bin/bash MYSQL=/usr/local/mysql/bin/mysqlMYSQL_HOST=localhost MYSQL_USER=root //连接mysql的用户名MYSQL_PASSWORD=root //连接mysql的密码CHECK_TIME=3#mysql is working MYSQL_OK is 1 , mysql down MYSQL_OK is 0 MYSQL_OK=1check_mysql_helth (){ $MYSQL -h $MYSQL_HOST -u $MYSQL_USER -p${MYSQL_PASSWORD} -e "show status;" &>/dev/null if [ $? -eq 0 ] ;then MYSQL_OK=1 else MYSQL_OK=0 fi return $MYSQL_OK }while [ $CHECK_TIME -ne 0 ]do check_mysql_helth if [ $MYSQL_OK -eq 1 ] ; then exit 0 filet CHECK_TIME-- sleep 1 done/etc/init.d/keepalived stopexit 1
[root@root ~]# chmod 755 /root/keepalived_check_mysql.sh
两边均启动keepalived[root@root ~]# /etc/init.d/keepalived start[root@root ~]# /etc/init.d/keepalived start[root@root ~]# chkconfig --add keepalived[root@root ~]# chkconfig keepalived on
五、测试及诊断注 keepalived之间使用vrrp组播方式通信使用的IP地址是224.0.0.18
Keepalived+mysql实现高可用
标签:identified master change admin mysql
小编还为您整理了以下内容,可能对您也有帮助:
mysql+MHA+keepalived高可用方案
关于基础介绍及原理略过,直接上操作步骤吧。
mysql:5.7
操作系统:centos7.4
地址规划:
MHA manage:10.21.20.89
mysql主:10.21.20.71
mysql从1:10.21.20.131
mysql从2:10.21.20.132
vip:10.21.20.77
(3)将mharepo.tar.gz上传四台需要安装的服务器解压。然后新建一个yum文件,指向解压的目录。
(4) 安装MHA,在3台mysql上安装node,在管理节点安装manager。
在主库和从库上观察ip发现,vip已经自动漂移到从库上。至此高可用完成。
mysql+MHA+keepalived高可用方案
关于基础介绍及原理略过,直接上操作步骤吧。
mysql:5.7
操作系统:centos7.4
地址规划:
MHA manage:10.21.20.89
mysql主:10.21.20.71
mysql从1:10.21.20.131
mysql从2:10.21.20.132
vip:10.21.20.77
(3)将mharepo.tar.gz上传四台需要安装的服务器解压。然后新建一个yum文件,指向解压的目录。
(4) 安装MHA,在3台mysql上安装node,在管理节点安装manager。
在主库和从库上观察ip发现,vip已经自动漂移到从库上。至此高可用完成。
mysql keepalive+ 双主多从是怎么做的
我们通常说的双机热备是指两台机器都在运行,但并不是两台机器都同时在提供服务。当提供服务的一台出现故障的时候,另外一台会马上自动接管并且提供服务,而且切换的时间非常短。MySQL双主复制,即互为Master-Slave(只有一个Master提供写操作),可以实现数据库服务器的热备,但是一个Master宕机后不能实现动态切换。使用Keepalived,可以通过虚拟IP,实现双主对外的统一接口以及自动检查、失败切换机制,从而实现MySQL数据库的高可用方案。之前梳理了Mysql主从/主主同步,下面说下Mysql+keeoalived双主热备高可用方案的实施。
Keepalived看名字就知道,保持存活,在网络里面就是保持在线了,也就是所谓的高可用或热备,用来防止单点故障(单点故障是指一旦某一点出现故障就会导
整个系统架构的不可用)的发生,那说到keepalived不得不说的一个协议不是VRRP协议,可以说这个协议就是keepalived实现的基础。
1)Keepalived的工作原理是VRRP(Virtual Router Rendancy Protocol)虚拟路由冗余协议。在VRRP中有两组重要的概念:VRRP路由器和虚拟路由器,主控路由器和备份路由器。
2)VRRP路由器是指运行VRRP的路由器,是物理实体,虚拟路由器是指VRRP协议创建的,是逻辑概念。一组VRRP路由器协同工作,共同构成一台虚拟路由器。
Vrrp中存在着一种选举机制,用以选出提供服务的路由即主控路由,其他的则成了备份路由。当主控路由失效后,备份路由中会重新选举出一个主控路由,来继
续工作,来保障不间断服务。
mysql keepalive+ 双主多从是怎么做的
我们通常说的双机热备是指两台机器都在运行,但并不是两台机器都同时在提供服务。当提供服务的一台出现故障的时候,另外一台会马上自动接管并且提供服务,而且切换的时间非常短。MySQL双主复制,即互为Master-Slave(只有一个Master提供写操作),可以实现数据库服务器的热备,但是一个Master宕机后不能实现动态切换。使用Keepalived,可以通过虚拟IP,实现双主对外的统一接口以及自动检查、失败切换机制,从而实现MySQL数据库的高可用方案。之前梳理了Mysql主从/主主同步,下面说下Mysql+keeoalived双主热备高可用方案的实施。
Keepalived看名字就知道,保持存活,在网络里面就是保持在线了,也就是所谓的高可用或热备,用来防止单点故障(单点故障是指一旦某一点出现故障就会导
整个系统架构的不可用)的发生,那说到keepalived不得不说的一个协议不是VRRP协议,可以说这个协议就是keepalived实现的基础。
1)Keepalived的工作原理是VRRP(Virtual Router Rendancy Protocol)虚拟路由冗余协议。在VRRP中有两组重要的概念:VRRP路由器和虚拟路由器,主控路由器和备份路由器。
2)VRRP路由器是指运行VRRP的路由器,是物理实体,虚拟路由器是指VRRP协议创建的,是逻辑概念。一组VRRP路由器协同工作,共同构成一台虚拟路由器。
Vrrp中存在着一种选举机制,用以选出提供服务的路由即主控路由,其他的则成了备份路由。当主控路由失效后,备份路由中会重新选举出一个主控路由,来继
续工作,来保障不间断服务。
MySQL高可用的几种方案MySQL的各种高可用方案,大多是基于以下几种基础来部署的:
基于主从复制;
基于Galera协议;
基于NDB引擎;
基于中间件/proxy;
基于共享存储;
基于主机高可用;
在这些可选项中,最常见的就是基于主从复制的方案,其次是基于Galera的方案,我们重点说说这两种方案。其余几种方案在生产上用的并不多,我们只简单说下。
基于主从复制的高可用方案
双节点主从 + keepalived/heartbeat
一般来说,中小型规模的时候,采用这种架构是最省事的。两个节点可以采用简单的一主一从模式,或者双主模式,并且放置于同一个VLAN中,在master节点发生故障后,利用keepalived/heartbeat的高可用机制实现快速切换到slave节点。
在这个方案里,有几个需要注意的地方:
采用keepalived作为高可用方案时,两个节点最好都设置成BACKUP模式,避免因为意外情况下(比如脑裂)相互抢占导致往两个节点写入相同数据而引发冲突;
把两个节点的auto_increment_increment(自增步长)和auto_increment_offset(自增起始值)设成不同值。其目的是为了避免master节点意外宕机时,可能会有部分binlog未能及时复制到slave上被应用,从而会导致slave新写入数据的自增值和原先master上冲突了,因此一开始就使其错开;当然了,如果有合适的容错机制能解决主从自增ID冲突的话,也可以不这么做;
slave节点服务器配置不要太差,否则更容易导致复制延迟。作为热备节点的slave服务器,硬件配置不能低于master节点;
如果对延迟问题很敏感的话,可考虑使用MariaDB分支版本,或者直接上线MySQL 5.7最新版本,利用多线程复制的方式可以很大程度降低复制延迟;
对复制延迟特别敏感的另一个备选方案,是采用semi sync replication(就是所谓的半同步复制)或者后面会提到的PXC方案,基本上无延迟,不过事务并发性能会有不小程度的损失,需要综合评估再决定;
keepalived的检测机制需要适当完善,不能仅仅只是检查mysqld进程是否存活,或者MySQL服务端口是否可通,还应该进一步做数据写入或者运算的探测,判断响应时间,如果超过设定的阈值,就可以启动切换机制;
keepalived最终确定进行切换时,还需要判断slave的延迟程度。需要事先定好规则,以便决定在延迟情况下,采取直接切换或等待何种策略。直接切换可能因为复制延迟有些数据无法查询到而重复写入;
keepalived或heartbeat自身都无法解决脑裂的问题,因此在进行服务异常判断时,可以调整判断脚本,通过对第三方节点补充检测来决定是否进行切换,可降低脑裂问题产生的风险。
双节点主从+keepalived/heartbeat方案架构示意图见下:
图解:MySQL双节点(单向/双向主从复制),采用keepalived实现高可用架构。
多节点主从+MHA/MMM
多节点主从,可以采用一主多从,或者双主多从的模式。这种模式下,可以采用MHA或MMM来管理整个集群,目前MHA应用的最多,优先推荐MHA,最新的MHA也已支持MySQL 5.6的GTID模式了,是个好消息。MHA的优势很明显:
开源,用Perl开发,代码结构清晰,二次开发容易;
方案成熟,故障切换时,MHA会做到较严格的判断,尽量减少数据丢失,保证数据一致性;
提供一个通用框架,可根据自己的情况做自定义开发,尤其是判断和切换操作步骤;
支持binlog server,可提高binlog传送效率,进一步减少数据丢失风险。
不过MHA也有些:
需要在各个节点间打通ssh信任,这对某些公司安全制度来说是个挑战,因为如果某个节点被黑客攻破的话,其他节点也会跟着遭殃;
自带提供的脚本还需要进一步补充完善,当然了,一般的使用还是够用的。
多节点主从+etcd/zookeeper
在大规模节点环境下,采用keepalived或者MHA作为MySQL的高可用管理还是有些复杂或麻烦。首先,这么多节点如果没有采用配置服务来管理,必然杂乱无章,线上切换时很容易误操作。在较大规模环境下,建议采用etcd/zookeeper管理集群,可实现快速检测切换,以及便捷的节点管理。
基于Galera协议的高可用方案
Galera是Codership提供的多主数据同步复制机制,可以实现多个节点间的数据同步复制以及读写,并且可保障数据库的服务高可用及数据一致性。基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster(简称PXC),目前PXC用的会比较多一些。
PXC的架构示意图见下:
(图片源自网络),图解:在底层采用wsrep接口实现数据在多节点间的同步复制。
(图片源自网络),图解:在PXC中,一次数据写入在各个节点间的验证/回滚流程。
PXC的优点
服务高可用;
数据同步复制(并发复制),几乎无延迟;
多个可同时读写节点,可实现写扩展,不过最好事先进行分库分表,让各个节点分别写不同的表或者库,避免让galera解决数据冲突;
新节点可以自动部署,部署操作简单;
数据严格一致性,尤其适合电商类应用;
完全兼容MySQL;
虽然有这么多好处,但也有些局限性:
只支持InnoDB引擎;
所有表都要有主键;
不支持LOCK TABLE等显式锁操作;
锁冲突、死锁问题相对更多;
不支持XA;
集群吞吐量/性能取决于短板;
新加入节点采用SST时代价高;
存在写扩大问题;
如果并发事务量很大的话,建议采用InfiniBand网络,降低网络延迟;
事实上,采用PXC的主要目的是解决数据的一致性问题,高可用是顺带实现的。因为PXC存在写扩大以及短板效应,并发效率会有较大损失,类似semi sync replication机制。
其他高可用方案
基于NDB Cluster,由于NDB目前仍有不少缺陷和,不建议在生产环境上使用;
基于共享存储,一方面需要不太差的存储设备,另外共享存储可也会成为新的单点,除非采用基于高速网络的分布式存储,类似RDS的应用场景,架构方案就更复杂了,成本也可能更高;
基于中间件(Proxy),现在可靠的Proxy选择并不多,而且没有通用的Proxy,都有有所针对,比如有的专注解决读写分离,有的专注分库分表等等,真正好用的Proxy一般要自行开发;
基于主机高可用,是指采用类似RHCS构建一个高可用集群后,再部署MySQL应用的方案。老实说,我没实际用过,但从侧面了解到这种方案生产上用的并不多,可能也有些局限性所致吧;
MySQL高可用的几种方案
标签:
MySQL-14mysql负载均衡
大家好,一起来搞一下mysql的负载均衡这个技术点。
1. haproxy介绍与配置
2. keeplived介绍与配置
3. mysql高可用搭建
1. 可靠性与稳定性都非常出色,可与硬件级设备媲美。
2. 支持连接拒绝,可以用于防止 DDoS 攻击
3. 支持长连接、短连接和日志功能,可根据需要灵活配置
4. 路由 HTTP 请求到后端服务器,基于 cookie 作会话绑定;同时支持通过获取指定的 url 来检测后 端服务器的状态
5. HAProxy 还拥有功能强大的 ACL 支持,可灵活配置路由功能,实现动静分离,在架构设计与实现上 带来很大方便
6. 可支持四层和七层负载均衡,几乎能为所有服务常见的提供负载均衡功能
7. 拥有功能强大的后端服务器的状态监控 web 页面,可以实时了解设备的运行状态 ,还可实现设备上 下线等简单操作。
8. 支持多种负载均衡调度算法,并且也支持 session 保持。
9. Haproxy 七层负载均衡模式下,负载均衡与客户端及后端的服务器会分别建立一次 TCP连接,而在 四层负载均衡模式下(DR),仅建立一次 TCP 连接;七层负载均衡对负载均衡设备的要求更高,处理能力 也低于四层负载均衡。
全局设定
global settings:主要用于定义 haproxy 进程管理安全及性能相关的参数。
代理设定
proxies 共分为4段:defaults,frontend,backend,listen
注意:此处只做配置文件介绍,不做为后期负载均衡配置
在192.168.199.175与192.168.199.172(负载均衡服务器)中安装与配置如下
haproxy状态检测脚本不执行问题,如果是使用的service keeplived start 或者是 systemctl 方式启动,脚本可能会不执行,可以使用 Keepalived -f /etc/keepalived/keepalived.conf方式启动Keepalived