主从架构中历史数据归档需在从库建独立归档库与表，关闭binlog后分批INSERT…SELECT或mysqldump导入，配合增量校验与pt-table-checksum保障一致性，严禁从库删主库数据或执行阻塞操作。
主从架构中，让从库承担历史数据归档任务是常见且可行的方案，但不能简单依赖默认同步机制——它只复制实时变更，不自动区分“热”与“冷”数据。关键在于主动设计归档路径：在从库上建独立历史表，按需将主库中已归档的旧数据定向迁移过去，同时保持主从基础同步不受干扰。
归档前的从库准备
从库不是天然适合存历史数据的“仓库”，需提前做三件事：
- 创建专用历史库（如 archive_db），避免和同步库混用；
- 在该库中建结构一致的历史表（例如 orders_archive），可用
SHOW CREATE TABLE orders获取建表语句后修改库名和表名； - 确认从库磁盘空间充足，并关闭 binlog 写入（
SET sql_log_bin = 0）再执行归档写入，防止归档操作又被同步回主库或产生冗余日志。
安全迁移数据的两种常用方式
迁移必须避开主库锁表影响业务，也得防止从库因大事务阻塞同步：
-
分批次 INSERT … SELECT：在从库上执行，按主键或时间范围切片，例如
INSERT INTO archive_db.orders_archive SELECT * FROM mysql_master.orders WHERE order_time < '2024-01-01' LIMIT 10000;
每次执行后加SLEEP(0.1)缓冲，再循环下一批； -
mysqldump + 导入：在主库导出指定条件的历史数据（如
mysqldump -h master -u u -p db orders --where="order_time < '2024-01-01'" > orders_old.sql），再导入到从库的 archive_db 中——这种方式不走复制链路，完全隔离。
自动化与一致性保障
手动操作不可持续，建议用脚本驱动归档流程，并嵌入校验环节：
- 脚本先查从库 archive_db.orders_archive 的最大 order_id 或最新时间戳；
- 再从主库拉取大于该值的符合条件数据（即增量归档），避免重复；
- 归档完成后，对比主库源表与从库归档表的行数差、时间范围覆盖是否连续；
- 定期用
pt-table-checksum检查主从核心业务表一致性，确保归档未干扰正常同步。
必须规避的风险点
这个模式容易踩坑，尤其在高并发场景：
- 不要在从库上直接
DELETE主库数据——归档是迁移，不是删除，删操作必须只在主库发起并由同步自然落到从库； - 避免在从库执行耗时长的
ALTER TABLE或全表统计，否则可能拖慢 SQL 线程，造成Seconds_Behind_Master持续升高； - 如果归档表需频繁查询，建议在从库上单独建只读账号，并限制其资源使用（如通过
MAX_QUERIES_PER_HOUR）； - 备份策略要分开：主库备份在线业务数据，从库归档库需单独制定保留周期与压缩策略。
