MHA 切换的2个异常(masterha_master_switch line 53)

MHA故障转移与在线切换IP地址问题解决
最新推荐文章于 2022-11-08 20:18:11 发布
转载 最新推荐文章于 2022-11-08 20:18:11 发布 · 195 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：https://yq.aliyun.com/articles/268296

本文详细阐述了MHA在测试手动故障转移和在线切换过程中遇到的两个诡异问题，即使用IP地址调用时均无法测试成功，并提供了对应的解决方案。通过将IP地址替换为主机名，问题得以解决。同时强调了在配置文件中参数的正确使用，避免使用IP地址作为死主节点标识。

        MHA 在测试手动故障转移和在线切换的过程中，碰到了2个比较诡异的问题，在使用IP地址调用的时候均无法测试成功，出现了Detected dead master xxx does not match with specified dead master以及xxx is not alive。下面是这2个错误问题的描述及解决方案。

 

1、MHA配置文件
[root@vdbsrv4 ~]# more /etc/masterha/app1.cnf
[server default]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log

user=mha
password=xxx
ssh_user=root
repl_user=repl  
repl_password=repl  
ping_interval=1
shutdown_script=""
master_ip_online_change_script=""
report_script=""
#master_ip_failover_script=/usr/bin/master_ip_failover
master_ip_failover_script=/tmp/master_ip_failover
 
[server1]
hostname=vdbsrv1
master_binlog_dir=/data/mysqldata

[server2]
hostname=vdbsrv2
master_binlog_dir=/data/mysqldata

[server3]
hostname=vdbsrv3
master_binlog_dir=/data/mysqldata/
#candidate_master=1

 

2、手动故障转移时的错误提示
[root@vdbsrv4 ~]# masterha_master_switch --master_state=dead --conf=/etc/masterha/app1.cnf --dead_master_host=192.168.1.6 \
> --dead_master_port=3306 --new_master_host=192.168.1.8 --new_master_port=3306 --ignore_last_failover
--dead_master_ip=<dead_master_ip> is not set. Using 192.168.1.6.
Wed Apr 21 09:08:30 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Wed Apr 21 09:08:30 2015 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Wed Apr 21 09:08:30 2015 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Wed Apr 21 09:08:30 2015 - [info] MHA::MasterFailover version 0.56.
Wed Apr 21 09:08:30 2015 - [info] Starting master failover.
Wed Apr 21 09:08:30 2015 - [info]
Wed Apr 21 09:08:30 2015 - [info] * Phase 1: Configuration Check Phase..
Wed Apr 21 09:08:30 2015 - [info]
Wed Apr 21 09:08:31 2015 - [info] GTID failover mode = 0
Wed Apr 21 09:08:31 2015 - [error][/usr/lib/perl5/site_perl/5.8.8/MHA/MasterFailover.pm, ln2083] Detected dead master vdbsrv1(192.168.1.6:3306)
   does not match with specified dead master 192.168.1.6(192.168.1.6:3306)!
Wed Apr 21 09:08:31 2015 - [error][/usr/lib/perl5/site_perl/5.8.8/MHA/MasterFailover.pm, ln2151]
   Got ERROR:  at /usr/bin/masterha_master_switch line 53

 

3、在线切换时的错误提示
[root@vdbsrv4 ~]# masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=alive --new_master_host=192.168.1.8 \
> --orig_master_is_new_slave --running_updates_limit=10000
Tue Apr 21 11:50:14 2015 - [info] MHA::MasterRotate version 0.56.
Tue Apr 21 11:50:14 2015 - [info] Starting online master switch..
Tue Apr 21 11:50:14 2015 - [info]
Tue Apr 21 11:50:14 2015 - [info] * Phase 1: Configuration Check Phase..
Tue Apr 21 11:50:14 2015 - [info]
Tue Apr 21 11:50:14 2015 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 21 11:50:14 2015 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Tue Apr 21 11:50:14 2015 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Tue Apr 21 11:50:14 2015 - [info] GTID failover mode = 0
Tue Apr 21 11:50:14 2015 - [info] Current Alive Master: vdbsrv1(192.168.1.6:3306)
Tue Apr 21 11:50:14 2015 - [info] Alive Slaves:
Tue Apr 21 11:50:14 2015 - [info]   vdbsrv2(192.168.1.7:3306)  Version=5.6.22-log (oldest major version between slaves) log-bin:enabled
Tue Apr 21 11:50:14 2015 - [info]     Replicating from 192.168.1.6(192.168.1.6:3306)
Tue Apr 21 11:50:14 2015 - [info]   vdbsrv3(192.168.1.8:3306)  Version=5.6.22-log (oldest major version between slaves) log-bin:enabled
Tue Apr 21 11:50:14 2015 - [info]     Replicating from 192.168.1.6(192.168.1.6:3306)

