安科网

MySQL高可用架构之MHA详解

woshihaiyong

woshihaiyong

2019-01-14

关注 关注

MHA介绍

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

MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中 
(通过将从库提升为主库),大概0.5-2秒内即可完成

自动故障检测和自动故障转移 
MHA能够在一个已经存在的复制环境中监控MySQL，当检测到Master故障后能够实现自动故障转移，通过鉴定出最“新”的Salve的relay log，并将其应用到所有的Slave，这样MHA就能够保证各个slave之间的数据一致性，即使有些slave在主库崩溃时还没有收到最新的relay log事件。一个slave节点能否成为候选的主节点可通过在配置文件中配置它的优先级。由于master能够保证各个slave之间的数据一致性，所以所有的slave节点都有希望成为主节点。在通常的replication环境中由于复制中断而极容易产生的数据一致性问题，在MHA中将不会发生。

注：在MHA的高可用环境的，主库宕机了，MHA服务将停止，如何恢复MHA服务了，需要把宕机的主库加入到高可用环境（也就是把宕机的主库变成从库）在重新启动MHA

交互式（手动）故障转移 
MHA可以手动地实现故障转移，而不必去理会master的状态，即不监控master状态，确认故障发生后可通过MHA手动切换

在线切换Master到不同的主机 
MHA能够在0.5-2秒内实现切换，0.5-2秒的写阻塞通常是可接受的，所以你甚至能在非维护期间就在线切换master。诸如升级到高版本，升级到更快的服务器之类的工作，将会变得更容易。

