Debezium报错处理系列之第112篇：Cannot replicate because the master purged required binary logs. Replicate the

已于 2024-07-08 18:06:39 修改
阅读量104 收藏
点赞数
分类专栏： debezium 文章标签： Debezium报错处理系列 Cannot replicate
于 2024-07-05 11:43:03 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhengzaifeidelushang/article/details/140204146
版权
debezium 专栏收录该内容
333 篇文章 307 订阅 ¥99.90 ¥299.90
订阅专栏

Debezium报错处理系列之第112篇：ERROR Producer failure io.debezium.DebeziumException: Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period. The GTID set sent by the slave is '19f5cc06-47a4-11ed-be66-0c42a1399368:1-253785170,d55b52f2-47a3-11ed-bbe6-0c42a1367010:1-595011873', and the missing transactions are 'd55b52f2-47a3-11ed-bbe6-0c42a1367010:595011874-727575473' Error code: 1236; SQLSTATE: HY000.

Debezium从入门到精通系列之：研究Debezium技术遇到的各种错误解决方法汇总：

在这里插入图片描述
更多Debezium技术请参考博主Debezium技术专栏：

一、完整报错

  • [2024-06-27 15:20:51,909] ERROR Producer failure (io.debezium.pipeline.ErrorHandler)
    io.debezium.DebeziumException: Cannot replicate because the master purged required binary logs. Replicate the missing transact
