18.6. Обновление кластера Postgres Pro
В этом разделе рассказывается, как обновить ваш кластер базы данных с одной версии Postgres Pro на другую.
Текущие номера версий Postgres Pro состоят из трёх цифровых групп: две из них берутся из версии PostgreSQL, а третья — номер релиза Postgres Pro. Например, в номере версии 12.11.2 число 12 обозначает основную версию, 11 — дополнительную, а 2 — номер выпуска Postgres Pro, то есть это второй выпуск после выхода PostgreSQL версии 12.11. Для выпусков Postgres Pro до версии 10.0 номера состояли из четырёх чисел, например 9.5.3.2. Тогда версия Postgres Pro образовывалась группой из трёх чисел версии PostgreSQL(например, 9.5.3), а четвёртая обозначала номер выпуска Postgres Pro, например цифра 2 означала, что это был второй выпуск Postgres Pro после выхода PostgreSQL версии 9.5.3.
Выпуски Postgres Pro одной дополнительной версии обычно совместимы с предыдущими и последующими выпусками. Если вы обновляете выпуск Postgres Pro на базе той же дополнительной версии, например с 12.11.1 до 12.11.2, обычно достаточно просто установить новый выпуск в текущий каталог инсталляции. Если же вы обновляете Postgres Pro на базе другой версии PostgreSQL, например с 12.11.1 до 12.15.1, вам следует обратить особое внимание на раздел «Миграция» в замечаниях к выпуску (Приложение E). Хотя вы можете перейти с одной версии на другую, пропустив промежуточные версии, обязательно ознакомьтесь с замечаниями к каждому выпуску, в том числе для каждой пропускаемой версии.
При обновлении основных версий Postgres Pro внутренний формат данных может меняться, что усложняет процедуру обновления. Традиционный способ переноса данных в новую основную версию — выгрузить данные из старой версии, а затем восстановить базу данных (это не самый быстрый вариант). Выполнить обновление быстрее позволяет pg_upgrade. Также для обновления можно использовать репликацию, как описано ниже.
Изменения основной версии обычно приносят какие-либо видимые пользователю несовместимости, которые могут требовать доработки приложений. Все подобные изменения описываются в замечаниях к выпуску (Приложение E), включая все необходимые для миграции инструкции в соответствующем разделе.
Осторожные пользователи обычно тестируют свои клиентские приложения с новой версией, прежде чем переходить на неё полностью; поэтому часто имеет смысл установить рядом старую и новую версии. При тестировании обновления основной версии Postgres Pro изучите следующие области возможных изменений:
- Администрирование
Средства и функции, предоставляемые администраторам для наблюдения и управления сервером, часто меняются и совершенствуются в каждой новой версии.
- SQL
В этой области чаще наблюдается появление новых возможностей команд SQL, чем изменение поведения существующих, если только об этом не говорится в замечаниях к выпуску.
- API библиотек
Обычно библиотеки типа libpq только расширяют свою функциональность, если об обратном так же не говорится в замечаниях к выпуску.
- Системные каталоги
Изменения в системных каталогах обычно влияют только на средства управления базами данных.
- API сервера для кода на C
Сюда относятся изменения в API серверных функций, которые написаны на языке программирования C. Такие изменения затрагивают код, обращающийся к служебным функциям глубоко внутри сервера.
18.6.1. Обновление данных с применением pg_dumpall
Один из вариантов обновления заключается в выгрузке данных из одной основной версии Postgres Pro и загрузке их в другую — для этого необходимо использовать средство логического копирования, например pg_dumpall; копирование на уровне файловой системы не подходит. (В самом сервере есть проверки, которые не дадут использовать каталог данных от несовместимой версии Postgres Pro, так что если попытаться запустить с существующим каталогом данных неправильную версию сервера, никакого вреда не будет.)
Для создания копии рекомендуется применять программы pg_dump и pg_dumpall от новой версии Postgres Pro, чтобы воспользоваться улучшенными функциями, которые могли в них появиться. Текущие версии этих программ способны читать данные любой версии сервера, начиная с 8.0.
В следующих указаниях предполагается, что сервер установлен в каталоге /usr/local/pgsql, а данные находятся в /usr/local/pgsql/data. Вам нужно подставить свои пути.
При запуске резервного копирования убедитесь в том, что в базе данных не производятся изменения. Изменения не повлияют на целостность полученной копии, но изменённые данные, само собой, в неё не попадут. Если потребуется, измените разрешения в файле
/usr/local/pgsql/data/pg_hba.conf(или подобном), чтобы подключиться к серверу могли только вы. За дополнительными сведениями об управлении доступом обратитесь к Главе 20.Чтобы получить копию всех ваших данных, введите:
pg_dumpall >выходной_файлДля создания резервной копии вы можете воспользоваться программой pg_dumpall от текущей версии сервера; за подробностями обратитесь к Подразделу 25.1.2. Однако для лучшего результата стоит попробовать pg_dumpall из Postgres Pro Enterprise 12.22.1, так как в эту версию вошли исправления ошибок и усовершенствования, по сравнению с предыдущими версиями. Хотя этот совет может показаться абсурдным, ведь новая версия ещё не установлена, ему стоит последовать, если вы планируете установить новую версию рядом со старой. В этом случае вы сможете выполнить установку как обычно, а перенести данные позже. Это также сократит время обновления.
Остановите старый сервер:
pg_ctl stopВ системах, где Postgres Pro запускается при загрузке, должен быть скрипт запуска, с которым можно сделать то же самое. Например, в Red Hat Linux может сработать такой вариант:
/etc/rc.d/init.d/postgresql stopПодробнее запуск и остановка сервера описаны в Главе 18.
При восстановлении из резервной копии удалите или переименуйте старый каталог, где был установлен сервер, если его имя не привязано к версии. Разумнее будет переименовать каталог, а не удалять его, чтобы его можно было восстановить в случае проблем. Однако учтите, что этот каталог может занимать много места на диске. Переименовать каталог можно, например так:
mv /usr/local/pgsql /usr/local/pgsql.old(Этот каталог нужно переименовывать (перемещать) как единое целое, чтобы относительные пути в нём не изменились.)
Установите новую версию Postgres Pro Enterprise.
При необходимости создайте новый кластер баз данных. Помните, что следующие команды нужно выполнять под именем специального пользователя БД (вы уже действуете под этим именем, если производите обновление).
/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
18.6.2. Обновление данных с применением pg_upgrade
Модуль pg_upgrade позволяет обновить инсталляцию Postgres Pro с одной основной версии на другую непосредственно на месте. Такое обновление может выполняться за считанные минуты, особенно в режиме --link. Для него требуются примерно те же подготовительные действия, что и для варианта с pg_dumpall: запустить/остановить сервер, выполнить initdb. Все эти действия описаны в документации pg_upgrade.
18.6.3. Обновление данных с применением репликации
Методы логической репликации также могут применяться для создания резервного сервера с обновлённой версией Postgres Pro. Это возможно благодаря тому, что логическая репликация поддерживается между разными основными версиями Postgres Pro. Резервный сервер может располагаться как на том же компьютере, так и на другом. Как только синхронизация с главным сервером (где работает старая версия Postgres Pro) будет завершена, можно сделать главным новый сервер, а старый экземпляр базы данных просто отключить. При таком переключении обновление возможно осуществить, прервав работу сервера всего на несколько секунд.
Этот вариант обновления можно осуществить, используя как встроенные средства логической репликации, так и внешние системы логической репликации, такие как pglogical, Slony, Londiste и Bucardo.
18.6. Upgrading a Postgres Pro Cluster
This section discusses how to upgrade your database data from one Postgres Pro release to a newer one.
Current Postgres Pro version numbers consist of three digit groups: two of them are based on the PostgreSQL version, and the third one is the Postgres Pro release number. For example, in the version number 12.11.2, the 12 is the major version number, the 11 is the minor version number, and the 2 is the Postgres Pro release number, meaning this would be the second release after the PostgreSQL release 12.11. For releases before Postgres Pro version 10.0, version numbers consist of four groups, for example, 9.5.3.2. In those cases, the Postgres Pro version consists of the three digit groups of the PostgreSQL version number, e.g., 9.5.3, and the fourth number is the Postgres Pro release number, e.g., 2, meaning this would be the second Postgres Pro release after the PostgreSQL release 9.5.3.
Postgres Pro releases of the same minor version are usually compatible with earlier and later releases. If you are upgrading from Postgres Pro of the same minor version, for example, from 12.11.1 to 12.11.2, it is usually enough to install the new version into your current installation directory. If you are upgrading from Postgres Pro based on another PostgreSQL minor version, for example, from 12.11.1 to 12.15.1, you should always pay attention to the section labeled "Migration" in the release notes (Appendix E). Though you can upgrade from one release version to another without upgrading to intervening versions, you should read the release notes of all intervening versions too.
For major releases of Postgres Pro, the internal data storage format is subject to change, thus complicating upgrades. The traditional method for moving data to a new major version is to dump and restore the database, though this can be slow. A faster method is pg_upgrade. Replication methods are also available, as discussed below.
New major versions also typically introduce some user-visible incompatibilities, so application programming changes might be required. All user-visible changes are listed in the release notes (Appendix E), including all the necessary instructions for migration in the corresponding section.
Cautious users will want to test their client applications on the new version before switching over fully; therefore, it's often a good idea to set up concurrent installations of old and new versions. When testing a Postgres Pro major upgrade, consider the following categories of possible changes:
- Administration
The capabilities available for administrators to monitor and control the server often change and improve in each major release.
- SQL
Typically this includes new SQL command capabilities and not changes in behavior, unless specifically mentioned in the release notes.
- Library API
Typically libraries like libpq only add new functionality, again unless mentioned in the release notes.
- System Catalogs
System catalog changes usually only affect database management tools.
- Server C-language API
This involves changes in the backend function API, which is written in the C programming language. Such changes affect code that references backend functions deep inside the server.
18.6.1. Upgrading Data via pg_dumpall
One upgrade method is to dump data from one major version of Postgres Pro and restore it in another — to do this, you must use a logical backup tool like pg_dumpall; file system level backup methods will not work. (There are checks in place that prevent you from using a data directory with an incompatible version of Postgres Pro, so no great harm can be done by trying to start the wrong server version on a data directory.)
It is recommended that you use the pg_dump and pg_dumpall programs from the newer version of Postgres Pro, to take advantage of enhancements that might have been made in these programs. Current releases of the dump programs can read data from any server version back to 8.0.
These instructions assume that your existing installation is under the /usr/local/pgsql directory, and that the data area is in /usr/local/pgsql/data. Substitute your paths appropriately.
If making a backup, make sure that your database is not being updated. This does not affect the integrity of the backup, but the changed data would of course not be included. If necessary, edit the permissions in the file
/usr/local/pgsql/data/pg_hba.conf(or equivalent) to disallow access from everyone except you. See Chapter 20 for additional information on access control.To back up your database installation, type:
pg_dumpall >outputfileTo make the backup, you can use the pg_dumpall command from the version you are currently running; see Section 25.1.2 for more details. For best results, however, try to use the pg_dumpall command from Postgres Pro Enterprise 12.22.1, since this version contains bug fixes and improvements over older versions. While this advice might seem idiosyncratic since you haven't installed the new version yet, it is advisable to follow it if you plan to install the new version in parallel with the old version. In that case you can complete the installation normally and transfer the data later. This will also decrease the downtime.
Shut down the old server:
pg_ctl stopOn systems that have Postgres Pro started at boot time, there is probably a start-up file that will accomplish the same thing. For example, on a Red Hat Linux system one might find that this works:
/etc/rc.d/init.d/postgresql stopSee Chapter 18 for details about starting and stopping the server.
If restoring from backup, rename or delete the old installation directory if it is not version-specific. It is a good idea to rename the directory, rather than delete it, in case you have trouble and need to revert to it. Keep in mind the directory might consume significant disk space. To rename the directory, use a command like this:
mv /usr/local/pgsql /usr/local/pgsql.old(Be sure to move the directory as a single unit so relative paths remain unchanged.)
Install the new version of Postgres Pro Enterprise.
Create a new database cluster if needed. Remember that you must execute these commands while logged in to the special database user account (which you already have if you are upgrading).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/dataRestore your previous
pg_hba.confand anypostgresql.confmodifications.Start the database server, again using the special database user account:
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/dataFinally, restore your data from backup with:
/usr/local/pgsql/bin/psql -d postgres -foutputfileusing the new psql.
The least downtime can be achieved by installing the new server in a different directory and running both the old and the new servers in parallel, on different ports. Then you can use something like:
pg_dumpall -p 5432 | psql -d postgres -p 5433
to transfer your data.
18.6.2. Upgrading Data via pg_upgrade
The pg_upgrade module allows an installation to be migrated in-place from one major Postgres Pro version to another. Upgrades can be performed in minutes, particularly with --link mode. It requires steps similar to pg_dumpall above, e.g., starting/stopping the server, running initdb. The pg_upgrade documentation outlines the necessary steps.
18.6.3. Upgrading Data via Replication
It is also possible to use logical replication methods to create a standby server with the updated version of Postgres Pro. This is possible because logical replication supports replication between different major versions of Postgres Pro. The standby can be on the same computer or a different computer. Once it has synced up with the master server (running the older version of Postgres Pro), you can switch masters and make the standby the master and shut down the older database instance. Such a switch-over results in only several seconds of downtime for an upgrade.
This method of upgrading can be performed using the built-in logical replication facilities as well as using external logical replication systems such as pglogical, Slony, Londiste, and Bucardo.