Kubernetes CronJob同步Postgres库后Django migrate与clean_db报错排查

开发者阿泽

2026-9-26

根因分析

PostgreSQL搜索路径（search_path）配置异常：pg_restore将所有表恢复到了public schema下，但Django连接数据库使用的myuser@staging用户默认搜索路径未包含public schema。Django操作数据库时默认不会显式指定schema前缀，导致无法定位到public下的表，触发"relation does not exist"错误；执行migrate时要新建django_migrations表也找不到可写入的schema，触发"no schema has been selected to create in"报错。正常情况下生产库的备份已经包含完整的django_migrations表，恢复后migrate会检测到所有迁移已执行，不会做任何操作，当前migrate尝试新建该表，说明Django完全无法读取到public schema下的已有表，进一步确认了该问题。
Schema权限不足：即使搜索路径包含public，如果myuser@staging用户对public schema没有USAGE和CREATE权限，也会触发相同报错。

修复步骤

验证配置：使用myuser@staging账户通过psql连接db_test，执行以下命令确认配置：

-- 查看当前搜索路径
show search_path;
-- 查看public schema权限
\dn+ public

配置搜索路径，二选一即可：

-- 方案1：修改数据库用户默认配置，永久生效
ALTER ROLE "myuser@staging" IN DATABASE db_test SET search_path TO public;

# 方案2：在Django settings.py中配置，仅对Django服务生效
DATABASES = {
    'default': {
        # 保持其他现有配置不变
        'OPTIONS': {
            'options': '-c search_path=public'
        }
    }
}

配置schema操作权限：

GRANT USAGE, CREATE ON SCHEMA public TO "myuser@staging";
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO "myuser@staging";
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO "myuser@staging";

更优实现方案

精简同步脚本：移除无实际作用的sleep 30逻辑；添加旧备份自动清理规则，避免磁盘占用过高，比如在脚本末尾添加find $HOME -name "db_prod-*.tar" -mtime +7 -delete，仅保留7天内的备份文件。
降低同步资源开销：如果生产库数据量较大，全量pg_dump+pg_restore的方式对网络、IO资源消耗过高，可以改用PostgreSQL逻辑复制实现增量同步，支持按需同步指定表，大幅降低同步耗时和资源占用。
提升合规性：当前方案会将完整生产数据落地到staging环境再做脱敏，存在合规风险。可以在pg_dump阶段通过--exclude-table参数直接排除敏感表，或使用专业数据脱敏工具在数据导出过程中完成敏感信息替换，避免敏感数据流出生产集群。
加速恢复流程：pg_restore添加-j N参数（N为CPU核心数的1-2倍）开启多线程恢复，大幅提升大库的恢复速度。

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