设为首页 收藏本站
查看: 1076|回复: 0

[经验分享] Mysql之运用MHA的功能实现服务高可用

[复制链接]

尚未签到

发表于 2018-10-11 06:58:17 | 显示全部楼层 |阅读模式
  MHA介绍 (Master High Availability)
  MHA(Master HA)是一款开源的 MySQL 的高可用程序,它为 MySQL 主从复制架构提供 了 automating master failover 功能。MHA 在监控到 master 节点故障时,会提升其中拥有最新数据的 slave 节点成为新的 master 节点,在此期间,MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能,即按需切换 master/slave 节点。
  MHA是由日本人yoshinorim(原就职于DeNA现就职于FaceBook)开发的比较成熟的MySQL高可用方案。MHA能够在30秒内实现故障切换,并能在故障切换中,最大可能的保证数据一致性。目前淘宝也正在开发相似产品TMHA,目前已支持一主一从。
  MHA服务架构角色定义
  MHA 服务有两种角色,MHA Manager(管理节点)和 MHA Node(数据节点):
  MHA Manager:
  通常单独部署在一台独立机器上管理多个 master/slave 集群(组),每个
  master/slave 集群称作一个 application,用来管理统筹整个集群。
  MHA node:
  运行在每台 MySQL 服务器上(master/slave/manager),它通过监控具备解析和清理 logs 功能的脚本来加快故障转移。
  主要是接收管理节点所发出指令的代理,代理需要运行在每一个mysql节点上。
  简单讲:node就是用来收集从节点服务器上所生成的bin-log。对比打算提升为新的主节点之上的从节点的是否拥有并完成操作,如果没有发给新主节点在本地应用后提升为主节点。
DSC0000.png

  如何实现写均衡;ID分或者根据用户名(把用户名hash的结果去对服务器取模)
  Architecture of MHA
  MySQL 复制集群中的 master 故障时,MHA 将按如下步骤进行故障转移。
DSC0001.png

  1、Slave等待我们的sql线程把本地所复制过来的所有事件,都在本地完成重放
  2、mha_node需要在slave(i)上把latest slave所没有的灰色部分bin-log读取出来传给latest slave,由latest slave在本地补上灰色部分,然后它就成为了主节点,且这个过程是自动进行的,背后实现过程是通过各种程序组件来完成。
  故障转移原理
  当master出现故障时,通过对比slave之间I/O线程读取master binlog的位置,选取最接近的slave做为latestslave。 其它slave通过与latest slave对比生成差异中继日志。在latest slave上应用从master保存的binlog,同时将latest slave提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master复制信息。
  在MHA实现Master故障切换过程中,MHA Node会试图访问故障的master(通过SSH),如果可以访问(不是硬件故障,比如InnoDB数据文件损坏等),会保存二进制文件,以最大程度保 证数据不丢失。MHA和半同步复制一起使用会大大降低数据丢失的危险。
  MHA 组件详情
  MHA 会提供诸多工具程序,其常见的如下所示。
  Manager 节点:

  •   masterha_check_ssh:MHA 依赖的 SSH 环境检测工具,各节点要互信;
  •   masterha_check_repl:检查MYSQL复制环境是否正常;
  •   masterha_manager:MHA 服务器主程序;
  •   masterha_check_status:检查MHA 集群工作是否正常;
  •   masterha_master_monitor:检查监控MySQL master 主节点是否正常;
  •   masterha_master_switch:完成master 节点和slave节点切换的工具;
  •   masterha_conf_host:添加或删除配置的节点工具;
  •   masterha_stop:关闭 (停)MHA 服务的工具;
  Node 节点:

  •   save_binary_logs:保存和复制 mysql的master 二进制日志:
  •   apply_diff_relay_logs:识别差异的中继日志事件并应用于其它 slave:
  •   filter_mysqlbinlog:去除不必要的 ROLLBACK 事件(MHA 已不再使用这个工具):
  •   purge_relay_logs:清除中继日志(不会阻塞 SQL 线程):
  自定义扩展(辅助类工具):

  •   secondary_check_script:通过多条网络路由检测 master 的可用性;
  •   master_ip_failover_script:更新 application 使用的 masterip;
  •   shutdown_script:强制关闭 master 节点;
  •   report_script:发送报告;
  •   init_conf_load_script:加载初始配置参数;
  •   master_ip_online_change_script:更新 master 节点 ip 地址;
  测试环境说明和Mysql Replication环境
  依据虚拟机搭建四台主机
  Master主节点;node2,地址:172.16.5.102
  Slave从节点A;node3,地址:172.16.5.103
  Slave从节点B;node4,地址:172.16.5.104
  MHA管理节点;node5,地址:172.16.5.105
  MySQL Replication要求

  MHA 对 MySQL 复制环境有特殊要求,各节点都要开启二进制日志及中继日志,各从节点必须显式启用其 read-only 属性,并关闭>  同步各个节点上的时间;
  基于主机名进行解析请求;
  各个节点都是基于SSH互信通信;
  各个节点上都要关闭selinux与iptables
  请做以下步骤
