标签频道
主从复制
该标签下的文章、提问与讨论帖。
【背景】 我负责一条实时数据落库链路：Kafka → 自研消费端攒批 → MySQL 8.0.32（单主 + 1 从，InnoDB，binlog_format=ROW，sync_binlog=1，innodb_flush_log_at_tr
背景 3 年运维，负责一套 MySQL 8.0.36 订单库（主 16C64G + 2 台从，binlog=row，已开 LOGICAL_CLOCK 并行复制 worker=8，GTID 全开）。最近在给故障切换（MHA 自托管脚本）写「该
【背景】 我负责一条实时数据落库链路：Kafka → 自研消费端攒批 → MySQL 8.0.32（单主 + 1 从，InnoDB，binlog_format=ROW，sync_binlog=1，innodb_flush_log_at_tr
«结论先行：千万行级批量 UPDATE 里，「每批 N 万行 + 批间 sleep X ms」的两个数都是拍脑袋的输入，真正的输出是「每批在 buffer pool 里砸出多少脏页」——批大小应该由 buffer pool 容量 × 允许的
«结论先行：千万行级的批量 UPDATE，站内主流做法是「单批 ≤ N 万行 + 批间 sleep X ms」——这是个开环系统，它只控制输入，不观察输出。我们一个 4200 万行的状态回刷任务，用这套静态策略，从库延迟峰值仍周期性飙到 4
«一句话结论："binlog_expire_logs_seconds" 不是「到点就删」的定时器，而是「可以删的上限」——真正决定删不删的，是所有存活从库的最小复制位点。一旦从库断开，它就从「位点集合」里消失，它需要的日志立刻暴露给时间策略
«结论先行：从库延迟不是"网络慢"，而是主库一条 2,348,000 行的大事务被从库单线程 SQL 线程串行回放。修它有三条路——拆事务（治本）、开 MTS 并行回放（缓解）、分库（重锤），三者各有代价，不能只挑一个。» 一、现象：凌晨对
结论先行：读写分离里「我刚写完，读从库却是旧值」，根因不是代码 bug，而是主从复制是异步的——主库把 binlog 落盘就返回成功，从库要等 relay log 拉取 + 重放，中间这段窗口（毫秒到秒级）读从库必然读到旧数据。解法分两层：
背景：MySQL 8.0.36，单主 + 2 从（半同步 rpl_semi_sync_master_wait_for_slave=ON），主库 32C/128G/ESSD PL2，从库同规格但磁盘是 SSD。binlog 日均增长约 200
一、现象：一次「我刚下的单怎么不见了」的 P0 去年 12 月大促前压测，订单链路是 MySQL 8.0.36（主从架构，主 16C64G、从 16C64G，从库走只读流量），业务侧反馈：下单接口返回 200 后立刻调「我的订单」列表，每
一个 1.2 亿行 UPDATE 让从库复制延迟 31 分钟：大事务的拆解、定位与治理 一、现象与背景 上个月我们的一条离线对账任务，把订单宽表 "t_order_stat"（约 1.2 亿行、InnoDB、MySQL 8.0.32）里 "
文
标题
摘要