MYSQL性能优化之Mysql数据库高可用架构设计之MHA架构设计（下）

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在集群中所有的服务器中启动

show variables like 'gtid_mode';

建立复制用户

从数据库初始化（略，备份，看上一篇）

从服务器启动复制链路

show slave status ;

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免认证是否配置正确

masterha check ssh --conf= /etc/mha/mysql_mha

监测主从复制的结构(环境)

masterha check repl --conf= /etc/mha/mysql_mha

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方式来排除故障服务器

读写分离

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