[root@node5 ~]# ntpdate cn.ntp.org.cn 各个节点分别执行时间同步  [root@node5 ~]# vim /etc/hosts 修改hosts文件,对以下每主机名进行解析
  [root@node5 ~]# setenforce 0 每个节点上都要做
  [root@node5~]# iptables -F 每个节点上都要做
  172.16.5.102 node2.glances.org node2
  172.16.5.103 node3.glances.org node3
  172.16.5.104 node4.glances.org node4
  172.16.5.105 node5.glances.org node5
  基于SSH的互信通信
  在MHA管理节点上做如下操作
  [root@node5 ~]# ssh-keygen
  [root@node5 ~]# scp -p /root/.ssh/id_rsa.pub /root/.ssh/id_rsa root@node2:/root/.ssh
  把以上在MHA管理节点上生成的私钥文件分别复制到其它三个节点上,确保可无需验证登录
  可以在生成后的节点上自己做个测试执行;ssh 172.16.5.105 'date'(第一次需要密码,以后都不需要)
  vim /etc/ssh/ssh_config
  注释去掉;把StrictHostKeyChecking ask 修改为no,保存退出 (跳过rsa的key验证yes or no)
  主节点配置
主机名,node2;地址,172.16.5.102  安装mariadb数据库
  yum install mariadb-server
  修改配置文件,加入以下内容
  vim /etc/my.cnf
  innodb_file_per_table=1 //每张表都独立一个idb文件
  skip_name_resolve=1 //跳过反向解析
  server_id=1 服务器id
  relay-log=relay-log //中继日志
  log-bin=master-log //二进制日志
  保存退出
  把配置文件拷贝到另一台从节点,把server_id改成2
  scp /etc/my.cnf root@node3:/etc/my.cnf
  从节点配置
主机名,node3;地址,172.16.5.103  其它两台从节点配置文件相同,只要server的ID不一样就行
  安装mariadb数据库
  yum install mariadb-server
  修改配置文件,加入以下内容
  vim /etc/my.cnf
  innodb_file_per_table=1
  skip_name_resolve=1
  server_id=2
  relay-log=relay-log
  log-bin=master-log
  relay-only=1
  relay-log-purge=0
  保存退出
  把配置文件拷贝到另一台从节点,把server_id改成3
  scp /etc/my.cnf root@node5:/etc/my.cnf
  各节点授权和认证操作
  
  主节点1操作;
  [root@node2 ~]# mysql //登录到mysql,执行下面步骤
  msyql>grant replication slave, replication client on * . * to 'repuser'@'172.16.5.%'>  授权主从节点允许登录的IP地址和用户
  mysql>show master status;
  查看节点状态,把master-log日志从哪个位置产生的,记录下来
  mysql>show binlog events in 'master-log.000003';
  查看下二进制日志事件有没有成功记录,在以上做的授权被事件日志准确记录后,我们就不需要一个一个去登录mariadb从节点做认证授权,等我们启动从节点后会自动同步过去。
  从节点2操作;
  [root@node2 ~]# mysql //登录到mysql,执行下面步骤
  mysql>change master to master_host='172.16.5.102',master_user='repuser',master_password='repuser',master_log_file='master-log.000003',master_log_pos=594;
  如果从节点在运行中执行 start top;
  msyql>start slave;
  mysql>show slave status\G
  mysql>select host user from mysql.user;
  节点2上面的操作一样在节点3上执行一遍,这样主从复制就成功搭建起来了。
  在主节点上执行创建数据库,修改数据库,看数据会不会自动同步到两个从节点上。
  在各节点上安装MHA
  除 了 源 码 包 , MHA 官 方 也 提 供 了 rpm 格 式 的 程 序 包 , 其 下 载 地 址 为 https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2。
  CentOS 7 适用于el6 程序包。另外MHA Manage 和 MHA Node 程序包的版本并不强制要求一致。
  安装:
  管理节点:node5,地址:172.16.5.105
  在管理节点安装MHA管理组件,先安装node再安装manager软件本身有依赖关系
  yum install ./mha4mysql-node-0.56-0.el6.noarch.rpm
  yum install ./mha4mysql-manager-0.56-0.el6.noarch.rpm
  把mha4mysql-node-0.56-0.el6.noarch.rpm程序包拷贝到其它三个节点上
  for i in 102 103 104; do scp mha4mysql-node-0.56-0.el6.noarch.rpm 172.16.5.$i:/root/ ;done
  三个节点都必须安装
  node2,地址:172.16.5.102
  node3,地址:172.16.5.103
  node4,地址:172.16.5.104
  yuminstall ./mha4mysql-node-0.56-0.el6.noarch.rpm
  初始化MHA
  Manger 节点需要为每个监控的 master/slave 集群提供一个专用的配置文件, 而所有的 master/slave 集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf,其为可选配置。如仅监控一组 master/slave 集群,可直接通过 application 的配置来提供各服务器的默认配置信息。而每个 application 的配置文件路径为自定义。
