从库同步挂起大概率是innodb_buffer_pool_size配置过高导致oom，需查dmesg确认是否被kill，并按热数据量、os预留内存（≥1.8gb）、chunk×instances整数倍三重约束调优，2gb内存从库推荐设为768m/4实例。
从库同步挂起时，先确认是不是 innodb_buffer_pool_size 撑爆了内存
MySQL 从库同步进程（SQL Thread）挂起但没报错，SHOW SLAVE STATUS\G 显示 Seconds_Behind_Master 持续增长、Slave_SQL_Running_State 卡在 “Reading event from the relay log” 或 “Updating”，大概率不是网络或主库问题，而是从库内存耗尽后触发 OOM Killer 杀掉了 mysqld 进程，或系统直接拒绝分配内存导致 SQL 线程卡死。
关键证据是查系统日志：dmesg -T | grep -i "killed process.*mysqld"。如果出现这条记录，基本坐实是 OOM；再看 free -h 的 available 值——若长期低于 500MB，说明 buffer pool 已严重挤压系统余量。
- 从库比主库更易 OOM：它要同时承担读请求 + 应用 relay log 的写压力，而很多运维只按主库规格配 buffer pool，忽略从库多出的并发写开销
- 别信
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'返回的值，它只是配置值；真正占用多少得看cat /proc/$(pgrep mysqld)/status | grep VmRSS，对比物理内存才准 - 云上小内存从库（如 2GB ECS）设
innodb_buffer_pool_size=1.5G是高危操作——OS 和 MySQL 其他线程至少要抢走 800MB，实际只剩 200MB 可用
给从库调小 innodb_buffer_pool_size 要守住三个硬约束
从库 buffer pool 不是简单“按比例砍掉”，必须满足三重限制：
-
下限不能低于热数据量：用
SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB' AND table_schema NOT IN ('mysql','performance_schema','information_schema');算出活跃库的总索引+数据大小，buffer pool 至少要比这个数大 20%，否则同步期间频繁刷脏页、磁盘 IO 拉满 -
上限必须给 OS 留足 1.5GB+：即使从库纯跑同步，也要预留内存给 page cache、内核网络栈、以及
relay_log_info_repository=TABLE时的系统表操作；free -h的available值稳定 ≥ 1.8GB 才算安全 -
必须是 chunk × instances 的整数倍：MySQL 8.0 默认
innodb_buffer_pool_chunk_size=128M，若你设innodb_buffer_pool_instances=4，那 buffer pool 只能是 512M、640M、768M… 任意非倍数值都会被静默向下取整，比如填600M实际生效仍是512M
典型安全配置（2GB 内存从库）：innodb_buffer_pool_size=768M、innodb_buffer_pool_instances=4、max_connections=64。重启后用 mysqladmin ext -i1 | grep -i "buffer.pool.size" 观察是否稳定在 768M。
innodb_buffer_pool_instances 在从库上不能照搬主库值
主库设 innodb_buffer_pool_instances=8 是为了扛住大量并发 SELECT，但从库的 SQL Thread 是单线程回放 relay log，高并发争用 buffer pool mutex 的场景极少。盲目设高反而浪费内存、拖慢初始化——尤其小内存从库，每个 instance 最小占 1GB 内存对齐空间，innodb_buffer_pool_size=768M 时设 =4 就会触发 warning：[Warning] InnoDB: buffer pool size reduced to 512M，因为 768M ÷ 4 = 192M
- 2GB 内存从库：强制设为
innodb_buffer_pool_instances=1（默认值），避免降级 - 4GB 内存从库：可设
=2，此时 768M ÷ 2 = 384M 仍低于 1G，但 MySQL 8.0+ 允许，不会报错 - 验证是否生效：执行
SELECT POOL_ID FROM information_schema.INNODB_BUFFER_POOL_STATS GROUP BY POOL_ID;，返回行数必须等于你配的instances值
同步恢复后必须关掉 innodb_buffer_pool_dump_at_shutdown
从库内存紧张时，最不该干的事就是让 MySQL 在 shutdown 时 dump 几百 MB 缓冲池快照。这个 dump 文件下次启动时会被 innodb_buffer_pool_load_at_startup=ON 加载，直接卡住启动流程，甚至因加载失败导致 SQL Thread 无法启动，表现就是 Slave_SQL_Running: No 且无错误日志。
- 立刻执行：
SET GLOBAL innodb_buffer_pool_dump_at_shutdown=OFF; - 永久禁用：在
my.cnf的[mysqld]段加一行innodb_buffer_pool_dump_at_shutdown=OFF - 删掉残留 dump 文件（通常在
datadir下，名如ib_buffer_pool），避免重启时误加载
小内存从库的 buffer pool 预热意义不大——热数据本就不多，强行 dump/load 只是把内存压力从运行时挪到启动瞬间。真正该盯的是 Innodb_buffer_pool_reads 是否持续上升，这才是同步延迟的根源。
