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

1. MHA（Master High Availability）是一个免费的开源工具,使用Prel开发。
2. MHA更多关注点是主从复制中的主DB.
3. 当主DB崩溃时，快速的在从服务器中找到最佳服务器。
4. 在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。
5. 主服务器宕机时，MHA会尝试从主服务器尽可能多的保存二进制日志，最大程度保证事务的不丢失。如果主服务器硬件或者网络出现问题（ssh无法访问），肯定也就无法保存二进制日志了
6. 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