Ошибка обновления кластера postgresql с 9.1 до 9.2

Question

Я на Ubuntu 12.04 64 бит на Amazon EC2. Пытается обновить 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 

Любая помощь будет оценена. Спасибо.

Answer 1

Основной причиной вашей проблемы является то, что hot_standby является on в postgresql.conf, поэтому сервер доступен только для чтения.

В общем, если у вас возникли проблемы с pg_upgradecluster из pg_wrapper инструментов, как правило, упакованные в Debian и Ubuntu вы можете сделать обновление вручную кластера вместо:

• Запустить старый сервер
• 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 инструмент в месте преобразовать базу данных, но это может запутать pg_wrapper.

Эти шаги могут быть упрощены с помощью команды pg_dumpall, чтобы создать весь кластерный дамп, но мне это не нравится. Я думаю, что восстановление pg_dumpall дампов оставляет желать лучшего с точки зрения обработки ошибок, трудно извлечь отдельные DB или таблицы из дампа, и он не может быть восстановлен в одной транзакции. Я предпочитаю использовать только pg_dumpall только для глобальных пользователей, таких как пользователи/группы/роли, и pg_dump резервные копии для отдельных баз данных для отдельных баз данных, как показано выше.