mysql 5.7 基于GTID 主从同步的1236故障处理（其它事务故障等同）

登录从库

stop slave;

查看执行事务

show slave status\G

Retrieved_Gtid_Set: ee3bdb44-f6a1-11e7-b194-005056a35fd4:21315405-51853406
Executed_Gtid_Set: ee3bdb44-f6a1-11e7-b194-005056a35fd4:1-51853406

注：Retrieved_Gtid_Set 为获取主库上的事务ID

Executed_Gtid_set为正在执行的事务ID

reset master;

SET @@GLOBAL.GTID_PURGED =‘ ee3bdb44-f6a1-11e7-b194-005056a35fd4:51853406‘

start slave;

show slave status\G,查看同步是否正常

如果错误很多。建议重新作从库。

原文地址：https://www.cnblogs.com/net2817/p/9340786.html

时间： 2024-07-30 01:31:47

mysql 5.7 基于GTID 主从同步的1236故障处理（其它事务故障等同）的相关文章

解决mysql开启GTID主从同步出现1236错误问题

最近遇到mysql开启gtid做复制时,从库出现1236错误,导致同步无法进行,本文就这问题记录下处理步骤,有关gtid知识在这里不做介绍,mysql版本为5.7.16. 一.错误原因分析 错误信息如下: Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER

Innobackup mysql 多实例环境搭建主从同步

Innobackup mysql 多实例环境搭建主从同步 该实验是在mysql多实例环境下做的:如果需要部署 mysql 多实例环境,则移步: mysql 多实例案例实战: http://blog.csdn.net/wanglei_storage/article/details/49305239 mysql 的主从搭建大家有很多种方式,传统的 mysqldump 方式是很多人的选择之一.但对于较大的数据库则该方式并非理想的选择.使用 Xtrabackup 可以快速轻松的构建 mysql 主从架构

CentOS6.8下MySQL5.6.40基于GTID主从及多线程复制

大纲 一 GTID简介 二 环境准备 三 数据库的安装 四 基于GTID主从配置步骤 五 验证GTID复制功能 一 GTID简介 GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号.GTID实际上是由UUID+TID组成的.其中UUID是一个MySQL实例的唯一标识.TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增.下面是一个GTID的具体形式3E11FA47-71CA-11E1-9E33-C80AA9429562:23更详

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

搭建MySQL代理服务器实现读写分离+主从同步

实验需求: 1.配置2台MySQL服务器(192.168.100.2,192.168.100.3)+1台代理服务器(192.168.100.1),实现MySQL代理的读写分离. 2.用户只需要访问MySQL代理服务器,实际的SQL查询.写入操作交给后台的2台MySQL服务器来完成. 3.2台MySQL服务器实现主从同步,其中Master服务器允许SQL查询.写入,Slave服务器只允许SQL查询. 一 .MASTER数据库服务器(192.168.100.2)的配置 1.安装软件包(本实验采用My

MySQL的读写分离与主从同步数据一致性

有没有做MySQL读写分离?如何实现mysql的读写分离?MySQL主从复制原理的是啥?如何解决mysql主从同步的延时问题? 高并发这个阶段,那肯定是需要做读写分离的,啥意思?因为实际上大部分的互联网公司,一些网站,或者是app,其实都是读多写少.所以针对这个情况,就是写一个主库,但是主库挂多个从库,然后从多个从库来读,那不就可以支撑更高的读并发压力了吗? (1)如何实现mysql的读写分离? 其实很简单,就是基于主从复制架构,简单来说,就搞一个主库,挂多个从库,然后我们就单单只是写主库,然后

MySQL面试题中：主从同步的原理

主从同步的原理:1.主库上面有一个IO线程,从库上有一个IO线程和一个SQL线程,从库中的IO线程负责从主库读取binlog,并写入从库的中继日志:SQL线程负责读取并执行中继日志中的binlog,转换sql语句后应用数据库汇总2.通信是:  从库的IO线程给主库发送同步请求,请求中包含用户名密码和binlog的文件名,pos点  主库验证成功后,发送从库需要的binlog日志文件,和binlog文件中pos点  从库的IO线程接收后,把binlog文件转存到中继日志的relay-log文件,并

mysql用户权限分配及主从同步复制

赋予wgdp用户查询权限: grant select on wg_dp.* to 'wgdp'@'%' IDENTIFIED BY 'weigou123'; grant all privileges on *.* to 'yangchao'@'%' IDENTIFIED BY 'weigou123' 查询mysql其他用户权限: show grants for wgdp; 取消wgdp用户权限: revoke all on *.* from wgdp; PS:grant, revoke 用户权限

MySQL主从同步报错故障处理记录

前言 在发生故障切换后,经常遇到的问题就是同步报错,下面是最近收集的报错信息. 记录删除失败 在master上删除一条记录,而slave上找不到 Last_SQL_Error: Could not execute Delete_rows event on table hcy.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysq