ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

自托管 Supabase 怎么用 pg_upgrade 把 Postgres 从 15 升级到 17?

自托管 Supabase 怎么用 pg_upgrade 把 Postgres 从 15 升级到 17? 自托管 Supabase 怎么用 pg_upgrade 把 Postgres 从 15 升级到 17【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase如果你的自托管 Supabase 还跑在 Postgres 15 上需要把数据库升级到 Postgres 17官方提供了一条基于pg_upgrade的原地升级路径仓库里的升级脚本 docker/utils/upgrade-pg17.sh 会拉取 Postgres 17 镜像、在临时容器里执行pg_upgrade迁移数据、交换数据目录并以 Postgres 17 启动整个 Supabase 栈。整个过程有逐步确认提示原始数据目录会保留为备份验证通过前可以回滚。完整说明见 apps/docs/content/guides/self-hosting/postgres-upgrade-17.mdx。本文只覆盖「升级已有部署」这一条路径没有存量数据的新部署直接以 Postgres 17 启动即可不需要升级操作。升级前确认前提条件在运行脚本之前环境必须满足以下条件脚本的预检会逐项检查不满足会直接报错退出所有自托管 Supabase 容器正在运行脚本要求升级前全部处于运行状态磁盘可用空间至少为当前数据库大小的 2 倍 5 GBpg_upgrade会复制整个数据目录且升级 tarball 约 1.2 GB 压缩后大小系统有bash并且脚本必须以 root 或sudo运行从docker/目录下执行脚本目录下需要存在docker-compose.yml、docker-compose.pg17.yml和.env含POSTGRES_PASSWORD。另外脚本会检查当前数据库镜像是否确实是 Postgres 15supabase/postgres:15.*如果发现已经在跑 Postgres 17 镜像会直接终止遇到非 15/17 的镜像也会终止。先检查 Postgres 17 中不存在的扩展以下扩展没有 Postgres 17 构建如果数据库里装了其中任何一个且你还需要用它不要继续升级如果确认可以丢弃脚本会提示你确认后自动DROP EXTENSION ... CASCADE扩展说明timescaledb未构建 Postgres 17 版本plv8未构建 Postgres 17 版本plcoffeeplv8 的配套扩展pllsplv8 的配套扩展自托管 Supabase 默认不安装这些扩展只有手动装过才会触发。创建独立备份升级脚本最后会自动把 pgsodium 密钥和原数据目录保存为备份但官方文档明确要求你在开始前自己再建一份独立备份以防磁盘故障等问题# 备份数据库数据目录 cp -a ./volumes/db/data ./volumes/db/data-manual-backuppgsodium 加密密钥存放在名为db-config的 Docker 命名卷里上面的cp -a覆盖不到它需要单独备份如果你使用了 Vault secrets丢失这个密钥意味着 secrets 不可恢复docker compose run --rm db cat /etc/postgresql-custom/pgsodium_root.key ./pgsodium_root.key.backup可选的逻辑备份docker exec supabase-db pg_dumpall -h localhost -U supabase_admin ./pg15_dump.sql运行升级脚本进入docker/目录后执行cd docker sudo bash utils/upgrade-pg17.sh脚本在磁盘空间检查、是否禁用扩展、是否删除上次遗留的备份等关键步骤都会请求确认非交互场景可以加--yes跳过所有提示。如果/tmp或TMPDIR所在文件系统空间有限可以把脚本的暂存目录指到别处——tarball 和升级脚本会放在这个目录下sudo TMPDIR/mnt/my-tmp bash utils/upgrade-pg17.sh脚本实际做了什么预检通过后脚本按以下顺序执行理解这些步骤有助于判断卡在哪一步拉取 Postgres 17 镜像用于升级 tarball 和目标运行镜像各一个并从镜像中提取升级二进制打包成 tarball首次运行需要几分钟之后缓存在./volumes/db/pg17_upgrade_bin_*.tar.gz丢弃检测到的不兼容扩展如果你确认过备份 pgsodium 密钥然后docker compose down停止所有 Supabase 容器在临时 Postgres 15 容器内跑pg_upgrade迁移全部数据会先跑pg_upgrade --check验证可行性再实际迁移pg_graphql、pg_stat_monitor、pg_backtrace会被临时禁用升级后重新启用postgres角色会被临时授予 superuser 后收回在临时 Postgres 17 容器内应用扩展兼容性补丁Wrappers、pg_net、pg_cron、Vault 的所有权与授权修正、重新启用扩展、执行vacuumdb --all --analyze-in-stages重建优化器统计交换数据目录——原 Postgres 15 数据目录保留为./volumes/db/data.bak.pg15以 Postgres 17 启动整个 Supabase 栈compose 叠加docker-compose.pg17.yml覆盖文件应用升级后迁移并把已安装扩展版本对齐到目标镜像。如果pg_upgrade阶段initiate.sh失败脚本会清理临时容器并退出此时你的数据目录未被移动或删除修好原因后重跑脚本即可。验证升级结果脚本自身在结束前会执行SELECT version();并列出全部扩展供你核对。你也可以自行验证 Postgres 17 已生效docker compose exec db psql -U postgres -c SELECT version();确认应用和服务都能正常工作后升级才算完成。注意验证阶段不要删除任何备份回滚只在./volumes/db/data.bak.pg15存在时才可能。回滚到 Postgres 15如果升级后发现问题按以下命令以 root 运行恢复 Postgres 15。注意它会删除当前的 Postgres 17 数据目录并用备份目录替换docker compose down \ rm -rf ./volumes/db/data \ mv ./volumes/db/data.bak.pg15 ./volumes/db/data \ sh run.sh config add pg15 \ docker compose run --rm db chown -R postgres:postgres /etc/postgresql-custom/ \ sh run.sh start这条命令恢复原始数据目录、修正db-config卷的文件属主Postgres 15 和 17 镜像使用不同的用户 ID所以属主和启动都必须是 15 的并通过 run.sh 的config add机制叠加docker-compose.pg15.yml覆盖文件让 Supabase 继续用旧的 Postgres 15 镜像。如果脚本内置的回滚不够用比如db-config卷里的 pgsodium 密钥需要恢复可以改用前面手动创建的备份先把./volumes/db/data-manual-backup复制回./volumes/db/data并sh run.sh config add pg15再把./pgsodium_root.key.backup写回db-config卷的/etc/postgresql-common/pgsodium_root.key……准确地说写回路径是/etc/postgresql-custom/pgsodium_root.key然后修正属主和权限docker compose run --rm db \ sh -c cat /etc/postgresql-custom/pgsodium_root.key ./pgsodium_root.key.backup \ docker compose run --rm db \ chown -R postgres:postgres /etc/postgresql-custom/ \ docker compose run --rm db \ chmod 600 /etc/postgresql-custom/pgsodium_root.key最后sh run.sh start启动 Postgres 15。常见问题排查pg_upgrade因复制槽报错。数据库里存在活动复制槽时pg_upgrade无法进行。默认自托管安装没有复制槽如果你配置过逻辑复制或自定义复制升级前先删除槽位升级后再手动重建docker exec supabase-db psql -h localhost -U supabase_admin -d postgres -c SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots; 然后重跑升级脚本。数据目录报 Permission denied。脚本会自动修正文件属主15 和 17 的用户 ID 不同如果仍然报权限错误手动修正docker compose run --rm db \ chown -R postgres:postgres /var/lib/postgresql/data升级后服务连不上数据库。重启所有服务让它们拾取新数据库sh run.sh recreate升级中磁盘空间不足。升级需要同时容纳 tarball约 1.2 GB 压缩、pg_upgrade生成的完整数据副本和保留的原始数据。脚本暂存目录默认用/tmp空间不足时如前述用TMPDIR指向更大的目录。若已经在升级中途耗尽空间最稳妥的做法是回滚、腾出空间后再重试。升级后想补充自定义 Postgres 配置。Postgres 17 镜像启动时会加载/etc/postgresql-custom/conf.d/下的.conf文件该目录在db-config命名卷上重启后保留Postgres 15 镜像不加载conf.d/。写入示例以max_connections 200为例该参数需要完全重启生效docker exec supabase-db bash -c cat /etc/postgresql-custom/conf.d/custom.conf EOF max_connections 200 EOF sh run.sh restart db用docker compose exec db psql -U postgres -c SHOW max_connections;验证新配置已生效。验证后清理确认一切正常后可以删掉备份和缓存的升级 tarball 释放空间。以下命令会永久删除Postgres 15 备份目录、pgsodium 密钥备份和升级二进制缓存删除后将无法再回滚到 15rm -rf ./volumes/db/data.bak.pg15 \ ./volumes/db/pgsodium_root.key.bak.pg15 \ ./volumes/db/pg17_upgrade_bin_*.tar.gz另外两个边界升级过程中切勿执行docker compose down -v它会销毁命名卷包括 pgsodium 根密钥使 Vault secrets 不可恢复以及升级后的数据库里原本使用的扩展版本会被脚本对齐到目标镜像的默认版本升级输出中的扩展版本列表可以用来核对差异。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表