pg_dump和mysqldump不支持断点续传；需拆分导出：PG用-t按表或schema导出，MySQL用--where按主键范围分片。
同步中断后怎么让 pg_dump / mysqldump 从断点继续
不能。原生命令不支持断点续传，pg_dump 和 mysqldump 都是单次全量快照导出，一旦网络中断就得重来。
真正能落地的方案是：把大库拆成小单元，用表粒度或主键范围分片导出，失败只重试局部。
- PostgreSQL 推荐用
pg_dump -t table_name按表导出，配合pg_dump -t 'schema.*'分 schema 批量调度 - MySQL 可用
mysqldump --where="id > 100000 AND id 切片，配合自增主键或时间字段分段 - 导出前先查最大 ID 或最新时间戳，写入临时标记文件（如
last_sync_pos.json），失败时读它续切 - 别依赖管道直连云数据库——本地磁盘中转更可控，哪怕只是
/tmp下的临时.sql文件
云数据库拒绝连接？先确认这三类权限不是“开了但没开对”
常见现象是测试连得通，同步脚本却报 Access denied 或 Connection refused，大概率不是账号没权限，而是权限绑错了上下文。
- 阿里云 RDS、腾讯云 CDB 要在控制台「白名单」里加真实出口 IP，不是你本机局域网 IP（
192.168.x.x），而是公网出口（可查curl ifconfig.me） - 云厂商默认禁用 super 权限，
mysqldump --single-transaction在 MySQL 8+ 云实例上可能因缺失REPLICATION CLIENT报错，需显式授权 - PostgreSQL 的
pg_hba.conf规则在云环境不可改，但 RDS 控制台的「高权限账号」开关必须打开，否则pg_dump无法读取系统表获取表结构
rsync 同步 SQL 文件时为什么总卡在 99%？
不是网络慢，是 rsync 默认启用压缩和校验，大 SQL 文件（尤其 >500MB）会吃光本地 CPU 和内存，导致假死或超时断连。
- 加
--compress-level=0关闭压缩，加--checksum换成--size-only跳过内容比对（前提是文件名和大小不变即代表未损坏） - 用
rsync --partial --progress保证断点续传能力，避免每次从头传；注意目标路径末尾加/，否则rsync src/ dst和rsync src/ dst/行为完全不同 - 如果云存储用的是对象存储（如 OSS、COS），别硬套
rsync，直接用厂商 CLI：ossutil cp -f local.sql oss://bucket/db/更稳
本地跑通了，一上 CI 就失败：环境差异藏在哪几个关键变量里
CI 环境没有交互终端、没有家目录缓存、DNS 解析策略不同，三个看似无关的点常让同步脚本静默失败。
-
PGPASSWORD和MYSQL_PWD必须设为环境变量，不能靠.pgpass或~/.my.cnf—— CI 容器里这些文件通常不存在或权限不对 - 云数据库域名在 CI 内网可能解析失败，别写
xxx.mysql.rds.aliyuncs.com，换成 IP +--host，或在 CI 配置里加extra_hosts显式绑定 - 某些 CI 平台（如 GitHub Actions）默认时区是 UTC，而你的同步脚本依赖
date +%Y%m%d生成文件名，结果本地和 CI 生成的路径对不上，后续找不到断点文件
断点续传真正的复杂点不在工具链，而在状态标记的持久化位置和读写一致性——本地磁盘、NAS、对象存储，选哪个，取决于你能否原子地更新“当前进度”和“对应文件”这两个东西。多数人卡在这一步，不是不会写脚本，是没想清楚“进度”到底该存在哪、谁来保证它不丢不乱。