MariaDB [(none)]> grant all on *.* to 'mhaadmin'@'172.16.5.%'>MariaDB [(none)]> flush privileges;
  为MHA专门创建一个管理用户,方便以后使用,在mysql的主节点上,三个节点自动同步
  mkdir /etc/mha_master
  vim /etc/mha_master/app1.cnf
  配置文件内容如下;
  [server default] //适用于server1,2,3个server的配置
  user=mhaadmin //mha管理用户
  password=mhaadmin //mha管理密码
  manager_workdir=/mydata/mha_master/app1 //mha_master自己的工作路径
  manager_log=/mydata/mha_master/manager.log // mha_master自己的日志文件
  remote_workdir=/mydata/mha_master/app1 //每个远程主机的工作目录在何处
  ssh_user=root // 基于ssh的密钥认证
  repl_user=repuser //数据库用户名
  repl_password=repuser //数据库密码
  ping_interval=1 // ping间隔时长
  [server1] //节点1
  hostname=172.16.5.102 //节点1主机地址
  ssh_port=22 //节点1的ssh端口
  candidate_master=1 // 将来可不可以成为master候选节点/主节点
  [server2]
  hostname=172.16.5.103
  ssh_port=22
  candidate_master=1
  [server2]
  hostname=172.16.5.104
  ssh_port=22
  candidate_master=1
  检测各节点间 ssh 互信通信配置是否 OK
  [root@node5 .ssh]# masterha_check_ssh –conf=/etc/mha_master/app1.cnf
  输出信息最后一行类似如下信息,表示其通过检测。 [info]
  All SSH connection tests passed successfully.
  检查管理的 MySQL 复制集群的连接配置参数是否 OK
  目的是我们的数据库定义的用户repuser和密码能否执行复制权限
  [root@node5 ~]# masterha_check_repl –conf=/etc/masterha/app1.cnf
  输出信息如下所示,最后一行的“Health is OK”信息表示通过检测。
  Mon Nov 9 17:22:48 2015 – [info] Slaves settings check done.
  ……
  MySQL Replication Health is OK.
  注意:
  在检查完成后末尾会有两条警号信息
  [warning] master_ip_failover_script is not defined.
  这个是用来定义master_ip地址的故障转移,谁成为主节点后自动把地址转移过去,让它成为主节点,谁成为主节点,谁配置vip(用来配置vip的)需要自己写脚本
  [warning] shutdown_script is not defined.
  这个showdown脚本在安装时已经有了
  rpm -qa mha4mysql-manager ,这个包里有。不用写
  以上两个提供不提供无所谓,只是测试,我们用其它方式启动
  启动 MHA
  启动方式用;nohup 后台运行
  如果不用nohup就意味着前台运行,如果终端关了。意味着服务就自动停了!!!
  第一次启动可以用配置文件启动
  masterha_manager –conf=/etc/mha_master/app1.cnf >/mydata/mha_master/app1/manager.log 2>&1
  直接后台运行,不用输出重定向到某个目录了
  masterha_manager –conf=/etc/mha_master/app1.cnf
  前台运行,更直观
  ok!!!
  这个时候可以在数据库里做一些操作了,创建数据库,创建表,删除字段,删除表,测试目的
  mysql>create database tbl05;
  mysql>drop database tbl04;
  mysql>use tbl05;
  mysql>create tables
  启动成功后,可通过如下命令来查看 master 节点的状态
  masterha_check_status --conf=/etc/mha_master/app1.cnf
  [root@node5 mydata]# masterha_check_status –conf=/etc/mha_master/app1.cnf
  app1 (pid:3211) is running(0:PING_OK), master:172.16.5.102
  [root@node5 mydata]#
  正常运行中……
  如果要停止 MHA,需要使用 masterha_stop 命令
  masterha_stop --conf=/etc/mha_master/app1.cnf
  [root@node5 mydata]# masterha_stop –conf=/etc/mha_master/app1.cnf
  测试故障转移
  (1) 在 master 节点关闭 mariadb 服务
  killall mysqld mysqld_safe
  systemctl stop mariadb.service
  (2) 在 manager 节点查看日志
  如果我们没有记录日志是没有的
  注意,故障转移完成后,manager 将会自动停止,此时使用 masterha_check_status
  命令检测将会遇到错误提示,如下所示。
  [root@node5 ~]# masterha_check_status --conf=/etc/mha-master/app1.cnf
  app1 is stopped(2:NOT_RUNNING)
  (3) 提供新的从节点以修复复制集群
  原有 master 节点故障后,需要重新准备好一个新的 MySQL 节点。基于来自于 master 节点的备份恢复数据后,将其配置为新的 master 的从节点即可。注意,新加入的节点如果为新 增节点,其 IP 地址要配置为原来 master 节点的 IP,否则,还需要修改 app1.cnf 中相应的 ip 地址。随后再次启动 manager,并再次检测其状态。
  (4)新节点提供后再次执行检查操作
  masterha_check_status --conf=/etc/mha_master/app1.cnf
  masterha_check_repl --conf=/etc/mha_master/app1.cnf
  检查无误,再次运行,这次要记录日志
  masterha_manager --conf=/etc/mha_master/app1.cnf >/mydata/mha_master/app1/manager.log 2>&1
  新节点上线,故障转换恢复注意事项
  (1)、在生产环境中,当你的主节点挂了后,一定要在从节点上做一个备份,拿着备份文件把主节点手动提升为从节点,并指明从哪一个日志文件的位置开始复制
  (2)、每一次自动完成转换后,每一次的(replication health )检测不ok始终都是启动不了
  必须手动修复主节点,除非你改配置文件
  (3)、手动修复主节点提升为从节点后,再次运行检测命令
  [root@node5 ~]# masterha_check_repl --conf=/etc/mha_master/app1.cnf
  app1 (pid:3211) is running(0:PING_OK), master:172.16.5.103
  (4)、再次运行起来就恢复成功了
  masterha_manager --conf=/etc/mha_master/app1.cnf
  手动完成在线主从节点切换
  注意:所有都正常,只是想改一下主节点是谁而已
  masterha_master_switch --master state=alive --conf=/etc/mha_master/app1.cnf
  会提示你在数据库主节点上执行某条语句
  flush no_write_to_binlog tables; //没有写操作的节点,执行flush
  确认,输入yes
  手动检测在各个节点上,把停止的节点手动修复,启用为slave模式
  更进一步的提升工作效率
  前面三个步骤已经配置了一个基本的MHA 环境。不过为了更多实际应用需求,还需进一步完成如下操作。
  (1)、提供额外检测机制,指明对 master 的监控做出误判;
  (2)、在 master 节点上提供虚拟 ip 地址向外提供服务,指明 master 节点转换时,客户端的请求无法正确送达;
  (3)、进行故障转移时对原有 master 节点执行 STONITH 操作以避免脑裂; 可通过指定shutdown_script 实现;
  (4)、必要时可进行在线 master 节点转换;
  done!!!



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-620098-1-1.html 上篇帖子: mysql tinyint和char(1)性能对比 下篇帖子: 玩转mysql授权
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表