It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on vdbsrv1(192.168.1.6:3306)? (YES/no): yes
Tue Apr 21 11:50:41 2015 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
Tue Apr 21 11:50:41 2015 - [info]  ok.
Tue Apr 21 11:50:41 2015 - [info] Checking MHA is not monitoring or doing failover..
Tue Apr 21 11:50:41 2015 - [info] Checking replication health on vdbsrv2..
Tue Apr 21 11:50:41 2015 - [info]  ok.
Tue Apr 21 11:50:41 2015 - [info] Checking replication health on vdbsrv3..
Tue Apr 21 11:50:41 2015 - [info]  ok.
Tue Apr 21 11:50:41 2015 - [error][/usr/lib/perl5/site_perl/5.8.8/MHA/MasterRotate.pm, ln228] 192.168.1.8 is not alive!
Tue Apr 21 11:50:41 2015 - [error][/usr/lib/perl5/site_perl/5.8.8/MHA/MasterRotate.pm, ln613] Failed to get new master!
Tue Apr 21 11:50:41 2015 - [error][/usr/lib/perl5/site_perl/5.8.8/MHA/MasterRotate.pm, ln652] Got ERROR:  at /usr/bin/masterha_master_switch line 53

 

4、解决方案
      直接将IP地址替换为主机名后问题解决，不再演示。

       按官方文档描述，参数--dead_master_host=(hostname)，而不是可以用IP地址。

       If these parameters are not set, --dead_master_ip will be the result of gethostbyname(dead_master_host), and --dead_master_port will be 3306.

       补充： 如果配置文件里hostname=IP地址，则在切换的时候使用IP地址也是可行的。 @20150522


