如何无停机更新PostgreSQL？解决每日CSV导入导致的API服务停机问题

方案1：蓝绿表零停机切换（最高优先级，改造成本最低） #

• 在现有PostgreSQL中建两张结构完全一致的业务表，比如命名为medical_staff_active（对外提供查询的活跃表）和medical_staff_staging（预发布导入用的 staging 表）
• 每日ETL流程拉取CSV文件后，全部写入medical_staff_staging表，写入完成、校验数据完整性（对比CSV行数、Unique Id完整性校验）的全程不影响活跃表的读写
• 数据校验无误后，执行PostgreSQL的表重命名原子操作：

BEGIN;
ALTER TABLE medical_staff_active RENAME TO medical_staff_old;
ALTER TABLE medical_staff_staging RENAME TO medical_staff_active;
COMMIT;

• 操作完成后删除旧表即可，整个切换过程耗时仅毫秒级，完全不会导致API downtime
• 补充优化：导入CSV时使用PostgreSQL原生的COPY命令，比普通INSERT快3~10倍，能大幅缩短40分钟的预处理耗时

方案2：增量同步方案（适合后续长期优化，降低每日处理开销） #

• 每次拿到新的全量CSV后，先和当前活跃表的数据做差分对比：
  1. 提取CSV中存在、活跃表不存在的Unique Id，做INSERT操作
  2. 提取活跃表存在、CSV不存在的Unique Id，做删除/软删除（可加is_deleted字段标记）操作
  3. 剩余字段有变化的数据做UPDATE操作
• 差分对比可以提前把CSV的Unique Id批量导入临时表，用SQL关联查询直接得到增删改的数据集，不需要在应用层遍历130万条数据，处理耗时可以压缩到分钟级
• 注意要把所有增删改操作放在同一个事务里执行，避免中间状态的脏数据对外暴露

配套API侧兼容优化 #

• 建议在NestJS服务中给查询逻辑里加一层短时间的读写重试机制，应对极端情况下的表切换瞬态错误，进一步提升稳定性
• 如果需要更高的可用性，可以给PostgreSQL配置只读副本，API读请求全部打到只读副本上，主库只做ETL写入操作，完全隔离读写压力

方案选型建议 #

• 临时紧急解决停机问题直接选方案1，不需要改现有ETL的核心逻辑，只需要调整导入的目标表和最后加一步原子切换即可，改造成本极低，零风险
• 后续长期优化可以往方案2的增量同步改造，进一步降低每日的计算资源开销

内容的提问来源于stack exchange，提问作者Kynes