MHA在线切换过程

MySQL MHA 在线切换是MHA除了自动监控切换换提供的另外一种方式,多用于诸如硬件升级,MySQL数据库迁移等等。该方式提供快速切换和优雅的阻塞写入,无关关闭原有服务器,整个切换过程在0.5-2s 的时间左右,大大减少了停机时间。本文演示了MHA 在线切换并给出了在线切换的基本步骤。

1、MHA在线切换方式及要求
    $ masterha_master_switch --master_state=alive --conf=/etc/app1.cnf --new_master_host=host2
  
    a、SQL threads on all slaves are running
    b、Seconds_Behind_Master on all slaves are less or equal than --running_updates_limit seconds
    c、On master, none of update queries take more than --running_updates_limit seconds in the show processlist output

2、在线进行切换基本步骤
    a、检测MHA配置置及确认当前master
    b、决定新的master
    c、阻塞写入到当前master
    d、等待所有从服务器与现有master完成同步
    e、并行切换从库
    f、重置原master为新master的slave

3、演示在线切换
###获取masterha_master_switch帮助
[[email protected] ~]# masterha_master_switch --help
Usage:
    # For master failover

masterha_master_switch --master_state=dead
    --global_conf=/etc/masterha_default.cnf
    --conf=/usr/local/masterha/conf/app1.cnf --dead_master_host=host1

# For online master switch

masterha_master_switch --master_state=alive
    --global_conf=/etc/masterha_default.cnf
    --conf=/usr/local/masterha/conf/app1.cnf

See online reference
    (http://code.google.com/p/mysql-master-ha/wiki/masterha_master_switch)
    for details.

###校验当前是否启用masterha_manager
[[email protected] ~]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RUNNING).

###切换前
mysql> show slave hosts;
+-----------+---------+------+-----------+--------------------------------------+
| Server_id | Host    | Port | Master_id | Slave_UUID                           |
+-----------+---------+------+-----------+--------------------------------------+
|      1001 | vdbsrv2 | 3306 |         1 | 75bef614-e342-11e4-921d-000c295fb2eb |
|      1002 | vdbsrv3 | 3306 |         1 | 091f79b8-e386-11e4-93d5-000c2943c830 |
+-----------+---------+------+-----------+--------------------------------------+

###实施在线切换
[[email protected] ~]# masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=vdbsrv3 \
> --orig_master_is_new_slave --running_updates_limit=10000 --interactive=0
Tue Apr 21 15:42:13 2015 - [info] MHA::MasterRotate version 0.56.
Tue Apr 21 15:42:13 2015 - [info] Starting online master switch..
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [info] * Phase 1: Configuration Check Phase..
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 21 15:42:13 2015 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Tue Apr 21 15:42:13 2015 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Tue Apr 21 15:42:13 2015 - [info] GTID failover mode = 0
Tue Apr 21 15:42:13 2015 - [info] Current Alive Master: vdbsrv1(192.168.1.6:3306)
Tue Apr 21 15:42:13 2015 - [info] Alive Slaves:
Tue Apr 21 15:42:13 2015 - [info]   vdbsrv2(192.168.1.7:3306)  Version=5.6.22-log (oldest major version between slaves) log-bin:enabled
Tue Apr 21 15:42:13 2015 - [info]     Replicating from 192.168.1.6(192.168.1.6:3306)
Tue Apr 21 15:42:13 2015 - [info]   vdbsrv3(192.168.1.8:3306)  Version=5.6.22-log (oldest major version between slaves) log-bin:enabled
Tue Apr 21 15:42:13 2015 - [info]     Replicating from 192.168.1.6(192.168.1.6:3306)
Tue Apr 21 15:42:13 2015 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
Tue Apr 21 15:42:13 2015 - [info]  ok.
Tue Apr 21 15:42:13 2015 - [info] Checking MHA is not monitoring or doing failover..
Tue Apr 21 15:42:13 2015 - [info] Checking replication health on vdbsrv2..   ###Author : Leshami
Tue Apr 21 15:42:13 2015 - [info]  ok.                                                             ###Blog    : http://blog.csdn.net/leshami
Tue Apr 21 15:42:13 2015 - [info] Checking replication health on vdbsrv3..
Tue Apr 21 15:42:13 2015 - [info]  ok.
Tue Apr 21 15:42:13 2015 - [info] vdbsrv3 can be new master.
Tue Apr 21 15:42:13 2015 - [info]
From:
vdbsrv1(192.168.1.6:3306) (current master)
 +--vdbsrv2(192.168.1.7:3306)
 +--vdbsrv3(192.168.1.8:3306)

