Mysql8 MHA(完结)

这篇具有很好参考价值的文章主要介绍了Mysql8 MHA(完结)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

3、故障切换演练

3.1 failover切换演练

场景一、自动failover,主从正常,从IO,SQL进程down掉,主库down掉

  1. slave01停止IO、SQL线程
  2. 模拟主库down机

3.1.1 slave01停止复制

Mysql>stop replica;

3.1.2 主库down机

Pkill -9 mysqld

3.1.3 观察maanger日志

Master 172.16.134.24(172.16.134.24:3310) is down!

Check MHA Manager logs at ebsproddb.ys:/var/log/mha/app1/manager.log for details.

Started automated(non-interactive) failover.

Invalidated master IP address on 172.16.134.24(172.16.134.24:3310)

None of existing slaves matches as a new master. Maybe preferred node is misconfigured or all slaves are too  far behind.

Got Error so couldn't continue failover from here.

Tue Mar 14 10:56:53 2023 - [info] Sending mail..

Unknown option: conf

tail: manager.log: file truncated

Thu Mar 16 19:32:14 2023 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.

Thu Mar 16 19:32:14 2023 - [info] Reading application default configuration from /etc/mha/masterha_default.cnf..

Thu Mar 16 19:32:14 2023 - [info] Reading server configuration from /etc/mha/masterha_default.cnf..

Thu Mar 16 19:32:14 2023 - [info] MHA::MasterMonitor version 0.58.

Thu Mar 16 19:32:15 2023 - [info] GTID failover mode = 1

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

masterha_default: MySQL Master failover 172.16.134.24(172.16.134.24:3310) to 172.16.134.25(172.16.134.25:3310) succeeded

Master 172.16.134.24(172.16.134.24:3310) is down!

Check MHA Manager logs at ebsproddb.ys:/var/log/mha/app1/manager.log for details.

Started automated(non-interactive) failover.

Invalidated master IP address on 172.16.134.24(172.16.134.24:3310)

Selected 172.16.134.25(172.16.134.25:3310) as a new master.

172.16.134.25(172.16.134.25:3310): OK: Applying all logs succeeded.

172.16.134.25(172.16.134.25:3310): OK: Activated master IP address.

172.16.134.26(172.16.134.26:3310): OK: Slave started, replicating from 172.16.134.25(172.16.134.25:3310)

172.16.134.25(172.16.134.25:3310): Resetting slave info succeeded.

Master failover to 172.16.134.25(172.16.134.25:3310) completed successfully.

场景二、自动failover,备主延迟>100M,从库设置no_maseter

  1. slave01停止IO线程
  2. 主库开启压力测试数据
  3. 开启slave01 IO线程

4、模拟主库down机

3.1.3 slave01停止复制

Mysql>stop slave io_thread;

3.1.2 主库创建测试数据

mysqlslap --user=root --password=123456 -h 172.16.134.24 -P 3310 --auto-generate-sql --auto-generate-sql-load-type=write --concurrency=128 --number-of-queries=1000000 --create-schema=test03

3.1.3 slave01开启复制

Slave01

Mysql>start slave io_thread;

3.1.4 主库down机

Pkill -9 mysqld

3.1.6 观察maanger日志

Tue Mar 14 10:56:48 2023 - [warning] Got error on MySQL select ping: 2006 (MySQL server has gone away)

Tue Mar 14 10:56:48 2023 - [info] Executing secondary network check script: /bin/masterha_secondary_check -s 172.16.134.25 -s 172.16.134.26  --user=root  --master_host=172.16.134.24  --master_ip=172.16.134.24  --master_port=3310 --master_user=root --master_password=123456 --ping_type=SELECT

Tue Mar 14 10:56:48 2023 - [info] Executing SSH check script: exit 0

Tue Mar 14 10:56:48 2023 - [info] HealthCheck: SSH to 172.16.134.24 is reachable.

Monitoring server 172.16.134.25 is reachable, Master is not reachable from 172.16.134.25. OK.

Monitoring server 172.16.134.26 is reachable, Master is not reachable from 172.16.134.26. OK.

