MySQL高可用自动故障恢复笔记（MHA）

最新推荐文章于 2023-08-30 22:21:01 发布
最新推荐文章于 2023-08-30 22:21:01 发布
阅读量774 收藏 2
点赞数
分类专栏： 数据库 MySQL MHA 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_40657218/article/details/120512054
版权
数据库 同时被 3 个专栏收录
3 篇文章 0 订阅
订阅专栏
MySQL
2 篇文章 0 订阅
订阅专栏
MHA
1 篇文章 0 订阅
订阅专栏

一、MHA架构

MHA-Manager

  1. MHA 可以在几秒钟内完成故障转移（9-12 秒检测 master 故障，可选 7-10 秒关闭 master 机器以避免裂脑，几秒钟将差分中继日志应用到新 master，因此总停机时间为一般10-30秒），只要slave不严重延迟复制。在恢复新的 master 后，MHA 并行恢复其余的 slave。即使你有几十个slave，也不影响master恢复时间，你可以很快恢复slave。
  2. 在 150 多个 {master, slaves} 环境中使用 MHA。当其中一个主节点崩溃时，MHA 在 4 秒内完成了故障转移。
a. Master crash 不会导致数据不一致

当前master崩溃时，MHA会自动识别slave之间的差异中继日志事件，并应用于每个slave。所以最后所有从服务器都可以同步，只要所有从服务器都活着。通过与半同步复制一起使用，也可以保证（几乎）没有数据丢失。

b. 没有性能损失

MHA 与常规异步或半同步 MySQL 复制一起使用。在监控主服务器时，MHA 只是每 N 秒（默认为 3）向主服务器发送 ping 数据包，并且不会发送大量查询。您可以期待与常规 MySQL 复制一样快的性能。

c. 适用于任何存储引擎

MHA 适用于任何存储引擎，只要 MySQL 复制有效，不限于 InnoDB（崩溃安全的事务存储引擎）。即使您使用不易迁移的旧版 MyISAM 环境，您也可以使用 MHA。

二、MHA服务角色

  1. MHA Manager：监控MySQL master、控制master故障切换等管理程序
  2. MHA Node：故障转移辅助脚本，例如解析 MySQL 二进制（binary log）/中继日志（relay log）、识别应将中继日志应用到其他从站的中继日志位置、将事件应用到目标从站等。 MHA 节点在每个 MySQL 服务器上运行

当 MHA 管理器进行故障转移时，MHA 管理器通过 SSH 连接 MHA 节点并在需要时执行 MHA 节点命令。

a. Manager节点脚本

masterha_check_ssh：MHA 依赖的 ssh 环境监测工具

masterha_check_repl：MYSQL 复制环境检测工具

masterga_manager：MHA 服务主程序

masterha_check_status：MHA 运行状态探测工具

masterha_master_monitor：MYSQL master 节点可用性监测工具

masterha_master_swith:master：节点切换工具

masterha_conf_host：添加或删除配置的节点

masterha_stop：关闭 MHA 服务的工具

b. Node节点脚本

（通常由MHA Manager的脚本触发，无需人为操作）

save_binary_logs：保存和复制 master 的二进制日志

apply_diff_relay_logs：识别差异的中继日志事件并应用于其他 slave

purge_relay_logs：清除中继日志（不会阻塞 SQL 线程）

c. 自定义扩展脚本

secondary_check_script：用于检查来自多个网络路由的 master 可用性

master_ip_failover_script: 用于更新应用程序使用的 master ip 地址

shutdown_script：强制关闭master

report_script：用于发送报告

init_conf_load_script：用于加载初始配置参数

master_ip_online_change_script：用于更新主IP地址。这不用于主故障转移，而是用于在线主交换机

三、安装MySQL

1. 节点规划
资源版本
Manager（MHA管理节点）4c8g0.58
Master4c8g（根据mysql实际使用情况）5.7.34
Slave14c8g（根据mysql实际使用情况）5.7.34
Slave24c8g（根据mysql实际使用情况）5.7.34
2. 安装mysql（此文mysql版本为mysqk5.7.34）
#添加源
vim /etc/yum.repo.d/mariadb.repo
[mariadb]
name = MariaDB 
baseurl = https://mirrors.ustc.edu.cn/mariadb/yum/10.4/centos7-amd64 gpgkey=https://mirrors.ustc.edu.cn/mariadb/yum/RPM-GPG-KEY-MariaDB 
gpgcheck=1
# 安装
yum -y install MariaDB-server MariaDB-client
# 初始化
mysql_secure_installation
3. master节点配置my.cnf
#配置my.cnf
[mysqld]
server-id = 1               //复制集群中的各节点的id均必须唯一
log-bin = master-log        //开启二进制日志
relay-log = relay-log       //开启中继日志
skip_name_resolve           //关闭名称解析（非必须）
4. 所有slave节点配置my.cnf
[root@slave1 ~]# vim /etc/my.cnf
    [mysqld]
    server-id = 2               //复制集群中的各节点的id均必须唯一；
    relay-log = relay-log       //开启中继日志
    log-bin = master-log        //开启二进制日志
    read_only = ON              //启用只读属性
    relay_log_purge = 0         //是否自动清空不再需要中继日志
    skip_name_resolve           //关闭名称解析（非必须）
    log_slave_updates = 1       //使得更新的数据写进二进制日志中
[root@slave1 ~]# systemctl restart mariadb
[root@slave2 ~]# vim /etc/my.cnf
    [mysqld]
    server-id = 3               //复制集群中的各节点的id均必须唯一；
    relay-log = relay-log       //开启中继日志
    log-bin = master-log        //开启二进制日志
    read_only = ON              //启用只读属性
    relay_log_purge = 0         //是否自动清空不再需要中继日志
    skip_name_resolve           //关闭名称解析（非必须）
    log_slave_updates = 1       //使得更新的数据写进二进制日志中
