当前位置:Gxlcms > 数据库问题 > 探索MySQL高可用架构之MHA(7)

探索MySQL高可用架构之MHA(7)

时间:2021-07-01 10:21:17 帮助过:20人阅读

-----构建mysql高可用系列(共9篇)

    上一篇文章介绍了本次架构的keepalive读写分离!

    本篇文章主要介绍本次架构中的mha安装部分!

    关于MHA

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

        该软件由两部分组成: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服务器上,因此可以保证所有节点的数据一致性。

    MHA工作原理

        a.从宕机崩溃的master保存二进制日志事件(binlog events)。

        b.识别含有最新更新的slave。

        c.应用差异的中继日志(relay log)到其它slave。

        d.应用从master保存的二进制日志事件(binlog events)。

        e.提升一个slave为新master。

        f.使其它的slave连接新的master进行复制。

    MHA工具包

        Manager工具

        a.masterha_check_ssh : 检查MHA的SSH配置。

        b.masterha_check_repl : 检查MySQL复制。

        c.masterha_manager : 启动MHA。

        d.masterha_check_status : 检测当前MHA运行状态。

        e.masterha_master_monitor : 监测master是否宕机。

        f.masterha_master_switch : 控制故障转移(自动或手动)。

        g.masterha_conf_host : 添加或删除配置的server信息。

        Node工具

        a.save_binary_logs : 保存和复制master的二进制日志。

        b.apply_diff_relay_logs : 识别差异的中继日志事件并应用于其它slave。

        c.filter_mysqlbinlog : 去除不必要的ROLLBACK事件(MHA已不再使用这个工具)。

        d.purge_relay_logs : 清除中继日志(不会阻塞SQL线程)。

    下面就让我们开始操作吧:

        安装node源码包(依赖很多per包,请按照我的安装顺序安装!)

rpm -ivhperl-DBI-1.620-1.el5.rfx.x86_64.rpm          
rpm -ivhMySQL-shared-compat-5.6.21-1.rhel5.x86_64.rpm
rpm -ivhperl-DBD-MySQL-3.0007-2.el5.x86_64.rpm   #如果是6系统先安装 rpm -ivhperl-Data-ShowTable-3.3-1.2.el6.rf.noarch.rpm
tar xfmha4mysql-node-0.53.tar.gz
cd mha4mysql-node-0.53
perl Makefile.PL
make && make install
#redhat5系列系统,会出现 Pleaseenter your CPAN site: []   随便输入反正也不用CPAN模块

        安装manager源码包(依赖很多per包,请按照我的安装顺序安装!)

rpm -ivhperl-Config-Tiny-2.10-1.el5.noarch.rpm       
rpm -ivhepel-release-5-4.noarch.rpm
rpm -ivh perl-Parallel-ForkManager-0.7.5-4.el5.noarch.rpm
rpm -ivhperl-Mail-Sender-0.8.16-1.el5.rf.noarch.rpm
rpm -ivhperl-Mail-Sendmail-0.79-1.2.el5.rf.noarch.rpm
rpm -ivhperl-Params-Validate-0.95-1.el5.rf.x86_64.rpm
rpm -ihvperl-Email-Date-Format-1.002-4.el5.noarch.rpm
rpm -ivhperl-MIME-Lite-3.029-1.el5.rf.noarch.rpm
rpm -ivhperl-TimeDate-1.16-1.2.el5.rf.noarch.rpm     #解决依赖:perl(Date::Format) perl(Date::Parse)
rpm -ivhperl-Pod-Escapes-1.04-5.el5.noarch.rpm
rpm -ivhperl-Pod-Simple-3.16-1.el5.rf.noarch.rpm
rpm -ivhperl-Test-Pod-1.45-1.el5.rf.noarch.rpm
rpm -ivh perl-MailTools-2.12-1.el5.rf.noarch.rpm  #解决依赖:perl(Mail::send)
rpm -ivhperl-Log-Dispatch-2.20-1.el5.noarch.rpm
tar xfmha4mysql-manager-0.53.tar.gz
cd mha4mysql-manager-0.53
perl Makefile.PL
make && make install
#redhat5系列系统,会出现 Pleaseenter your CPAN site: []   随便输入反正也不用CPAN模块

        配置ssh信任(所有机器全做)

