作为服务器升级的一部分,我们将从 32 位 Linux 升级到 64 位 Linux(如果有区别的话,则是 Gentoo),并将 Postgresql 9.1 升级到 9.2。我花了很长时间使用 pg_upgrade 升级数据库...
我的第一次尝试是存储旧的(32 位 9.1)pgsql bin&lib 目录,更新系统,然后在更新的(64 位)系统上运行:
pg_upgrade -b pgsql.old/bin -B /usr/lib64/postgresql-9.2/bin -d data.old -D data.new
失败是因为 pg_upgrade 尝试使用错误的 libpq.so.5(64 位系统版本,而不是 pgsql.old/lib 中的 32 位版本)运行 pgsql.old/bin/pg_ctl。如果我将 LD_LIBRARY_PATH 设置为指向 pgsql.old/lib,那么我可以手动运行旧的 32 位 pg_ctl,但这似乎对 pg_upgrade 没有帮助。
因此,我想我只需安装 64 位 Postgresql 9.1 和 9.2。现在,当我运行:
pg_upgrade -b /usr/lib64/postgresql-9.1/bin -B /usr/lib64/postgresql-9.2/bin -d data.old -D data.new
二进制文件运行良好,但升级提前失败:
old and new pg_controldata alignments are invalid or do not match
我猜这是由于数据库中的 32 位与 64 位对齐问题造成的?
我知道 pg_dump/pg_restore 可以很好地工作,但出于速度原因,如果可能的话,我更愿意使用 pg_upgrade。这不是一次性交易 - 我们在现场有几百个系统需要以自动方式更新(通过使用适当脚本的可启动拇指驱动器)。
答案1
您不能使用 pg_upgrade 从 32 位升级到 64 位,或者从任何 OS/CPU/平台升级到任何其他 OS/CPU/平台。数据文件依赖于平台,而 pg_upgrade 的工作方式是复制(或链接)未更改的数据文件。所以这永远不会奏效。
此时您的选择是转储/恢复,或使用逻辑复制系统来移动数据(Slony、Londiste、Bucardo)。
答案2
我绝不会像你那样做。仅供参考,我从 6.x 时代就开始使用 PostgreSQL 了(也就是说很多年了)。
我总是毫无疑问地采取这样的做法:
- 使用 pg_dump 转储旧版本
- 安装新版本,可能与您当前版本一起安装。我总是符号链接默认位置。例如,如果 pgsql 最终位于 /usr/local/pgsql,我会将其更改为 /usr/local/pgsql-v9.1.2,然后将其与 pgsql 符号链接,这样我的 RC 脚本就不需要进行大量调整,我的 LD_CONFIG 也不需要
- 使用刚刚安装的新版本初始化新的数据库环境
- 使用 psql 恢复数据
我使用自定义 RC 脚本来停止、启动和重新启动邮政局长,并且在其中我有指向当前数据和 xlog 目录的设置。
另外,我知道您正在使用特定发行版的包管理器。我避免这种情况,并始终从源代码构建 PostgreSQL。