美文网首页
1.7 配置mysql高可用-一主两从+MHA

1.7 配置mysql高可用-一主两从+MHA

作者: 回眸淡然笑 | 来源:发表于2023-07-12 16:59 被阅读0次

    一、MHA概述

    1.1什么是MHA

    MHA（MasterHigh Availability）是一套优秀的MySQL高可用环境下故障切换和主从复制的软件

    MHA的出现就是解决MySQL 单点的问题

    MySQL故障切换过程中，MHA能做到0-30秒内自动完成故障切换操作

    MHA能在故障切换的过程中最大程度上保证数据的一致性，以达到真正意义上的高可用

    1.2MHA的组成
    1.2.1MHA node（数据节点）

    MHA node运行在每台mysql服务器上

    1.2.2MHA manager（管理节点）

    MHA Manager 可以单独部署在一台独立的机器上，管理多个 master-slave 集群；也可以部署在一台 slave 节点上

    MHA Manager 会定时探测集群中的 master 节点。当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master， 然后将所有其他的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明

    1.3MHA的特点

    自动故障切换过程中，A试图从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失

    使用半同步复制，可以大大降低数据丢失的风险，如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性

    目前MHA支持一主多从架构，最少三台服务，即一主两从

    1.4MHA工作原理总结
    1. 从宕机崩溃的master保存二进制日志事件（binlog events）;
    2. 识别含有最新更新的slave；
    3. 应用差异的中继日志（relay log）到其他的slave；
    4. 应用从master保存的二进制日志事件（binlog events）；
    5. 提升一个slave为新的master；
    6. 使其他的slave连接新的master进行复制；
      当master出现故障时，通过对比slave之间I/O线程读取master binlog的位置，选取最接近的slave做为latest slave。其它slave通过与latest slave对比生成差异中继日志。在latest slave上应用从master保存的binlog，同时将latest slave提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。

    在MHA实现Master故障切换过程中，MHA Node会试图访问故障的master（通过SSH），如果可以访问（不是硬件故障，比如InnoDB数据文件损坏等），会保存二进制文件，以最大程度保证数据不丢失。MHA和半同步复制一起使用会大大降低数据丢失的危险。

    1.5面试常问
    1.5.1MHA如何保持数据的一致性呢？

    主要通过MHA node的以下几个工具实现，但是这些工具由mha manager触发：
    save_binary_logs 如果master的二进制日志可以存取的话，保存复制master的二进制日志，最大程度保证数据不丢失
    apply_diff_relay_logs 相对于最新的slave，生成差异的中继日志并将所有差异事件应用到其他所有的slave
    注意：
    对比的是relay log，relay log越新就越接近于master，才能保证数据是最新的。
    purge_relay_logs删除中继日志而不阻塞sql线程

    1.5.2 MHA的优势

    1. 故障切换快
    在主从复制集群中，只要从库在复制上没有延迟，MHA通常可以在数秒内实现故障切换。9-10秒内检查到master故障，可以选择在7-10秒关闭master以避免出现裂脑，几秒钟内，将差异中继日志（relay log）应用到新的master上，因此总的宕机时间通常为10-30秒。恢复新的master后，MHA并行的恢复其余的slave。即使在有数万台slave，也不会影响master的恢复时间。

    DeNA在超过150个MySQL（主要5.0/5.1版本）主从环境下使用了MHA。当mater故障后，MHA在4秒内就完成了故障切换。在传统的主动/被动集群解决方案中，4秒内完成故障切换是不可能的。

    2. master故障不会导致数据不一致
    当目前的master出现故障时，MHA自动识别slave之间中继日志（relay log）的不同，并应用到所有的slave中。这样所有的salve能够保持同步，只要所有的slave处于存活状态。和Semi-Synchronous Replication（半同步复制）一起使用，（几乎）可以保证没有数据丢失。

    3. 无需修改当前的MySQL设置
    MHA的设计的重要原则之一就是尽可能地简单易用。MHA工作在传统的MySQL版本5.0和之后版本的主从复制环境中。和其它高可用解决方法比，MHA并不需要改变MySQL的部署环境。MHA适用于异步和半同步的主从复制。

    启动/停止/升级/降级/安装/卸载MHA不需要改变（包扩启动/停止）MySQL复制。当需要升级MHA到新的版本，不需要停止MySQL，仅仅替换到新版本的MHA，然后重启MHA　Manager就好了。

    MHA运行在MySQL 5.0开始的原生版本上。一些其它的MySQL高可用解决方案需要特定的版本（比如MySQL集群、带全局事务ID的MySQL等等），但并不仅仅为了master的高可用才迁移应用的。在大多数情况下，已经部署了比较旧MySQL应用，并且不想仅仅为了实现Master的高可用，花太多的时间迁移到不同的存储引擎或更新的前沿发行版。MHA工作的包括5.0/5.1/5.5的原生版本的MySQL上，所以并不需要迁移。

    4. 无需增加大量的服务器
    MHA由MHA Manager和MHA Node组成。MHA Node运行在需要故障切换/恢复的MySQL服务器上，因此并不需要额外增加服务器。MHA Manager运行在特定的服务器上，因此需要增加一台（实现高可用需要2台），但是MHA Manager可以监控大量（甚至上百台）单独的master，因此，并不需要增加大量的服务器。即使在一台slave上运行MHA Manager也是可以的。综上，实现MHA并没用额外增加大量的服务。

    5. 无性能下降
    MHA适用与异步或半同步的MySQL复制。监控master时，MHA仅仅是每隔几秒（默认是3秒）发送一个ping包，并不发送重查询。可以得到像原生MySQL复制一样快的性能。

    6. 适用于任何存储引擎
    MHA可以运行在只要MySQL复制运行的存储引擎上，并不仅限制于InnoDB，即使在不易迁移的传统的MyISAM引擎环境，一样可以使用MHA。

    二、MHA搭建准备
    节点服务器 系统 主机名 IP地址
    MHA manager节点服务器 CentOS7.4(64 位) manage 192.168.3.75
    master节点服务器 CentOS7.4(64 位) master 192.168.3.74
    salve1节点服务器 CentOS7.4(64 位) salve1 192.168.3.71
    salve2节点服务器 CentOS7.4(64 位) salve1 192.168.3.70
    三、搭建

    关闭防火墙

    systemctl stop firewalld
