FAQ系列 | 不同复制模式下,如何忽略某些binlog事件

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: FAQ系列 | 不同复制模式下,如何忽略某些binlog事件

导读

在MySQL复制中,如何忽略slave节点上发生的主键冲突、数据不存在等错误。

在MySQL复制中,如果slave节点上遇到错误,比如数据不存在或者主键冲突等错误时,想要忽略这些错误,可以采用以下几种方法:

1、未启用GTID模式时

只需通过设定 SQL_SLAVE_SKIP_COUNTER 的值,即可忽略一些复制事件。例如:

#需要先关闭SLAVE服务
root@imysql.com [test]> STOP SLAVE;

#忽略N个事件(event),通常一个SQL是一个事件
root@imysql.com [test]> SET SQL_SLAVE_SKIP_COUNTER=N;

#再次启动SLAVE服务
root@imysql.com [test]> START SLAVE;

2、启用GTID模式时

启用GTID,想要忽略某些错误事件就稍微麻烦一点点了。

首先,我们需要先查看当前SLAVE复制的进度:

mysql> SHOW SLAVE STATUS\G

从中看到,当前SLAVE复制的GTID进展是:

Slave_IO_Running: Yes

Slave_SQL_Running: No
Last_Errno: 1062
Last_Error: ...Duplicate...key 'PRIMARY', Error_code: 1062;...
Master_UUID: f2b6c829
Retrieved_Gtid_Set: 3a16ef7a:1-283,f2b6c829:1-33
Executed_Gtid_Set: 3a16ef7a:1-283,f2b6c829:1-31
Auto_Position: 1

备注: 为了排版样式,我把下面两个UUID进行了简写(下同)

  • f2b6c829-9c87-11e4-84e8-deadeb54b599 => f2b6c829
  • 3a16ef7a-75f5-11e4-8960-deadeb54b599 => 3a16ef7a

从上面的信息可以看到,当前从MASTER取到了1-33的事务列表,并且已执行(看Executed_Gtid_Set)到了31这个事务GTID位置,在这下一个位置(32)上发生错误。

这时候,我们需要手工调整SLAVE已清除的GTID列表 GTID_PURGED,人为通知SLAVE哪些事务已经被清除了,后续可以忽略:

root@imysql.com [test]> STOP SLAVE;
root@imysql.com [test]> RESET MASTER;
root@imysql.com [test]> SET @@GLOBAL.GTID_PURGED = "3a16ef7a:1-283,f2b6c829:1-32";
root@imysql.com [test]> START SLAVE;

上面这些命令的用意是,忽略 f2b6c829:32 这个GTID事务,下一次事务接着从 33 这个GTID开始,即可跳过上述错误。

3、无论是否启用GTID,使用pt-slave-restart工具

首先不得不说,percona toolkit工具集对DBA而言实在太方便了。pt-slave-restart工具的作用是监视某些特定的复制错误,然后忽略,并且再次启动SLAVE进程(Watch and restart MySQL replication after errors)。

简单用法示例:

#忽略所有1062错误,并再次启动SLAVE进程
[yejr@imysql.com ]# pt-slave-resetart -S./mysql.sock --error-numbers=1062

#检查到错误信息只要包含 test.yejr,就一概忽略,并再次启动 SLAVE 进程
[yejr@imysql.com ]# pt-slave-resetart -S./mysql.sock --error-text="test.yejr"

综上,我们虽然可以利用工具来快速忽略复制错误,但还是要掌握如何人为忽略复制错误的方法,在没有工具的时候也能了然于胸。

            </div>
相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
弹性计算 网络协议 容灾
PostgreSQL 时间点恢复(PITR)在异步流复制主从模式下,如何避免主备切换后PITR恢复(备库、容灾节点、只读节点)走错时间线(timeline , history , partial , restore_command , recovery.conf)
标签 PostgreSQL , 恢复 , 时间点恢复 , PITR , restore_command , recovery.conf , partial , history , 任意时间点恢复 , timeline , 时间线 背景 政治正确非常重要,对于数据库来说亦如此,一个基于流复制的HA架构的集群,如果还有一堆只读节点,当HA集群发生了主备切换后,这些只读节点能否与新的主节点保持
1807 0
|
关系型数据库 流计算 PostgreSQL
关于PostgreSQL逻辑订阅中的复制状态
关于PostgreSQL逻辑订阅中的复制状态
2671 0
|
5月前
|
存储 SQL 关系型数据库
实时计算 Flink版操作报错合集之按时间恢复时,报错:在尝试读取binlog时发现所需的binlog位置不再可用,该怎么办
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
761 0
|
3月前
|
关系型数据库 数据库 PostgreSQL
[postgres]配置主从异步流复制
[postgres]配置主从异步流复制
|
5月前
|
存储 关系型数据库 分布式数据库
PolarDB操作报错合集之修改了binlog的存储时间为1小时,但在重启后发现仍有90GB的binlog文件未被删除,是什么原因
在使用阿里云的PolarDB(包括PolarDB-X)时,用户可能会遇到各种操作报错。下面汇总了一些常见的报错情况及其可能的原因和解决办法:1.安装PolarDB-X报错、2.PolarDB安装后无法连接、3.PolarDB-X 使用rpm安装启动卡顿、4.PolarDB执行UPDATE/INSERT报错、5.DDL操作提示“Lock conflict”、6.数据集成时联通PolarDB报错、7.编译DN报错(RockyLinux)、8.CheckStorage报错(源数据库实例被删除)、9.嵌套事务错误(TDDL-4604)。
|
5月前
|
资源调度 Kubernetes Java
实时计算 Flink版产品使用问题之全量快照初始化时,如果任务异常自动从ck restore后,会从上次binlog断点续传吗
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
SQL NoSQL 关系型数据库
二十五:从库的关闭和恢复流程(笔记)
一、stop slave流程 用户线程: stop_slave -> terminate_slave_threads ->带入参数rpl_stop_slave_timeout设置,作为等待SQL线程退出的超时时间。
858 0
|
SQL 存储 JSON
pg流复制详解
pg流复制详解
436 0
|
关系型数据库 MySQL 数据库管理
FAQ系列 | 不同复制模式下,如何忽略某些binlog事件
FAQ系列 | 不同复制模式下,如何忽略某些binlog事件
|
关系型数据库 数据库 PostgreSQL
PostgreSQL 同步流复制原理和代码浅析
数据库ACID中的持久化如何实现 数据库ACID里面的D,持久化。 指的是对于用户来说提交的事务,数据是可靠的,即使数据库crash了,在硬件完好的情况下,也能恢复回来。PostgreSQL是怎么做到的呢,看一幅图,画得比较丑,凑合看吧。假设一个事务,对数据库做了一些操作,并且产生了一些脏数据,
13375 0
下一篇
无影云桌面