Tue Mar 14 10:56:48 2023 - [info] Master is not reachable from all other monitoring servers. Failover should start.

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

masterha_default: MySQL Master failover 172.16.134.24(172.16.134.24:3310)

Master 172.16.134.24(172.16.134.24:3310) is down!

Check MHA Manager logs at ebsproddb.ys:/var/log/mha/app1/manager.log for details.

Started automated(non-interactive) failover.

Invalidated master IP address on 172.16.134.24(172.16.134.24:3310)

None of existing slaves matches as a new master. Maybe preferred node is misconfigured or all slaves are too  far behind.

Got Error so couldn't continue failover from here.

Tue Mar 14 10:56:53 2023 - [info] Sending mail..

Unknown option: conf

结论:自动failover 失败,主从延迟>100M,另外从添加no_master,找不到新maseter,切换失败。

场景三、自动failover,备主延迟<100M

  1. slave01停止IO线程
  2. 主库开启压力测试数据
  3. 开启slave01 IO线程
  4. 模拟主库down

结论:自动failover成功,备主延迟<100M,切换到备主成功。

场景四、自动failover, 备主延迟>100M,从库未设置no_maseter

  1. slave01停止IO线程
  2. 主库开启压力测试数据
  3. 开启slave01 IO线程

4 模拟主库down

结论:自动failover成功,备主延迟>100M,切换到从库成功

3.2 手动切换演练

手动failover,这种场景意味着在业务上没有启用MHA自动切换功能,当主服务器故障时,人工手动调用MHA来进行故障切换操作,具体命令如下:

3.2.1检测未开启MHA

masterha_check_status --conf=/etc/mha/masterha_default.cnf

masterha_default is stopped(2:NOT_RUNNING).

3.2.2 模拟主库down机

pkill -9 mysqld

注意:如果,MHA manager检测到没有dead的server,将报错,并结束failover

Thu Mar 16 20:05:47 2023 - [error][/usr/share/perl5/vendor_perl/MHA/MasterFailover.pm, ln188] None of server is dead. Stop failover.

Thu Mar 16 20:05:47 2023 - [error][/usr/share/perl5/vendor_perl/MHA/ManagerUtil.pm, ln177] Got ERROR:  at /bin/masterha_master_switch line 53.

3.2.3手工切换MHA

masterha_master_switch --master_state=dead --conf=/etc/mha/masterha_default.cnf --dead_master_host=172.16.134.24 --dead_master_port=3310 --new_master_host=172.16.134.25 --new_master_port=3310 --ignore_last_failover

输出信息询问是否进行切换yes/no

3.2.4 查看切换日志

Thu Mar 16 20:14:48 2023 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.

Thu Mar 16 20:14:48 2023 - [info] Reading application default configuration from /etc/mha/masterha_default.cnf..

Thu Mar 16 20:14:48 2023 - [info] Reading server configuration from /etc/mha/masterha_default.cnf..

Thu Mar 16 20:14:48 2023 - [info] MHA::MasterFailover version 0.58.

Thu Mar 16 20:14:48 2023 - [info] Starting master failover.

Thu Mar 16 20:14:48 2023 - [info]

Thu Mar 16 20:14:48 2023 - [info] * Phase 1: Configuration Check Phase..

Thu Mar 16 20:14:48 2023 - [info]

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

masterha_default: MySQL Master failover 172.16.134.24(172.16.134.24:3310) to 172.16.134.25(172.16.134.25:3310) succeeded

Master 172.16.134.24(172.16.134.24:3310) is down!

Check MHA Manager logs at ebsproddb.ys for details.

Started manual(interactive) failover.

Invalidated master IP address on 172.16.134.24(172.16.134.24:3310)

Selected 172.16.134.25(172.16.134.25:3310) as a new master.

172.16.134.25(172.16.134.25:3310): OK: Applying all logs succeeded.

172.16.134.25(172.16.134.25:3310): OK: Activated master IP address.

172.16.134.26(172.16.134.26:3310): OK: Slave started, replicating from 172.16.134.25(172.16.134.25:3310)

