【MySQL案例】HA: GTID_MODE配置不一致

最新推荐文章于 2025-04-30 09:06:16 发布
最新推荐文章于 2025-04-30 09:06:16 发布
阅读量1.7k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： mysql 文章标签： mysql mysql5.6 gtid_mode
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/jason_asia/article/details/36422039
本文介绍了 MySQL 主从复制环境中，GTID 模式配置不一致导致的问题及解决方案。当 Master 和 Slave 的 GTID 模式配置不一致时，会导致 Slave 的 I/O 线程停止工作。文章提供了调整 Slave 配置以解决问题的方法。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

1.1.1. HA: GTID_MODE配置不一致

【环境描述】

msyql5.6.14

【报错信息】

初始状态Master和Slave都开启了enforce-gtid-consistency和gtid-mode，然后在Master上把它俩都修改成了off关闭状态，这时，Slave发生报错：

Last_IO_Error: The slave IO thread stopsbecause the master has @@GLOBAL.GTID_MODE OFF and this server has@@GLOBAL.GTID_MODE ON

【报错原因】

MySQL的Master和Slave必须同时开启或者关闭enforce-gtid-consistency和gtid-mode功能，即要保持一致。

【解决方法】

关闭Slave上的enforce-gtid-consistency和gtid-mode功能。

 

【参考资料】

gtid-mode用来设置是否开启GTID功能，如果要开启GTID功能，需要同时开启log-bin和log_slave_updates功能，另外还需要开启enforce_gtid_consistency功能。gtid_mode参数可以设置为on、off、upgrade_step_1、upgrade_step_2四种值，其中upgrade_step_1和upgrade_step_2是给将来mysql可能的新功能预留的，对当前的myql没有任何意义。同时，mysql建议在mysql_upgrade的时候，关闭gtid_mode功能和enforce_gtid_consistency功能，因为Mysql在upgrade期间可能会操作非事务的MyISAM存储引擎表，会引起报错。

续：MySQL的gtid模式
m0_64431500的博客
08-27 1348
为什么要启用gtid?master端和slave端有延迟。
海山数据库(He3DB)技术分享：海山MySQL 5.7版本GTID丢失问题分析及解决方案
于巍，花名漠雪，移动云数据库技术委员会主任，海山数据库研发负责人，PG中文社区常委，PG中文社区海外联络人。15年数据库内核研发经验，4年美国、以色列等海外研发经历，华为GaussDB、阿里云PolarDB、移动云He3DB等核心架构
07-26 453
本文将从源码层面分析MySQL 5.7因异常重启导致整个binlong中GTID丢失问题，并逐步梳理出MySQL 5.7中GTID持久化和初始化的过程。本问题的复现步骤、产生的原因、修复方案均以BUG和patch的方式反馈给了社区，percona社区已经在其5.7版本中merge了我们贡献的patch代码。
配置mysql 主主模式 GTID
JavaOpsPro的博客
10-29 2126
本文详细介绍了配置 MySQL 主主模式 GTID 的过程，包括前提条件、修改 my.cnf 文件（分别针对主 1 和主 2 给出具体配置内容）、配置主从关系（双向配置）、验证配置效果以及同步问题排查与恢复方法（如查看同步状态、判断数据一致性与延迟、过滤常见错误、处理同步失败的多种情况）。通过这些步骤，能够帮助读者理解并实现 MySQL 主主模式 GTID 的配置，同时在遇到同步问题时提供相应的解决思路，适用于需要进行 MySQL 高可用配置及管理的技术人员。
MySQL 的 GTID （全局事务标识符）详细介绍
weixin_57024726的博客
04-30 982
MySQL的GTIDMySQL的uuid是 MySQL 数据库服务器在第一次初始化时生成的。这个 UUID（Universally Unique Identifier）是一个全局唯一的标识符，用于唯一标识 MySQL 数据库服务器实例。通常存储在 MySQL 数据目录下的 auto.cnf文件中。
MySQL Replication之GTID MODE
老叶茶馆
06-07 549
*GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。GTID概述MySQL5.6 在原有主从复制的基础上增加了一个新的复制方式，即基于GTID的复制方式，它由UUID和事务ID两个部分组成，具有如下特点：GTID事务是全局唯一性的，并且一个事务对应一个GTID值。一个GTID值在同一个MySQL实例上只会执行一次。GTID相较与传统复制的优势主...
MySQL复制技术方案——GTID复制配置
JC的博客
01-03 2336
如何跳过一个GTID在复制中，偶尔会遇到主键冲突或从库找不到该条记录等错误。那么如何解决呢?在传统的复制模式中，经常通过设置 sql_slave_skip_counter参数跳过一个事件，如下。但是在GTID模式中，如果继续执行上述操作，就会有如下错误产生。在GTID模式的复制情况下，如果SLAVE发生错误，则可以通过跳过该事务的方式恢复主从复制，如图13.1所示。从图13.1中可以看出，出错事务的Binlog文件为mysql-bin.000003，end_log_pos为426，其开始位置为194。
MySQL主从不一致问题相关处理
企业实战系列集 ●●● https://ximenjianxue.blog.youkuaiyun.com
09-26 1万+
某业务采取mysql的主从架构，但因为存储的问题，导致备库一直无法存储，数据同步一致性问题一直也未恢复，某次安全检查要求完成主备倒换演练，必须限期恢复主备，但是在恢复过程中，同步显示正常一段时间后，便会出现sql线程异常，主备数据不一致导致的同步错误情况。主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。根据上面的NR行数，查看附近的行，定位数据不一致的地方，后续手动补全。
MySQL5.6 - 基于GTID复制模式搭建主从复制、故障模拟、问题解决！
weixin_34194359的博客
05-20 1396
写在前面：本文主要讲解，GTID复制模式的参数配置、搭建过程中遇到的一些问题及其解决方法；针对一些常见问题场景，进行故障模拟，然后解决。如果对GTID的其他方面的知识想要做个了解，如：GTID优点、使用限制、实现原理等，可以移步到笔者的另一篇文章 GTID模式介绍环境：MySQL5.6.16版本CentOS release 6.5主从参数配置：对于GTID参数的含义，请参阅M...
MHA架构MySQL迁移执行masterha_check_repl报错处理一则
AkenGan的博客
10-17 937
朋友在MHA架构MySQL异机迁移过程中发现执行MHA的 masterha_check_repl 检测无法通过，报错服务不存在： [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln188] There is no alive server. We can't do failover 详细的信息如下： [mysql@mysq...
MySQL HA方案:MMM,MHA,Orchestrator,MGR
dustzhu的博客
07-19 2121
一.前言 MySQL常用的HA方案：MMM,MHA；前者已经很多年没有更新版本了，不推荐使用，MHA也有多年未更新了,5.7及以上版本也不推荐使用，一些新特性要么不支持，要么会触发BUG；综合看Orchestrator相对来说算是目前比较好的解决方案。 二.简介 Orchestrator是使用go语言编写的MySQL高可用性和复制拓扑管理工具，支持复制拓扑结构的调整，自动故障转移和手动主从切换等。后端数据库用MySQL或SQLite存储元数据，并提供Web界面展示MySQL复制的拓扑关系及状态，通过Web可
十七：主库的DUMP线程（笔记）
cri5768的博客
07-09 1185
本文是我《深入理解MySQL主从原理》 系列的笔记部分，具体可以点击：ttps://j.youzan.com/yEY_Xi ...
ClickHouse引擎之-MaterializeMYSQL
liuwei0376的专栏
07-21 1337
使用MaterializeMySQL存储引擎，需要一下先决条件1.支持mysql库级别的数据同步，暂不支持表级别的。2.MySQL库映射到clickhouse中自动创建为ReplacingMergeTree引擎的表3.支持全量和增量同步，首次创建数据库引擎时进行一次全量复制，之后通过监控binlog变化进行增量数据同步4.支持的MySQL版本5.支持的操作insert，update，delete，alter，create，drop，truncate等大部分DDL操作。......
解决mysql二进制日志恢复数据报错：@@GLOBAL.GTID_MODE = OFF.
weixin_34375233的博客
01-05 1954
解决mysql利用二进制日志恢复数据报错：ERROR 1781 (HY000) at line 16: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.工作中，运用二进制日志，帮开发的同事恢复数据时，出现了报错告警：[root@localhosttmp]#mysq...
GTID的常见错误和处理方法
热门推荐
cug_jiang126com的专栏
11-20 2万+
主从同步错误 mysql> stop slave; Query OK, 0 rows affected (0.00 sec)   mysql> set global sql_slave_skip_counter=1; ERROR 1858 (HY000): sql_slave_skip_counter can not be set when theserver is running wi
Clickhouse MaterializeMySQL 数据库引擎
vkingnew 的技术博客
09-27 3144
在Clickhouse 20.8.2.3 版本中新增一个数据库引擎，将clickhouse模拟为MySQL的从库，可以通过mysql的binlog实时的接收来自mysql的数据并在clickhouse物化,极大提升了数仓的查询性能和数据同步的时效性。同时增加了获取mysql数据的方式，除了mysql协议和mysql函数和mysql表引擎，clickhouse可以作为mysql的从库。 ClickHouse can work as MySQL replica - it is implemented by
ClickHouse MaterializeMySQL引擎
我思，顾我在
06-30 1455
MySQL 的用户群体很大，为了能够增强数据的实时性，很多解决方案会利用 binlog 将 数据写入到 ClickHouse。想要实时监听 binlog 事件，可以采用MaterializeMySQL引擎
MYSQL --延时同步-恢复数据
Jerry00713的博客
07-29 2413
情况一：不做gtid 1、主、备机关闭gtid，,如果主备有一个开启，有一个未开启，做主备同步时候会报错： The replication receiver thread cannot start because the master has GTID_MODE = ON and this server has GTID_MODE = OFF. 2、主、备机开启autocommit=0，取消自动提交 临时生效： set @@autocommit=0 （0为关闭状态，1为开启状态） 永久生效...
如何查看mysql的gtid_mode_配置MHA开启主从同步的时候会提示从库gtid_mode为ON的状态...
hws_0910的博客
07-20 1033
通过MHA从库查看show slave status \G;会提示如下报错！
Slave_IO_State: Connecting to master Master_Host: mysql-master Master_User: slave Master_Port: 3306 Connect_Retry: 30 Master_Log_File: mysql-master-bin.000003 Read_Master_Log_Pos: 2412 Relay_Log_File: mysql-relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: mysql-master-bin.000003 Slave_IO_Running: Connecting 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: 2412 Relay_Log_Space: 156 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: NULL 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: 0 Master_UUID: 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: Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: Master_public_key_path: Get_master_public_key: 0 Network_Namespace:
最新发布
07-16
<think>我们正在排查MySQL主从复制中Slave_IO_Running状态为Connecting的问题。这个状态表示从库的I/O线程正在尝试连接主库但尚未成功。以下是完整的排查步骤： ### 1. 检查主从基础配置 - **主库IP/域名**：确保从库配置的主库地址正确（`MASTER_HOST`） - **端口**：主库防火墙是否开放复制端口（默认3306） - **复制账号**：检查复制账号权限及密码 - **主库`server_id`**：必须唯一 **验证命令**： ```sql SHOW SLAVE STATUS\G ``` 关注字段： ``` Master_Host: 192.168.1.100 Master_User: repl_user Master_Port: 3306 Connect_Retry: 60 ``` ### 2. 网络连通性测试 在从库执行： ```bash # 测试TCP连接 telnet <主库IP> 3306 # 或使用nc nc -zv <主库IP> 3306 ``` > 若连接失败，检查： > - 主库防火墙：`sudo ufw status`（Ubuntu） > - 云服务器安全组规则 > - 网络路由（尤其跨机房/VPC场景） ### 3. 复制账号权限验证 登录主库检查复制账号权限： ```sql SHOW GRANTS FOR 'repl_user'@'从库IP'; ``` 必需权限： ```sql GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl_user'@'从库IP'; ``` ### 4. 主库状态检查 登录主库查看： ```sql SHOW MASTER STATUS; ``` 确保从库连接的`MASTER_LOG_FILE`和`MASTER_LOG_POS`在有效范围内（新搭建复制时需特别注意） ### 5. 错误日志分析 - **从库错误日志**： ```bash tail -f /var/log/mysql/error.log ``` 常见错误： ``` [ERROR] Slave I/O: error connecting to master 'repl_user@主库IP:3306' - retry-time: 60 retries: 1, Error_code: 2003 ``` ### 6. 主库连接限制检查 - 主库`max_connections`是否已满 - 主库`max_user_connections`是否限制复制账号 ### 7. SSL/TLS配置问题 若主从启用SSL： ```sql SHOW SLAVE STATUS\G ``` 检查： ``` Master_SSL_Allowed: Yes Master_SSL_CA_File: /path/to/ca.pem ``` > 证书路径需在从库存在且可读 ### 8. 跳过DNS解析 在从库`my.cnf`添加： ```ini [mysqld] skip-name-resolve ``` 重启MySQL服务后重试 ### 9. 临时停止IO线程 若之前有未完成的复制操作： ```sql STOP SLAVE IO_THREAD; -- 引用[1]中提到需先停止IO线程 START SLAVE; ``` ### 故障排查流程图 ```mermaid graph TD A[Slave_IO_Running=Connecting] --> B{网络连通性} B -->|失败| C[检查防火墙/路由] B -->|成功| D{复制账号权限} D -->|不足| E[主库授权REPLICATION SLAVE] D -->|正常| F{主库SHOW MASTER STATUS} F -->|无输出| G[主库未启用二进制日志] F -->|正常| H{错误日志分析} H -->|SSL错误| I[检查证书路径] H -->|连接数超限| J[调整max_connections] H -->|其他错误| K[根据错误码处理] ``` ### 关键命令汇总 | 步骤 | 命令 | |------|------| | 检查复制状态 | `SHOW SLAVE STATUS\G` | | 测试主库端口 | `nc -zv 主库IP 3306` | | 主库授权复制账号 | `GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'从库IP' IDENTIFIED BY '密码'` | | 重置复制线程 | `STOP SLAVE; START SLAVE;` | > **注意**：修改配置后需重启MySQL服务：`sudo systemctl restart mysql` §§相关问题§§ 1. 如何修复MySQL主从复制错误1236？ 2. 主从复制延迟持续增长该如何处理？ 3. MySQL多源复制如何配置？ 4. 如何监控MySQL复制状态？ 5. 如何配置安全的复制账号？</think>### MySQL Slave_IO_Running 状态为 "Connecting" 的排查指南 当 MySQL 主从复制中 Slave_IO_Running 状态显示为 "Connecting" 时，表示从库的 I/O 线程正在尝试连接主库但尚未成功。以下是系统化的排查步骤： --- #### 1. **检查基础配置** ```sql SHOW SLAVE STATUS\G ``` 关注以下字段： - `Master_Host`：主库 IP 是否正确 - `Master_User`：复制账号是否存在 - `Master_Port`：端口是否匹配主库 - `Master_SSL_Allowed`：SSL 配置是否一致 > **关键点**：确保从库配置的 IP、端口、账号与主库一致[^2]。 --- #### 2. **网络连通性测试** 在从库执行： ```bash # 测试主库端口连通性 telnet <Master_IP> 3306 # 或使用网络工具 nc -zv <Master_IP> 3306 ``` - 若连接失败，检查： - 防火墙规则（主/从双方） - 云服务器安全组 - 路由表/NAT 配置 --- #### 3. **验证复制账号权限** 登录主库检查账号权限： ```sql SHOW GRANTS FOR 'repl_user'@'从库IP'; ``` 必需权限： ```sql GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl_user'@'从库IP'; ``` --- #### 4. **检查主库状态** 在主库执行： ```sql SHOW MASTER STATUS; ``` 确保从库连接的 `MASTER_LOG_FILE` 和 `MASTER_LOG_POS` 在有效范围内。 --- #### 5. **分析错误日志** 查看从库错误日志： ```bash tail -f /var/log/mysql/error.log ``` 常见错误示例： ``` [ERROR] Slave I/O: error connecting to master 'repl_user@主库IP:3306' - retry-time: 60 retries: 1, Error_code: 2003 ``` - **Error_code 2003**：网络连接问题 - **Error_code 1045**：账号认证失败 - **Error_code 2061**：SSL 配置错误 --- #### 6. **特殊场景处理** - **SSL 连接问题**： 若主库启用 SSL，需确保从库有正确的证书： ```sql CHANGE MASTER TO MASTER_SSL=1, MASTER_SSL_CA='/path/to/ca.pem', MASTER_SSL_CERT='/path/to/client-cert.pem', MASTER_SSL_KEY='/path/to/client-key.pem'; ``` - **多源复制冲突**： 检查 `REQUIRE_TABLE_PRIMARY_KEY_CHECK` 设置是否一致[^2] - **IO 线程阻塞**： 按引用[1]建议停止 IO 线程： ```sql STOP SLAVE IO_THREAD; -- 先停止线程 START SLAVE; -- 重新启动 ``` --- #### 7. **防火墙与 SELinux** ```bash # 检查防火墙 sudo ufw status # 临时开放端口 sudo ufw allow 3306 # 检查 SELinux sudo sestatus sudo setsebool -P mysqld_connect_any 1 ``` --- ### 故障排查流程图 ```mermaid graph TD A[Slave_IO_Running=Connecting] --> B{网络连通性} B -->|失败| C[检查防火墙/路由] B -->|成功| D{复制账号权限} D -->|不足| E[主库授权REPLICATION SLAVE] D -->|正常| F{主库SHOW MASTER STATUS} F -->|无输出| G[主库未启用二进制日志] F -->|正常| H{错误日志分析} H -->|SSL错误| I[配置证书] H -->|认证失败| J[重置复制密码] H -->|其他错误| K[根据错误码处理] ``` --- ### 修复后验证 ```sql STOP SLAVE; START SLAVE; SHOW SLAVE STATUS\G ``` 期望输出： ``` Slave_IO_Running: Yes Slave_SQL_Running: Yes Last_IO_Error: ``` > **注意**：修改配置后需重启 MySQL 服务：`sudo systemctl restart mysql`
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值