systemctl disable firewalld
setenforce 0

    接前面几篇文章，使用的是主主-组复制架构，本篇首先转换成一主两从架构，并且是GTID模式
    修改master的mysql配置文件 /etc/my.cnf

    datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
rpl_semi_sync_master_enabled = 1
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
server-id = 1 #设置id 全局不能重复
gtid_mode=ON #GTID
enforce_gtid_consistency=ON #GTID
master_info_repository=TABLE
relay_log_info_repository=FILE #作为MHA的master库，这里需要改为FILE
log_slave_updates=ON
log_bin=binlog
relay-log=relay-log-bin
binlog_format=ROW
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

    修改slave1的mysql配置文件 /etc/my.cnf

    datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
rpl_semi_sync_slave_enabled=1
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
server-id = 2 #设置id 全局不能重复
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

    修改slave2的mysql配置文件 /etc/my.cnf

    datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=4
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
server-id=3
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
    修改 master、Slave1、Slave2 节点的主机名
    #在master上
hostnamectl set-hostname master
bash
 
#在Slave1
hostnamectl set-hostname slave1
bash
 
#在Slave2
hostnamectl set-hostname slave2
bash
    在master、slave1、slave2添加域名解析
    vim /etc/hosts
192.168.3.74 master
192.168.3.71 slave1
192.168.3.70 slave2
    配置主从同步

    登录数据库主从配置授权,Master、Slava1、Slava2上

    ###master、Slave1、Slave2 节点上都授权###
grant replication slave on *.* to 'myslave'@'192.168.3.%' identified by '123456';
#授权主从用户
grant all privileges on *.* to 'mha'@'192.168.3.%' identified by '123456';
grant all privileges on *.* to 'mha'@'mysql1' identified by '123456';
grant all privileges on *.* to 'mha'@'mysql2' identified by '123456';
grant all privileges on *.* to 'mha'@'mysql3' identified by '123456';

//刷新数据库
flush privileges;
    在 slave1、slave2 节点执行同步操作
    CHANGE MASTER TO  MASTER_HOST='192.168.3.74', MASTER_PORT=3306, MASTER_USER='myslave',MASTER_PASSWORD='123456',MASTER_AUTO_POSITION=1;
