ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

MHA配置

2019-05-12 15:50:36  阅读:226  来源: 互联网

标签:mastermha slave 配置 MHA 故障 Master master


 

1,背景

MHA的目的在于维持MySQL Replication中Master库的高可用性,其最大特点是可以修复多个Slave之间的差异日志,最终使所有Slave保持数据一致,然后从中选择一个充当新的Master,并将其它Slave指向它

当master出现故障时,通过对比slave之间I/O线程读取masterbinlog的位置,选取最接近的slave做为latestslave。 其它slave通过与latest slave对比生成差异中继日志。在latest slave上应用从master保存的binlog,同时将latest slave提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。

在MHA实现Master故障切换过程中,MHA Node会试图访问故障的master(通过SSH),如果可以访问(不是硬件故障,比如InnoDB数据文件损坏等),会保存二进制文件,以最大程度保 证数据不丢失。MHA和半同步复制一起使用会大大降低数据丢失的危险。流程如下:
• 从宕机崩溃的master保存二进制日志事件(binlog events)。
• 识别含有最新更新的slave。
• 应用差异的中继日志(relay log)到其它slave。
• 应用从master保存的二进制日志事件(binlog events)。
• 提升一个slave为新master并记录binlog file和position。
• 使其它的slave连接新的master进行复制。
• 完成切换manager主进程OFFLINE

功能:

MHA具有如下几个功能:
(1) Master自动监控和故障转移
           基于现有的MySQL主从复制环境,MHA可以监控Master,当发现其故障时,自动进行切换。
(2) 互动(手动)Master故障转移
           可以只使用MHA的故障转移功能,而不监控Master,当其故障时,手动调用MHA来进行故障切换。
(3)非交互式自动故障转移
          MHA还支持非交互式的Master故障切换(不监控Master,但实现自动故障切换),这个特性其实是将Master的监控和VIP接管交给第三方工具来做,比如Heartbeat,MHA只负责Master故障转移和Slave之间的数据同步。
(4) 在线切换Master到不同的主机
           在有些情况下,比如更换Raid控制器,升级主机硬件等,则需要将其上的Master实例迁移到其它主机上,MHA支持快速的Master切换和短暂的写操作阻塞,通常只需0.5-2秒的downtime,这是可以接受的,也方便了DBA的操作。

一些问题: 后端数据库切换不应影响到前端应用访问

方案:1)vip   第三方软件如keeplived      2)全局目录数据库

 

2,配置

首先manage,后端主从之间配置ssh可互相登陆,MHA使用该功能在主节点服务挂掉后网络正常下可复制日志。

在管理节点上安装两个包:
mha4mysql-manager
mha4mysql-node

配置文件:
cat  /etc/mastermha/app1.cnf 
[server default] 
##管理账户(完全权限)
user=sqluser
password=redhat
manager_workdir=/data/mastermha/app1/
manager_log=/data/mastermha/app1/manager.log
remote_workdir=/data/mastermha/app1/
##ssh用户
ssh_user=root 
##复制日志账号(replication  slave 权限)
repl_user=repluser          
repl_password=redhat
ping_interval=1
[server1]
hostname=192.168.36.72
candidate_master=1
[server2]
hostname=192.168.36.73
candidate_master=1
[server3]
hostname=192.168.36.74
在被管理节点安装:
mha4mysql-node

主从之间ssh验证 

ssh-keygen  
ssh-copy-id   互相拷贝


master数据库配置文件   :
log_bin
server_id=1
skip_name_resolve=1
#创建用于主从复制用户和管理端用于管理后端服务其的用户,即该操作在所有后端主从节点操作,如果已搭建好主从结构建立连接,只在主库操作。
show master logs
grant    replication slave   on   *.*    to repluser@'192.168.8.%'   identifiedby   ‘redhat';
grant    all    on   *.*     to sqluser@'192.168.8.%’    identified by    ‘magedu';

slave配置文件 : 
[mysqld]
server_id=2 不同节点此值各不相同
log-bin
read_only
relay_log_purge=0
skip_name_resolve=1
#连接主库
CHANGE MASTER TO
  MASTER_HOST='master ip ',
  MASTER_USER='repluser',
  MASTER_PASSWORD='redhat',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='master2-bin.001',
  MASTER_LOG_POS=245


测试方式(主从及管理端配置之后操做测试):
masterha_check_ssh   --conf=/etc/mastermha/app1.cnf 
masterha_check_repl --conf=/etc/mastermha/app1.cnf
masterha_manager --conf=/etc/mastermha/app1.cnf
/data/mastermha/app1/manager.log    

服务为脚本,主库挂掉,程序改变提升某一slave为master恢复之后,程序不再启动,为一次性

 

 

标签:mastermha,slave,配置,MHA,故障,Master,master
来源: https://www.cnblogs.com/g2thend/p/MHA.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有