To:
vdbsrv3(192.168.1.8:3306) (new master)
 +--vdbsrv2(192.168.1.7:3306)
 +--vdbsrv1(192.168.1.6:3306)
Tue Apr 21 15:42:13 2015 - [info] Checking whether vdbsrv3(192.168.1.8:3306) is ok for the new master..
Tue Apr 21 15:42:13 2015 - [info]  ok.
Tue Apr 21 15:42:13 2015 - [info] vdbsrv1(192.168.1.6:3306): SHOW SLAVE STATUS returned empty result. To check replication filtering rules,
  temporarily executing CHANGE MASTER to a dummy host.
Tue Apr 21 15:42:13 2015 - [info] vdbsrv1(192.168.1.6:3306): Resetting slave pointing to the dummy host.
Tue Apr 21 15:42:13 2015 - [info] ** Phase 1: Configuration Check Phase completed.
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [info] * Phase 2: Rejecting updates Phase..
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [warning] master_ip_online_change_script is not defined. Skipping disabling writes on the current master.
Tue Apr 21 15:42:13 2015 - [info] Locking all tables on the orig master to reject updates from everybody (including root):
Tue Apr 21 15:42:13 2015 - [info] Executing FLUSH TABLES WITH READ LOCK..
Tue Apr 21 15:42:13 2015 - [info]  ok.
Tue Apr 21 15:42:13 2015 - [info] Orig master binlog:pos is mysql-bin.000023:651371104.
Tue Apr 21 15:42:13 2015 - [info]  Waiting to execute all relay logs on vdbsrv3(192.168.1.8:3306)..
Tue Apr 21 15:42:13 2015 - [info]  master_pos_wait(mysql-bin.000023:651371104) completed on vdbsrv3(192.168.1.8:3306). Executed 0 events.
Tue Apr 21 15:42:13 2015 - [info]   done.
Tue Apr 21 15:42:13 2015 - [info] Getting new master‘s binlog name and position..
Tue Apr 21 15:42:13 2015 - [info]  mysql-bin.000016:301477519
Tue Apr 21 15:42:13 2015 - [info]  All other slaves should start replication from here. Statement should be:
    CHANGE MASTER TO MASTER_HOST=‘vdbsrv3 or 192.168.1.8‘, MASTER_PORT=3306, MASTER_LOG_FILE=‘mysql-bin.000016‘,
    MASTER_LOG_POS=301477519, MASTER_USER=‘repl‘, MASTER_PASSWORD=‘xxx‘;
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [info] * Switching slaves in parallel..
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [info] -- Slave switch on host vdbsrv2(192.168.1.7:3306) started, pid: 13099
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [info] Log messages from vdbsrv2 ...
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [info]  Waiting to execute all relay logs on vdbsrv2(192.168.1.7:3306)..
Tue Apr 21 15:42:13 2015 - [info]  master_pos_wait(mysql-bin.000023:651371104) completed on vdbsrv2(192.168.1.7:3306). Executed 0 events.
Tue Apr 21 15:42:13 2015 - [info]   done.
Tue Apr 21 15:42:13 2015 - [info]  Resetting slave vdbsrv2(192.168.1.7:3306) and starting replication from the new master vdbsrv3(192.168.1.8:3306)..
Tue Apr 21 15:42:13 2015 - [info]  Executed CHANGE MASTER.
Tue Apr 21 15:42:13 2015 - [info]  Slave started.
Tue Apr 21 15:42:13 2015 - [info] End of log messages from vdbsrv2 ...
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [info] -- Slave switch on host vdbsrv2(192.168.1.7:3306) succeeded.
Tue Apr 21 15:42:13 2015 - [info] Unlocking all tables on the orig master:
Tue Apr 21 15:42:13 2015 - [info] Executing UNLOCK TABLES..
Tue Apr 21 15:42:13 2015 - [info]  ok.
Tue Apr 21 15:42:13 2015 - [info] Starting orig master as a new slave..
Tue Apr 21 15:42:13 2015 - [info]  Resetting slave vdbsrv1(192.168.1.6:3306) and starting replication from the new master vdbsrv3(192.168.1.8:3306)..
Tue Apr 21 15:42:13 2015 - [info]  Executed CHANGE MASTER.
Tue Apr 21 15:42:13 2015 - [info]  Slave started.
Tue Apr 21 15:42:13 2015 - [info] All new slave servers switched successfully.
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [info] * Phase 5: New master cleanup phase..
Tue Apr 21 15:42:13 2015 - [info]
Tue Apr 21 15:42:13 2015 - [info]  vdbsrv3: Resetting slave info succeeded.
Tue Apr 21 15:42:13 2015 - [info] Switching master to vdbsrv3(192.168.1.8:3306) completed successfully.

###切换结果
mysql> show slave hosts;
+-----------+---------+------+-----------+--------------------------------------+
| Server_id | Host    | Port | Master_id | Slave_UUID                           |
+-----------+---------+------+-----------+--------------------------------------+
|         1 | vdbsrv1 | 3306 |      1002 | f2824060-e2cb-11e4-8f18-000c2926f457 |
|      1001 | vdbsrv2 | 3306 |      1002 | 75bef614-e342-11e4-921d-000c295fb2eb |
+-----------+---------+------+-----------+--------------------------------------+

时间: 2024-10-29 14:19:32

MHA在线切换过程的相关文章

MHA在线切换脚本master_ip_online_change结合VIP

结合vip的主库在线切换脚本master_ip_online_change: #!/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 Fr

MHA 主从切换过程及日志分析

本文主要在MHA 切换日志的角度分析MHA切换的过.MHA故障切换过程如下图所示 第一部分:开启MHA 监控 通过分析日志,得到以下步骤: 1.读取MHA manager 节点的配置文件,并检查配置文件中参数设置的正确性. Sat Jun 22 20:16:29 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping. Sat Jun 22 20:16:29 2019 - [

MHA的在线切换后的一些总结(mha方案来自网络)

mha方案来自:http://www.cnblogs.com/xuanzhi201111/p/4231412.html MHA的在线切换 192.168.2.131 [root bin]$ masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=192.168.2.129 --new_master_port=3306 --orig_master_is_new_slave

MySQL MHA在线手动切换——小坑

今天测试了MySQL的高可用架构--MHA,并进行了自动切换.手动failover以及手动在线切换,其中手动在线切换发现小坑:当旧master切换为新slave后,没有自动将read_only设置为on,例证如下: 环境说明: OS:CentOS release 6.5 MySQL: 5.6.22-71.0-log Percona Server slave1:172.16.52.130 mysql> show variables like 'read_only'; +--------------

MHA 自动切换步骤及过程剖析

MHA是众多使用MySQL数据库企业高可用的不二选择,它简单易用,功能强大,实现了基于MySQL replication架构的自动主从故障转移,本文主要描述了MHA自动切换的步骤,对切换过程做了演示以及进行了适当的分析,供大家参考和理解MHA以及MySQL的原理. 1.MHA自动切换的步骤a.MHA manager启动时的校验阶段   根据配置文件校验复制配置以及识别当前的master   导致监控终止情形:复制配置异常,存在的异常slave,一些需要的脚本脚本异常   MHA manager启

MHA自动Failover过程解析(updated) 转

允许转载, 转载时请以超链接形式标明文章原始出处和网站信息 http://www.mysqlsystems.com/2012/03/figure-out-process-of-autofailover-on-mha.html MHA自动Failover过程解析(updated) By zhang, on March 31st, 2012 MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案,来保证数据库系统的高可用.近期,在田老师的推动下,开始一步步深入了解这个HA方案,并也计

MHA masterha_check_repl 检测过程

MHA部署及配置是否OK,我们可以借助于MHA自带的masterha_check_ssh以及masterha_check_repl脚本来检测.masterha_check_repl检测是保证MHA成功切换的重要一步.本文主要描述了masterha_check_repl这个检测脚本到底做了些什么事情.有助于更好的理解MHA的相关原理及过程等. 1.当前的主从环境[roo[email protected] ~]# more /etc/hosts127.0.0.1    localhost.local

【MySQL】【高可用】从masterha_master_switch工具简单分析MHA的切换逻辑

简介:masterha_master_switch作为一个切换工具被集成在MHA程序包中, 安装:编译安装MHA manager后会在/usr/local/bin/中生成二进制可执行程序masterha_master_switch. 使用: $masterha_master_switch --help Usage: # For master failover masterha_master_switch --master_state=dead --global_conf=/etc/masterh

测试keepalived备备模式的主从切换过程

继续上次"测试keepalived备备模式"的配置后,测试运行状态中主从的切换过程 主要是分析优先级的改变过程.(目前的分析不一定正确,且可能片面,后续会更新,仅供参考) 优先级priority用P来代替 1.首先: Pa = 85 Pb = 75 此时 Pa > Pb 主 = Pa 从 = Pb weight = -20 检测脚本(retval)返回0,表示成功,其他(例如1),则表示失败 weight>0时, retval=0,则P = P + weight retva