start slave;
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.3.74
                  Master_User: myslave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000008
          Read_Master_Log_Pos: 234
               Relay_Log_File: slave2-relay-bin.000002
                Relay_Log_Pos: 361
        Relay_Master_Log_File: binlog.000008
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 234
              Relay_Log_Space: 569
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 2
                  Master_UUID: bbd4275f-1af0-11ee-911e-0800278b8ad6
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 28c4b399-1af4-11ee-9051-080027745082:1-25,
36689b3d-1af9-11ee-b57a-08002765ff81:1-24,
bbd4275f-1af0-11ee-911e-0800278b8ad6:1-12
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.01 sec)
    设置两个从节点 只读模式
    set global read_only=1;
    image.png
    验证主从同步
    INSERT INTO `master`.`im_article`(`user_id`, `class_id`, `tags_id`, `title`, `abstract`, `image`, `is_asterisk`, `status`, `created_at`, `updated_at`, `deleted_at`) VALUES (1, 1, '1', '1', '1', '1', 1, 1, '2023-07-05 13:46:08', '2023-07-05 13:46:04', '2023-07-05 13:46:11');

    通过navicat查看slave1和slave2数据库上增加对应的数据列

    安装MHA软件

    四台服务器安装依赖环境

    yum install epel-release --nogpgcheck -y

yum install -y perl-DBD-MySQL \
perl-Config-Tiny \
perl-Log-Dispatch \
perl-Parallel-ForkManager \
perl-ExtUtils-CBuilder \
perl-ExtUtils-MakeMaker \
perl-CPAN
    下载mha软件包

    可以通过网盘下载，也可以通过github上下载，这里是我提供的网盘提取地址

    https://pan.baidu.com/s/134tw07kruHXXsXSILHcKFw?pwd=9919 提取码: 9919

    每台服务器上解压安装node组件,上传文件包后，进入文件包目录

    ##将需要的包下载到/opt下##
cd /opt
tar zxf mha4mysql-node-0.57.tar.gz
cd mha4mysql-node-0.57
perl Makefile.PL
make && make install

    在 MHA-manager 节点服务器上还需要安装 manager 组件

    将软件包mha4mysql-manager-0.57.tar.gz放入/opt目录下
cd /opt
tar zxf mha4mysql-manager-0.57.tar.gz 
cd mha4mysql-manager-0.57/
perl Makefile.PL
make && make install

    manager组件安装后在/usr/local/bin下面会生成几个工具，主要包括以下几个：

    masterha_check_ssh  检查 MHA 的 SSH 配置状况
masterha_check_repl 检查 MySQL 复制状况
masterha_manger 启动 manager的脚本
masterha_check_status   检测当前 MHA 运行状态
masterha_master_monitor 检测 master 是否宕机
masterha_master_switch  控制故障转移（自动或者手动）
masterha_conf_host  添加或删除配置的 server 信息
masterha_stop   关闭manager
 node组件安装后也会在/usr/local/bin 下面会生成几个脚本（这些工具通常由 MHAManager 的脚本触发，无需人为操作）主要如下：

save_binary_logs    保存和复制 master 的二进制日志
apply_diff_relay_logs   识别差异的中继日志事件并将其差异的事件应用于其他的 slave
filter_mysqlbinlog  去除不必要的 ROLLBACK 事件
purge_relay_logs    清除中继日志（不会阻塞sql线程）

    四台服务器配置无密码认证

    #在 manager 节点上配置到所有数据库节点的无密码认证
ssh-keygen -t rsa               #一路按回车键
ssh-copy-id 192.168.3.74
ssh-copy-id 192.168.3.71
ssh-copy-id 192.168.3.70

    #在 master 节点上配置到所有数据库节点的无密码认证
ssh-keygen -t rsa 
ssh-copy-id 192.168.3.71
ssh-copy-id 192.168.3.70

    #在 slave1 节点上配置到所有数据库节点的无密码认证
ssh-keygen -t rsa 
ssh-copy-id 192.168.3.74
ssh-copy-id 192.168.3.70

    #在 slave2节点上配置到所有数据库节点的无密码认证
ssh-keygen -t rsa 
ssh-copy-id 192.168.3.74
ssh-copy-id 192.168.3.71
    manager节点配置MHA

    进入/usr/local/bin

    [root@manager bin]# ls
apply_diff_relay_logs  masterha_check_repl    masterha_conf_host       masterha_master_switch    master_ip_failover       purge_relay_logs
docker-compose         masterha_check_ssh     masterha_manager         masterha_secondary_check  master_ip_online_change  save_binary_logs
filter_mysqlbinlog     masterha_check_status  masterha_master_monitor  masterha_stop             power_manager            send_report

    修改master_ip_failover

    vi /usr/local/bin/master_ip_failover