拿47机器举例
(1)#生成公钥
ssh-keygen -t rsa  生成公钥
(2)#输出公钥匙
cat id_rsa.pub  
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7........
(3)#在48、50、51、52分别操作, vi authorized_keys 
增加47机器上 id_rsa.pub的内容
(4)#测试
ssh 10.142.132.52 date
ssh 10.142.132.51 date
ssh 10.142.132.50 date
ssh 10.142.132.48 date
ssh 10.142.132.47 date
总结:上面4步操作,在其它机器也一样操作,所有机器就可以实现ssh信任了

        编辑manager节点配置文件  //10.142.132.50

(1) mkdir -p /etc/masterha   #创建目录
(2) vi /etc/masterha/app1.cnf   #增加如下内容
[server default]
user=root   #linux用于管理mysql用戶名
password=mysql   #linux用于管理mysql密码
ssh_user=root    #ssh免密钥登录的帐号名
repl_user=lipengfei  #mysql复制帐号,用来在主从机之间同步二进制日志等
repl_password=lipengfei   #mysql复制帐号的密码
manager_workdir=/app/masterha/app1    #manager目录       
manager_log=/app/masterha/app1/app1.log   #管理节点工作日志文件
remote_workdir=/app/masterha/app1    #node 上用于产生日志的工作目录
ping_interval=1    #ping间隔,用来检测master是否正常
[server1]
hostname=10.142.132.52  #具体IP
candidate_master=1    #优先级成为新master
check_repl_delay=0    #MHA在选择新的Master时,会忽略复制延迟。
master_binlog_dir=/app/mysql/data  #binlog日志所在目录
[server2]
hostname=10.142.132.51   #具体IP
candidate_master=1     #优先级成为新master
check_repl_delay=0      #MHA在选择新的Master时,会忽略复制延迟。
master_binlog_dir=/app/mysql/data  #binlog日志所在目录
[server3]
hostname=10.142.132.48   #具体IP
no_master=1     #不能成为主库
[server4]
hostname=10.142.132.47    #具体IP
no_master=1  #不能成为主库

        启动mha-manager

nohup masterha_manager--conf=/etc/masterha/app1.cnf --ignore_last_failover < /dev/null > /app/masterha/app1/app1.log2>&1 &    #以nohup模式,放在后台启动

        故障测试

a.手工停止 52上的mysql服务,service mysql stop
b.大约30秒,51自动成为新的主库   #在47或48从库上show slave status就可以看出来
c.52再次启动mysql服务,要手工加入到AB架构中   #51是主库,使用如下演示命令加入AB架构
  change master to master_host=‘10.142.132.51‘, master_port=3306,master_user=‘lipengfei‘, master_password=‘lipengfei‘,master_log_file=‘binlog.000001‘,master_log_pos=120;
d.手工停止51上的Mysql服务
e大约30秒,52自动成为新的主库  #在47或48从库上show slave status就可以看出来

        注意如下2个问题

a.当主DB故障,切换到另外的服务器上后,即使恢复了原来的主DB,也不能立即加入整套MHA系统中,得重新手工加入AB架构。
b.当发生一次切换后,管理节点的监控进程就会自动退出,需要用脚本来自动启动。另外还得删除app1.failover.complete这个文件,否则新的主DB出现问题MHA就不会切换了。

        mha-manager常用命令

(1) nohup masterha_manager--conf=/etc/masterha/app1.cnf --ignore_last_failover < /dev/null > /app/masterha/app1/app1.log2>&1 &  
#开启MHA Manager监控
(2) masterha_check_status--conf=/etc/masterha/app1.cnf 
#查看MHA Manager监控是否正常
(3) masterha_stop--conf=/etc/masterha/app1.cnf 
#关闭MHA Manage监控
(4)masterha_check_ssh--conf=/etc/masterha/app1.cnf    
#检查SSH配置
(5)masterha_check_repl--conf=/etc/masterha/app1.cnf  
#检查整个复制环境状况

    到此为止,咱们的mah功能就配置结束了!

    只要朋友们仔细点按着我写的文章一步一步操作,相信你也可以成功的,加油吧!



本文出自 “走不完的路,看不完的书!” 博客,请务必保留此出处http://51power.blog.51cto.com/3549599/1672730

探索MySQL高可用架构之MHA(7)

标签:ha   高可用   keepalived   读写分离   mha   

人气教程排行