一 问题 巡检发现mysql5.7的主从库有一个从库与主库断开同步，应该是版本升级时主从不同步，原从库变为主了，而原主库变为从库了，且数据比现在主库多。 2023-11-14T15:23:00.919194+08:00 2 [ERROR] Slave SQL for channel '': Could not execute Write_rows event on table xxxxx.xxxx

我们了解到在主从库集群模式下，如果从库发生故障，客户端可以继续向主库或其他从库发送请求，执行相应的操作。然而，当主库发生故障时，会直接影响从库的同步，因为此时从库失去了可用的主库进行数据复制。 而且，如果客户端发送的都是读操作请求，那还可以由从库继续提供服务，这在纯读的业务场景下还能被接受。但是，一旦有写操作请求了，按照主从库模式下的读写分离要求，需要由主库来完成写操作。此时，也没有实例可以来服务

版本：  8.0.34  relay_log_recovery – > OFF 表： 从状态： 主日志： 关闭relay_log_recovery 实验 停止SQL slave 应用，主库插入，查询从库 可见数据未同步 观测从库log状态 数据状态 观测relay日志 可见已经写入 模拟断电后消除该log再次观测log情况 模拟丢失这个log 打开mysql服务器 可见生成一个新的relay

如果是在主从做了大量的变更操作，建议重做主从。少部分的变更可以尝试使用此方法使gtid恢复一致。 生产环境操作需谨慎，可以使用show slave status命令查看当前数据库是否为从库。 主库： 从库： 查看当前gtid show global variables like 'gtid_executed'; 主库： 从库： 在从库执行变更操作，如赋权。 从库： 主库： 现在主从数据库gtid不

一个线上数据丢失故障案例，引出了在 GTID 模式下 AUTO POSITION MODE 的必要性。 作者：孙绪宗 新浪微博 DBA 团队工程师，主要负责 MySQL、PostgreSQL 等关系型数据库运维。 本文来源：原创投稿 * 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 阅读前需知 Retrieved_Gtid_Set：从库已经接收到主库的事务编号（从库

什么是从库? 从库是MySQL主从复制的一部分，它是MySQL集群中负责重复主库的数据更新的从属服务器。从库的目的是提高系统的可用性、负载均衡以及防止数据丢失。 判断mysql连接从库的步骤 在数据库集群中，主库负责写入，而从库则负责读取，这样可以减轻主库的压力，从库也同样可以被作为备份实现容灾。以下是判断mysql连接从库的步骤： 步骤一：查看状态 有一个简单的命令就能查看主从复制的状态： SH

repl_backlog_buffer：它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量复制带来的性能开销。如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量复制，所以repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量复制的概率。而在repl_backlog_buf

在之前的文章《mysql主从复制io线程源码分析》，我们分析了MySQL从库的io线程工作的主要过程，大致回顾一下，如下： 连接主库 发送COM_REGISTER_SLAVE命令注册从库 发送COM_BINLOG_DUMP_GTID命令请求拉取binlog 下面将结合源码，分析一下主库接收到从库io线程发送过来的命令后，是如何具体处理的。 MySQL源码版本：5.7.19 1. 注册从库 主库在接

本文通过一组测试，来看一下MySQL主从库服务器时钟的差异对MySQL复制延迟的影响。 一、测试环境 操作系统：CentOS 7.3，4核，16G MySQL： 5.7.19 1主2从 二、测试场景 主库时钟比从库早1分钟，5分钟，1小时，1天 主库时钟比从库晚1分钟，5分钟，1小时，1天 三、测试步骤 sysbench 4线程往主库写入数据 修改主库时间，如date -s "2020-02-05

slave_preserve_commit_order 参数在多线程复制环境下，能够保证从库回放relay log事务的顺序与这些事务在relay log中的顺序完全一致，也就是与主库提交的顺序完全一致。 举个例子，开启并行复制后，如果relay log中有3个事务A,B,C，他们在relay log中的顺序是A->B->C，而它们的last_commited相同，也就是说他们可以并行

背景 昨天我研读了源码大佬八怪的新文章《MySQL:主从 HASH SCAN 算法可能导致从库数据错误》，我将其内容概括如下：如果主从复制的行搜索算法设置为使用 HASH SCAN，从库数据可能会与主库不同，导致从库直接抛出复制异常。 结合文章细节，我再补充一些理解: 这个问题只在 MySQL8.0 中出现，不在 5.7 中发生，因为两者的代码实现有所不同。 数据不一致时会导致从库复制报错，而不是