//增加如下信息
#############################添加内容部分#########################################
my $vip = '192.168.3.100/24';                    #指定vip的地址
my $brdc = '192.168.3.255';                    #指定vip的广播地址
my $ifdev = 'enp0s3';                        #指定vip绑定的网卡
my $key = '1';                            #指定vip绑定的虚拟网卡序列号
my $ssh_start_vip = "/sbin/ifconfig enp0s3:$key $vip";        #代表此变量值为ifconfig enp0s3:1 192.168.3.100
my $ssh_stop_vip = "/sbin/ifconfig enp0s3:$key down";        #代表此变量值为ifconfig enp0s3:1 192.168.3.100 down
my $exit_code = 0;                        #指定退出状态码为0
#my $ssh_start_vip = "/usr/sbin/ip addr add $vip/24 brd $brdc dev $ifdev label $ifdev:$key;/usr/sbin/arping -q -A -c 1 -I $ifdev $vip;iptables -F;";
#my $ssh_stop_vip = "/usr/sbin/ip addr del $vip/24 dev $ifdev label $ifdev:$key";
##########################################################################

    创建 MHA 软件目录并复制配置文件，使用app1.cnf配置文件来管理 mysql 节点服务器，配置文件一般放在/etc/目录下

    mkdir /etc/masterha
cp /opt/mha4mysql-manager-0.57/samples/conf/app1.cnf /etc/masterha

vim /etc/masterha/app1.cnf

    [server default]
manager_log=/var/log/masterha/app1/manager.log　　　　　　#manager日志
manager_workdir=/var/log/masterha/app1　　　　　　　　    #manager工作目录
master_binlog_dir=/usr/local/mysql/data/　　　　　　　　　#master保存binlog的位置，这里的路径要与master里配置的binlog的路径一致，以便MHA能找到
master_ip_failover_script=/usr/local/bin/master_ip_failover　　#设置自动failover时候的切换脚本，也就是上面的那个脚本
master_ip_online_change_script=/usr/local/bin/master_ip_online_change　　#设置手动切换时候的切换脚本
password=manager            #设置mysql中root用户的密码，这个密码是前文中创建监控用户的那个密码
ping_interval=1             #设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行failover
remote_workdir=/tmp         #设置远端mysql在发生切换时binlog的保存位置
repl_password=123456            #设置复制用户的密码
repl_user=myslave           #设置复制用户的用户
report_script=/usr/local/send_report　　　　　#设置发生切换后发送的报警的脚本
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.137.15 -s 192.168.137.10  #指定检查的从服务器IP地址
shutdown_script=""          #设置故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机防止发生脑裂,这里没有使用）
ssh_user=root               #设置ssh的登录用户名
user=mha                    #设置监控用户root
 
[server1]
hostname=192.1683.74
port=3306
 
[server2]
hostname=192.168.3.71
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=192.168.3.70
port=3306

    我的配置如下

    [server default]
manager_log=/var/log/masterha/app1/manager.log
manager_workdir=/var/log/masterha/app1
master_binlog_dir=/var/lib/mysql/
master_ip_failover_script=/usr/local/bin/master_ip_failover
master_ip_online_change_script=/usr/local/bin/master_ip_online_change
password=123456
ping_interval=1
remote_workdir=/tmp
repl_password=123456
repl_user=myslave
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.3.70 -s 192.168.3.71
shutdown_script=""
ssh_user=root
user=mha

[server1]
hostname=192.168.3.74
port=3306

[server2]
candidate_master=1
check_repl_delay=0
hostname=192.168.3.71
port=3306

[server3]
hostname=192.168.3.70
port=3306
    在master服务器上手动开启vip

    ifconfig enp0s3:1 192.168.3.100/24 通过ip a进行ip查看

    在 manager 节点上测试 ssh 无密码认证，如果正常最后会输出 successfully

    image.png
    在 manager 节点上测试 mysql 主从连接情况，最后出现 MySQL Replication Health is OK 字样说明正常 
    masterha_check_repl -conf=/etc/masterha/app1.cnf
    image.png
    在 manager 节点上启动 MHA 
    nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &


- -remove_dead_master_conf  该参数代表当发生主从切换后，老的主库的 ip 将会从配置文件中移除
- -manger_log   日志存放位置
 - -ignore_last_failover：在缺省情况下，如果 MHA 检测到连续发生宕机，且两次宕机间隔不足 8 小时的话，则不会进行 Failover， 之所以这样限制是为了避免 ping-pong 效应。该参数代表忽略上次 MHA 触发切换产生的文件，默认情况下，MHA 发生切换后会在日志记目录，也就是上面设置的日志app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为–ignore_last_failover

#查看 MHA 状态，可以看到当前的 master 是 Mysql1 节点

masterha_check_status --conf=/etc/masterha/app1.cnf

#查看 MHA 日志，也可以看到当前的 master 是 192.168.3.74

