Данный раздел рассказывает как обновить ваши данные в базе данных
с одного выпуска PostgreSQL на более новый.
Старшие номера версий PostgreSQL предоставляются
двумя цифрами через точку, например, 8.4. Младшие номера версий
PostgreSQL указываются третьей цифрой, например,
8.4.2 - это вторая младшая версия выпуска 8.4. При смене младших
номеров версий внутренний формат хранения никогда не меняется,
так что и ранние и поздние младшие версии одной и той же старшей
версии всегда совместимы, например, версия 8.4.2 совместима с
любыми версиями 8.4, 8.4.1 и 8.4.6. Чтобы выполнить обновление
между совместимыми версиями, вы просто заменяете исполняемые
файлы при остановленном сервере и перезапускаете сервер. Каталог
data с данными остаётся без изменений — обновлять младшие
версии очень просто.
Для старших версий выпусков PostgreSQL,
внутренний формат хранения может быть изменён, что усложняет
обновления. Традиционный метод переноса данных на новую старшую
версию состоит в создании дампа и его загрузке. Доступны и другие
методы, которые рассматриваются ниже.
Новые старшие версии также обычно вводят некоторые несовместимости,
заметные пользователю, так как могут потребоваться изменения в
программировании приложений. Все значимые изменения перечисляются
в замечаниях к выпуску (Appendix E); уделите особое
внимание разделу с названием "Migration" (миграция). Если вы
производите обновление через несколько старших версий, обязательно
прочитайте замечания к выпускам для каждой промежуточной версии.
Осторожные пользователи захотят протестировать свои клиентские
приложения на новой версии перед тем как полностью на неё переключиться;
таким образом, часто является хорошей идеей выполнить одновременную
установку старой и новой версий. Когда тестируется обновление какой-либо
старшей версии PostgreSQL, рассматривайте следующие
категории возможных изменений:
- Администрирование
Возможности доступные для администраторов для мониторинга и
управления сервером часто изменяются и улучшаются с каждой
старшей версией.
- SQL
Обычно изменения включают новые SQL команды без изменений в поведении,
за исключением специально оговоренных в замечаниях к выпуску.
- API библиотеки
Обычно изменения в таких библиотеках как libpq
только добавляют новую функциональность, но опять-таки за исключением
оговоренных в замечаниях к выпуску.
- Системные каталоги
Изменения системного каталога обычно влияют только на инструменты
управления СУБД.
- Серверный API языка Cи
Включают в себя изменения в API функций бакэнда, которые написаны
на языке программирования Си. Такие изменения оказывают эффект на
код, который обращается к функциям бакэнда глубоко внутри сервера.
Чтобы сделать дамп данных из одной версии PostgreSQL и
загрузить его на другую, вы должны использовать pg_dump;
методы резервного копирования на уровне файловой системы работать не будут.
(Существуют проверки, которые предотвращают использование каталога
data с данными с несовместимой версией PostgreSQL,
так что при попытке запустить неправильную версию сервера на каталоге
с данными большого вреда не будет.)
Рекомендуется, чтобы вы использовали программы pg_dump и
pg_dumpall от новой версии PostgreSQL,
для получения преимущества расширений, которые могут быть сделаны
в этих программах. Текущие выпуски программы dump могут читать данные
от любого сервера до версии 7.0.
Эти инструкции предполагают, что ваши данные находится в каталоге
/usr/local/pgsql и что область данных находится в
каталоге /usr/local/pgsql/data. Соответственно,
подставляйте ваши пути.
Для создания резерной копии, убедитесь, что ваша СУБД не
обновляется. Это не окажет эффекта на целостность резервной копии,
но изменение данных, конечно, в резервную копию включено не будет.
Если необходимо, измените права доступа в файле
/usr/local/pgsql/data/pg_hba.conf (или его эквивалете),
чтобы запретить доступ для всех за исключением вас.
См. Chapter 19 для дополнительной
информации по управлению доступом.
Чтобы выполнить резервное копирование всех данных, введите:
pg_dumpall > файл_вывода
Если вам нужно сохранить OID (в случаях, когда вы используете
их как внешние ключи), то используйте опцию -o,
при запуске pg_dumpall.
Чтобы выполнить резервное копирование, вы можете использовать команду
pg_dumpall из версии, которую вы используете
в данный момент. Для наилучших результатов, однако, попытайтесь
использовать команду pg_dumpall из
PostgreSQL 9.1.1, которая содержит
все исправления ошибок и улучшения, начиная со старых версий.
Хотя этот совет может показаться своеобразным, так как у вас
ещё не установлена новая версия, всё же желательно следовать ему,
если вы планируете установить новую версию параллельно со старой.
В этом случае, вы можете завершить установку новой версии обычным
образом и перенести данные позднее. Также этот способ снизит
время простоя.
Остановите старый сервер:
pg_ctl stop
В системах, которые запускают PostgreSQL при загрузке,
предположительно есть файл запуска, который делает то же самое.
Например, в системе Red Hat Linux
это делается так:
/etc/rc.d/init.d/postgresql stop
Подробности о запуске и остановке сервера СУЬД см. в Chapter 17.
Для выполнения восстановления из резервной копии, переименуйте или
удалите старый каталог с установкой. Переименовать каталог вместо
его удаления - это хорошая идея, в случае если у вас возникнут проблемы
и вам нужно будет вернуть всё назад. Держите в голове, что данный
каталог может занимать значительное место на диске. Чтобы переименовать
каталог, используйте команду типа этой:
mv /usr/local/pgsql /usr/local/pgsql.old
(Убедитесь, что вы переименовывайте каталог как неделимый элемент, так
чтобы относительные пути остались неизменными.)
Установите новую версию PostgreSQL как
рассказывается в
Section 15.4.
Если необходимо, создайте новый кластер баз данных. Помните, что
вы должны запустить эти команды после того как войдёте в систему
пользователем под специальной учётной записью (которая уже есть,
если вы выполняете обновление).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Восстановите ваш предыдущий файл pg_hba.conf и
все сделанные вами изменения в postgresql.conf.
Запустите сервер СУБД, снова используя специальную учётную
запись пользователя:
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Наконец, восстановите ваши данные из резервной копии:
/usr/local/pgsql/bin/psql -d postgres -f outputfile
используя новую команду psql.
Минимального простоя можно добиться, установив новый сервер в другой
каталог и запустив оба, старый и новый серверы параллельно, на
разных портах. Затем вы можете сделать что-то такое:
pg_dumpall -p 5432 | psql -d postgres -p 5433
чтобы перенести ваши данные.
Модуль pg_upgrade позволяет
выполнить миграцию с одной старшей установленной версии
PostgreSQL на следующую. Обновления могут
быть выполнены в течение нескольких минут.
Также возможно использовать определённые методы репликации, такие как
Slony, для создания сервера горячего резерва с обновляемой
версией PostgreSQL. Сервером горячего резерва может
быть и тот же самый и другой компьютер. После завершения синхронизации
с мастер-сервером (запущенным на старой версии PostgreSQL),
вы можете переключить мастер-серверы и сделать сервером горячего резерва
мастер-сервер и остановить старый экземпляр СУБД. В результате таких
переключений, время простоя при обновлении не будет превышать всего
нескольких секунд.