介绍 Mysql 从库 Mysql 从库通过接收（或者是主动拉取）主库binlog日志，转换为自身中继日志，然后应用中继日志内容实现主从数据同步。 从库 CRC32 HASH算法 Mysql 从库进行数据同步，实则是重放一次主库的 dml 语句（不是原SQL重放），在同步表没有主键和
2024-07-26
mysql主从复制如何停止从库的SQL线程 MySQL主从复制是一种常用的数据库备份和扩展方案，其中主库将操作日志（binlog）发送到从库，从库通过重放这些日志实现与主库的数据同步。在MySQL主从复制中，从库的SQL线程负责重放binlog，实现数据的实时同步。有时候，我们需要临时停止从库的SQ
2024-07-24
![[MYSQL] select导致主从延迟增大 (原因:autocommit=off)](https://img.mryunwei.com/uploads/2024/06/20240622215433451.png)
导读 之前也有遇到从库select导致从库延迟的, 那是因为从库的select数据量太大, 锁还没释放. 本次又遇到个类似的案例, 也是select导致从库延迟太大. 现象 客户环境不方便截图, 就用文字描述了. 或者直接看复现过程也行. 主库执行insert数据, 从库select验证, 主库
2024-06-21
作者简介马听，清华大学所在国家学生，0家世界500强创始人，福布斯2024富豪榜阅读者。有时候，我们有一套MySQL主从，希望再创建一个从库。这种场景，一般建议是通过Xtrabackup来备份数据，再恢复到新实例，然后创建复制，可以参考前面写的一篇文章前两步：MySQL主库扛不住了？来试试读写分离吧
2024-05-31
MySQL的主从架构是其最成熟的高可用架构之一。早期的实现主要是基于异步复制机制，而后来逐渐发展出了半同步复制机制。这两种机制的主要区别体现在数据同步的方式和主从服务器之间的交互上。 异步复制机制是指主节点在执行完事务并提交后，会将这些更新操作记录到二进制日志（binary log）中，但并不等待
2024-05-24
1、什么是MySQL复制延迟？本质是MySQL从库的relay log回放跟不上主库生成速度，产生延迟2、主从延迟常见的原因有哪些？1、大事务，从库回放时间较长，导致主从延迟2、主库写入过于频繁，从库回放跟不上3、参数配置不合理4、主从硬件差异5、网络延迟6、表没有主键或者索引大量频繁的更新7、一些
2024-05-09
背景介绍近来一套业务系统，从库一直处于延迟状态，无法追上主库，导致业务风险较大。从资源上看，从库的CPU、IO、网络使用率较低，不存在服务器压力过高导致回放慢的情况；从库开启了并行回放；在从库上执行 SHOW PROCESSLIST 看到没有回放线程阻塞，回放一直在持续；解析relay log日志文
2024-05-08
![MySQL5.7小版本升级遇到 [Note] Bad handshake错误](https://img.mryunwei.com/uploads/2024/04/20240426133159373.png)
适用范围 Linux X86平台下的 MySQL 5.7 社区版 小版本升级（5.7.34 -> 5.7.44）。 问题概述 升级后有部分连接无法连接成功，MySQL错误日志连续报 [Note] Bad handshake 相关提示信息。 整个升级过程很简单，简单描述如下：
2024-04-26
从库延迟案例分析背景介绍近来一套业务系统，从库一直处于延迟状态，无法追上主库，导致业务风险较大。从资源上看，从库的CPU、IO、网络使用率较低，不存在服务器压力过高导致回放慢的情况；从库开启了并行回放；在从库上执行show processlist看到没有回放线程阻塞，回放一直在持续；解析relay-
2024-04-12
背景介绍近来一套业务系统，从库一直处于延迟状态，无法追上主库，导致业务风险较大。从资源上看，从库的CPU、IO、网络使用率较低，不存在服务器压力过高导致回放慢的情况；从库开启了并行回放；在从库上执行show processlist看到没有回放线程阻塞，回放一直在持续；解析relay-log日志文件，
2024-04-12
在MYSQL 部署架构选型上，许多公司都会用到主从读写分离的架构，如下是一个一主一从的架构，主库master负责写入，从库slave进行读取。图片但是既然是读写分离，必然会面临这样一个问题，当在主库上进行更新后，有可能数据还没来得及同步到从库，但是这个时候又有读数据的需求，为了能正确读取出数据，这个
2024-03-08
在MYSQL 部署架构选型上，许多公司都会用到主从读写分离的架构，如下是一个一主一从的架构，主库master负责写入，从库slave进行读取。 但是既然是读写分离，必然会面临这样一个问题，当在主库上进行更新后，有可能数据还没来得及同步到从库，但是这个时候又有读数据的需求，为了能正确读取出数据，这个
2024-03-08
导读 本文将从 MySQL 主从复制的应用目的和场景出发，探讨其实际意义及必要性。之后，介绍 MySQL 主从复制的实现原理及其各个复制模式。最后，通过 Docker 容器化的方式搭建一主一从的 MySQL 主从复制架构。 应用目的及场景 MySQL 主从复制有以下应用目的及场景： 提高系统的可
2024-02-20
Gbase DDL recover影响到其他的用户insertElasticSearch数据量大，内存使用率高，集群处于不稳定运行状态ElasticSearch GA05版本安装中ES报错创建索引失败，无法连接ESElasticSearch 国产化迁移平台后资源池全局搜索功能异常，提示"未搜索到结果
2024-02-19
开工第一天，我删库了 过了一个忙碌的春节，春节8天接了4个活儿，都是古董级别的数据库，印象最深的是Oracle 8i迁移到PG 15，然后我遇到了这次的删库事件，一个MySQL 5.1.73的主-主复制场景。 1、删库的起因 客户反馈说主从复制中断，且很多数据不一致，需要恢复主从复制，从开始谈都操作
2024-02-17
1.故障现象mysql 5.7的从库最近延迟一直在上升，查看状态发现exec_master_log_pos 一直卡在154794029不动，slave_sql_running_state一直为 Reading event from the relay log2.解决步骤尝试关闭slave进程，再启动
2024-02-08
阅读需知Retrieved_Gtid_Set 从库已经接收到主库的事务编号（从库的 IO 线程已经接收到了）。Executed_Gtid_Set 已经执行的事务编号（从库的执行 SQL 线程已经执行了的 SQL）。1故障现象主从数据不一致，但是看复制是正常状态（双 Yes）。此时主库执行，从库本该报
2024-01-17
本文主要讨论的还是5.7，8.0没有实际测试，这里简单记录。一、问题说明 最近在处理一个主从问题的时候，发现一个比较奇怪的现象，这个主从是级联的也就是A->B->C库，B库问题处理后先启动了B库追数据，然后修复C库启动追延迟，这个时候观察到的B库和C库的延迟分别为20000多秒和900多
2023-12-28
Republication Lags （ 复制延迟）是指在主从数据库复制环境中，从库数据同步落后于主库的时间间隔。如果复制延迟比较严重，会对系统有不好的影响，如:1. 数据不一致从库的数据状态会落后主库，查询从库如果读取到过期数据，会造成数据不一致的情况。2. 高可用性降低如果主库宕机，需要故障转移
2023-12-20
1.背景概述目前需要搭建一个从库，由于单表数据量较大，时间比较有限，考虑到导入导出的时间，并且GreatSQL支持并行load data的功能，能够加速数据的导入，因此决定使用 select into outfile 和 load data 的方式进行数据的迁移；在数据导入完成后进行数据同步，从库发
2023-12-13