[root@slave2 ~]# systemctl restart mariadb
5. 配置一主多从mysql
# master节点
# 授权同步数据账号
[root@master ~]# mysql -uroot -p'keer'
MariaDB [(none)]>grant replication slave,replication client on *.* to 'slave'@'192.168.%.%' identified by 'keer';
# 备份数据导出到从库
[root@master ~]# mysqldump -uroot -p'keer' --all-databases > `date +%F`-mysql-all.sql
[root@master ~]# scp *mysql-all.sql  192.168.20.100:/root
[root@master ~]# mysql -uroot -p'keer'
MariaDB [(none)]> show master status;
# slave节点
#导入数据
[root@slave1 ~]# mysql -uroot -p'keer' < *mysql-all.sql
[root@slave1 ~]# mysql -uroot -p'keer'
MariaDB [(none)]> change master to master_host='192.168.37.122', 
    -> master_user='slave', 
    -> master_password='keer',
    -> master_log_file='mysql-bin.000001',
    -> master_log_pos=415;
MariaDB [(none)]> start slave;
MariaDB [(none)]> show slave status\G;

四、安装MHA-manager（manager管理节点）、MHA-node（所有mysql节点）

MHA下载链接：https://github.com/yoshinorim/mha4mysql-manager/releases/tag/v0.58

1. 操作系统依赖

yum install epel-release -y

yum -y install libmysqlclient.so.18

yum install perl-DBD-MySQL -y

yum install perl-Config-Tiny -y

yum install perl-Log-Dispatch -y

yum install perl-Parallel-ForkManager -y

rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm

所有节点对向免密

2. 配置mha.cnf
[server default]
user=mhaadmin
password=MHAP@ssw0rd_2021
manager_workdir=/var/lib/mha-manager/app
manager_log=/etc/mha_master/manager.log
remote_workdir=/var/lib/mha
ssh_user=root
repl_user=slave
repl_password=P@ssw0rd_2021
ping_interval=3
master_ip_failover_script=/etc/mha_master/master_ip_failover.pl
[server1]
hostname=111.16.100.253
ssh_port=22
candidate_master=1
[server2]
hostname=111.16.100.224
ssh_port=22
candidate_master=1
[server3]
hostname=111.16.101.73
ssh_port=22
candidate_master=1

配置说明参考地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Configuration

3. master故障ip切换脚本

#!/usr/bin/env perl

#  Copyright (C) 2011 DeNA Co.,Ltd.
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#   along with this program; if not, write to the Free Software
#  Foundation, Inc.,
#  51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA

## Note: This is a sample script and is not complete. Modify the script based on your environment.

use strict;
use warnings FATAL => 'all';

use Getopt::Long;
use MHA::DBHelper;

my (
  $command,        $ssh_user,         $orig_master_host,
  $orig_master_ip, $orig_master_port, $new_master_host,
  $new_master_ip,  $new_master_port,  $new_master_user,
  $new_master_password
);
# 这里的vip和网卡需要自己根据服务器网络配置
my $vip = '111.16.100.189/22';
my $key = "1";
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,
  'new_master_user=s'     => \$new_master_user,
  'new_master_password=s' => \$new_master_password,
);

exit &main();

