17.6. Обновление PostgreSQL кластера

В этом разделе будет рассказано о том, как перевести вашу БД с одного PostgreSQL релиза на более новый.

Мажорные версии PostgreSQL определяются первыми двумя группами цифр номера версии, например 8.4; минорные - третьей группой, например 8.4.2 - второй минорный релиз мажорной версии 8.4. При изменении минорного релиза формат внутреннего хранилища не изменяется и он всегда совместим с более ранними и поздними минорными релизами того же мажорного релиза; другими словами 8.4.2 совместим с 8.4, 8.4.1 и 8.4.6. Для того, чтобы провести обновление между совместимыми версиями, Вы просто замещаете выполняемые файлы на выключенном сервере и затем запускаете его. Каталог данных остаётся прежним - минорные обновления очень просты.

Для мажорных релизов PostgreSQL формат внутреннего хранилища может быть изменён и это усложняет обновления. Традиционный метод перемещения данных между мажорными версиями - создать дамп и перезагрузить БД. Но есть и другие методы, описанные ниже.

Кроме того, новые мажорные релизы обычно содержат несовместимость заметную для пользователя, так что может потребоваться изменение клиентского ПО. Все такие изменения перечислены в примечаниях к релизу (Приложение Е); особое внимание уделите разделу "Миграция". Если Вы производите обновления между мажорными версиями, обязательно прочитайте все примечания к релизу для промежуточных версий.

Осторожные пользователи могут захотеть протестировать клиентские приложения на новой версии перед тем, как переключаться на неё окончательно. Поэтому зачастую является хорошей идеей установить параллельно новую версию для тестирования. Когда Вы производите тестирование мажорной версии PostgreSQL, обратите внимание на изменения в следующих категориях:

Администрирование

Возможности управления и мониторинга сервера зачастую меняются и улучшаются в каждом мажорном релизе

SQL

Обычно добавляются новые команды SQL и не меняется поведение существующих, если это специально не оговорено

API библиотеки

Обычно в библиотеках лишь добавляется новая функциональность, если что-то другое не указано в примечаниях к релизу

Системные каталоги

Изменение системных каталогов обычно затрагивает только инструменты управления БД

C-API сервера

Сюда относятся изменения в API бэкенда, написанного на C. Эти изменения влияют на код функций глубоко в сервере.

17.6.1 Обновление данных посредством pg_dump

Для того, чтобы задампить данные с одной мажорной версии PostgreSQL и загрузить их в другую, Вы должны использовать pg_dump; резервное копирование на уровне ФС не будет работать. (Более того, есть проверки, которые не позволят Вам использовать каталог данных из несовместимой версии PostgreSQL. Так что ничего страшного не случится, если Вы запустите сервер на другом каталоге данных).

Рекомендуется использовать программы pg_dump  и pg_dumpall более новой версии PostgreSQL чтобы воспользоваться новыми возможностями, которые могли в них появиться. Текущие релизы программ дампа могут считывать данные с серверов начиная с версии 7.0.

Следующие инструкции предполагают что ваша текущая версия установлена в /usr/local/pgsql, а данные хранятся в /usr/local/pgsql/data:

1. Перед тем, как создать резервную копию данных, убедитесь, что данные вашей БД не будут обновлены. Обновление не повлияет на целостность бакупа, но новые данные в него просто не войдут. Если необходимо, отредактируйте разрешения в файле /usr/local/pgsql/data/pg_hba.conf (или соответствующий файл) для того, чтобы закрыть доступ всем, кроме Вас. В главе 19 о контроле доступа говорится более подробно.
   Для того, чтобы сделать резервную копию вашей БД выполните:
   pg_dumpall > outputfile
   Если Вам нужно сохранить OID'ы (например, если Вы используете их как внешние ключи), используйте опцию -о
   Для того, чтобы сделать резервную копию, можно использовать pg_dumpall используемой версии. Но лучших результатов можно добиться используя комманду pg_dumpall для PostgreSQL 9.1.1, так как эта версия содержит исправления ошибок и некоторые улучшения по отношению к прошлой версии. Хотя этот совет может казаться странным, ведь Вы же ещё не установили новую версию, им можно воспользоваться, если Вы хотите использовать новую версию параллельно со старой. В этом случае Вы можете сперва установить новую версию, после чего перенести данные. Кроме того, это сократит время недоступности сервера.
2. Выключите старый сервер:
   pg_ctl stop
   На системах, где PostgreSQL запускается при запуске, скорее всего есть файл, который делает то же самое. Например, на Red Hat Linux это можно сделать так:
   /etc/rc.d/init.d/postgresql stop
   В главе 17 подробнее говорится о запуске и остановке сервера.
3. Если Вы восстанавливаете данные из резервной копии, то переименуйте или удалите старую папку установки. Лучше всего, конечно, её переименовать, а не удалить, так что в случае какой-либо проблемы Вы сможете быстро её восстановить. Однако помните, что она может занимать значительное место на диске. Для того, чтобы переименовать каталог, воспользуйтесь командой вроде этой:
   mv /usr/local/pgsql /usr/local/pgsql.old
   (Убедитесь, что Вы перемещаете каталог целиком, чтобы сохранить относительные пути)
4. Установите новую версию PostgreSQL, как это описано в разделе 15.4
5. Создайте новый кластер БД, если это необходимо. Помните, что Вы должны выполнить это, зайдя под пользователем БД (в принципе, Вы под ним уже должны быть, если Вы обновляетесь):
   /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
6. Восстановите предыдущую версию pg_hba.conf и изменений в postgresql.conf
7. Запустите сервер БД из под пользователя БД:
   /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
8. И, наконец, восстановите данные из резервной копии:
   /usr/local/pgsql/bin/psql -d postgres -f outputfile
   используя новую версию psql

Сократить время недоступности сервера можно установив новый сервер в другой каталог и запустив параллельно оба сервера на разных портах. После чего можно сделать что-то вроде этого для передачи данных:

pg_dumpall -p 5432 | psql -d postgres -p 5433

17.6.2 Обновление без дампа

Модуль pg_upgrade позволяет переместить данные с одной мажорной версии PostgreSQL на следующую. Сделать это можно за несколько минут.

Кроме того, можно использовать методы репликации, вроде Slony, для создания резервного сервера с обновлённой версией PostgreSQL. Это возможно, поскольку Slony поддерживает репликацию между разными мажорными версиями PostgreSQL. Резервный сервер может быть как на той же машине, так и на другой. Как только он синхронизирован с мастером (где запущена старая версия PostgreSQL), Вы можете изменить его роль на мастера и выключить старый сервер. Такой метод позволяет сократить время недоступности сервера до нескольких секунд.