172.16.134.25(172.16.134.25:3310): Resetting slave info succeeded.

Master failover to 172.16.134.25(172.16.134.25:3310) completed successfully.

3.3 在线切换演练

许多情况下, 需要将现有的主服务器迁移到另外一台服务器上。 比如主服务器硬件故障,RAID 控制卡需要重建,将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降, 导致停机时间至少无法写入数据。 另外, 阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。 MHA 提供快速切换和优雅的阻塞写入,这个切换过程只需要 0.5-2s 的时间,这段时间内数据是无法写入的。在很多情况下,0.5-2s 的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口。

MHA在线切换的大概过程:

1.检测复制设置和确定当前主服务器

2.确定新的主服务器

3.阻塞写入到当前主服务器

4.等待所有从服务器赶上复制

5.授予写入到新的主服务器

6.重新设置从服务器

注意,在线切换的时候应用架构需要考虑以下两个问题:

1.自动识别master和slave的问题(master的机器可能会切换),如果采用了vip的方式,基本可以解决这个问题。

2.负载均衡的问题(可以定义大概的读写比例,每台机器可承担的负载比例,当有机器离开集群时,需要考虑这个问题)

为了保证数据完全一致性,在最快的时间内完成切换,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秒。

检测MHA状态

masterha_check_status --conf=/etc/mha/masterha_default.cnf

masterha_default is stopped(2:NOT_RUNNING).

在线切换

masterha_master_switch --conf=/etc/mha/masterha_default.cnf --master_state=alive --new_master_host=172.16.134.25 --new_master_port=3310 --orig_master_is_new_slave --running_updates_limit=10000

查看切换日志

   masterha_master_switch --conf=/etc/mha/masterha_default.cnf --master_state=alive --new_master_host=172.16.134.25 --new_master_port=3310 --orig_master_is_new_slave --running_updates_limit=10000

Mon Mar 20 19:14:23 2023 - [info] MHA::MasterRotate version 0.58.

Mon Mar 20 19:14:23 2023 - [info] Starting online master switch..

Mon Mar 20 19:14:23 2023 - [info]

Mon Mar 20 19:14:23 2023 - [info] * Phase 1: Configuration Check Phase..

Mon Mar 20 19:14:23 2023 - [info]  

Mon Mar 20 19:16:37 2023 - [info] -- Slave switch on host 172.16.134.26(172.16.134.26:3310) succeeded.

Mon Mar 20 19:16:37 2023 - [info] Unlocking all tables on the orig master:

Mon Mar 20 19:16:37 2023 - [info] Executing UNLOCK TABLES..

Mon Mar 20 19:16:37 2023 - [info]  ok.

Mon Mar 20 19:16:37 2023 - [info] Starting orig master as a new slave..

Mon Mar 20 19:16:37 2023 - [info]  Resetting slave 172.16.134.24(172.16.134.24:3310) and starting replication from the new master 172.16.134.25(172.16.134.25:3310)..

Mon Mar 20 19:16:37 2023 - [info]  Executed CHANGE MASTER.

Mon Mar 20 19:16:37 2023 - [info]  Slave started.

Mon Mar 20 19:16:37 2023 - [info] All new slave servers switched successfully.

Mon Mar 20 19:16:37 2023 - [info]

Mon Mar 20 19:16:37 2023 - [info] * Phase 5: New master cleanup phase..

Mon Mar 20 19:16:37 2023 - [info]

Mon Mar 20 19:16:37 2023 - [info]  172.16.134.25: Resetting slave info succeeded.

Mon Mar 20 19:16:37 2023 - [info] Switching master to 172.16.134.25(172.16.134.25:3310) completed successfully.

You have mail in /var/spool/mail/root

切换成功文章来源地址https://www.toymoban.com/news/detail-465079.html

