不能直接用，因主从复制会全量重演生产库所有操作（含误删），使测试库成为其镜像；须用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）在同步时要不要保留原值？多数情况要，否则业务侧的“最后修改时间”会被覆盖成同步时间