cat /var/log/masterha/app1/manager.log | grep "current master"

#查看 msater 的 VIP 地址 192.168.3.100 是否存在，这个 VIP 地址不会因为 manager 节点停止 MHA 服务而消失

ifconfig

#若要关闭 manager 服务，可以使用如下命令,或者可以直接采用 kill 进程 ID 的方式关闭
masterha_stop --conf=/etc/masterha/app1.cnf

    故障模拟

    在 manager 节点上监控观察日志记录
    tail -f /var/log/masterha/app1/manager.log
    在 master 节点mysql1上停止mysql服务
    systemctl stop mysqld
或
pkill -9 mysql

    正常自动切换一次后，MHA 进程会退出。HMA 会自动修改 app1.cnf 文件内容，将宕机的 mysql1 节点删除
    故障切换备选主库的算法：
    1．一般判断从库的是从（position/GTID）判断优劣，数据有差异，最接近于master的slave，成为备选主。
    2．数据一致的情况下，按照配置文件顺序，选择备选主库。
    3．设定有权重（candidate_master=1），按照权重强制指定备选主。
    （1）默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重，也会失效。
    （2）如果check_repl_delay=0的话，即使落后很多日志，也强制选择其为备选主

    查看 mysql2 是否接管 VIP

    ifconfig

    查看manager节点动态日志

    故障修复

    修复master
    systemctl restart mysqld
    修复主从

    在原主库服务器 master(192.168.3.74)执行同步操作

    change master to CHANGE MASTER TO  MASTER_HOST='192.168.3.71', MASTER_PORT=3306, MASTER_USER='myslave', MASTER_PASSWORD='123456', MASTER_AUTO_POSITION=1;
start slave;
show slave status\G;

    在 manager 节点上修改配置文件app1.cnf（再把这个记录添加进去，因为它检测掉失效时候会自动消失）

    vim /etc/masterha/app1.cnf
……
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.3.74 -s 192.168.3.70
......
[server1]
hostname=192.168.3.71
port=3306
 
[server2]
candidate_master=1
check_repl_delay=0
hostname=192.168.3.74
port=3306
 
[server3]
hostname=192.168.3.70
port=3306


在 manager 节点上启动 MHA

masterha_stop --conf=/etc/masterha/app1.cnf
 
nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &
 
masterha_check_status --conf=/etc/masterha/app1.cnf

    总结

    MHA的作用：解决mysql的高可用和故障切换；mha的核心部分由manager和node俩部分组成：manager：主要功能：做MHA启动、关闭、管理和检测mysql各种健康状态、node：在发生故障时，尽可能的保存二进制日志，并且实现故障切换（vip地址飘移）。

    故障切换MHA会做哪些工作：
    Mha会多次尝试检测master存活状态
    Mha会多次尝试、尽可能的保存master的二进制文件
    Mha会根据app1.cnf中的配置部分，进行从服务器—>主服务器的位置
    Mha最后会将master的vip地址作为切换到从服务器的位置
    Mha在选择完新的master之后，会在其余的slave上执行change master操作，指向新的master，来保证mysql的集群的健康

    Mha故障问题：
    ①免交互登录
    ②5个账号授权（其中三个账号是测试环境需要做的）
    ③初次运行mha功能时需要临时添加虚拟ip
    ④配置文件需要校验（master_ip_failover 1个故障切换脚本，app1.cnf mha的主配置文件）
    ⑤先安装node节点，在安装主节点

    相关文章

      网友评论

          本文标题：1.7 配置mysql高可用-一主两从+MHA

          本文链接：https://www.haomeiwen.com/subject/rfesudtx.html

          延伸阅读

          深度阅读

          • 您也可以注册成为美文阅读网的作者，发表您的原创作品、分享您的心情！

          栏目导航

          热点阅读

          关于我们|服务条款|联系我们|1.7 配置mysql高可用-一主两从+MHA|投稿指南|网站地图|RSS订阅|排版工具|手机版

          提供经典美文摘抄,优美散文欣赏,现代诗歌精选,短篇小说,心情随笔,表白情书范文,故事会在线阅读欣赏

          Copyright © 2014-2023 Haomeiwen.com All Rights Reserved. 好美文阅读网 版权所有

          备案信息：桂公网安备 45052102000051号 · 桂ICP备13007215号-3

          本站所收录作品、热点评论等信息部分来源互联网，目的只是为了系统归纳学习和传递资讯

          所有作品版权归原创作者所有，与本站立场无关，如不慎侵犯了你的权益，请联系我们告知，我们将做删除处理！