3

Amazon EC2 で Ubuntu 12.04 64 ビットを使用しています。postgresql を 9.1 から 9.2 にアップグレードしようとしています。

$ uname -a
Linux db2 3.2.0-32-virtual #51-Ubuntu SMP Wed Sep 26 21:53:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ apt-cache policy postgresql
postgresql:
  Installed: 9.1+136~precise
  Candidate: 9.1+136~precise
  Version table:
 *** 9.1+136~precise 0
    500 http://ppa.launchpad.net/pitti/postgresql/ubuntu/ precise/main amd64                 Packages
    100 /var/lib/dpkg/status
 9.1+129ubuntu1 0
    500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
 9.1+129 0
    500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

私がフォローしているアップグレードプロセスは次のとおりです。

$ sudo add-apt-repository ppa:pitti/postgresql
$ sudo apt-get update
$ sudo apt-get install postgres-9.2
$ sudo pg_dropcluster --stop 9.2 main
$ sudo pg_upgradecluster 9.1 main /var/lib/postgresql/9.2
Stopping old cluster...
Disabling connections to the old cluster during upgrade...
Restarting old cluster with restricted connections...
Creating new cluster (configuration: /etc/postgresql/9.2/main, data: /var/lib/postgresql/9.2)...
Moving configuration file /var/lib/postgresql/9.2/postgresql.conf to /etc/postgresql/9.2/main...
Moving configuration file /var/lib/postgresql/9.2/pg_hba.conf to /etc/postgresql/9.2/main...
Moving configuration file /var/lib/postgresql/9.2/pg_ident.conf to /etc/postgresql/9.2/main...
Configuring postgresql.conf to use port 5433...
Disabling connections to the new cluster during upgrade...
Roles, databases, schemas, ACLs...
Fixing hardcoded library paths for stored procedures...
ERROR:  cannot set transaction read-write mode during recovery
Error: Could not fix library paths
Re-enabling connections to the old cluster...
Re-enabling connections to the new cluster...
Error during cluster dumping, removing new cluster

どんな助けでも大歓迎です。ありがとうございました。

4

2 に答える 2

4

問題の根本原因はにhot_standbyあるため、サーバーは読み取り専用です。onpostgresql.conf

pg_upgradecluster通常、Debian および Ubuntu に通常パッケージ化されているツールで問題が発生した場合はpg_wrapper、代わりに手動でクラスターをアップグレードできます。

  • 古いサーバーを起動する
  • sudo -i -u postgres
  • for db in $(psql --tuples-only template1 -c "select datname from pg_database where datname not in ('template0','template1','postgres','template_postgis');"); do pg_dump -Fc -f $db.backup $db; done
  • pg_dumpall --globals-only > globals.sql
  • 古いサーバーを停止する
  • initdb削除した場合は、新しいサーバー上の新しいクラスター。で、これpg_wrapperに使うと思いますpg_createcluster。
  • 新しいサーバーを起動します。それでもpostgresユーザーとして：
  • psql -f globals.sql
  • for backup in *.backup; do pg_restore --dbname postgres --create $backup; done

または、pg_upgradeツール ツールを使用して DB をインプレース変換しますが、混乱する可能性がありpg_wrapperます。

これらの手順は、コマンドを使用してクラスター全体のダンプを作成することで簡素化できますがpg_dumpall、あまり好きではありません。ダンプの復元には、エラー処理の点で多くの要望が残されていると思います。pg_dumpallダンプから個々の DB やテーブルを抽出するのは難しく、1 回のトランザクションですべてを復元することはできません。pg_dumpall上記のように、ユーザー/グループ/ロールなどのグローバルとpg_dump、個々のデータベースのデータベースごとのカスタム形式のバックアップのみを使用することを強く好みます。

于 2012-10-18T00:02:03.483 に答える