Задачи администрирования
Обновление сервера
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. Установлены пакеты с новой версией и инициализирован
кластер. Новый сервер выключен и не содержит никаких
пользовательских объектов, только стандартные базы данных и
системный каталог.
Старый сервер продолжает работать.
Важный момент: новый кластер должен быть инициализирован с той же
локалью, что и старый.