MHA优势

  1. 自动故障转移快
  2. 主库崩溃不存在数据一致性问题
  3. 配置不需要对当前mysql环境做重大修改
  4. 不需要添加额外的服务器(仅一台manager就可管理上百个replication）
  5. 性能优秀，可工作在半同步复制和异步复制，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。
  6. 只要replication支持的存储引擎，MHA都支持，不会局限于innodb

MHA组成

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

MySQL高可用架构之MHA详解

MHA工作原理

  1. 从宕机崩溃的master保存二进制日志事件（binlog events）;
  2. 识别含有最新更新的slave；
  3. 应用差异的中继日志（relay log）到其他的slave；
  4. 应用从master保存的二进制日志事件（binlog events）；
  5. 提升一个slave为新的master；
  6. 使其他的slave连接新的master进行复制；

MHA安装

准备四个节点，其中一个是管理节点，三个是一主两从的环境 
MHA项目地址

https://code.google.com/p/mysql-master-ha/

主从环境我这已近搭建好 
环境如下：

主机名ip
mycat0110.0.0.200
master0110.0.0.201
master0210.0.0.204
slave0210.0.0.203

注：master01 是主库 master02是从库 ，slave02 是从库，一主两从

mha 管理节点需要mysql命令环境

    1. 在所有节点上安装node节点 
      yum install –y perl-DBD-MySQL 
      rpm -ivh mha4mysql-node-0.54-0.noarch.rpm

    2. 在管理节点上安装manager节点 
      yum install -y perl-Config-Tiny 
      yum install -y perl-Log-Dispatch 
      yum install -y perl-Parallel-ForkManager 
      rpm -ivh mha4mysql-manager-0.55-0.el6.noarch.rpm

    3. 在四个节点的/etc/hosts中添加主机内容： 
      10.0.0.200 mycat01 
      10.0.0.201 master01 
      10.0.0.204 master02 
      10.0.0.202 slave01

    4. 在管理节点创建配置文件

[root@mycat01 ~]# cat /etc/app1.cnf
[server default]
# mysql user and password
user=root
password=123456
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
repl_user=repl
repl_password=123456
user=root
ping_interval=1
remote_workdir=/tmp
[server1]
hostname=master01
port=3306
master_binlog_dir=/usr/local/mysql/data
[server2]
hostname=master02
port=3306
master_binlog_dir=/usr/local/mysql/data
#candidate_master=1
#check_repl_delay=0
[server3]
hostname=slave01
port=3306
master_binlog_dir=/usr/local/mysql/data
  1. 在所有节点的my.cnf 文件 添加一下内容
log-bin=mysql-bin
relay_log_purge=0
log-slave-updates=true

添加完记得重启所有mysql环境

    1. 所有节点（管理节点和node节点）实现无密码登录 
      MHA manager通过SSH访问所有的node节点，各个node节点也同样需要通过SSH来相互发送不同的relay log 文件，所以有必要在每一个node和manager上配置SSH无密码登陆。
    2. 设置目录和软连接 

mkdir /var/log/masterha/app1 –p #管理节点 存放mha日志

ln -s /usr/local/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog #所有节点 
　　　　　　ln -s /usr/local/mysql/bin/mysql /usr/bin/mysql #所有节点

    1. 检测所有节点SSH连接是否配置正常 
      MHAmanager可通过masterha_check_ssh脚本检测SSH连接是否配置正常

masterha_check_ssh --conf=/etc/app1.cnf

MySQL高可用架构之MHA详解

    1. 在管理节点检查复制配置 
      为了让MHA正常工作，所有的master和slave必须在配置文件中正确配置，MHA可通过masterha_check_repl 脚本检测复制是否正确配置

 　　　　　　masterha_check_repl --conf=/etc/app1.cnf

　　　　如果主从复制正常会出现 
　　　　MySQL Replication Health is OK

　　

    1. 开启Manager 
      当你正确配置了mysql复制，正确安装了manager和node节点，SSH配置也正确，那么下一步就是开启manager，可通过 masterha_manager 命令开启
nohup masterha_manager --conf=/etc/app1.cnf > /var/log/masterha/app1/mha_manager.log < /dev/null &

    1. 检查manager状态 
      当MHA manager启动监控以后，如果没有异常则不会打印任何信息。我们可通过masterha_check_status命令检查manager的状态，以下是范例

    2. 测试master的自动故障转移 
      现在master运行正常，manager监控也正常，下一步就是停止master，测试自动故障 
      转移，可以简单地停止master上的mysqld服务 
      [root@master01 bin]# /etc/init.d/mysql.server stop 
      Shutting down MySQL………… SUCCESS! 
      这时候检查manager的log日志，看看slave1是否成功成为新的master，并且slave2从slave1中复制。

    3. 查看MHA切换日志 
      vim /var/log/masterha/app1/mha_manager.log

Master failover to master02(10.0.0204:3306) completed successfully. 
会出现迁移成功的字样。

注：有一个主库停止了服务，故障切换完毕， mha的服务也会停止

ok MHA搭建完成

MHA 配置文件介绍

cat /etc/masterha/app1.cnf
[server default]
manager_workdir=/var/log/masterha/app1.log //设置manager的工作目录
manager_log=/var/log/masterha/app1/manager.log //设置manager的日志
master_binlog_dir=/data/mysql //设置master 保存binlog的位置，以便MHA可以找到master的日志，我这里的也就是
mysql的数据目录
master_ip_failover_script= /usr/local/bin/master_ip_failover //设置自动failover时候的切换脚本
master_ip_online_change_script= /usr/local/bin/master_ip_online_change //设置手动切换时候的切换脚本
password=123456 //设置mysql中root用户的密码，这个密码是前文中创建监控用户的那个密码
user=root 设置监控用户root
ping_interval=1 //设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行failover
remote_workdir=/tmp //设置远端mysql在发生切换时binlog的保存位置
repl_password=123456 //设置复制用户的密码
repl_user=repl //设置复制环境中的复制用户名
report_script=/usr/local/send_report //设置发生切换后发送的报警的脚本
secondary_check_script= /usr/local/bin/masterha_secondary_check -s server03 -s server02  # //一旦MHA到server02的监控之间出现问���，MHA Manager将会尝试从server03登录到server02
shutdown_script="" //设置故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机放在发生脑裂,这里没有使用）
ssh_user=root //设置ssh的登录用户名
[server1]
hostname=10.0.0.201
port=3306
[server2]
hostname=10.0.0.204
port=3306
candidate_master=1 //设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个
主库不是集群中事件最新的
slave check_repl_delay=0 //默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为
一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个
新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换
的过程中一定是新的master
[server3]
hostname=10.0.0.202
port=3306

设置relay log的清除方式（在每个slave节点上）：

mysql -e ‘set global relay_log_purge=0’ 
注意： 
MHA在发生切换的过程中，从库的恢复过程中依赖于relay log的相关信息，所以这里要将relay log的自动清除设置为OFF，采用手动清除relay log的方式。在默认情况下，从服务器上的中继日志会在SQL线程执行完毕后被自动删除。但是在MHA环境中，这些中继日志在恢复其他从服务器时可能会被用到，因此需要禁用中继日志的自动删除功能

MHA 手动模拟故障

mha 没有开启服务

    1. 先关闭两个从库的slave进程 
      mysql> stop slave;

    2. 在主库上执行插入操作，而从库没办法同步 
      mysql> insert into temp2 values(5000,’abc’); 
      Query OK, 1 row affected (0.00 sec)

    3. 主库MySQL直接关闭，两个从库开启复制进程，依旧没有最数据
[root@master01 ~]# /etc/init.d/mysql.server stop
Shutting down MySQL…. SUCCESS!
从库查询刚插入的数据
mysql> select * from temp2 where >
Empty set (0.00 sec)
  1. 开启mha进程，发现完成主从切换

查看日志

[root@mycat01 app1]# tail -10 mha_manager.log
Invalidated master IP address on master01.
The latest slave master02(10.0.0.204:3306) has all relay logs for recovery.
Selected master02 as a new master.
master02: OK: Applying all logs succeeded.
master02: OK: Activated master IP address.
slave01: This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
slave01: OK: Applying all logs succeeded. Slave started, replicating from master02.
master02: Resetting slave info succeeded.
Master failover to master02(10.0.0.204:3306) completed successfully.　

主库已近切换到master02了

5.  查看新的主从是否有5000这条记录 

mysql> select * from temp2 where >
+——+——+
| id | name |
+——+——+
| 5000 | abc |

插入成功

可以通过binlog 分析 
[root@master01 app1]# mysqlbinlog -v /var/log/masterha/app1/saved_master_binlog_from_master01_3306_20180909014109.binlog

MHA手动切换

手动failover，这种场景意味着在业务上没有启用MHA自动切换功能，当主服务器故障时，人工手动调用MHA来进行故障切换操作，具体命令如下： 
我还原先前的主从关系

    1. 先关闭mha进程，确保不会自动执行切换 
      [root@mycat01 ~]# masterha_stop –conf=/etc/app1.cnf

    2. 再关闭maser主库 
      [root@master01 ~]# /etc/init.d/mysql.server stop 
      Shutting down MySQL………… SUCCESS!

    3. 执行手动切换

[root@mycat01 ~]# masterha_master_switch --master_state=dead --conf=/etc/app1.cnf --dead_master_host=master01 --dead_master_port=3306 --new_master_ip=10.0.0.204 --new_master_port=3306

  1. 开启mha进程，可以查看日志确定是否切换成功

  2. 去数据库验证show slave status\G;

MHA在线切换

还原先前主从环境 
为了保证数据完全一致性，在最快的时间内完成切换，MHA的在线切换必须满足以下条件才会切换成功，否则会切换失败。 
1.所有slave的IO线程都在运行 
2.所有slave的SQL线程都在运行 
3.所有的show slave status的输出中Seconds_Behind_Master参数小于或者等于running_updates_limit秒，如果在切换过程中不指定running_updates_limit,那么默认情况下running_updates_limit为1秒。 
4.在master端，通过show processlist输出，没有一个更新花费的时间大于running_updates_limit秒。

在线切换步骤如下：

    1. 首先，停掉MHA监控： 
      [root@mycat01 ~]# masterha_stop –conf=/etc/app1.cnf
    2. 其次，进行在线切换操作 
      （模拟在线切换主库操作，原主库10.0.0.201变为slave， 
      10.0.204提升为新的主库）
[root@mycat01 ~]# masterha_master_switch –conf=/etc/app1.cnf –master_state=alive –new_master_host=master02 –new_master_port=3306 –orig_master_is_new_slave –running_updates_limit=10000

-orig_master_is_new_slave 切换时加上此参数是将原 master 变为 slave 节点，如果不加此参数，原来的 master 将不启动 
–running_updates_limit=10000,故障切换时,候选master 如果有延迟的话， mha 切换不能成功，加上此参数表示延迟在此时间范围内都可切换（单位为s），但是切换的时间长短是由 
recover 时relay 日志的大小决定

  1. 去数据库验证 show slave status\G;

MHA vip漂移

记得还原先前主从环境 
为什么要做vip地址 ？ 
简单点就是为了数据库发生故障期间，感觉不到数据库发生了故障，所以才需要vip漂移 
当然这个你想用keepalive 做vip 取决于你

    1. 在master节点上执行ifconfig eth0:2 10.0.0.210/24
    2. 在管理监控节点上配置/usr/local/bin/master_ip_failover 
      master_ip_failover内容如下
#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';
use Getopt::Long;
my (
    $command,          $ssh_user,        $orig_master_host, $orig_master_ip,
    $orig_master_port, $new_master_host, $new_master_ip,    $new_master_port
);
my $vip = '10.0.0.210/24';
my $key = '2';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
GetOptions(
    'command=s'          => \$command,
    'ssh_user=s'        => \$ssh_user,
    'orig_master_host=s' => \$orig_master_host,
    'orig_master_ip=s'  => \$orig_master_ip,
    'orig_master_port=i' => \$orig_master_port,
    'new_master_host=s'  => \$new_master_host,
    'new_master_ip=s'    => \$new_master_ip,
    'new_master_port=i'  => \$new_master_port,
);
exit &main();
sub main {
    print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";
    if ( $command eq "stop" || $command eq "stopssh" ) {
        my $exit_code = 1;
        eval {
            print "Disabling the VIP on old master: $orig_master_host \n";
            &stop_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn "Got Error: $@\n";
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "start" ) {
        my $exit_code = 10;
        eval {
            print "Enabling the VIP - $vip on the new master - $new_master_host \n";
            &start_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn $@;
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "status" ) {
        print "Checking the Status of the script.. OK \n";
        exit 0;
    }
    else {
        &usage();
        exit 1;
    }
}
sub start_vip() {
    `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
sub stop_vip() {
    return 0  unless  ($ssh_user);
    `ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}
sub usage {
    print
    "Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
 
 

    1. 在监控节点的/etc/app1.cnf中添加此文件 
      master_ip_failover_script=/usr/local/bin/master_ip_failover

    2. 测试当把master关机之后， VIP漂移到了新的主节点上

[root@master01 bin]# /etc/init.d/mysql.server stop 
Shutting down MySQL………… SUCCESS!

MySQL高可用架构之MHA详解

mha mysql master 高可用 mysql主从配置 mysql集群

woshihaiyong

woshihaiyong

0 关注 0 粉丝 0 动态

关注 关注

相关推荐

MySQL高可用之MHA

MHA Node运行在每台 MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新 数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过

herohope 2020-07-19

Mysql通过MHA实现高可用

MHA是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的master 节点

KFLING 2020-06-13

8.MHA高可用集群搭建

MHA通过masterha_manger脚本启动MHA的功能.自动判断所有从库的日志量.将最接近主库数据的从库作为新主.按照配置文件先后顺序的进行选新主.前提条件：1.最少三台MySQL服务器，1主2从。mysql> grant all privi

wiseMale 2020-05-11

MySQL-高可用架构MHA

第1章 主从复制架构演变。多活:MGR ——5.7 新特性 MySQL Group replication --->Innodb Cluster. 第2章 MHA部署流程。这里我把管理节点安装在了db03上；在实际生产中，如果没有足够的服务器，也可以

这些年来 2020-05-25

MySQL高可用集群之MHA

MHA目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切

xiaojiang0 2020-02-22

mysql实现高可用架构之MHA

MHA是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating. MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的。slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节

康慧欣 2020-02-18

MHA主库宕机，binlog保存

[ binlog]# mysqlbinlog -R --host=172.16.1.52 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &. -rw-rw---- 1

elitechen 2020-07-28

MHA搭建

先查看系统本身是否存在MySQL或者mariadb，若存在将其卸载：。rpm -qa | grep mysql && yum -y remove mysql. log-bin=mysql-bin，同理修改其他两个节点的配置

inhumming 2020-06-10

MHA+Altas 读写分离的结合

Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天

李高峰 2020-05-25

MySQL MHA架构

MHA目前在MySQL高可用方案中应该也是比较成熟和常见的方案，它由日本人开发出来，在MySQL故障切换过程中，MHA 能做到快速自动切换操作，而且还能最大限度保持数据的一致性，该架构采用 perl 语言编写，可完成秒级别的主库故障切换。MHA Manag

ithzhang 2020-04-19

MHA之虚拟IP

在MySQL高可用之MHA部署这篇博文中，已经将MHA的基础架构部署完成，但是并没有解决一个虚拟IP的问题，因为当master宕机后，新的master顶上来，这时前端APP要连接的数据库IP已经发生了变化，为了解决这个问题，必然要引入虚拟IP，谈起虚拟IP

会哭的雨 2020-02-24

MySQL架构——MHA部署

目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作

阿亮 2019-12-25

MySQL数据库——MHA高可用集群架构（实战！！！）

在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

xiaobaif 2019-12-25

MHA高可用集群

本案例要求通过MHA 监控MySQL 数据库在故障时进行自动切换，不影响业务。

sofast 2019-12-25

MySQL数据库---MHA高可用群集架构

日本DeNA公司youshimaton 开发。一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失。使用MySQL 5.5的半同步复制，可以大大降

xiaoxiangyu 2019-12-23

MHA高可用群集基本部署（纯实战）

MHA目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton开发。MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进

ShiShuo 2019-12-23

MySQL高可用集群架构——MHA架构

在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

贤冰 2019-12-19

MySQL高可用架构之MHA

MHA目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切

herohope 2019-12-14

MySQL 有关MHA搭建与切换的几个错误log

Thu Nov 21 15:33:15 2018 - [info] MHA::MasterMonitor version 0.56.Thu Nov 21 15:33:16 2018 - [info] Got exit code 1 .Tue Nov 19

achiverhai 2019-12-06

基于 MHA 的MySQL高可用-CentOS7（理论）

MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节 点上。MHA Node 运行在每台 MySQL 服务器及 Manager 服务器上，MHA Manager 会定时探 测集群中

mycosmos 2019-11-04
woshihaiyong

woshihaiyong

W3CSchool教程
HTML 教程
CSS 教程
Bootstrap 教程
Javascript 教程
jQuery 教程
后端教程
C 教程
Java 教程
PHP 教程
Python 教程
Go 教程
移动开发
Android 教程
Swift 教程
Kotlin 教程
jQuery Mobile 教程
ionic 教程
关于我们
新闻动态
联系方式
招聘英才
安科实验室
帮助与反馈

安科网(Ancii)，中国第一极客网

Copyright © 2013 - 2019 Ancii.com

京ICP备18063983号 京公网安备11010802014868号