一 问题 巡检发现mysql5.7的主从库有一个从库与主库断开同步，应该是版本升级时主从不同步，原从库变为主了，而原主库变为从库了，且数据比现在主库多。 2023-11-14T15:23:00.919194+08:00 2 [ERROR] Slave SQL for channel '': Coul
2023-11-24
我们了解到在主从库集群模式下，如果从库发生故障，客户端可以继续向主库或其他从库发送请求，执行相应的操作。然而，当主库发生故障时，会直接影响从库的同步，因为此时从库失去了可用的主库进行数据复制。而且，如果客户端发送的都是读操作请求，那还可以由从库继续提供服务，这在纯读的业务场景下还能被接受。但是，一旦
2023-10-25
版本： 8.0.34 relay_log_recovery – > OFF 表： 从状态： 主日志： 关闭relay_log_recovery 实验 停止SQL slave 应用，主库插入，查询从库 可见数据未同步 观测从库log状态 数据状态 观测relay日志
2023-10-19
如果是在主从做了大量的变更操作，建议重做主从。少部分的变更可以尝试使用此方法使gtid恢复一致。生产环境操作需谨慎，可以使用show slave status命令查看当前数据库是否为从库。主库：从库：查看当前gtidshow global variables like 'gtid_executed'
2023-10-18
一个线上数据丢失故障案例，引出了在 GTID 模式下 AUTO POSITION MODE 的必要性。 作者：孙绪宗 新浪微博 DBA 团队工程师，主要负责 MySQL、PostgreSQL 等关系型数据库运维。 本文来源：原创投稿 * 爱可生开源社区出品，原创内容未经授权不得
2023-10-12
什么是从库?从库是MySQL主从复制的一部分，它是MySQL集群中负责重复主库的数据更新的从属服务器。从库的目的是提高系统的可用性、负载均衡以及防止数据丢失。判断mysql连接从库的步骤在数据库集群中，主库负责写入，而从库则负责读取，这样可以减轻主库的压力，从库也同样可以被作为备份实现容灾。以下是判
2023-09-23
repl_backlog_buffer：它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量复制带来的性能开销。如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量复制，所以repl_backlog
2023-09-12
在之前的文章《mysql主从复制io线程源码分析》，我们分析了MySQL从库的io线程工作的主要过程，大致回顾一下，如下： 连接主库 发送COM_REGISTER_SLAVE命令注册从库 发送COM_BINLOG_DUMP_GTID命令请求拉取binlog 下面将结合源码，分析一下主
2023-08-15
本文通过一组测试，来看一下MySQL主从库服务器时钟的差异对MySQL复制延迟的影响。 一、测试环境 操作系统：CentOS 7.3，4核，16G MySQL： 5.7.19 1主2从 二、测试场景 主库时钟比从库早1分钟，5分钟，1小时，1天 主库时钟比从库晚1分钟，5
2023-08-15
slave_preserve_commit_order 参数在多线程复制环境下，能够保证从库回放relay log事务的顺序与这些事务在relay log中的顺序完全一致，也就是与主库提交的顺序完全一致。 举个例子，开启并行复制后，如果relay log中有3个事务A,B,C，他们在relay l
2023-08-15
背景昨天我研读了源码大佬八怪的新文章《MySQL:主从 HASH SCAN 算法可能导致从库数据错误》，我将其内容概括如下：如果主从复制的行搜索算法设置为使用 HASH SCAN，从库数据可能会与主库不同，导致从库直接抛出复制异常。结合文章细节，我再补充一些理解:这个问题只在 MySQL8.0 中出
2023-08-15
作者简介：高鹏，笔名八怪。《深入理解MySQL主从原理》图书作者，同时运营个人公众号“MySQL学习”，持续分享遇到的有趣case以及代码解析！一、问题来源这是今天的一个问题，是朋友杨长江给我的，版本MySQL 5.7.17。问题为show slave status遇到了大量的空洞，如下：这里只是部
2023-08-15
刚开始我们只用单机数据库就够了，随后面对越来越多的请求，我们将数据库的写操作和读操作进行分离， 使用多个从库副本（Slaver Replication）负责读，使用主库（Master）负责写， 从库从主库同步更新数据，保持数据一致。架构上就是数据库主从同步。 从库可以水平扩展，所以更多的读请求不成问
2023-08-12
MySQL高可用集群的必要性MySQL数据库是应用广泛的关系型数据库，在大多数Web应用中都扮演着核心角色。但是，如果单个MySQL节点失效，将会造成严重的数据丢失和应用中断，对业务造成不可承受的后果。因此，保证MySQL数据库的高可用性就显得尤为重要。MySQL高可用集群架构分析常见的MySQL高
2023-08-11
读写分离 读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。 读写分离 一般情况下，我们都会选择一主多从，也就是一台主数据库负责写，其他的从数据库负责读。主库和从库之间会进行数据同步，以保证从库中数据的准确性。这样的架构实现起来比较简单，并且也符合系统的写少读多的特点。
2023-07-30
本文将通过复制场景下的异常分析，介绍手工搭建MySQL主从复制时需要注意的关键细节。 作者：秦福朗 爱可生 DBA 团队成员，负责项目日常问题处理及公司平台问题排查。热爱互联网，会摄影、懂厨艺，不会厨艺的 DBA 不是好司机，didi~ 本文来源：原创投稿 爱可生开源社区出品，原创内容未经授权
2023-07-19
前言 运维工程师在工作中一定会使用到mysql数据库的主从复制，那么肯定会有扩展从库的需求，比如数据库当前吞吐量比较大或者需要单独加一台从库做专门的数据分析。那么生产环境如何添加mysql从库，就是本文要说明的内容。 前提 在添加mysql的从库的时候，从库需要先导入一次主库的全量备份，并且需要知道
2023-07-16
开始我们只用单机数据库就够了，随后面对越来越多的请求，我们将数据库的写操作和读操作进行分离， 使用多个从库副本（Slaver Replication）负责读，使用主库（Master）负责写， 从库从主库同步更新数据，保持数据一致。架构上就是数据库主从同步。 从库可以水平扩展，所以更多的读请求不成问题
2023-07-10
前言： MySQL 主从架构应该是最常用的一组架构了。从库会实时同步主库传输来的数据，一般从库可以作为备用节点或作查询使用。其实不只是主库需要多关注，从库有时候也要经常维护
2023-04-30
MySQL动态修改复制过滤器 说说今天遇到的问题吧，今天在处理一个业务方的需求，比较变态，我大概描述一下： 1、线上的阿里云rds上面有个游戏的日志库，里面的表都是日表的形式，
2023-04-30