Mysql 5.7 CentOS 7 安装MHA

• 1. MHA简介
  • 1.1. 功能
  • 1.2. MHA切换逻辑
  • 1.3. 工具
• 2. 环境
  • 2.1. 软件
  • 2.2. 环境
• 3. Mysql 主从复制
  • 3.1. Mysql数据同步方式
    • 3.1.1. 异步复制（Asynchronous replication）
    • 3.1.2. 全同步复制(Fully synchronous replication)
    • 3.1.3. 半同步复制(Semisynchronous replication)
  • 3.2. 搭建Mysql 主从架构
    • 3.2.1. Mysql 数据库安装
    • 3.2.2. 调整Mysql数据库
    • 3.2.3. 定时清理relay
• 4. MHA安装配置
  • 4.1. *安装依赖包*
    • 4.1.1. 依赖包的依赖包
    • 4.1.2. 依赖包
    • 4.1.3. 其他包
  • 4.2. 下载manager与node
  • 4.3. 安装
  • 4.4. 配置MHA
    • 4.4.1. MHA Manager
  • 4.5. 添加主机互信
  • 4.6. 测试SSH连接
  • 4.7. 配置VIP
    • 4.7.1. Keepalive
    • 4.7.2. 脚本方式
  • 4.8. 检查整个复制环境状况
    • 4.8.1. 命令
    • 4.8.2. 结果
  • 4.9. 启停MHA
    • 4.9.1. 通过daemonize 启动
    • 4.9.2. 检查MHA状态
    • 4.9.3. 停止MHA
    • 4.9.4. 坑
  • 4.10. 主从切换
    • 4.10.1. 主动切换
    • 4.10.2. 被动切换
    • 4.10.3. 修复故障数据库
    • 4.10.4. 坑

开始之前，我只想说，这是一个磨碎了我的小心灵的过程，虽然最终还是被我抛弃了，但是给有兴趣的人留个念想吧~

1 MHA简介

官方介绍：https://code.google.com/archive/p/mysql-master-ha/

源码地址：https://github.com/yoshinorim (在Popular repositories 可以直接看到 Manager 与 node 的连接)

MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由youshimaton(现就职于 Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换 过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度 上保证数据的一致性,以达到真正意义上的高可用. 并且代码一直在维护中。

1.1 功能

该软件由两部分组成：MHA Manager(管理节点)和MHA Node(数据节点). MHA Manager可以单独部署在一台独立的机器上 管理多个master-slave集群,也可以部署在一台slave节点上.MHA Node运行在每台MySQL服务器上,MHA Manager会定时探 测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的 slave重新指向新的master.整个故障转移过程对应用程序完全透明.

在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度的保证数据的不丢失,但这并不总是可 行的.例如,如果主服务器硬件故障或无法通过ssh访问,MHA没法保存二进制日志,只进行故障转移而丢失了最新的数据,使 用MySQL 5.5开始提供的半同步复制功能，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来.如果只有一个 slave已经收到了最新的二进制日志,MHA可以将最新的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节 点的数据一致性。

特点:

• 一个manager 可以管理一组或者多组主从结构
• 通过VIP 实现对应用的透明

1.2 MHA切换逻辑

• 从宕机的master中保存二进制文件
• 检测含有最新日至更新的slave
• 应用差异的中继日至（relay log）到其他的slave
• 应用从master中保存的二进制日至事件到其他的slave中
• 提升一个slave为master
• 使其他的slave指向最新的master进行复制。

1.3 工具

• Manager工具
  • masterha_check_ssh 检查MHA的SSH配置状况
  • masterha_check_repl 检查MySQL复制状况
  • masterha_manger 启动MHA
  • masterha_check_status 检测当前MHA运行状态
  • masterha_master_monitor 检测master是否宕机
  • masterha_master_switch 控制故障转移（自动或者手动）
  • masterha_conf_host 添加或删除配置的server信息
• failover 相关脚本
  • master_ip_failover //自动切换时vip管理的脚本，不是必须，如果我们使用keepalived的，我们可以自己 编写脚本完成对vip的管理，比如监控mysql，如果mysql异常,我们停止keepalived vip就会自动漂移
  • master_ip_online_change //在线切换时vip的管理
  • power_manager //故障发生后关闭主机的脚本
  • send_report //因故障切换后发送报警的脚

• Node 工具
  • save_binary_logs 保存和复制master的二进制日志
  • apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave
  • filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
  • purge_relay_logs 清除中继日志（不会阻塞SQL线程）

2 环境

2.1 软件

2.2 环境

3 Mysql 主从复制

使用Mysql MHA 需要使用到 Mysql 5.5以后出现的半同步复制。 Oracle公司的Mysql https://dev.mysql.com/downloads/mysql/ 下载需要的版本。 小红帽默认使用的Mariadb 至10.3.5 版本都没有提供super_read_only 参数。而在安装MHA时需要对此参数进行检验。 因此只能弃用RHEL默认提供的Mariadb。

3.1 Mysql数据同步方式

mysql 主从数据同步分为三种类型： 异步，实时全同步、半同步

3.1.1 异步复制（Asynchronous replication）

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否 已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果 此时，强行将从提升为主，可能导致新主上的数据不完整

3.1.2 全同步复制(Fully synchronous replication)

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才 能返回，所以全同步复制的性能必然会收到严重的影响。

3.1.3 半同步复制(Semisynchronous replication)

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个 从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造 成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用.

半同步复制在5.7版本中发生了一次处理逻辑顺序的调整。先来看下5.5中的处理逻辑:

mysql SQL parse –> Storage Involve –> Write Binary Log –> Storage Commit –> Waiting Slave Dump –> Return to Client

在5.7中，将 Waiting Slave Dump 调整至 Storage Commit 之前进行.这样调整后,保证了主从数据的一致性, 并避免了重复提交.

• 5.5中半同步逻辑隐患

  客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时，可能的情况有两种

  事务还没发送到从库上

  此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。

  事务已经发送到从库上

  此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。

• 无数据丢失的半同步复制

  针对上述潜在问题，MySQL 5.7引入了一种新的半同步方案：Loss-Less半同步复制。

  “Waiting Slave dump”被调整到“Storage Commit”之前。

  之前的半同步方案同样支持，MySQL 5.7.2引入了一个新的参数进行控制: rpl_semi_sync_master_wait_point

  rpl_semi_sync_master_wait_point有两种取值

  AFTER_SYNC

  Waiting Slave dump在Storage Commit之前。

  AFTER_COMMIT Waiting Slave dump在Storage Commit之后。

• 启用半同步复制

  在安装完插件后，半同步复制默认是关闭的，这时需设置参数来开启半同步

  主：
  mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;
  从：
  mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;
  

  以上的启动方式是在命令行操作，也可写在配置文件中。

  主：

  plugin-load=rpl_semi_sync_master=semisync_master.so
  rpl_semi_sync_master_enabled=1
  

  从：

  plugin-load=rpl_semi_sync_slave=semisync_slave.so
  rpl_semi_sync_slave_enabled=1
  

  在有的高可用架构下，master和slave需同时启动，以便在切换后能继续使用半同步复制

  plugin-load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
  rpl-semi-sync-master-enabled = 1
  rpl-semi-sync-slave-enabled = 1
  

3.2 搭建Mysql 主从架构

3.2.1 Mysql 数据库安装

此部分仅供参照。此部分记录是之前在其他环境中搭建主从架构的文档。操作步骤是一样的。

1. system	mariadb
   CentOS 7.2	10.2.6

• 互为主从的关系。

  master	slave
  10.100.3.61	10.100.3.62
  10.100.3.62	10.100.3.61

• 本示例中，将文件上传至/root

  tar -xzvf ./mariadb-10.2.6.tar.gz 
  cd mariadb-10.2.6
  

1. mysql 被收购后，不再提供源码，因此不可能再做源码安装。 想进行源码安装，可以选择Mariadb。

   Oracle mysql:

   https://dev.mysql.com/downloads/mysql/

   mariadb: https://downloads.mariadb.org/mariadb/+releases/

   下载后，上传至服务器并解压。这是一般的步骤。对于不熟悉此操作的，请先熟悉 Linux基本操作.