Задачи администрирования
Обновление сервера
13
Авторские права
© Postgres Professional, 2016–2022.
Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Нумерация версий и общие замечания
Обновление на дополнительный выпуск
Обновление основной версии
3
Версии сервера
Основные версии (9.6, 10, 11, ...)
поддержка сообщества в течение 5 лет
добавляется и изменяется функционал
новая версия не совместима на двоичном уровне с предыдущей
для обновления всегда требуются специальные действия
Дополнительные выпуски (13.1, 13.2, ...)
только исправление ошибок и проблем безопасности
гарантируется двоичная совместимость
обычно достаточно установить новые исполняемые файлы
Номер версии PostgreSQL состоит из двух частей: номер основной
версии (major release) и номер дополнительного выпуска (minor release).
До версии 10 основной номер состоял из двух чисел (9.5, 9.6), затем
перешли на одно (10, 11). Номер дополнительного выпуска —
последнее число через точку (например, 5 в 13.5).
Дополнительные выпуски служат только и исключительно для
исправления ошибок, найденных в основной версии. Для них
гарантируется сохранение двоичной совместимости (на одной
платформе). Поэтому обновление на следующий дополнительный
выпуск делается максимально просто и рекомендуется, как только
дополнительный выпуск появляется.
Новая основная версия привносит изменение функционала: какие-то
возможности добавляются, изменяются, реже — удаляются. В этом
случае двоичная совместимость отсутствует. Если попробовать
подключить новую версию исполняемых файлов к старой версии
кластера БД, PostgreSQL откажется с ним работать.
Для обновления основной версии требуется предпринимать
специальные шаги. Не исключено, что помимо обновления сервера БД,
потребуется внесение изменений и в приложение. Мотивацией для
перехода на новую версию служит появление новых возможностей
и окончание поддержки старой версии (которая распространяется на
5 лет с момента выпуска). Из-за сложности процесса часто пропускают
несколько версий, например, переходят с 10 сразу на 13 и т. п.
4
Общие соображения
«Замечания к выпуску»
необходимо изучить раздел «Миграция» всех промежуточных версий
Проверка обновления на тестовом окружении
заранее обнаружить возможные проблемы
автоматизировать процесс для сокращения времени простоя
Запасной вариант
на случай проблем при обновлении производственного сервера
Независимо от того, какое обновление выполняется, стоит обратить
внимание на некоторые моменты.
Всегда следует внимательно ознакамливаться с приложением
«Замечания к выпуску» (Release Notes) документации. В нем в разделе
«Миграция» описаны все несовместимости и нестандартные действия,
необходимые при обновлении.
Например, если планируется переход с 12.7 на 13.8 (последний доп.
выпуск выбранной основной версии), надо прочитать все замечания
к версиям 12.8, …, 12.12 (последний доп. выпуск для 12), 13.0, …, 13.8.
Обновление следует проверять на тестовой среде, эквивалентной
производственной, с последующим тестированием приложения, что
позволит заранее выявить возможные проблемы и «обкатать»
и автоматизировать процедуру обновления.
Это существенно снижает риск возникновения проблем при обновлении
производственного сервера, но не исключает его полностью. Поэтому
всегда необходимо иметь (протестированный) запасной вариант на
случай, если обновление пойдет не так. Таким вариантом, например,
может быть готовая реплика или резервная копия, в зависимости от
требований к возможному времени простоя.
5
Дополнительный выпуск
Обновление на дополнительный выпуск
Использование физических реплик
6
+ простота
– вынужденное прерывание обслуживания
Дополнительный выпуск
установка пакетов новой версии (сервер, клиент, расширения)
перезапуск сервера
при необходимости обновление расширений, доп. действия
13.4
13.5
Для того чтобы обновить сервер до очередного дополнительного
выпуска, требуется:
1. Установить новые исполняемые файлы.
Если PostgreSQL был установлен из пакета, необходимо установить
новые версии пакетов (сервер, клиент, расширения). Некоторые
пакетные менеджеры, в частности, apt в ОС Ubuntu, по умолчанию
автоматически перезапускают сервер; обычно это нежелательно.
Если PostgreSQL был собран из исходных кодов, необходимо
выполнить make install.
2. Перезапустить сервер. После перезапуска он продолжит работу уже
на новой версии.
Обслуживание клиентов прерывается на время, требуемое для
перезапуска.
3. После перезапуска может быть нужно обновить расширения (ALTER
EXTENSION … UPDATE) и выполнить дополнительные действия,
указанные в «Замечаниях к выпуску». Однако в большинстве случаев
это не требуется.
7
Обновление средствами операционной системы
sudo apt upgrade postgresql-13
Может автоматически перезапустить сервер
man needrestart
apt upgrade
Если PostgreSQL установлен из пакета, операционная система сама
может обновить его версию. В Ubuntu для этого используется команда
sudo apt upgrade имя-пакета
При таком обновлении сервер обычно автоматически перезапускается,
что может быть неудобно. Это поведение настраивается, подробности
описаны в справочной странице по команде needrestart.
8
Уменьшение простоя
Процесс перезапуска сервера
запрещаются новые соединения
smart ожидает завершения всех сеансов,
fast принудительно отключает все сеансы (по умолчанию)
выполняется контрольная точка
Контрольная точка
вручную до перезапуска сервера
PgBouncer
«пауза» на время перезапуска сервера
открытые транзакции продолжают выполняться,
все новые — приостанавливаются
Прерывание обслуживания можно сократить, а в некоторых случаях
и устранить полностью.
Что происходит при перезапуске сервера?
Во-первых, PostgreSQL перестает принимать новые подключения
(клиенты будут получать ошибку «shutdown in progress»).
Во-вторых, в зависимости от режима останова, сервер либо
дожидается завершения активных сеансов, либо принудительно
завершает их. Последнее подразумевается по умолчанию утилитой
управления, но, вероятно, это не лучший выбор для производственной
среды, если сервер в основном имеет дело с OLTP-нагрузкой (короткие
запросы).
В-третьих, выполняется финальная контрольная точка (shutdown
checkpoint), чтобы синхронизировать данные из буферов в оперативной
памяти с диском (как рассматривалось в модуле «Журналирование»).
При большом размере буферного кеша этот процесс может занимать
значительное время. Поэтому может оказаться целесообразным
сначала выполнить контрольную точку вручную (CHECKPOINT), а затем
перезапустить сервер. В этом случае финальная контрольная точка все
равно будет выполнена, но значительно быстрее.
Если используется pgbouncer (https://pgbouncer.org), имеет смысл
поставить его на «паузу» на время перезагрузки. При этом
(подразумевая режим «transaction») работающие транзакции продолжат
выполнение, но все новые будут отложены. Таким образом (для OLTP-
приложения) перезапуск будет выглядеть как увеличившееся время
отклика СУБД.
9
Репликация
резервный сервер догнал основной, переключение
+ возможно обновление без или с минимальным прерыванием обслуживания
основной резерв
основной
резерв
резервный сервер
обновляется первым
Если в системе используется физическая репликация и предусмотрен
механизм плавного переключения пользователей между серверами,
процедуру обновления можно провести и без прерывания
обслуживания.
Для этого сначала выполняют обновление резервного сервера.
Во время его перезапуска вся нагрузка ложится на основной сервер.
Поскольку версии двоично-совместимы, репликация работает между
уже обновленным резервным сервером и еще не обновленным
основным. В абсолютном большинстве случаев репликация будет
работать и в другом направлении (от обновленного сервера к серверу
со старой версией), но от ошибок обратной совместимости никто не
застрахован. Поэтому сначала лучше обновлять именно резервный
сервер.
Затем, когда резервный сервер «догоняет» после перезагрузки
основной сервер, основной сервер останавливают и выполняют
переключение на резервный. После запуска бывшего основного
сервера он подключается к новому основному в качестве резервного
(это может потребовать запуска утилиты pg_rewind; вся процедура
рассматривается подробно в курсе DBA3).
10
Основная версия
Логическая резервная копия pg_dumpall
Утилита pg_upgrade
Логическая репликация
11
pg_dumpall
+ можно сменить платформу, разрядность, кодировку баз данных и т. п.
– большое время обновления, требуется много дискового пространства
установка пакетов и инициализация кластера
отключение пользователей (только чтение)
логическая копия (pg_dumpall)
восстановление копии (psql)
сбор статистики
начало работы
Самый простой способ обновления на основную версию — сделать
логическую резервную копию и развернуть ее на другом сервере
с новой версией. (Логическая копия — это команды SQL, воссоздающие
базу данных; подробнее см. курс DBA3).
Сначала устанавливаем новый сервер и инициализируем кластер
(некоторые пакетные менеджеры выполняют инициализацию сразу при
установке).
Если новый сервер разворачивается на том же компьютере, надо
позаботиться, чтобы каталоги данных не пересекались. Обычно пакеты
собираются с учетом этого требования (например, /var/lib/pgsql/12/
и /var/lib/pgsql/13/). Потребуется изменить конфигурационные файлы
нового кластера, внеся в них изменения с работающего кластера.
Резервную копию надо делать при работающем сервере, но требуется
отключить всех пользователей (кроме только читающих), поскольку
изменения, сделанные после запуска резервного копирования, не
попадут в копию.
После этого можно запускать новый сервер и в нем разворачивать
подготовленную резервную копию. И затем собрать статистику — без
этого оптимизатор не сможет строить адекватные планы запросов.
После всех необходимых проверок каталоги старого сервера
(исполняемые файлы, содержимое PGDATA, пользовательские
табличные пространства) можно удалить.
12
pg_dumpall
Ускорение переноса данных
pg_dumpall --globals-only
pg_dump --format=d --jobs=N
pg_restore --jobs=N
Экономия места
pg_dumpall | psql параметры-соединения-с-новым-кластером
Сбор статистики
$ vacuumdb --analyze-in-stages
расширение dump_stat
Быстрая проверка
pg_dumpall --schema-only
для каждой базы данных отдельно
Хотя утилита pg_dumpall и делает резервную копию всего кластера,
она всегда выполняется в один поток. Восстановление также
выполняется в один поток утилитой psql.
Если аппаратные ресурсы позволяют, можно сохранить глобальные
объекты кластера с помощью pg_dumpall, а затем выполнить копии
каждой БД отдельно в параллельном режиме с помощью утилиты
pg_dump в формате directory. В таком случае и восстановление можно
выполнять в параллельном режиме утилитой pg_restore. Подробности
см. в курсе DBA3.
Если стоит задача сэкономить место на диске, можно не сохранять
резервную копию, а просто направить выход pg_dumpall на вход psql.
Чтобы как можно раньше собрать хоть какую-то статистику, можно
выполнять сбор в несколько (3) этапов. Можно попробовать начать
работу с СУБД уже после второго этапа, сократив тем самым время
прерывания обслуживания. Еще одна возможность — использовать
внешнее расширение dump_stat:
При проверке обновления на тестовой среде сначала можно выполнить
обновление с переносом только схемы данных (без самих данных).
Таким образом можно достаточно быстро выявить часть возможных
проблем.
Заметим, что лучше использовать все утилиты от новой (уже
установленной) версии, поскольку они могут содержать улучшения,
недоступные в предыдущей версии.
14
pg_upgrade
Условия применимости
в новой версии изменяется формат только служебной информации
в остальном сохраняется двоичная совместимость,
включая представление типов и файлы данных
в базах данных не используются REG-типы
обновление с версии 8.4 или более поздней
обновление до версии, соответствующей утилите
Второй, наиболее распространенный способ обновления — утилита
pg_upgrade, которая умеет приводить файлы кластера к виду,
совместимому с новой версией.
Возможность применения утилиты обусловлена тем, что при
обновлении основной версии меняются служебные таблицы,
относящиеся к системному каталогу, но форматы файлов данных и
индексов как правило остаются без изменений. Поэтому достаточно
поправить только небольшую часть данных, оставив основной массив
как есть, без изменений.
При этом, конечно, новый кластер должен быть совместим со старым
по разрядности, кодировке и локалям.
В некоторых версиях (достаточно редко) изменяется двоичное
представление типов данных. В таких случаях утилита не сможет
помочь, но по крайней мере перечислит, где используется проблемный
тип. Это поможет избавиться от него вручную перед обновлением.
Есть и дополнительные ограничения. Например, утилита не сможет
обновить кластер, если в одной из баз данных используются REG-типы
(кроме regtype, regclass и regrole).
Утилитой поддерживается обновление любой версии, начиная с 8.4,
на версию, соответствующую утилите. Таким образом, pg_upgrade
от версии 13 может обновить старый сервер только до 13, но не до 12.
Уменьшение версии сервера (downgrade) невозможно.
15
pg_upgrade
установка пакетов и инициализация кластера
останов сервера
логическая копия каталога и схемы данных
сбор статистики, обновление расширений
начало работы
pg_upgrade
восстановление каталога и схемы данных
перенос данных и настройка
+ скорость обновления, обычно не требуется дополнительное место
– ограниченная применимость
Вначале рассмотрим общую (упрощенную) последовательность
действий при обновлении с помощью pg_upgrade.
Сначала необходимо установить новый сервер и инициализировать
(но не запускать) кластер. Этот шаг выполняется так же, как и при
обновлении с помощью pg_dumpall.
Затем старый сервер останавливается и запускается утилита
pg_upgrade. Пока обозначим схематически, что она делает:
- Старый сервер запускается на время, чтобы сделать логическую
резервную копию общих объектов кластера и схемы данных всех БД.
Это как раз та информация, для которой теряется двоичная
совместимость.
- Временно запускается новый сервер, выполняются необходимые
проверки применимости, из резервной копии восстанавливаются
глобальные объекты и схема данных.
- Выполняется перенос данных: либо копирование, либо простановка
жестких ссылок, либо клонирования (для файловых систем
с копированием при записи).
В результате работы утилиты новый кластер становится обновленной
версией старого. Далее выполняются заключительные действия, такие,
как сбор статистики и обновление расширений.
Огромный плюс pg_upgrade состоит в возможности очень быстрого
обновления кластера любого размера без дополнительного места на
диске (при использовании жестких ссылок). Из минусов отметим то, что
утилита применима не всегда.
16
pg_upgrade
установка пакетов и инициализация кластера
системный каталог,
служебные файлы
пользовательские
данные
исполняемые
файлы 12
пользовательские
данные
системный каталог,
служебные файлы
исполняемые
файлы 13
та же
локаль
Чуть более подробно рассмотрим, что происходит с файловыми
системами старого и нового кластера при обновлении.
Шаг 1. Установлены пакеты с новой версией и инициализирован
кластер. Новый сервер выключен и не содержит никаких
пользовательских объектов, только стандартные базы данных и
системный каталог.
Старый сервер продолжает работать.
Важный момент: новый кластер должен быть инициализирован с той же
локалью, что и старый.
18
pg_upgrade
установка пакетов и инициализация кластера
останов сервера
логическая копия каталога и схемы данных
восстановление каталога и схемы данных
системный каталог,
служебные файлы
пользовательские
данные
исполняемые
файлы 12
системный каталог,
служебные файлы
исполняемые
файлы 13
пользовательские
данные
pg_dump, pg_dumpall
pg_restore
Шаг 2. Старый сервер останавливается, запускается утилита
pg_upgrade. Она выполняет резервную копию каталога и схем данных
всех баз с помощью утилит pg_dump и pg_dumpall в режиме
--binary-upgrade, который сохраняет нумерацию файлов (этот режим не
нужен для обычной работы и официально не поддерживается):
pg_dumpall --globals-only --binary-upgrade
pg_dump --schema-only --binary-upgrade
Затем эти объекты восстанавливаются на новом сервере с помощью
pg_restore (подробно эти утилиты рассматриваются в курсе DBA3).
Все эти действия выполняются достаточно быстро — время не зависит
от объема данных в кластере.
После этого системный каталог нового кластера соответствует
системному каталогу старого кластера с точностью до изменения
формата данных (именно поэтому для него и используется логическая,
а не физическая резервная копия). Фактически, в новом кластере
созданы все базы данных и все объекты внутри них, но системный
каталог ссылается на еще не существующие файлы данных.
На самом деле утилита pg_upgrade выполняет еще много довольно
тонких операций. Знать о них необязательно, но полезно на случай
возникновения нештатной ситуации. Она замораживает все транзакции
нового кластера (чтобы не зависеть от номеров транзакций, которые
там выполнялись), копирует статусы транзакций (CLOG), копирует
информацию о мультитранзакциях, устанавливает счетчик транзакций
в значение со старого кластера.
19
pg_upgrade
установка пакетов и инициализация кластера
останов сервера
логическая копия каталога и схемы данных
восстановление каталога и схемы данных
перенос данных и настройка
системный каталог,
служебные файлы
пользовательские
данные
исполняемые
файлы 12
системный каталог,
служебные файлы
исполняемые
файлы 13
пользовательские
данные
ln / cp
нельзя
запускать
старый
кластер
Шаг 3. Утилита pg_upgrade выполняет перенос пользовательских
данных.
Теперь либо файлы данных нового кластера скопированы со старого,
либо на них проставлены жесткие ссылки.
Заметим, что если файлы данных копируются, то старый кластер никак
не затрагивается обновлением и можно в любой момент вернуться
к нему, если при обновлении что-то пошло не так.
Но при использовании жестких ссылок файлы данных фактически
становятся общими — точнее, одноименные файлы двух кластеров
ссылаются на одинаковые индексные дескрипторы файловой системы
(inode). Поэтому, как только новый кластер будет запущен первый раз,
старый уже станет невозможно запустить безопасным образом. Такой
режим обновления требует наличия «плана Б».
Для файловых систем c copy-on-write возможен третий вариант —
клонирование (--clone), сочетающий преимущества двух предыдущих:
быстрый перенос данных и возможность запуска обоих кластеров.
После переноса пользовательских данных утилите остается выставить
счетчик OID в значение со старого кластера (это выполняется утилитой
pg_resetwal).
А администратору остается обновить расширения, собрать статистику
и не забыть про плановое резервное копирование обновленного
кластера.
21
Утилита-обертка
старый кластер переключается на другой порт
файлы конфигурации копируются
pg_dump: можно сменить локаль
pg_upgrade: копирование файлов или жесткие ссылки
Неприменима для табличных пространств
pg_upgradecluster
pg_upgradecluster
pg_upgrade
pg_dump + pg_restore
--method=dump
--method=upgrade
Утилита-обертка pg_upgradecluster для ОС Ubuntu облегчает
обновление кластера в простых случаях. По умолчанию используется
вариант с логической копией, также поддерживается обновление
утилитой pg_upgrade как в режиме копирования файлов, так и в режиме
жестких ссылок.
Новый кластер использует тот же порт, старый настраивается на другой
неиспользуемый порт и ручной запуск. Утилита копирует
конфигурационные файлы в новый кластер, поэтому может
потребоваться их дополнительная настройка.
При обновлении через логическую копию можно поменять локаль или
отдельные категории локали.
Но если в кластере имеются дополнительные табличные пространства,
придется выполнять обновление вручную: утилита такую конфигурацию
не поддерживает.
22
Физическая репликация
Реплики нужно создать заново
нельзя не обновлять (нет двоичной совместимости)
но использовать pg_upgrade тоже нельзя (недетерминированность)
Вариант 1 (pg_basebackup)
развернуть новые реплики из физической резервной копии, сделанной
после обновления основного сервера
надежно, но долго
Вариант 2 (rsync)
воспользоваться тем, что файлы данных не изменяются
применимо только для Unix и только для жестких ссылок
быстро, но сложно
При использовании физической репликации возникают дополнительные
трудности. Дело в том, что и мастер, и реплики необходимо обновлять
одновременно. Соединение мастера одной версии с репликой другой
версии скорее всего приведет к потере данных.
Еще одна тонкость: реплику нельзя обновлять с помощью pg_upgrade.
Такое обновление не дает 100% гарантии того, что два идентичных
экземпляра после обновления также получатся идентичными.
Обычный способ состоит в том, чтобы забыть про существующие
реплики и создать их заново. Для этого надо выполнить базовую
резервную копию мастера и развернуть из нее новую реплику
(процедура подробно рассматривается в курсе DBA3). Понятно, что это
достаточно длительная процедура.
Если речь идет об операционной системе семейства Unix и при
обновлении мастера использовался режим жестких ссылок, то время
развертывания новой реплики можно существенно ускорить, получив
примерно такой же выигрыш по времени, который дает pg_upgrade для
мастера. Для этого надо правильным образом воспользоваться
утилитой rsync.
23
Физическая репликация
системный каталог,
служебные файлы
пользовательские
данные
исполняемые
файлы 12
системный каталог,
служебные файлы
исполняемые
файлы 13
пользовательские
данные
системный каталог,
служебные файлы
пользовательские
данные
исполняемые
файлы 12
системный каталог,
служебные файлы
исполняемые
файлы 13
пользовательские
данные
ln
основной серверреплика
реплика
полностью догнала
основной сервер
Исходная позиция: мастер обновлен, но новый сервер еще не
запускался. Реплика выключена, причем перед выключением она
полностью догнала мастер (таким образом файлы данных совпадают).
На реплике устанавливается новая версия сервера, но кластер не
инициализируется.
24
Физическая репликация
системный каталог,
служебные файлы
пользовательские
данные
исполняемые
файлы 12
исполняемые
файлы 13
системный каталог,
служебные файлы
пользовательские
данные
исполняемые
файлы 12
системный каталог,
служебные файлы
исполняемые
файлы 13
пользовательские
данные
ln
основной серверреплика
rsync
системный каталог,
служебные файлы
rsync
пользовательские
данные
ln
Дальше запускается rsync так, чтобы в одной команде скопировать
с мастера оба кластера, старый и новый, на реплику.
В таком режиме rsync понимает, что:
- старый и новый кластеры разделяют общие файлы данных;
- файлы данных старого кластера на мастере и на реплике совпадают
(чтобы не зависеть от объема, сравниваются только размеры файлов,
а не их содержимое);
- следовательно, файлы данных не надо физически копировать на
реплику, а достаточно проставить жесткие ссылки.
И rsync остается скопировать только файлы, относящиеся к системному
каталогу, а они имеют небольшой размер.
Этот процесс описан в документации к pg_upgrade
(https://postgrespro.ru/docs/postgresql/13/pgupgrade), в том числе и
конкретные команды, которые необходимо выполнить. К сожалению,
документация не объясняет, почему необходимы именно такие
команды. Для того, чтобы разобраться в этом вопросе детально,
полезно ознакомиться с перепиской разработчиков:
25
Логическая репликация
переключение
+ возможно обновление без или с минимальным прерыванием обслуживания
– сложная настройка, не реплицируются схема данных и команды DDL,
требуется дополнительное место на диске и т. д.
создание схемы данных и подписка на публикацию
создание публикации
синхронизация данных
Можно выполнить обновление основной версии без (или
с минимальным) прерывания обслуживания, если использовать
логическую репликацию.
Для этого требуется установить и настроить необходимым образом
новый экземпляр. На старом сервере создаются публикации всех
изменений во всех базах данных. На новом сервере создаются
подписки на эти публикации с синхронизацией данных. После того, как
данные синхронизированы, остается переключить пользователей на
новый сервер, удалить подписку и остановить старый сервер.
Штатная логическая репликация появилась в PostgreSQL 10.
К сожалению, это решение пока далеко от идеала: не реплицируются
схема данных, команды DDL, данные последовательностей. Все это
делает такой подход более сложным и менее привлекательным, чем
использование pg_upgrade.
26
Итоги
Обновление на дополнительный выпуск —
простая замена исполняемых файлов
физическая репликация, чтобы не прерывать обслуживание
Обновление основной версии:
резервная копия (pg_dumpall)
утилита обновления (pg_upgrade)
логическая репликация
наличие физической репликации усложняет процедуру
сразу после — сделать физическую резервную копию
27
Практика
1. В кластере PostgreSQL 12 создайте пользователя
с аутентификацией по паролю.
2. От имени нового пользователя создайте в базе данных
таблицу со столбцом типа uom.
3. Обновите кластер 12 на версию 13 с помощью логической
резервной копии. При обновлении сделайте так, чтобы все
данные оказались размещены в отдельном табличном
пространстве.
4. Проверьте корректность обновления: доступность сервера,
аутентификацию пользователя, содержимое таблицы.
1. PostgreSQL 12 уже установлен в /var/postgresql/12/prod/, кластер
инициализирован. Сервер работает на порту 5433. Локальные
соединения безусловно разрешены, при подключении по TCP/IP
настроена парольная аутентификация. В кластере создана
единственная роль postgres с правами суперпользователя.
Для начального подключения к кластеру используйте команду
psql -p 5433 -U postgres
Рекомендуем остановить основной кластер main, чтобы при
выполнении практики не подключиться к нему по ошибке.
При создании нового пользователя укажите пароль. Не забудьте
изменить настройки аутентификации для нового пользователя
в pg_hba.conf.
2. Тип данных uom доступен в одноименном расширении (см. тему
«Расширения»).
3. PostgreSQL 13 уже установлен в /var/postgresql/13/prod/, кластер
инициализирован аналогично кластеру версии 12.
Чтобы разместить данные в отдельном табличном пространстве,
предварительно создайте его и отредактируйте файл с резервной
копией (добавьте табличное пространство по умолчанию для БД).
Чтобы сохранить аутентификацию, внесите в файл pg_hba.conf те же
изменения, что были сделаны в старом кластере.