作者简介：高鹏，笔名八怪。《深入理解MySQL主从原理》图书作者，同时运营个人公众号“MySQL学习”，持续分享遇到的有趣case以及代码解析！ 一、问题来源 这是今天的一个问题，是朋友杨长江给我的，版本MySQL 5.7.17。问题为show slave status遇到了大量的空洞，如下： 这里只是部分截屏，GTID SET已经分成了无数段。正常情况下我们的从库GTID SET应该是不会出现这

刚开始我们只用单机数据库就够了，随后面对越来越多的请求，我们将数据库的写操作和读操作进行分离， 使用多个从库副本（Slaver Replication）负责读，使用主库（Master）负责写， 从库从主库同步更新数据，保持数据一致。架构上就是数据库主从同步。 从库可以水平扩展，所以更多的读请求不成问题。 但是当用户量级上来后，写请求越来越多，该怎么办？加一个Master是不能解决问题的，因为数据要

MySQL高可用集群的必要性 MySQL数据库是应用广泛的关系型数据库，在大多数Web应用中都扮演着核心角色。但是，如果单个MySQL节点失效，将会造成严重的数据丢失和应用中断，对业务造成不可承受的后果。因此，保证MySQL数据库的高可用性就显得尤为重要。 MySQL高可用集群架构分析 常见的MySQL高可用架构包括：（1）主从复制：主库写入，从库异步复制数据；（2）半同步复制：主库写入，等待至少

读写分离 读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。 读写分离 一般情况下，我们都会选择一主多从，也就是一台主数据库负责写，其他的从数据库负责读。主库和从库之间会进行数据同步，以保证从库中数据的准确性。这样的架构实现起来比较简单，并且也符合系统的写少读多的特点。 读写分离会带来什么问题？如何解决？ 读写分离对于提升数据库的并发非常有效，但是，同时也会引来一个问题：主库和从库的

本文将通过复制场景下的异常分析，介绍手工搭建MySQL主从复制时需要注意的关键细节。 作者：秦福朗 爱可生 DBA 团队成员，负责项目日常问题处理及公司平台问题排查。热爱互联网，会摄影、懂厨艺，不会厨艺的 DBA 不是好司机，didi~ 本文来源：原创投稿 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 背景 有人反馈装了一个数据库，来做现有库的从库。做好主从复制关系

前言 运维工程师在工作中一定会使用到mysql数据库的主从复制，那么肯定会有扩展从库的需求，比如数据库当前吞吐量比较大或者需要单独加一台从库做专门的数据分析。那么生产环境如何添加mysql从库，就是本文要说明的内容。 前提 在添加mysql的从库的时候，从库需要先导入一次主库的全量备份，并且需要知道这次全量备份之后mysql的二进制日志文件名称和二进制日志位置，然后才可以根据这个位置开始复制主库的

开始我们只用单机数据库就够了，随后面对越来越多的请求，我们将数据库的写操作和读操作进行分离， 使用多个从库副本（Slaver Replication）负责读，使用主库（Master）负责写， 从库从主库同步更新数据，保持数据一致。架构上就是数据库主从同步。 从库可以水平扩展，所以更多的读请求不成问题。 但是当用户量级上来后，写请求越来越多，该怎么办？加一个Master是不能解决问题的，因为数据要保

前言： MySQL 主从架构应该是最常用的一组架构了。从库会实时同步主库传输来的数据，一般从库可以作为备用节点或作查询使用。其实不只是主库需要多关注，从库有时候也要经常维护 前言： MySQL 主从架构应该是最常用的一组架构了。从库会实时同步主库传输来的数据，一般从库可以作为备用节点或作查询使用。其实不只是主库需要多关注，从库有时候也要经常维护，本篇文章将会分享几点从库维护经验，一起来学习吧。 1

MySQL动态修改复制过滤器 说说今天遇到的问题吧，今天在处理一个业务方的需求，比较变态，我大概描述一下： 1、线上的阿里云rds上面有个游戏的日志库，里面的表都是日表的形式， MySQL动态修改复制过滤器     说说今天遇到的问题吧，今天在处理一个业务方的需求，比较变态，我大概描述一下： 1、线上的阿里云rds上面有个游戏的日志库，里面的表都是日表的形式，数据量比较大了，每次备份的时候，都会导