mysql 大事务 binlog_执行大事务时出现binlog解析失败

现象:Err: table id 267724937: invalid table id, no corresponding table map event"

[2019/06/25 18:04:19] [error] binlogsyncer.go:639 connection was bad

[2019/06/25 18:04:20] [info] binlogsyncer.go:581 begin to re-sync from (mysql-bin.003014, 923556481)

[2019/06/25 18:04:20] [info] binlogsyncer.go:211 register slave for master server

[2019/06/25 18:04:20] [error] binlogsyncer.go:239 kill connection 2818644069 error ERROR 1094 (HY000): Unknown thread id: 2818644069

[2019/06/25 18:04:20] [info] binlogsyncer.go:245 kill last connection id 2818644069

[2019/06/25 18:04:20] [info] binlogsyncer.go:731 rotate to (mysql-bin.003014, 923556481)

[2019/06/25 18:15:41] [info] sync.go:66 rotate binlog to (mysql-bin.003014, 923556481)

当binlog同步过程中出现网络错误导致重连resync的时候,mysql会向canal发送rorate 事件更新当前的Pos. 如果此时重启了canal。canal将从当前保存的这个位置开始继续同步。但是由于当前这条binlog所对应的table id获取不到,会出现no corre

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
GTID(Global Transaction ID)是MySQL 5.6版本引入的一种全局事务标识机制,用于在主从复制和数据恢复等场景下精确追踪事务执行情况。在GTID模式下,每个事务都会分配一个全局唯一的ID,由GTID组成,用于标识该事务的唯一性。 在MySQL中,有两种类型的GTID:基于二进制日志的GTID(gtid_binlog)和基于事务的GTID(gtid_current_pos)。其中,基于二进制日志的GTID是默认启用的。它由两部分组成:server_uuid和transaction_id。其中,server_uuid是MySQL实例的唯一标识符,transaction_id是一个递增的整数,用于标识每个事务。 基于GTID的数据恢复可以通过以下步骤实现: 1. 确认目标数据库的GTID模式,以及需要恢复的数据起始和结束的GTID范围。 2. 在备份服器上创建一个与目标数据库相同的空数据库。 3. 将备份服器上的二进制日志文件和索引文件拷贝到目标服器上,并将它们放置在与备份服器相同的目录下。 4. 在目标服器上使用mysqlbinlog命令解析备份服器上的二进制日志文件,并过滤出需要恢复的数据,生成一个SQL文件。 5. 在目标服器上执行步骤4生成的SQL文件,恢复数据。 在执行步骤4,可以使用mysqlbinlog命令的--start-position和--stop-position参数指定需要恢复的二进制日志文件的起始和结束位置,也可以使用--start-datetime和--stop-datetime参数指定需要恢复的间范围。 需要注意的是,在基于GTID的数据恢复中,必须确保目标服器和备份服器的server_uuid相同,否则会导致GTID不一致,无法进行数据恢复。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值