到了这里,关于Mysql8 MHA(完结)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • MHA高可用配置及故障切换

    (1)MHA (Master High Availability) 是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。 (2)MHA的出现就是解决MySQL 单点的问题。 (3)MySQL故障切换过程中,MHA能做到0-30秒内自动完成故障切换操作。 (4)MHA能在故障切换的过程中最大程度上保证数据的一致性,以达

    2024年02月15日
    浏览(9)
  • 【Linux】MHA高可用配置及故障切换

    提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档 MHA(MasterHigh Availability)是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。 MHA 的出现就是解决MySQL 单点的问题。 MySQL故障切换过程中,MHA能做到0-30秒内自动完成故障切换操作。 MHA能在故障切

    2024年02月11日
    浏览(23)
  • MySQL MHA切换过程分析

    启动  MHA的启动脚本为masterha_manager(安装后,默认路径--/usr/local/bin/masterha_manager)。启动的过程中会主动检查各节点的SSH连接和主从复制的状态是否正常。运行期间,manager会调用masterha_master_monitor脚本(masterha_master_monitor进一步调用XXX/mha4mysql-manager-0.5?/lib/MHA/MasterMonitor.pm 和

    2024年01月22日
    浏览(12)
  • MySQL 高可用配置及故障切换

    1、MHA(MasterHigh Availability)是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。 2、MHA 的出现就是解决MySQL 单点的问题。 3、MySQL故障切换过程中,MHA能做到0-30秒内自动完成故障切换操作。 4、MHA能在故障切换的过程中最大程度上保证数据的一致性,以达到真正意义上

    2024年02月11日
    浏览(23)
  • 混沌工程和故障演练

    混沌工程是近年来新出现的概念,主要用于稳定性方面的研究,英文全称为chaos engineering,由网飞公司最先提出。因为最开始混沌工程称作chaos monkey,形容就像有一只猴子在系统中捣乱一样,以至于到现在每次提到混沌工程都会用一只捣乱的猴子来比喻。 但是稳定性测试不是

    2024年02月05日
    浏览(14)
  • Linux下Master-Master Replication Manager for MySQL 双主故障切换

    简述: Master-Master Replication Manager for MySQL(MMRM)是一种用于MySQL数据库的主-主复制管理工具。它允许在多个MySQL主机之间建立双向的主-主复制关系,实现数据的同步和高可用性。 工作原理是通过在每个MySQL主机上配置双向复制,使得每个主机都可以同时作为主服务器和从服务

    2024年02月11日
    浏览(13)
  • 【大厂面试演练】知道ZooKeeper有什么应用场景吗

    面试官:咳咳咳,看你简历写了精通ZooKeeper,那我就随便考考你吧 面试官:不用慌尽管说,错了也没关系😊。。。 每日分享大厂面试演练,感兴趣就关注我吧 ❤️ 嗯嗯,主要有这几种。 数据发布/订阅。可以用来实现配置中心 命名服务。类似于UUID,可以生成全局唯一的

    2024年03月15日
    浏览(21)
  • MySQL高可用MHA

    MHA(MasterHigh Availability)是一套优秀的MySQL高可用环境下故障切换和主从复制的软件 MHA 的出现就是解决MySQL 单点的问题。 MySQL故障切换过程中,MHA能做到0-30秒内自动完成故障切换操作。 MHA能在故障切换的过程中最大程度上保证数据的一致性,以达到真正意义上的高可用。

    2024年02月12日
    浏览(11)
  • MySQL----MHA高可用

    MHA(MasterHigh Availability)是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。 MHA 的出现就是解决MySQL 单点的问题。 MySQL故障切换过程中,MHA能做到0-30秒内自动完成故障切换操作。 MHA能在故障切换的过程中最大程度上保证数据的一致性,以达到真正意义上的高可用。

    2024年02月12日
    浏览(15)
  • MySQL MHA

    目录 概述 MHA MHA 的组成 MHA 的特点 搭建 MySQL MHA 配置主从复制 1.关防火墙,安全机制 2.修改 Master、Slave1、Slave2 节点的主机名 3.在Master、Slave1、Slave2添加主机映射关系 4.修改 Master、Slave1、Slave2 节点的 Mysql主配置文件/etc/my.cnf 5.在 Master、Slave1、Slave2 节点上都创建两个软链接

    2024年02月09日
    浏览(10)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包