MHA全自动切换
xpiou
02-03 713
1：切换脚本[root@server1 masterha]# masterha_master_switch --conf=/usr/local/masterha/app1.cnf --master_state=alive --new_master_host=172.25.200.1 --new_master_port=3306 --orig_master_is_new_slave --running
mysql 5.7的MHA及组复制，读写分离及常见错误归类
yangkaiorange的博客
10-11 985
一 MHA介绍 MHA能够在较短的时间内实现自动故障检测和故障转移，通常在10-30秒以内;在复制框架中，MHA能够很好地解决复制过程中的数据一致性问题，由于不需要在现有的replication中添加额外的服务器，仅需要一个manager节点，而一个Manager能管理多套复制，所以能大大地节约服务器的数量;另外，安装简单，无性能损耗，以及不需要修改现有的复制部署也是它的优势之处。 MHA还...
mysql MHA脚本masterha_master_switch手动操作常见错误
u010719917的专栏
05-23 3902
Mon May 21 16:56:06 2018 - [error][/usr/local/share/perl5/MHA/MasterFailover.pm, ln1261] Failed to activate master IP address for centos129 with return code 10:0解决办法：？ [warning] Got timeout on MySQL ...
MHA failover GTID 专题
weixin_33849942的博客
11-10 271
MHA failover GTID 专题 这里以masterha_master_switch为背景详解各种可能遇到的场景 假定环境(经典三节点) host_1(host_1:3306) (current master) +--host_2(host_2:3306 slave[candidate master]) +--host_3(host_3:33...
MHA高可用配置及故障切换
qjwthink的博客
12-08 387
一、MHA的介绍 1、MHA概述 ·一套优秀的MySQL高可用环境下故障切换和主从复制的软件 ·MHA的出现就是解决MySQL单点的问题。 ·MySQL故障过程中，MHA能做到0-30秒内自动完成故障切换 ·MHA能在故障切换的过程中最大程度上保证数据的一致性，以达到真正意义上的高可用 2、MHA的组成 ·MHA Manager（管理节点） ·MHA Node(数据节点) 3、MHA特点 ·自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失 ·
Mysql MHA高可用配置及故障切换
weixin_48271370的博客
11-08 603
Mysql MHA高可用配置及故障切换
Mysql高可用集群搭建(三) MHA VipHa 故障转移恢复
vc33569的专栏
08-26 1506
MHA VIP漂移配置 常见生产故障解决
Mysql数据库—MHA高可用配置及故障切换
wf19880114的博客
04-15 619
目录 一、MHA概述 二、MHA的组成 三、MHA的特点 四、搭建MHA 4.1 服务器准备 4.2 思路 4.3 三个节点安装mysql5.7并修改主机名 4.4 修改三个节点的Mysql主配置文件 4.5 在三个节点上都创建两个软链接 4.6 配置mysql一主两从 4.6.1 三个节点进行mysql授权 4.6.2 master节点查看二进制文件和同步点 4.6.3 slave1、slave2节点执行同步操作 4.6.4 Slave1、Slave2节点查看数据同步...
Linux之Mysql的读写分离与MHA高可用集群配置（手动、半自动和全自动切换master）
qq_43830639的博客
07-30 2690
一、Mysql的读写分离和高可用 1.读写分离 在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。 2. mysql的高可用 高可用对于互联网应用基本上是标配，目的是最大程度的为用户提供服务，避免因为服务器宕机等意外故障而终止服务...
mysql mha切换应用无法访问_MySQL MHA切换失败一例
weixin_39524842的博客
01-28 485
先看下引起问题的密码啥样, 包含两个特殊字符[和~.$ egrep -w 'user|password' /etc/masterha/app1.cnfpassword=P[AI3M~5zuser=mha_mgr用户mha_mgr的作用, 如下文档中的说明, 可见其对数据库实例起到管理的作用.MySQL administrative database username to the target M...
MySQL高可用之MHA切换测试（switchover & failover）
diankuozhi9810的博客
08-02 563
Preface I've installed MasterHA yesterday,Now let's test the master-slave switch and failover feature. Framework Hostname IP Port Identity OS Version MySQL V...
MHA failover NON-GTID 专题
weixin_33717298的博客
11-22 181
MHA failover NON-GTID 专题 这里以masterha_master_switch为背景详解各种可能遇到的场景 假定环境(经典三节点) host_1(host_1:3306) (current master) +--host_2(host_2:3306 slave[candidate master]) +--host_3(host_...
MySQL MHA 基础知识介绍
weixin_51614581的博客
02-19 794
MySQL MHAMySQL MHA1．什么是 MHA2．MHA 的组成3．MHA 的特点 MySQL MHA 1．什么是 MHA MHA（MasterHigh Availability）是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。 MHA 的出现就是解决MySQL 单点的问题。 MySQL故障切换过程中，MHA能做到0-30秒内自动完成故障切换操作。 MHA能在故障切换的过程中最大程度上保证数据的一致性，以达到真正意义上的高可用。 2．MHA 的组成 MHA Node（数据节点）
MHA-6 两个脚本 master_ip_failover master_ip_online_change
m493096871的博客
02-26 625
master_ip_failover #!/usr/bin/env perl use strict; use warnings FATAL =&gt; 'all'; use Getopt::Long; my (     $command,          $ssh_user,        $orig_master_host, $orig_master_ip,     $orig_maste...
安装MHA踩过的坑
热门推荐
文档搬运工
04-29 1万+
MHA 0.58+Mysql5.7+redhat7.4 已测试通过。 之前在redhat6.10上安装，在家里电脑安装OK，一样的包，拿到公司安装，失败了。很郁闷。随后改成redhat7.4安装，安装成功，走了不少弯路。把坑写出来。 一些包的下载地方 ，在使用redhat6.10的时候，下载过，安装成功了，redhat7.4没有从这里下载直接光盘yum了。 http://rpm.pbone....
MHA配置与主的手动切换
weixin_49222959的博客
12-23 1128
一、简介 MHA（Master HA）是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新数据的 slave 节点成为新的master 节点，在此期间，MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点。 　　MHA 是由日本人 yoshinorim（原就职
Mysql5.7高可用集群MHA搭建+shell脚本监测切换Manager节点解决单点故障问题
迷茫的IT老腊肉
03-21 3248
PS：楼主技术能力有限，如有更好的解决思路请留下评论哈，谢谢。 文章目录前言一、3个数据库节点安装mysql5.7.36二、使用步骤1.引入库2.读入数据总结 前言 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切.
记录一次 MHA集群报错
辅导自学转行
12-05 550
MHA 报错
maxscale master_accept_reads=true 这个参数什么意思
最新发布
06-15
<think>我们正在讨论MaxScale的两个关键点：`master_accept_reads`参数的作用，以及MaxScale与MariaDB的连接原理。根据引用内容，我们可以整合相关信息。首先，关于`master_accept_reads`参数：引用[4]提到了maxscalerouter之readwritesplit的参数，其中虽然没有直接提到`master_accept_reads`，但我们可以根据经验推断，这个参数通常出现在读写分离的路由配置中。它的作用一般是控制是否允许将读请求（SELECT）发送到主节点（master）。默认情况下，读写分离会将读请求发送到从节点，写请求发送到主节点。但在某些情况下，比如从节点延迟较大或者没有从节点可用时，我们可能希望将读请求也发送到主节点，以避免读不到最新数据或者没有节点可用的情况。因此，`master_accept_reads`参数的作用是：-当设置为`true`（默认值可能是`false`）时，允许将读请求发送到主节点。-当设置为`false`时，读请求只能发送到从节点，即使主节点是唯一可用的节点，读请求也不会发送到主节点（这可能导致读请求失败）。注意：该参数的具体默认值和可用性可能因版本而异，需要查看对应版本的官方文档。其次，关于MaxScale与MariaDB的连接原理：引用[2]和[3]提到MaxScale是一个中间件，实现MySQL读写分离与负载均衡。应用连接MaxScale，MaxScale再连接后端的MariaDB服务器。引用[1]给出了MaxScale服务的配置，包括启动用户、配置文件路径等。引用[5]提到下载和安装MaxScale。连接原理可以概括为：1.应用服务使用MySQL协议连接到MaxScale监听的端口（如4006）。2.MaxScale根据配置的路由规则（如readwritesplit）对SQL语句进行解析，决定将请求发送到哪个后端数据库服务器。3.MaxScale与后端MariaDB服务器建立连接，并转发请求。4.MaxScale将数据库返回的结果转发给应用。在连接过程中，MaxScale会维护一个到后端数据库的连接池，以复用连接，提高性能。下面详细说明：###1.`master_accept_reads`参数详解该参数通常出现在读写分离路由器（readwritesplit）的配置中。例如：```ini[Read-Write-Service]type=servicerouter=readwritesplitservers=server1,server2master_accept_reads=true#允许读操作发送到主节点```**作用**：-`true`：当从节点不可用或延迟过大时，允许将读操作发送到主节点，确保读操作可以执行。-`false`：读操作只能发送到从节点。如果所有从节点都不可用，读操作将失败（即使主节点可用）。**使用场景**：-在从节点延迟较大但主节点负载不高的情况下，可以临时允许读主，减轻从节点压力并保证读取最新数据。-在只有主节点的情况下（例如没有配置从节点），必须设置为`true`才能执行读操作。**注意**：该参数可能会影响读写分离的效果（增加主节点负担），需根据实际情况调整。###2.MaxScale与MariaDB连接原理MaxScale作为中间件，连接原理分为两个层面：**a.应用服务与MaxScale的连接**-应用使用标准MySQL客户端协议连接MaxScale（如通过JDBC、mysql命令行等）。-MaxScale监听一个或多个端口（如4006），接收客户端连接。-认证：MaxScale可以配置为使用后端数据库的认证（直通模式）或本地认证。**b.MaxScale与MariaDB的连接**-**连接池**：MaxScale为每个后端数据库服务器维护一个连接池。当应用发送请求时，MaxScale从连接池中获取一个空闲连接（或建立新连接）来执行查询。-**路由决策**：根据路由模块（如readwritesplit）决定将请求发送到哪个服务器。例如：-写请求（INSERT/UPDATE/DELETE等）发送到主节点。-读请求（SELECT）根据负载均衡策略（如LEAST_CURRENT_OPERATIONS）发送到从节点。-**结果返回**：MaxScale接收到MariaDB的响应后，将结果返回给应用，并释放连接回连接池（如果连接可复用）。**连接池配置示例**（在MaxScale配置文件中）：```ini[server1]type=serveraddress=192.168.1.10port=3306protocol=MySQLBackendconnection_timeout=10s```**连接复用优势**：-减少与后端数据库建立连接的开销（TCP三次握手、认证等）。-有效管理数据库连接数，避免数据库因连接过多而崩溃。**监控与故障转移**：-MaxScale通过监控模块（如`mariadbmon`）定期检查后端数据库状态。-当主节点故障时，监控模块触发故障转移，将写请求路由到新的主节点（需配合GaleraCluster或MHA等）。引用[4]中提到的连接选择策略（如`LEAST_CURRENT_OPERATIONS`）也是MaxScale连接管理的一部分，用于优化读请求的分发。###总结1.**`master_accept_reads`**：控制读请求是否可发送到主节点，用于增强系统在从节点不可用时的可用性。2.**连接原理**：-应用连接MaxScale（模拟MySQL服务器）-MaxScale通过连接池连接后端MariaDB，并根据路由规则转发请求-连接池复用连接，提高性能配置示例（读写分离服务启用`master_accept_reads`）：```ini[ReadWrite-Split]type=servicerouter=readwritesplitservers=master,slave1,slave2user=maxscalepassword=********master_accept_reads=true#允许读主max_slave_connections=100%#允许使用所有从节点```注意：实际使用时需结合监控模块和负载均衡策略进行调优。如果遇到从节点延迟大或不可用的情况，设置`master_accept_reads=true`可提高读操作可用性，但会增加主节点负担，需权衡使用。以上内容参考了提供的引用并结合了MaxScale的常规知识。下面生成相关问题：</think>### MaxScale `master_accept_reads` 参数详解及连接原理 #### 一、`master_accept_reads` 参数作用 `master_accept_reads` 是 MaxScale 读写分离路由(`readwritesplit`)的关键参数，主要控制**主节点(Master)是否接受读请求**： ```ini [Read-Write-Service] type=service router=readwritesplit servers=master,slave1,slave2 master_accept_reads=true # 核心参数 ``` | 参数值 | 行为 | 适用场景 | |--------|------|----------| | `true` (默认) | 允许读请求发送到主节点 | 从节点延迟较高时保证读取最新数据 | | `false` | 强制所有读请求仅发送到从节点 | 严格读写分离，减轻主节点压力 | **工作原理**： 1. 当 SQL 为 `SELECT` 时： - `master_accept_reads=true`：优先发送到从节点，但当： - 所有从节点不可用 - 从节点延迟超过 `max_slave_replication_lag` - 事务内查询（需读最新数据） 会**自动降级到主节点** - `master_accept_reads=false`：即使主节点是唯一可用节点，也**拒绝读请求** 2. 典型配置示例： ```ini [readwritesplit] master_accept_reads=true max_slave_replication_lag=5 # 从库最大允许延迟(秒) slave_selection_criteria=LEAST_CURRENT_OPERATIONS # 选择活动连接最少的从节点[^4] ``` #### 二、MaxScale 与 MariaDB 连接原理 ##### 核心架构 ```mermaid graph LR A[应用服务] -->|MySQL协议| B(MaxScale) B --> C{路由决策} C -->|写操作| D[Master] C -->|读操作| E[Slave1] C -->|读操作| F[Slave2] ``` ##### 关键连接机制 1. **协议层转换** - MaxScale 同时实现 **MySQL客户端协议** (前端)和 **MySQL服务端协议** (后端) - 应用连接 MaxScale 时： ```bash mysql -h MaxScale_IP -P 4006 -u user -p # 连接示例[^2] ``` - MaxScale 解析协议后，转换为后端 MariaDB 协议 2. **连接池管理** - 维护到每个后端节点的 **复用连接池** - 配置参数： ```ini [server1] type=server address=192.168.1.10 port=3306 connection_timeout=10s max_connections=1000 # 最大连接数[^1] ``` 3. **路由决策流程** 1. 接收 SQL 请求 2. 解析 SQL 类型： - `INSERT/UPDATE/DELETE` → 路由到主节点 - `SELECT` → 根据 `master_accept_reads` 和从节点状态路由 3. 从连接池获取物理连接 4. 转发 SQL 并返回结果 4. **故障转移机制** - 监控模块(如 `mariadbmon`)每秒检测： ```sql SHOW GLOBAL STATUS LIKE 'wsrep_ready'; # Galera集群检测[^3] ``` - 主节点故障时： - 自动切换到新主节点 - 更新路由表 - 客户端连接保持有效（需 `retry_on_failure=true`） #### 三、配置实践建议 **读写分离优化配置**： ```ini [ReadWrite-Service] router=readwritesplit servers=master,slave1,slave2 master_accept_reads=true # 允许主节点处理读请求 max_slave_connections=70% # 从节点最大连接占比 connection_keepalive=300s # 连接保活时间[^1] ``` **连接池监控命令**： ```bash maxctrl list servers --tsv | awk '{print $1, "连接数:" $6}' ``` #### 四、典型问题处理 1. **主节点过载** - 现象：主节点 CPU 利用率高 - 解决方案：设置 `master_accept_reads=false` 强制读请求到从节点 2. **读取过时数据** - 现象：从节点延迟导致读取旧数据 - 解决方案： ```ini master_accept_reads=true # 允许降级到主节点 max_slave_replication_lag=3 # 设置严格延迟阈值 ``` 3. **连接泄露** - 排查方法： ```bash maxctrl show sessions | grep 'Duration' ``` - 修复：调整 `connection_keepalive` 和 `connection_timeout`[^1] > **最佳实践**：在 Galera 集群中，建议设置 `master_accept_reads=false` 以充分利用多主写入能力，避免单点过载。 --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值