了解本专栏 订阅专栏 解锁全文
快乐骑行^_^
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
订阅专栏
Debezium报错处理系列之第110篇： ERROR Error during binlog processing.Access denied
zhengzaifeidelushang的博客
07-05 232
Debezium报错处理系列之第110篇：ERROR Error during binlog processing. Last offset stored = null, binlog reader near position = /4 Access denied; you need at least one of the REPLICATION SLAVE privilege for this operation
mysql主从复制报错：the master has purged binary logs containing GTIDs that the slave requires
雅冰石的专栏
03-13 6847
方法一具体案例： 拓扑架构为A->B->C，假如从库C的复制报错了，原因：需要的binlog在B上被purge掉了，而A上的binlog完整无损。 解决办法：将C指向A进行复制。 在C上执行： stop slave; change master to master_host='A的IP',master_port=A的端口号,MASTER_USER='RepUser',MASTE......
Debezium报错处理系列三：Access denied； you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s)
zhengzaifeidelushang的博客
12-29 5725
Debezium报错处理系列三：Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) 一、debezium报错 Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s)) 二、报错产生原因 数据库账号没有复制binlog权限 三、解决方法 数据库账号添加权限 给账号opt
【Flink】Error during binlog processing last offset stored = null binglog reader near position
九师兄
11-07 2228
1.概述 flink 读取mysql binglog的时候报错如下 Error during binlog processing last offset stored = null binglog reader near position 对应的代码如下 引入如下 原因如下 [呲牙] mysql binlog 日志被提前删除了？感觉像是找不到需要的 binlog 日志呢 查看log如下 这里可以看 估计是过期太快，这里可以设置 读取失败 应该是这个原因 https://stackoverf
mysql gitd 数据结构同步失败_MySQL案例-GTID同步失败:master has purged binary logs
weixin_32952295的博客
01-19 466
GTID工具联动:http://blog.itpub.net/29510932/viewspace-1736132/-------------------------------------------------------------------------------------------------正文-------------------------------------------...
Received error packet: errno = 1236, sqlstate = HY000 errmsg = Slave can not handle replication even
arkblue的专栏
03-15 7928
使用版本是5.6.22 异常： Caused by: java.io.IOException: Received error packet: errno = 1236, sqlstate = HY000 errmsg = Slave can not handle replication events with the checksum that master is configured
MySQL的半同步复制+多级复制（让slave扮演其它slave的master）
qq_45225437的博客
08-19 7242
文章目录一、半同步复制前言：1. master配置2. slave配置3. 测试验证二、发送复制事件到其它slave前言：1. master(a)与slave(b)的配置2. master(b)与slave(3)的配置3. 测试验证4. 错误问题 一、半同步复制 前言： 两台服务器已经实现了主从异步复制 半同步复制是在设定了GTID的基础上配置的； servera为主服务器，IP为192.168.1.136； serverb为从服务器，IP为192.168.1.116； 1. master配置 [root@
一次主库binlog删除一起的mgr集群从库不停recoving
qq_39570637的博客
09-30 671
一次主库binlog删除一起的mgr集群从库不停recoving 问题描述： 三个用docker容器部署的mysql实例，组建了一个mgr集群 在重启docker容器后，进行压测。此时只三台机器都未加入mysql group replication 对master进行性能压测，构建测试库 过程中出现问题：数据盘写满了 ----drop未成功都testdb，删除多余binlog binlog序号为1->11 开始prepare run 直到全部压测完毕 先简单解释下磁盘满的原因：我的数据盘是50G，在压
MySQL全备+binlog恢复方法之伪装master
lmrylll的博客
06-21 490
发现又多了个61cfd125-a0f2-11e8-b8bc-000c2969aede:1-2，不太清楚是哪个gtid，查看3307的uuid也不是这个，为了影响实验效果，下面的gtid_purged也把这个加入进去了。查看备份的binlog位置为959b9f31-75ef-11e8-97de-000c2969aede:1-61970,d20b918a-96c9-11e8-aae4-000c2969aede:1-15。先备份3309的datadir，并清除里面的文件。
The MySQL 8.0.0 Milestone Release is available
帅的数说
09-20 1810
http://mysqlserverteam.com/the-mysql-8-0-0-milestone-release-is-available/ The MySQL Development team is happy to announce our 8.0.0 development milestone release (DMR), now available for downloa
mysql binlog出错_MySQL mysqlbinlog 读取mysql-bin文件出错
weixin_42405503的博客
01-27 980
问题mysqlbinlog -v -v --base64-output=DECODE-ROWS mysql-bin.000166 | lessERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 111, event_type: 35/*!50530 SET @@...
Debezium报错处理系列之九十：使用debezium消息过滤filter报错ClassNotFoundException: io.debezium.DebeziumException
最新发布
zhengzaifeidelushang的博客
08-07 388
Debezium报错处理系列之九十：使用debezium消息过滤filter报错ClassNotFoundException: io.debezium.DebeziumException
Debezium for MySQL解析binlog报错
码农无双的博客
08-07 5807
运行在Kafka Connect 分布式worker上的debezium for mysql connector报错： {"name":"debezium-mysql-source-dev","connector":{"state":"RUNNING","worker_id":&q
阿里云RDS Mysql 8.0 与本地主从同步
月色无痕的专栏
10-11 2789
阿里云RDS Mysql8 本地主从同步
解析mysql binlog 报错：ErrorPacket[packetMarker=255,errorCode=1236,slash=#,sqlState=HY000,errorMessage=bo
linux_ja的专栏
01-12 3335
在用java的openpaser解析mysql binlog报错如下异常： ErrorPacket[packetMarker=255,errorCode=1236,slash=#,sqlState=HY000,errorMessage=bogus data in log event] 解决办法：因为读取mysql master的binlog的时候，setBinlogPosition
Mysql主从库不同步1236错误：could not find first log file name in binary....
热门推荐
Eric专栏
07-13 1万+
Mysql主从库不同步1236错误：could not find first log file name in binary log index file错误是主从的一个日志问题，我们只要简单的配置一下即可解决
Debezium指定binlog位置初始化异常排查修复
yyoc97的专栏
05-17 3465
文章目录异常现象如何复现排查定位线索定位 异常现象 最近项目需要使用Debezium指定binlog位置读取数据，当配置FileDatabaseHistory 保存offset就会出现无法识别schema异常。 14:52:18.237 [blc-9.135.12.10:3307] ERROR io.debezium.connector.mysql.MySqlStreamingChangeEventSource - Encountered change event 'Event{header=EventHe
报错了 Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).
06-07
这个错误是因为你的主从服务器的 server-id 相同导致的，解决方法有两个： 1. 修改从服务器的 server-id 在从服务器上修改 my.cnf 文件，将 server-id 修改为一个不同于主服务器的值，然后重启 MySQL 服务器。 比如在 my.cnf 文件中加入以下内容： ``` [mysqld] server-id=2 ``` 2. 使用 --replicate-same-server-id 参数 在启动从服务器的时候，使用 --replicate-same-server-id 参数，这个参数会让从服务器使用和主服务器相同的 server-id，但是需要注意这种方式有一定的风险，可能会导致数据不一致。 比如启动从服务器的命令如下： ``` mysqld --replicate-same-server-id ``` 需要注意的是，使用 --replicate-same-server-id 参数可能会导致数据不一致，因此在使用之前需要仔细阅读 MySQL 官方文档，了解其使用方法和注意事项。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

快乐骑行^_^

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值