GTID复制异常的解决步骤

GTID复制异常的解决方法

主从复制使用的是GTID方式。

下面这个环境,出问题的原因不提了。

下面是从库的截图:

Retrieved_Gtid_Set:167b4197-09fa-11e7-993f-000c296a2c0d:1-6

Executed_Gtid_Set:167b4197-09fa-11e7-993f-000c296a2c0d:1-5,

261aafbc-0ace-11e7-9ea6-000c298f384b:1-305

第一行表示收到的事务,第二行表示已经执行完的事务。也就是说执行到Retrieved_Gtid_Set时候发生错误了。因此,我们直接单单跳过这个事务即可。

在从库执行修复:

step1、修补数据

(我当时这个情况是当时在主库关闭binlog然后执行了一个alter操作,但是忘记在从库执行这个alter操作,导致复制异常的。复制异常后,我在从库补了这个alter操作,但是实际上数据是否一致需要自己对比主和从在alter操作后那段时间内的binlog记录)

step2、重新配置主从

SET gtid_next=‘167b4197-09fa-11e7-993f-000c296a2c0d:6‘;    # 跳过Retrieved_Gtid_Set这个最后的事务就行了

BEGIN;

COMMIT;

SETgtid_next=‘automatic‘;

startslave;

showslave status\G

时间: 2024-10-07 05:56:02

GTID复制异常的解决步骤的相关文章

MySQL 5.7基于GTID复制的常见问题和修复步骤(二)

[问题二] 有一个集群(MySQL5.7.23)切换后复制slave报1236,其实是不小心在slave上执行了事务导致 Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containin

mariadb10.x启用gtid复制时提示mysql.gtid_slave_pos找不到的解决方案

mariadb10.x安装方式为yum时,当启用gtid复制方式后,一直提示mysql.gtid_slave_pos找不到的解决方案 造成的原因不详 解决方案:/usr/share/mysql/mysql_system_tables.sql是创建系统表的脚本 找到innodb_table_stats,innodb_index_stats,gtid_slave_pos表的创建方式 innodb_table_stats表的创建语句: SET FOREIGN_KEY_CHECKS=0; DROP TA

mysql 5.6 的新特性:GTID 复制

mysql 5.6 的新特性: MySQL 5.6 包含了一个复制的新功能,enabling DevOps teams to reliably scale-out their MySQL infrastructure across commodity hardware, rel="nofollow">Global Transaction Identifiers (GTIDs)功能, 为了解决以下问题: -能够无缝的故障恢复和master与slave的切换 -能把slave指向新的

切换-5.7-传统复制切换成GTID复制

1.基本环境:   Master Slave MySQL版本 MySQL-5.7.16-X86_64 MySQL-5.7.16-X86_64 IP 192.168.56.156 192.168.56.157 Port 3306 3306 2.在线切换 1.master和slave执行 mysql>set @@global.enforce_gtid_consistency = warn; mysql>set @@global.enforce_gtid_consistency = on; mysq

MySQL5.7.16 gtid复制

<基础环境准备:> 首先安装两台MySQL5.7.16数据库,安装如下步骤即可: 一.系统环境准备: ①:系统yum源配置: [linux] name=linux hae baseurl=file:///media/ gpgcheck=1 gpgkey=file:///media/RPM-GPG-KEY-redhat-release ②:挂载Linux7.1系统盘安装必要的软件 yum -y install gcc* gcc-c++ ncurses ncurses-devel cmake bi

MariaDB 10 Slave Crash-Safe需转为GTID复制模式

之前写了一篇<MySQL5.6 crash-safe replication> ,但在Mariadb10.0.X和10.1.X上不支持relay_log_info_repository = TABLE参数,官网建议用GTID复制模式代替传统复制模式,传统复制模式是不支持Slave Crash-Safe的. 在mysql库下,会有一张gtid_slave_pos表(在安装初始化时,就已经是innodb引擎) START TRANSACTION; -- Statement 1 -- ... -- 

MySQL5.7不停业务将传统复制变更为GTID复制

由于GTID的优势,我们需要将传统基于file-pos的复制更改为基于GTID的复制,如何在线变更成为我们关心的一个点,如下为具体的方法: 目前我们有一个传统复制下的M-S结构: port 3301 master port 3302 slave master上(3301): [zejin] 3301>select * from t_users; +----+------+ | id | name | +----+------+ | 1 | hao | | 2 | zhou | +----+---

MySQL复制异常大扫盲:快速溯源与排查错误全解

MySQL复制异常大扫盲:快速溯源与排查错误全解https://mp.weixin.qq.com/s/0Ic8BnUokyOj7m1YOrk1tA 作者介绍王松磊,现任职于UCloud,从事MySQL数据库内核研发工作,主要负责UCloud云数据库UDB的内核故障排查工作以及数据库新特性的研发工作. 复制作为MySQL原生的数据同步功能,在MySQL高可用架构中起着至关重要的作用.本文梳理了MySQL高可用产品UDB在日常运维中遇到的复制问题,并总结了当复制发生异常时,排查复制异常的方法. 一.

MHA集群(gtid复制)和vip漂移

在上一片博客中,讲述了怎么去配置MHA架构!这片博客不再细说,只说明其中MySQL主从搭建,这里使用的是gtid加上半同步复制! 步骤与上一片博客一样,不同之处在于MySQL主从的搭建!详细的gtid搭建过程https://www.cnblogs.com/wxzhe/p/10055154.html 上一片博客中,把MySQL主从的搭建由filename和pos的过程改变为如下的基于gtid的过程就可以,因此不再详细说明,只展示gtid的搭建! 四台服务器分配如下: MHA管理节点: 10.0.1