- MHA(Master High Availability)是一个免费的开源工具,使用Prel开发。
- MHA更多关注点是主从复制中的主DB.
- 当主DB崩溃时,快速的在从服务器中找到最佳服务器。
- 在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用。
- 主服务器宕机时,MHA会尝试从主服务器尽可能多的保存二进制日志,最大程度保证事务的不丢失。如果主服务器硬件或者网络出现问题(ssh无法访问),肯定也就无法保存二进制日志了
- MHA可以与半同步复制结合起来
MHA功能
MHA主从切换过程
- 2可以手动设置从服务器不参与选举
- 3弥补其他从服务器数据差异
- 4如果重复的主键等会使MHA停止进行故障转移
- 5虚拟IP切换
MHA提供两个主要优点:
- 自动故障切换:有助于意外的主站故障,崩溃等等(故障切换也可以手动完成)。
- 快速在线主切换:在执行内核更新,MySQL升级,硬件升级等常规计划或计划维护操作时有用。
MHA演示架构(基于GTID)
MHA配置步骤
- SSH->故障转移过程中保存原主服务器二进制日志,配置虚拟IP地址等
- 日志点和GTID(推荐)
- ssh和复制链路的监测
MHA实例
确保gtid在集群中所有的服务器中启动
建立复制用户
从数据库初始化(略,备份,看上一篇)
从服务器启动复制链路
MHA配置
重复1,2步骤在每台服务器执行一遍
生成密钥之后,进行免密钥密码的配置
1 主服务器生成ssh密钥
2 主服务器拷贝ssh密钥到从服务器(主服务器的密钥验证也要配置)
3安装包下载
4 安装prel支持包
数据节点只需要这几个包,每天服务器都安装
yum -y install perl-DBD-MYSQL nctfp perl-DBI.x86
每天服务器都安装node节点包
rpm -ivh mha.....rpm
监控服务器安装依赖(上面的那个命令(监控节点))
安装监控包
rpm -ivh mha.....rpm
4 MHA配置(只需要在监控服务器配置就行)
- 创建配置文件保存目录
- 创建mha工作目录
- 创建配置文件
- 服务器默认信息
- mha主从管理用户(在主数据库(节点1)建立)
- 密码
- 管理服务工作目录
- remote_workdir远程服务器工作目录(手动在每个服务器建立)
- ssh用户(启动mha时的用户)
- 复制用户和密码
- ping_interval 检查主数据库是否可以连通的时间间隔
- master_binlog_dir目录
- show variables like ‘%log%’; -> log_bin_basename(主服务器查看位置)
- master_ip_failover_script执行脚本,完成主从切换之后,虚拟IP漂移
- 还可以添加完成主从切换后,自动邮箱通知DBA
- secondary_check_script(MHA默认只通过monitor服务器来监控主服务器是否可用),该脚本可以通过多网络路径来监测主服务器是否可用(当网络抖动时,避免错误切换)
- 主机信息
- hostname
- 参加master选举的服务器(不参加选举)
- 服务器默认信息
脚本
5 监测MHA配置
查看ssh免认证是否配置正确
监测主从复制的结构(环境)
6 启动MHA
MHA不会自动的配置虚拟IP,所以需要手动配置
nohup(放到后台) masterha manager --conf=/etc/mha/mysql_mha.cnf & [1]
ps -ef
ifconfig eth0:1 192.168.3.90/24 配置虚拟IP
7 测试MHA
停止数据库
/etc/init.d/mysql stop
ip addr 查看虚拟IP是否转移 OR
show slave status 监控服务器
8 MHA优缺点
- 优点
- Perl,开源
- 支持GTID
- MHA在故障转移时不易产生数据丢失(加强数据安全性)
- 同一个监控节点可以监控多个集群
- 缺点
- 没有虚拟IP的配置
- (脚本)->增加MHA工具复杂度
- 第三方工具,失去自动从多个从服务器去选取最优服务器的功能,增加集群部署的复杂性
- MHA运行时不监控复制链路,也就无法发现问题(复制链路中断,主从延迟增大)。
- MMM在主从链路出现问题时,通过切换故障服务器读VIP方式来排除故障服务器
- 没有虚拟IP的配置
读写分离
Mysql主从复制配置一个主要目的:为了分担主库的读负载(读>>写)
那么读写分离的目的:写负载是不能分担的,只能在主上进行写操作(读操作,主从都可以)
两种读写分离方式
- 由程序实现读写分离
- 架构简单,易于维护
- DBA和开发(控制读写分离)之间沟通成本的增加(重上线,重启程序)
- 由中间件实现读写分离
- mysql-proxy(实验项目,一直没正式上线) maxScale(MariaDB)
- 依赖中间层的性能(损耗比较严重,最好上线前进行一些基准测试,QPS降低50%到70%),故障点
- 加入提示关键字,对程序修改->从而对程序不再透明
负载均衡
- 程序轮询
- 软件:LVS Haproxy MaxScale
- 硬件 : F5
MaxScale Core
- Authentication
- 认证连接:后端数据库读取Mysql.user->缓存到MS服务器端->用户连接->判断是否通过验证 ->无此用户->对后端数据进行更新再进行验证
- Protocal:负责MS和外部接口的协议
- 客户端到MS的接口(mysql客户端协议插件)
- MS到后端数据的接口(mysql服务端协议插件)
- Router
- readconnroute(多台服务器负载均衡)
- readwritesplit(读写分离)
- Monitor 对后端数据库进行实时监控(前端请求->正确的后台数据库)
- Filter 数据库防火墙(对sql过滤和改写,sql容错和自动转换)
MaxScale Core安装和配置
演示环境:一主两从,主:192.168.3.101,从:192.168.3.100,192.168.3.102
账号的建立(监控模块,路由模块 )
加密密码(略)
修改配置文件
cd /etc/
ls -l maxscale*
- threads 进程(8)
- 服务器信息(全部)
- 监控模块的配置(加密密码填写,略)
- 读负载模块(略)
- 读写分离模块(也能实现读负载)
- 最大可用从服务器数量(默认:all)
- 从服务器最大的延迟 (当延迟大于60s后,从服务器不再参与读写分离)
- 监听
- 读监听
- 读写模块监听(独立服务器,3306端口)
MaxScale Core启动
maxscale --config=/etc/maxscale.cnf
确认
ps -ef | grep maxscale
netstat -ntelp
默认用户admin,密码:mariadb