В данном разделе описывается процесс обновления Digital Q.DataBase.
Текущий номер версии Digital Q.DataBase состоит из основного (мажорного) и дополнительного (минорного) номеров. Например, в номере версии 17.4
число 17 является номером мажорной версии, а 4 — номером минорной версии;
В имени файла дистрибутива также указывается дата выпуска в формате YYMMDD (год, месяц, день) и дополнительная информация: номер сборки и версия
операционной системы, для которой собран дистрибутив.
Для мажорных выпусков Digital Q.DataBase, внутренний формат хранения данных может быть изменен, что осложняет процедуру обновления. Традиционный метод переноса данных в новую мажорную версию заключается в создании дампа и восстановлении базы данных, хотя это может занять много времени. Более быстрым методом является pg_upgrade. Также доступны методы репликации, которые рассматриваются ниже.
Новые мажорные версии обычно вносят некоторые видимые пользователю несовместимости, поэтому могут потребоваться изменения в программном коде приложений. Все значимые для пользователя изменения перечислены в замечаниях к выпуску (Приложение 8.5). Хотя обновление с одной мажорной версии на другую возможно без установки промежуточных версий, рекомендуется ознакомиться с замечаниями к выпуску для всех промежуточных мажорных версий.
Осмотрительным пользователям рекомендуется протестировать клиентские приложения на новой версии перед полным переходом; поэтому часто рекомендуется выполнять параллельную установку старой и новой версий. При тестировании Digital Q.DataBase основного обновления следует учитывать следующие категории возможных изменений:
Возможности мониторинга и управления сервером, доступные администраторам, часто меняются и совершенствуются в каждом основном выпуске.
Как правило, это подразумевает появление новых возможностей SQL-команд, а не изменение логики работы, если иное специально не указано в замечаниях к выпуску.
Обычно такие библиотеки, как libpq, добавляют новые функциональные возможности, если иное не оговорено в замечаниях к выпуску.
Изменения в системных каталогах обычно затрагивают только инструменты управления базами данных.
Это касается изменений в API внутренних функций сервера, написанных на языке программирования C. Такие изменения затрагивают код, обращающийся к функциям серверной части на низком уровне.
Одним из способов обновления является выгрузка данных из одной основной версии Digital Q.DataBase и их восстановление в другой — для выполнения этой операции необходимо использовать логическое средство резервного копирования, такое как pg_dumpall; методы резервного копирования на уровне файловой системы не будут работать. (Существуют механизмы проверки, предотвращающие использование каталога данных с несовместимой версией Digital Q.DataBase, поэтому попытка запуска сервера неверной версии с указанием каталога данных не причинит серьёзного вреда.)
Рекомендуется использовать pg_dump и pg_dumpall программы из состава более новой версии Digital Q.DataBase, чтобы воспользоваться преимуществами улучшений, которые могли быть реализованы в этих программах. Текущие версии программ выгрузки могут считывать данные из любой версии сервера, начиная с версии 9.2.
В данных инструкциях предполагается, что текущая установка находится в
/usr/local/pgsql каталоге, а область данных расположена в
/usr/local/pgsql/data. Укажите соответствующие пути
нужным образом.
При создании резервной копии убедитесь, что база данных не обновляется. Это не влияет на целостность резервной копии, но изменённые данные, разумеется, не будут в неё включены. При необходимости отредактируйте права доступа в файле /usr/local/pgsql/data/pg_hba.conf
(или его аналоге), чтобы запретить доступ всем, кроме текущего пользователя.
См. Глава 3.5 для получения дополнительной информации об
управлении доступом.
Для создания резервной копии установленной базы данных введите команду:
pg_dumpall > выходной_файл
Для создания резервной копии можно использовать команду pg_dumpall из текущей используемой версии; см. Раздел 3.10.1.2 для получения более подробных сведений. Тем не менее, для достижения наилучших результатов рекомендуется использовать pg_dumpall команду из состава Digital Q.DataBase 17.4, так как эта версия содержит исправления ошибок и улучшения по сравнению с более старыми версиями. Хотя этот совет может показаться необычным, поскольку новая версия ещё не установлена, ему рекомендуется следовать, если планируется установка новой версии параллельно со старой. В этом случае можно завершить установку в обычном режиме и перенести данные позже. Это также позволит сократить время простоя.
Остановить старый сервер:
pg_ctl stop
В системах, где запуск Digital Q.DataBase запускается при загрузке системы, вероятно, существует файл автозапуска, выполняющий те же функции. Например, в Red Hat Linux системе можно обнаружить, что работает следующее:
/etc/rc.d/init.d/postgresql stop
См. Глава 3.3 для получения подробных сведений о запуске и остановке сервера.
При восстановлении из резервной копии следует переименовать или удалить старую директорию установки, если она не привязана к конкретной версии. Рекомендуется переименовать директорию, а не удалять её, на случай возникновения проблем и необходимости отката к предыдущему состоянию. Следует учитывать, что директория может занимать значительное дисковое пространство. Для переименования директории используйте команду следующего вида:
mv /usr/local/pgsql /usr/local/pgsql.old
(Директорию следует перемещать как единое целое, чтобы относительные пути остались без изменений.)
Установить новую версию Digital Q.DataBase как описано в Глава 3.1.
При необходимости создать новый кластер баз данных. Помните, что данные команды необходимо выполнять от имени специальной учетной записи пользователя базы данных (которая уже должна существовать, если выполняется обновление).
/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 выходной_файл
используя новый psql.
Минимального времени простоя можно добиться путем установки нового сервера в другую директорию и параллельного запуска старого и нового серверов на разных портах. После этого можно использовать команду вида:
pg_dumpall -p 5432 | psql -d postgres -p 5433
для переноса данных.
Модуль pg_upgrade позволяет выполнить миграцию установленной системы между мажорными Digital Q.DataBase
версиями без перезаписи данных (in-place). Обновление можно выполнить за несколько минут,
в частности при использовании режима --link mode. Для этого требуются действия, аналогичные описанным
pg_dumpall выше, например: запуск и остановка сервера,
выполнение initdb. В pg_upgrade документации приведен перечень необходимых шагов.
Также для создания резервного сервера с обновленной версией можно использовать методы логической репликации Digital Q.DataBase. Это возможно, так как логическая репликация поддерживает взаимодействие между различными мажорными версиями Digital Q.DataBase. Резервный сервер может быть расположен на том же или на другом компьютере. Как только он будет синхронизирован с основным сервером (работающим под управлением старой версии Digital Q.DataBase), можно сменить основной сервер, сделав ведомый сервер основным и остановив старый экземпляр базы данных. Такое переключение при обновлении приводит к простою длительностью всего в несколько секунд.
Данный метод обновления может быть реализован как с помощью встроенных средств логической репликации, так и с использованием внешних систем логической репликации, таких как pglogical, Slony, Londiste, и Bucardo.