sub main {
  if ( $command eq "stop" || $command eq "stopssh" ) {

    # $orig_master_host, $orig_master_ip, $orig_master_port are passed.
    # If you manage master ip address at global catalog database,
    # invalidate orig_master_ip here.
    my $exit_code = 1;
    eval {

      # updating global catalog, etc
      $exit_code = 0;
    };
    if ($@) {
      warn "Got Error: $@\n";
      exit $exit_code;
    }
    exit $exit_code;
  }
    elsif ( $command eq "start" ) {

        # all arguments are passed.
        # If you manage master ip address at global catalog database,
        # activate new_master_ip here.
        # You can also grant write access (create user, set read_only=0, etc) here.
        my $exit_code = 10;
        eval {
            print "Enabling the VIP - $vip on the new master - $new_master_host \n";
            &start_vip();
            &stop_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";
        `ssh $ssh_user\@$orig_master_host \" $ssh_start_vip \"`;
        exit 0;
    }
    else {
        &usage();
        exit 1;
    }
}


sub start_vip() {
    `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
# A simple system call that disable the VIP on the old_master
sub stop_vip() {
   `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";
}

五、检查MHA

检查主机之间是否完成对向免密配置

masterha_check_ssh

$ > masterha_check_ssh --conf=/etc/mha_master/mha.cnf
Mon Sep 27 16:32:07 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Sep 27 16:32:07 2021 - [info] Reading application default configuration from /etc/mha_master/mha.cnf..
Mon Sep 27 16:32:07 2021 - [info] Reading server configuration from /etc/mha_master/mha.cnf..
Mon Sep 27 16:32:07 2021 - [info] Starting SSH connection tests..
Mon Sep 27 16:32:08 2021 - [debug]
Mon Sep 27 16:32:07 2021 - [debug]  Connecting via SSH from root@111.16.100.253(111.16.100.253:22) to root@111.16.100.224(111.16.100.224:22)..
Mon Sep 27 16:32:07 2021 - [debug]   ok.
Mon Sep 27 16:32:07 2021 - [debug]  Connecting via SSH from root@111.16.100.253(111.16.100.253:22) to root@111.16.101.73(111.16.101.73:22)..
Mon Sep 27 16:32:08 2021 - [debug]   ok.
Mon Sep 27 16:32:08 2021 - [debug]
Mon Sep 27 16:32:07 2021 - [debug]  Connecting via SSH from root@111.16.100.224(111.16.100.224:22) to root@111.16.100.253(111.16.100.253:22)..
Mon Sep 27 16:32:08 2021 - [debug]   ok.
Mon Sep 27 16:32:08 2021 - [debug]  Connecting via SSH from root@111.16.100.224(111.16.100.224:22) to root@111.16.101.73(111.16.101.73:22)..
Mon Sep 27 16:32:08 2021 - [debug]   ok.
Mon Sep 27 16:32:09 2021 - [debug]
Mon Sep 27 16:32:08 2021 - [debug]  Connecting via SSH from root@111.16.101.73(111.16.101.73:22) to root@111.16.100.253(111.16.100.253:22)..
Mon Sep 27 16:32:08 2021 - [debug]   ok.
Mon Sep 27 16:32:08 2021 - [debug]  Connecting via SSH from root@111.16.101.73(111.16.101.73:22) to root@111.16.100.224(111.16.100.224:22)..
Mon Sep 27 16:32:08 2021 - [debug]   ok.
Mon Sep 27 16:32:09 2021 - [info] All SSH connection tests passed successfully.

检查replication是否正常

$ > masterha_check_repl --conf=/etc/mha_master/mha.cnf
Mon Sep 27 16:32:46 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Sep 27 16:32:46 2021 - [info] Reading application default configuration from /etc/mha_master/mha.cnf..
Mon Sep 27 16:32:46 2021 - [info] Reading server configuration from /etc/mha_master/mha.cnf..
Mon Sep 27 16:32:46 2021 - [info] MHA::MasterMonitor version 0.58.
Mon Sep 27 16:32:47 2021 - [info] GTID failover mode = 0
Mon Sep 27 16:32:47 2021 - [info] Dead Servers:
Mon Sep 27 16:32:47 2021 - [info] Alive Servers:
Mon Sep 27 16:32:47 2021 - [info]   111.16.100.253(111.16.100.253:3306)
Mon Sep 27 16:32:47 2021 - [info]   111.16.100.224(111.16.100.224:3306)
Mon Sep 27 16:32:47 2021 - [info]   111.16.101.73(111.16.101.73:3306)
Mon Sep 27 16:32:47 2021 - [info] Alive Slaves:
Mon Sep 27 16:32:47 2021 - [info]   111.16.100.253(111.16.100.253:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 16:32:47 2021 - [info]     Replicating from 111.16.100.224(111.16.100.224:3306)
Mon Sep 27 16:32:47 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 16:32:47 2021 - [info]   111.16.101.73(111.16.101.73:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 16:32:47 2021 - [info]     Replicating from 111.16.100.224(111.16.100.224:3306)
Mon Sep 27 16:32:47 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 16:32:47 2021 - [info] Current Alive Master: 111.16.100.224(111.16.100.224:3306)
Mon Sep 27 16:32:47 2021 - [info] Checking slave configurations..
Mon Sep 27 16:32:47 2021 - [warning]  relay_log_purge=0 is not set on slave 111.16.100.253(111.16.100.253:3306).
Mon Sep 27 16:32:47 2021 - [info] Checking replication filtering settings..
Mon Sep 27 16:32:47 2021 - [info]  binlog_do_db= , binlog_ignore_db=
Mon Sep 27 16:32:47 2021 - [info]  Replication filtering check ok.
Mon Sep 27 16:32:47 2021 - [info] GTID (with auto-pos) is not supported
Mon Sep 27 16:32:47 2021 - [info] Starting SSH connection tests..
Mon Sep 27 16:32:50 2021 - [info] All SSH connection tests passed successfully.
Mon Sep 27 16:32:50 2021 - [info] Checking MHA Node version..
Mon Sep 27 16:32:51 2021 - [info]  Version check ok.
Mon Sep 27 16:32:51 2021 - [info] Checking SSH publickey authentication settings on the current master..
Mon Sep 27 16:32:51 2021 - [info] HealthCheck: SSH to 111.16.100.224 is reachable.
Mon Sep 27 16:32:51 2021 - [info] Master MHA Node version is 0.58.
Mon Sep 27 16:32:51 2021 - [info] Checking recovery script configurations on 111.16.100.224(111.16.100.224:3306)..
Mon Sep 27 16:32:51 2021 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/var/lib/mysql,/var/log/mysql --output_file=/var/lib/mha/save_binary_logs_test --manager_version=0.58 --start_file=master-log.000003
Mon Sep 27 16:32:51 2021 - [info]   Connecting to root@111.16.100.224(111.16.100.224:22)..
  Creating /var/lib/mha if not exists..    ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /var/lib/mysql, up to master-log.000003
Mon Sep 27 16:32:51 2021 - [info] Binlog setting check done.
Mon Sep 27 16:32:51 2021 - [info] Checking SSH publickey authentication and checking recovery script configurations on all alive slave servers..
Mon Sep 27 16:32:51 2021 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mhaadmin' --slave_host=111.16.100.253 --slave_ip=111.16.100.253 --slave_port=3306 --workdir=/var/lib/mha --target_version=5.7.34-log --manager_version=0.58 --relay_log_info=/var/lib/mysql/relay-log.info  --relay_dir=/var/lib/mysql/  --slave_pass=xxx
Mon Sep 27 16:32:51 2021 - [info]   Connecting to root@111.16.100.253(111.16.100.253:22)..
  Checking slave recovery environment settings..
    Opening /var/lib/mysql/relay-log.info ... ok.
    Relay log found at /var/lib/mysql, up to relay-log.000002
    Temporary relay log file is /var/lib/mysql/relay-log.000002
    Checking if super_read_only is defined and turned on.. not present or turned off, ignoring.
    Testing mysql connection and privileges..
mysql: [Warning] Using a password on the command line interface can be insecure.
 done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Mon Sep 27 16:32:52 2021 - [info]   Executing command : apply_diff_relay_logs --command=test --slave_user='mhaadmin' --slave_host=111.16.101.73 --slave_ip=111.16.101.73 --slave_port=3306 --workdir=/var/lib/mha --target_version=5.7.34-log --manager_version=0.58 --relay_log_info=/var/lib/mysql/relay-log.info  --relay_dir=/var/lib/mysql/  --slave_pass=xxx
Mon Sep 27 16:32:52 2021 - [info]   Connecting to root@111.16.101.73(111.16.101.73:22)..
  Checking slave recovery environment settings..
    Opening /var/lib/mysql/relay-log.info ... ok.
    Relay log found at /var/lib/mysql, up to relay-log.000002
    Temporary relay log file is /var/lib/mysql/relay-log.000002
    Checking if super_read_only is defined and turned on.. not present or turned off, ignoring.
    Testing mysql connection and privileges..
mysql: [Warning] Using a password on the command line interface can be insecure.
 done.
    Testing mysqlbinlog output.. done.
    Cleaning up test file(s).. done.
Mon Sep 27 16:32:52 2021 - [info] Slaves settings check done.
Mon Sep 27 16:32:52 2021 - [info]
111.16.100.224(111.16.100.224:3306) (current master)
 +--111.16.100.253(111.16.100.253:3306)
 +--111.16.101.73(111.16.101.73:3306)

Mon Sep 27 16:32:52 2021 - [info] Checking replication health on 111.16.100.253..
Mon Sep 27 16:32:52 2021 - [info]  ok.
Mon Sep 27 16:32:52 2021 - [info] Checking replication health on 111.16.101.73..
Mon Sep 27 16:32:52 2021 - [info]  ok.
Mon Sep 27 16:32:52 2021 - [info] Checking master_ip_failover_script status:
Mon Sep 27 16:32:52 2021 - [info]   /etc/mha_master/master_ip_failover.pl --command=status --ssh_user=root --orig_master_host=111.16.100.224 --orig_master_ip=111.16.100.224 --orig_master_port=3306
Checking the Status of the script.. OK
Mon Sep 27 16:32:53 2021 - [info]  OK.
Mon Sep 27 16:32:53 2021 - [warning] shutdown_script is not defined.
Mon Sep 27 16:32:53 2021 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

启动MHA

nohup masterha_manager --conf=/etc/mha_master/mha.cnf &> /var/log/mha-manager/manager.log &

六、测试mysql-master故障恢复

1. 停止master mysql节点，查看mha-manager日志
Mon Sep 27 14:50:08 2021 - [info] Set master ping interval 3 seconds.
Mon Sep 27 14:50:08 2021 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Mon Sep 27 14:50:08 2021 - [info] Starting ping health check on 111.16.100.253(111.16.100.253:3306)..
Mon Sep 27 14:50:08 2021 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '111.16.100.253' (111))
Mon Sep 27 14:50:08 2021 - [warning] Connection failed 1 time(s)..
Mon Sep 27 14:50:08 2021 - [info] Executing SSH check script: save_binary_logs --command=test --start_pos=4 --binlog_dir=/var/lib/mysql,/var/log/mysql --output_file=/var/lib/mha/save_binary_logs_test --manager_version=0.58 --binlog_prefix=master-log
Mon Sep 27 14:50:09 2021 - [info] HealthCheck: SSH to 111.16.100.253 is reachable.
Mon Sep 27 14:50:11 2021 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '111.16.100.253' (111))
Mon Sep 27 14:50:11 2021 - [warning] Connection failed 2 time(s)..
Mon Sep 27 14:50:14 2021 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '111.16.100.253' (111))
Mon Sep 27 14:50:14 2021 - [warning] Connection failed 3 time(s)..
Mon Sep 27 14:50:17 2021 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '111.16.100.253' (111))
Mon Sep 27 14:50:17 2021 - [warning] Connection failed 4 time(s)..
Mon Sep 27 14:50:17 2021 - [warning] Master is not reachable from health checker!
Mon Sep 27 14:50:17 2021 - [warning] Master 111.16.100.253(111.16.100.253:3306) is not reachable!

