不能直接用，因主从复制会全量重演生产库所有操作（含误删），使测试库成为其镜像；须用ROW格式、read_only+super_read_only组合、专用账号，并避免库级过滤。
MySQL 主从复制能直接用于生产库到测试库同步吗
不能直接用，除非你清楚它会把 drop table、truncate、误删的 delete from users 也原样重放过去。主从复制是强一致性机制，不是“选同步”，而是“全量重演”，测试库一旦挂上从库角色，就等于成了生产库的镜像——包括所有线上事故。
实操建议：
- 禁用
replicate-do-db这类库级过滤，它在语句级复制下不可靠，跨库操作容易漏同步或错同步 - 必须用基于行的复制（
binlog_format = ROW），否则触发器、函数等上下文丢失会导致数据不一致 - 从库开启
read_only = ON，但要额外加super_read_only = OFF（否则无法执行STOP SLAVE等管理命令） - 如果只是单向同步测试库，建议用专用账号，权限仅限
REPLICATION SLAVE和SELECT，禁止写入
pg_dump + pg_restore 定时同步 PostgreSQL 测试库
适合中小规模（pg_dump 导出小于 5GB）、对同步延迟不敏感（小时级）的场景。它本质是快照式覆盖，不是增量，所以不会把测试库里的临时表或调试数据带进生产逻辑。
常见错误现象：同步后测试库报 relation "xxx" does not exist，或序列值重置回 1。
实操建议：
- 用
pg_dump --clean --no-owner --no-privileges --exclude-table-data='.*_tmp'避免清空不该动的表 - 恢复前先
DROP DATABASE testdb再CREATE DATABASE testdb WITH TEMPLATE template0，防止字符集或 LC_COLLATE 不一致 - 加
--inserts而非默认的COPY，方便排查导入失败的具体行；但大数据量时改用--column-inserts降低内存压力 - 定时任务里检查
pg_restore的退出码，非 0 就发告警，别只看日志有没有 “done”
如何避免同步时阻塞测试库上的开发查询
同步过程本身会锁表（如 pg_restore 默认加 ACCESS EXCLUSIVE），而开发人员可能正连着测试库跑 SELECT * FROM orders LIMIT 100 调接口，一锁就是几分钟，体验极差。
实操建议：
- 同步目标不直连
testdb，而是导到新库名如testdb_next，再原子切换：ALTER DATABASE testdb RENAME TO testdb_old; ALTER DATABASE testdb_next RENAME TO testdb - 切换前用
SELECT pid, state, query FROM pg_stat_activity WHERE datname = 'testdb'杀掉长连接，但跳过idle in transaction状态（可能是开发正在调试事务） - 如果用 MySQL，可用
pt-online-schema-change做无锁替换，但它只适用于表结构变更，不适用整库同步 - 所有同步脚本开头加
SET lock_timeout = '5s';，超时就退出，别死等
无损发布中“数据同步”和“服务更新”的边界在哪
很多人以为只要数据库同步完，代码一上线就万事大吉。其实关键断点在应用层：旧代码还在读 user_profile_v1 表，新代码已开始写 user_profile_v2，此时同步脚本若把 v1 数据也刷进 v2，就会造成双写冲突或字段覆盖。
实操建议：
- 同步脚本必须明确知道当前发布阶段——是灰度前、灰度中、还是全量后，不同阶段同步范围不同（例如灰度中只同步白名单用户）
- 在应用配置里加
sync_mode: 'readonly' / 'migrate' / 'disabled'，同步脚本读这个开关决定是否执行、是否清理旧表 - 不要让同步逻辑耦合在发布脚本里，它应该独立部署、可观测（比如暴露
/health/sync接口返回最近一次同步时间戳和行数） - 最易被忽略的一点：时间戳字段（
updated_at）在同步时要不要保留原值？多数情况要，否则业务侧的“最后修改时间”会被覆盖成同步时间