Mon Sep 27 14:50:17 2021 - [warning] SSH is reachable.
Mon Sep 27 14:50:17 2021 - [info] Connecting to a master server failed. Reading configuration file /etc/masterha_default.cnf and /etc/mha_master/mha.cnf again, and trying to connect to all servers to check server status..
Mon Sep 27 14:50:17 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon Sep 27 14:50:17 2021 - [info] Reading application default configuration from /etc/mha_master/mha.cnf..
Mon Sep 27 14:50:17 2021 - [info] Reading server configuration from /etc/mha_master/mha.cnf..
Mon Sep 27 14:50:18 2021 - [info] GTID failover mode = 0
Mon Sep 27 14:50:18 2021 - [info] Dead Servers:
Mon Sep 27 14:50:18 2021 - [info]   111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:18 2021 - [info] Alive Servers:
Mon Sep 27 14:50:18 2021 - [info]   111.16.100.224(111.16.100.224:3306)
Mon Sep 27 14:50:18 2021 - [info]   111.16.101.73(111.16.101.73:3306)
Mon Sep 27 14:50:18 2021 - [info] Alive Slaves:
Mon Sep 27 14:50:18 2021 - [info]   111.16.100.224(111.16.100.224:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:18 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:18 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:18 2021 - [info]   111.16.101.73(111.16.101.73:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:18 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:18 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:18 2021 - [info] Checking slave configurations..
Mon Sep 27 14:50:18 2021 - [info]  read_only=1 is not set on slave 111.16.100.224(111.16.100.224:3306).
Mon Sep 27 14:50:18 2021 - [info] Checking replication filtering settings..
Mon Sep 27 14:50:18 2021 - [info]  Replication filtering check ok.
Mon Sep 27 14:50:18 2021 - [info] Master is down!
Mon Sep 27 14:50:18 2021 - [info] Terminating monitoring script.
Mon Sep 27 14:50:18 2021 - [info] Got exit code 20 (Master dead).
Mon Sep 27 14:50:18 2021 - [info] MHA::MasterFailover version 0.58.
Mon Sep 27 14:50:18 2021 - [info] Starting master failover.
Mon Sep 27 14:50:18 2021 - [info]
Mon Sep 27 14:50:18 2021 - [info] * Phase 1: Configuration Check Phase..
Mon Sep 27 14:50:18 2021 - [info]
Mon Sep 27 14:50:20 2021 - [info] GTID failover mode = 0
Mon Sep 27 14:50:20 2021 - [info] Dead Servers:
Mon Sep 27 14:50:20 2021 - [info]   111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:20 2021 - [info] Checking master reachability via MySQL(double check)...
Mon Sep 27 14:50:20 2021 - [info]  ok.
Mon Sep 27 14:50:20 2021 - [info] Alive Servers:
Mon Sep 27 14:50:20 2021 - [info]   111.16.100.224(111.16.100.224:3306)
Mon Sep 27 14:50:20 2021 - [info]   111.16.101.73(111.16.101.73:3306)
Mon Sep 27 14:50:20 2021 - [info] Alive Slaves:
Mon Sep 27 14:50:20 2021 - [info]   111.16.100.224(111.16.100.224:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:20 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:20 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:20 2021 - [info]   111.16.101.73(111.16.101.73:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:20 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:20 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:20 2021 - [info] Starting Non-GTID based failover.
Mon Sep 27 14:50:20 2021 - [info]
Mon Sep 27 14:50:20 2021 - [info] ** Phase 1: Configuration Check Phase completed.
Mon Sep 27 14:50:20 2021 - [info]
Mon Sep 27 14:50:20 2021 - [info] * Phase 2: Dead Master Shutdown Phase..
Mon Sep 27 14:50:20 2021 - [info]
Mon Sep 27 14:50:20 2021 - [info] Forcing shutdown so that applications never connect to the current master..
Mon Sep 27 14:50:20 2021 - [info] Executing master IP deactivation script:
Mon Sep 27 14:50:20 2021 - [info]   /etc/mha_master/master_ip_failover.pl --orig_master_host=111.16.100.253 --orig_master_ip=111.16.100.253 --orig_master_port=3306 --command=stopssh --ssh_user=root
Mon Sep 27 14:50:20 2021 - [info]  done.
Mon Sep 27 14:50:20 2021 - [warning] shutdown_script is not set. Skipping explicit shutting down of the dead master.
Mon Sep 27 14:50:20 2021 - [info] * Phase 2: Dead Master Shutdown Phase completed.
Mon Sep 27 14:50:20 2021 - [info]
Mon Sep 27 14:50:20 2021 - [info] * Phase 3: Master Recovery Phase..
Mon Sep 27 14:50:20 2021 - [info]
Mon Sep 27 14:50:20 2021 - [info] * Phase 3.1: Getting Latest Slaves Phase..
Mon Sep 27 14:50:20 2021 - [info]
Mon Sep 27 14:50:20 2021 - [info] The latest binary log file/position on all slaves is master-log.000007:154
Mon Sep 27 14:50:20 2021 - [info] Latest slaves (Slaves that received relay log files to the latest):
Mon Sep 27 14:50:20 2021 - [info]   111.16.100.224(111.16.100.224:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:20 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:20 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:20 2021 - [info]   111.16.101.73(111.16.101.73:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:20 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:20 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:20 2021 - [info] The oldest binary log file/position on all slaves is master-log.000007:154
Mon Sep 27 14:50:20 2021 - [info] Oldest slaves:
Mon Sep 27 14:50:20 2021 - [info]   111.16.100.224(111.16.100.224:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:20 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:20 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:20 2021 - [info]   111.16.101.73(111.16.101.73:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:20 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:20 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:20 2021 - [info]
Mon Sep 27 14:50:20 2021 - [info] * Phase 3.2: Saving Dead Master's Binlog Phase..
Mon Sep 27 14:50:20 2021 - [info]
Mon Sep 27 14:50:20 2021 - [info] Fetching dead master's binary logs..
Mon Sep 27 14:50:20 2021 - [info] Executing command on the dead master 111.16.100.253(111.16.100.253:3306): save_binary_logs --command=save --start_file=master-log.000007  --start_pos=154 --binlog_dir=/var/lib/mysql,/var/log/mysql --output_file=/var/lib/mha/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58
  Creating /var/lib/mha if not exists..    ok.
 Concat binary/relay logs from master-log.000007 pos 154 to master-log.000007 EOF into /var/lib/mha/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog ..
 Binlog Checksum enabled
  Dumping binlog format description event, from position 0 to 154.. ok.
  Dumping effective binlog data from /var/lib/mysql/master-log.000007 position 154 to tail(177).. ok.
 Binlog Checksum enabled
 Concat succeeded.
Mon Sep 27 14:50:21 2021 - [info] scp from root@111.16.100.253:/var/lib/mha/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog to local:/var/lib/mha-manager/app/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog succeeded.
Mon Sep 27 14:50:21 2021 - [info] HealthCheck: SSH to 111.16.100.224 is reachable.
Mon Sep 27 14:50:21 2021 - [info] HealthCheck: SSH to 111.16.101.73 is reachable.
Mon Sep 27 14:50:22 2021 - [info]
Mon Sep 27 14:50:22 2021 - [info] * Phase 3.3: Determining New Master Phase..
Mon Sep 27 14:50:22 2021 - [info]
Mon Sep 27 14:50:22 2021 - [info] Finding the latest slave that has all relay logs for recovering other slaves..
Mon Sep 27 14:50:22 2021 - [info] All slaves received relay logs to the same position. No need to resync each other.
Mon Sep 27 14:50:22 2021 - [info] Searching new master from slaves..
Mon Sep 27 14:50:22 2021 - [info]  Candidate masters from the configuration file:
Mon Sep 27 14:50:22 2021 - [info]   111.16.100.224(111.16.100.224:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:22 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:22 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:22 2021 - [info]   111.16.101.73(111.16.101.73:3306)  Version=5.7.34-log (oldest major version between slaves) log-bin:enabled
Mon Sep 27 14:50:22 2021 - [info]     Replicating from 111.16.100.253(111.16.100.253:3306)
Mon Sep 27 14:50:22 2021 - [info]     Primary candidate for the new Master (candidate_master is set)
Mon Sep 27 14:50:22 2021 - [info]  Non-candidate masters:
Mon Sep 27 14:50:22 2021 - [info]  Searching from candidate_master slaves which have received the latest relay log events..
Mon Sep 27 14:50:22 2021 - [info] New master is 111.16.100.224(111.16.100.224:3306)
Mon Sep 27 14:50:22 2021 - [info] Starting master failover..
Mon Sep 27 14:50:22 2021 - [info]
From:
111.16.100.253(111.16.100.253:3306) (current master)
 +--111.16.100.224(111.16.100.224:3306)
 +--111.16.101.73(111.16.101.73:3306)

To:
111.16.100.224(111.16.100.224:3306) (new master)
 +--111.16.101.73(111.16.101.73:3306)
Mon Sep 27 14:50:22 2021 - [info]
Mon Sep 27 14:50:22 2021 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
Mon Sep 27 14:50:22 2021 - [info]
Mon Sep 27 14:50:22 2021 - [info]  This server has all relay logs. No need to generate diff files from the latest slave.
Mon Sep 27 14:50:22 2021 - [info] Sending binlog..
Mon Sep 27 14:50:22 2021 - [info] scp from local:/var/lib/mha-manager/app/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog to root@111.16.100.224:/var/lib/mha/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog succeeded.
Mon Sep 27 14:50:22 2021 - [info]
Mon Sep 27 14:50:22 2021 - [info] * Phase 3.5: Master Log Apply Phase..
Mon Sep 27 14:50:22 2021 - [info]
Mon Sep 27 14:50:22 2021 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Mon Sep 27 14:50:22 2021 - [info] Starting recovery on 111.16.100.224(111.16.100.224:3306)..
Mon Sep 27 14:50:22 2021 - [info]  Generating diffs succeeded.
Mon Sep 27 14:50:22 2021 - [info] Waiting until all relay logs are applied.
Mon Sep 27 14:50:22 2021 - [info]  done.
Mon Sep 27 14:50:22 2021 - [info] Getting slave status..
Mon Sep 27 14:50:22 2021 - [info] This slave(111.16.100.224)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(master-log.000007:154). No need to recover from Exec_Master_Log_Pos.
Mon Sep 27 14:50:22 2021 - [info] Connecting to the target slave host 111.16.100.224, running recover script..
Mon Sep 27 14:50:22 2021 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='mhaadmin' --slave_host=111.16.100.224 --slave_ip=111.16.100.224  --slave_port=3306 --apply_files=/var/lib/mha/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog --workdir=/var/lib/mha --target_version=5.7.34-log --timestamp=20210927145018 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon Sep 27 14:50:22 2021 - [info]
MySQL client version is 5.7.34. Using --binary-mode.
Applying differential binary/relay log files /var/lib/mha/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog on 111.16.100.224:3306. This may take long time...
Applying log files succeeded.
Mon Sep 27 14:50:22 2021 - [info]  All relay logs were successfully applied.
Mon Sep 27 14:50:22 2021 - [info] Getting new master's binlog name and position..
Mon Sep 27 14:50:22 2021 - [info]  master-log.000003:154
Mon Sep 27 14:50:22 2021 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='111.16.100.224', MASTER_PORT=3306, MASTER_LOG_FILE='master-log.000003', MASTER_LOG_POS=154, MASTER_USER='slave', MASTER_PASSWORD='xxx';
Mon Sep 27 14:50:22 2021 - [info] Executing master IP activate script:
Mon Sep 27 14:50:22 2021 - [info]   /etc/mha_master/master_ip_failover.pl --command=start --ssh_user=root --orig_master_host=111.16.100.253 --orig_master_ip=111.16.100.253 --orig_master_port=3306 --new_master_host=111.16.100.224 --new_master_ip=111.16.100.224 --new_master_port=3306 --new_master_user='mhaadmin'   --new_master_password=xxx
Enabling the VIP - 111.16.100.189/24 on the new master - 111.16.100.224
Mon Sep 27 14:50:23 2021 - [info]  OK.
Mon Sep 27 14:50:23 2021 - [info] ** Finished master recovery successfully.
Mon Sep 27 14:50:23 2021 - [info] * Phase 3: Master Recovery Phase completed.
Mon Sep 27 14:50:23 2021 - [info]
Mon Sep 27 14:50:23 2021 - [info] * Phase 4: Slaves Recovery Phase..
Mon Sep 27 14:50:23 2021 - [info]
Mon Sep 27 14:50:23 2021 - [info] * Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
Mon Sep 27 14:50:23 2021 - [info]
Mon Sep 27 14:50:23 2021 - [info] -- Slave diff file generation on host 111.16.101.73(111.16.101.73:3306) started, pid: 26625. Check tmp log /var/lib/mha-manager/app/111.16.101.73_3306_20210927145018.log if it takes time..
Mon Sep 27 14:50:24 2021 - [info]
Mon Sep 27 14:50:24 2021 - [info] Log messages from 111.16.101.73 ...
Mon Sep 27 14:50:24 2021 - [info]
Mon Sep 27 14:50:23 2021 - [info]  This server has all relay logs. No need to generate diff files from the latest slave.
Mon Sep 27 14:50:24 2021 - [info] End of log messages from 111.16.101.73.
Mon Sep 27 14:50:24 2021 - [info] -- 111.16.101.73(111.16.101.73:3306) has the latest relay log events.
Mon Sep 27 14:50:24 2021 - [info] Generating relay diff files from the latest slave succeeded.
Mon Sep 27 14:50:24 2021 - [info]
Mon Sep 27 14:50:24 2021 - [info] * Phase 4.2: Starting Parallel Slave Log Apply Phase..
Mon Sep 27 14:50:24 2021 - [info]
Mon Sep 27 14:50:24 2021 - [info] -- Slave recovery on host 111.16.101.73(111.16.101.73:3306) started, pid: 26627. Check tmp log /var/lib/mha-manager/app/111.16.101.73_3306_20210927145018.log if it takes time..
Mon Sep 27 14:50:25 2021 - [info]
Mon Sep 27 14:50:25 2021 - [info] Log messages from 111.16.101.73 ...
Mon Sep 27 14:50:25 2021 - [info]
Mon Sep 27 14:50:24 2021 - [info] Sending binlog..
Mon Sep 27 14:50:24 2021 - [info] scp from local:/var/lib/mha-manager/app/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog to root@111.16.101.73:/var/lib/mha/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog succeeded.
Mon Sep 27 14:50:24 2021 - [info] Starting recovery on 111.16.101.73(111.16.101.73:3306)..
Mon Sep 27 14:50:24 2021 - [info]  Generating diffs succeeded.
Mon Sep 27 14:50:24 2021 - [info] Waiting until all relay logs are applied.
Mon Sep 27 14:50:24 2021 - [info]  done.
Mon Sep 27 14:50:24 2021 - [info] Getting slave status..
Mon Sep 27 14:50:24 2021 - [info] This slave(111.16.101.73)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(master-log.000007:154). No need to recover from Exec_Master_Log_Pos.
Mon Sep 27 14:50:24 2021 - [info] Connecting to the target slave host 111.16.101.73, running recover script..
Mon Sep 27 14:50:24 2021 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='mhaadmin' --slave_host=111.16.101.73 --slave_ip=111.16.101.73  --slave_port=3306 --apply_files=/var/lib/mha/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog --workdir=/var/lib/mha --target_version=5.7.34-log --timestamp=20210927145018 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon Sep 27 14:50:25 2021 - [info]
MySQL client version is 5.7.34. Using --binary-mode.
Applying differential binary/relay log files /var/lib/mha/saved_master_binlog_from_111.16.100.253_3306_20210927145018.binlog on 111.16.101.73:3306. This may take long time...
Applying log files succeeded.
Mon Sep 27 14:50:25 2021 - [info]  All relay logs were successfully applied.
Mon Sep 27 14:50:25 2021 - [info]  Resetting slave 111.16.101.73(111.16.101.73:3306) and starting replication from the new master 111.16.100.224(111.16.100.224:3306)..
Mon Sep 27 14:50:25 2021 - [info]  Executed CHANGE MASTER.
Mon Sep 27 14:50:25 2021 - [info]  Slave started.
Mon Sep 27 14:50:25 2021 - [info] End of log messages from 111.16.101.73.
Mon Sep 27 14:50:25 2021 - [info] -- Slave recovery on host 111.16.101.73(111.16.101.73:3306) succeeded.
Mon Sep 27 14:50:25 2021 - [info] All new slave servers recovered successfully.
Mon Sep 27 14:50:25 2021 - [info]
Mon Sep 27 14:50:25 2021 - [info] * Phase 5: New master cleanup phase..
Mon Sep 27 14:50:25 2021 - [info]
Mon Sep 27 14:50:25 2021 - [info] Resetting slave info on the new master..
Mon Sep 27 14:50:25 2021 - [info]  111.16.100.224: Resetting slave info succeeded.
Mon Sep 27 14:50:25 2021 - [info] Master failover to 111.16.100.224(111.16.100.224:3306) completed successfully.
Mon Sep 27 14:50:25 2021 - [info]

----- Failover Report -----

mha: MySQL Master failover 111.16.100.253(111.16.100.253:3306) to 111.16.100.224(111.16.100.224:3306) succeeded

Master 111.16.100.253(111.16.100.253:3306) is down!

Check MHA Manager logs at mysql-mha-manager:/etc/mha_master/manager.log for details.

Started automated(non-interactive) failover.
Invalidated master IP address on 111.16.100.253(111.16.100.253:3306)
The latest slave 111.16.100.224(111.16.100.224:3306) has all relay logs for recovery.
Selected 111.16.100.224(111.16.100.224:3306) as a new master.
111.16.100.224(111.16.100.224:3306): OK: Applying all logs succeeded.
111.16.100.224(111.16.100.224:3306): OK: Activated master IP address.
111.16.101.73(111.16.101.73:3306): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
111.16.101.73(111.16.101.73:3306): OK: Applying all logs succeeded. Slave started, replicating from 111.16.100.224(111.16.100.224:3306)
111.16.100.224(111.16.100.224:3306): Resetting slave info succeeded.
Master failover to 111.16.100.224(111.16.100.224:3306) completed successfully
2. 切换master节点完成，检测VIP以及master状态
$ > masterha_check_status --conf=/etc/mha_master/mha.cnf
mha (pid:26678) is running(0:PING_OK), master:111.16.100.224

登陆新master节点以及模拟故障master节点，查看是否已经完成VIP切换

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0sgs9YQH-1632732235168)(/Users/xiaohu/Library/Application Support/typora-user-images/image-20210927164007176.png)]

参考：

https://github.com/yoshinorim/mha4mysql-manager/wiki

https://zhuanlan.zhihu.com/p/132508138

.Feng_
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MHA的配置及错误模拟与恢复
sjc090132的博客
09-27 924
MHA的配置及模拟故障修复
MySQL MHA高可用+VIP 集群故障转移
12-20
MySQL MHA高可用+VIP 集群故障转移最佳实践
部署mysql的高可用MHA（manager high available）集群架构和MHA故障恢复
最新发布
weixin_67775126的博客
08-30 160
mha也是第三方软件或者插件，用于部署mysql高可用的一种方式，主要采取故障转移的策略，当主节点发生故障时，mha就会将主节点的master身份赋予给子节点slave，被指定的slave节点就会升级为master节点，赋予的策略默认就是按照接受到MHA的master机器的binlog日志最新的机器，当然，也可以使用权重来设置，自我感觉最原始的比较好，毕竟数据一致性很重要，最新的数据最贴近一致性。跟zookeeper里面的机制差不多，不过zookeeper里面的机制是采用选举，这里采用最新日志状态。
MySQL-MHA高可用方案
weixin_45636702的博客
07-11 1721
MySQL-MHA高可用方案 一、MHA简介 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA里有两个角色一个是
Mysql 5.7 高可用 MHA+阿里云SLB 实现故障秒级恢复
少说多做
07-10 1175
简介 Mysql的主从结构是目前产线使用的主要架构，配合MHA可以实现故障秒级切换，但是对于应用来说，主节点的地址换了以后，应用就连接不上了。通过使用SLB可以有效的解决这个问题，数据库主从切换，应用可以很快速的连接上新的主库。架构图如下 实现思路: 当主数据挂了以后，MHA侦测到以后，调用脚本，将SLB的后端地址更改为从数据库 环境准备 MHAManager:172.16.3.121 CentOS 7.4 Mysql Master:172.16.3.122 CentOS 7.4 ...
ＭＨＡ搭建ＭｙＳＱＬ高可用架构与故障修复
qq_45507377的博客
09-11 210
ＭＨＡ集群搭建 一，ＭＨＡ介绍： 　　１，简介：ＭＨＡ是一套解决ＭｙＳＱＬ高可用的架构，当数据库故障时，它能够在０～３０ｓ之内完成故障自动切换，保证数据库服务正常运行；在故障自动切换的过程中它能够最大限度的保障数据的一致性，这样真正意义上达到高可用． 　　２，组成： 　　MHA　Ｍanager(管理节点)：管理所有数据库服务器，可以单独部署在一台服务器上，也可部署在某一台数据库服务器上 　　MHA...
MHA文档翻译about部分
FaN()
07-19 752
概览MHA能够实现自动化的master failover和从库升级为new master,通常这一过程只需要10-30秒的停机时间.MHA最大程度保证了数据一致性,对性能零影响,易于安装,并且不需要改变现有部署情况.MHA支持计划性在线主库切换,在短时间内(0.5-2秒)的停机时间(仅限阻塞写入)，将当前运行的主机安全地更改为新主机.MHA提供以下功能,并且可用于需要高可用性,数据完整性和近乎不间断
mha数据备份_mysql MHA高可用故障恢复
weixin_39517241的博客
12-21 126
、恢复MHA故障1.手动修复1)修复挂掉的数据库[root@db01 ~]# systemctl start mysqld2)找到主从语句[root@db03 ~]# grep 'CHANGE MASTER TO' /service/mha/managerMon Nov 9 20:14:17 2020 - [info] All other slaves should start replica...
灾难恢复能力等级（业界公认）
f1092522699的博客
01-20 2331
灾难恢复能力等级 系统发生故障（掉电、宕机、进程误杀等等）时，业务如何考察系统的“高可用”能力 RTO (服务可用性) RTO (Recovery Time oBjective)恢复时间目标：在故障或灾难发生之后，数据库停止工作的最高可承受时间，这是一个最大可容忍时限，必须在此时限内恢复数据 RPO (数据可靠性) 这是一个过去的时间点，当灾难或紧急事件发生时，数据可以恢复到时间点，时业务系统所容忍的数据丢失量 ...
mha高可用
ITwang1的博客
12-07 1006
mha高可用 实际操作 1初始化环境 systemctl stop firewalld systemctl disable firewalld setenforce 0 2.修改 Master、Slave1、Slave2 节点的主机名 hostnamectl set-hostname mysql1 hostnamectl set-hostname mysql2 hostnamectl set-hostname mysql3 vim /etc/hosts 192.168.91.100 Mysql1 192
MySQL下高可用故障转移方案MHA的超级部署教程
09-10
主要介绍了MySQL下高可用故障切换方案MHA的超级部署教程,文中队MHA方案的一些特点做了介绍,示例基于Linux系统的服务器环境,需要的朋友可以参考下
MySQL高可用学习笔记mysqlrouter_MHA.docx
08-14
该文档前半部分是一步一步怎么配置mysql_router,然后测试，后半部分是一步一步配置常用的MHA高可用工具和测试，文档详细清楚，基本上按照文档步骤一步步做下去都能配置成功
MySQL高可用MHA自动Failover过程解析
10-30
文档东西是这段时间的学习笔记和个人理解，没有具体的实战经验，只是人为测试模拟故障的发生，通过日志来分析MHA背后的自动切换过程
MySQL MHA高可用架构搭建手册
02-21
MySQL MHA高可用架构搭建手册
Linux——MySQL MHA高可用配置及故障切换以及修复
不够优秀才会那么依赖其他人，不够成熟才会信任所有耀眼的外衣，不够强大才会浪费时光去迎合他们的玩闹！
05-20 1667
目录标题MHA应用场景及概述数据库MHA高可用方案部署方法安装MySQL数据库配置+主从同步 MHA应用场景及概述 传统的MySQL主从架构存在单点故障的问题 试想？如果主从架构中MySQL的master挂了呢？ MHA概述 一套优秀的MySQL高可用环境下故障切换和主从复制的软件 MySQL故障过程中，MHA能做到0-30秒内自动完成故障切换有效解决单点故障 MHA的组成 MHA Manager（管理节点）：可以单独部署 在一台独立的机器上管理多个master-slave集群，也可以部署在一台sla
mysql 主库高可用_数据库架构之【MySQL8+MHA】RDBMS 主从库高可用方案
weixin_32705179的博客
01-19 293
MySQL8 是一款功能强大且开源的(遵循GPL协议)关系型数据库管理系统(RDBMS)。MHA(Master High Availability) 是一个成熟的 MySQL 高可用解决方案。作为 MySQL 高可用性环境下故障切换和主从提升的高可用中间件，在 MySQL 故障切换过程中，能做到在 0~30 秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中能够最大程度上保证数据的一致...
数据库管理与高可用----MySQL 备份与恢复
LPFAM的博客
08-21 473
文章目录一: 数据库备份的分类1.1: 数据备份的重要性1.2: 数据库备份的分类1.3: 从数据库的备份策略角度,备份可分为1.4: 常见的备份方法1.5: MySQL物理冷备份与恢复二：MySQL的完全备份2.1：完全备份概念2.2：完全备份的优缺点2.2.1：优点：2.2.2：缺点：2.3：mysqldump备份库2.3.1：完全备份MySQL数据库分类2.3.2：mysqldump介绍2.3.3：mysqldump命令备份数据库2.3.4：mysqldump命令备份表三: MySQL数据恢复3.1：
MHA参数整理
wutuobang321的专栏
09-17 1903
1.    MHA配置文件参数 Parameter Name Required? Parameter Scope Default Value hostname Yes Local Only - ip No Local Only gethostbynam
MHA 自动故障转移步骤及过程剖析
乐沙弥的世界
04-21 7374
MHA是众多使用MySQL数据库企业高可用的不二选择，它简单易用，功能强大，实现了基于MySQL replication架构的自动主从故障转移，本文主要描述了MHA自动切换的步骤，对切换过程做了演示以及进行了适当的分析，供大家参考和理解MHA以及MySQL的原理......
mysql高可用mha
08-27
在MySQL故障切换过程中，MHA能够在0-30秒内自动完成故障切换操作，并且最大程度上保证数据的一致性，实现真正意义上的高可用。 MHA由多个组件组成，具体包括一个管理节点（manager node）和多个MySQL节点（MySQL ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值