PostgreSQL 14 заканчивает поддержку: как обновить базу и не потерять приложение

MAATRIX · 17 октября 2026 · 8 мин чтения

Двенадцатое ноября 2026 года — хорошая дата для календаря администратора и плохая дата для первого разговора об обновлении PostgreSQL 14. В этот день заканчивается поддержка ветки со стороны проекта. База не выключится по таймеру, таблицы не исчезнут, но привычный поток исправлений завершится. На 17 октября до этой границы осталось меньше месяца.

Главная работа при переезде обычно находится не в команде обновления. Нужно выяснить, кто подключается к базе, какие расширения используются и можно ли вернуть прежнюю систему после первой записи в новую. Именно эти вопросы превращают смену версии из азартного мероприятия в управляемую процедуру.

Какую версию выбирать вместо четырнадцатой

Даты завершения поддержки опубликованы в политике PostgreSQL. Выбирайте поддерживаемую стабильную ветку, совместимую с приложением и расширениями. На дату статьи PostgreSQL 18 — стабильная ветка, а PostgreSQL 19 находится на стадии кандидата в релиз. Испытывать будущую версию полезно отдельно; срочный производственный переезд не обязан становиться таким испытанием.

Не требуется последовательно устанавливать все промежуточные основные версии. Но их примечания к миграции прочитать необходимо: изменение, появившееся между четырнадцатой и выбранной веткой, продолжает действовать и в конечной версии. Особое внимание уделите расширениям, драйверу приложения, аутентификации и инструментам резервного копирования.

Сначала запросите реальную версию сервера, а не только установленного клиента:

SELECT version();
SELECT extname, extversion FROM pg_extension ORDER BY extname;

Выполните второй запрос в каждой базе. Расширение может быть нужно одному служебному приложению, о котором основной разработчик не знает. Проверьте также фоновые задания, отчётные системы, выгрузки и подключения сотрудников. У базы часто больше собеседников, чем у её владельца.

Три маршрута, разные обязательства

Официальное руководство по обновлению описывает перенос через логическую копию, pg_upgrade и репликацию. Выбор зависит от объёма данных и допустимого перерыва.

Не выбирайте репликацию исключительно из-за обещания «без простоя». Она добавляет обязанности, которые нужно выполнить до переключения. Не выбирайте режим ссылок pg_upgrade ради скорости, пока не понятны ограничения возврата: совместное использование файлов и запуск нового кластера меняют картину безопасности старой копии.

Для первого самостоятельного обновления небольшой базы обычно проще отрепетировать выгрузку и восстановление. Далее разберём этот маршрут. Он не требует угадывать состояние рабочей базы после эксперимента: новая система получает отдельную копию.

Репетиция на новом VPS

Новый сервер нужен прежде всего для изоляции. Рабочая база продолжает обслуживать пользователей, а копия позволяет повторять неудачные попытки без героизма. Для небольшой базы и приложения ориентиром может стать MAATRIX Heka Standard с 4 vCPU и 8 GB памяти. Это начальная конфигурация стенда, а не обещание вместить любую базу.

Диск рассчитывают по сумме данных, индексов, временных файлов восстановления и запаса на рост. Архив выгрузки не равен итоговому размеру базы. Не забудьте место для журналов и резервной копии вне этого VPS. Система с заполненным диском превращает плановый переезд в дополнительный сюжет.

На поддерживаемой Ubuntu или Debian установите выбранную PostgreSQL и нужные расширения из совместимых источников. Зафиксируйте версии пакетов. Не копируйте старый конфигурационный файл целиком поверх нового: переносите осмысленные параметры, проверяя, существуют ли они и подходят ли новой машине.

Изолируйте копию приложения от платежей, почты и реальных очередей. Доступ к персональным данным стенда ограничьте теми, кому он нужен. Размещение в подходящей локации выбирают по задержке и требованиям к данным, а не только по цене процессора.

Сначала восстановите учебную копию

Используйте клиентские инструменты выбранной новой ветки. Создайте защищённый каталог для выгрузки. Параметры соединения задайте через отдельный service-файл PostgreSQL либо защищённый файл паролей; пароль не нужен в командной строке или истории терминала.

В примере old_app — заранее настроенное подключение к старой базе, а new_admin — к отдельному тестовому серверу. Имя app_rehearsal обозначает новую пустую базу. Это команды репетиции, не удаления рабочей системы:

pg_dump --dbname='service=old_app' --format=custom --file=app.dump
pg_restore --list app.dump > app.contents.txt
createdb --maintenance-db='service=new_admin' app_rehearsal
pg_restore --dbname='service=new_admin dbname=app_rehearsal' \
  --exit-on-error --no-owner --no-privileges app.dump

Параметры --no-owner и --no-privileges намеренно исключают перенос владельцев и разрешений в учебной копии. После восстановления назначьте их отдельно по подготовленной схеме. Для настоящего переноса роли, членство и права нужно инвентаризировать и восстановить корректно; одна выгрузка базы не переносит все глобальные объекты кластера.

Сохраните вывод и код завершения. Наличие таблиц ещё не означает успешного восстановления: ошибка на расширении или индексе способна оставить внешне правдоподобную половину базы. Возможности формата описаны в pg_dump, а режимы восстановления — в pg_restore.

После переноса обновите статистику предусмотренным способом и подключите копию приложения отдельной учётной записью. Не повышайте ей права до администратора ради обхода первой ошибки: так легко спрятать реальную несовместимость.

Проверяйте работу бизнеса, а не только таблицы

Начните с простых контрольных величин. Сравните число записей в ключевых таблицах, последние идентификаторы, диапазоны дат и суммы учебных выборок. Для больших таблиц продумайте стоимость подсчёта; тяжёлая проверка на рабочей базе сама может создать неприятную нагрузку.

Затем выполните полный пользовательский путь: вход, создание сущности, изменение, поиск, отчёт и удаление учебной записи. Если приложение принимает заказы, недостаточно открыть каталог. Проверьте создание заказа, смену статуса и возврат тестовой операции без обращения к настоящему эквайрингу.

Отдельный список составьте для фоновых задач. Ночной отчёт не появится в десятиминутной проверке интерфейса. Запустите его вручную на копии с контролируемым набором данных и сравните результат. Проверьте часовые пояса, сортировку текста, уникальные ограничения и работу последовательностей.

Снимите длительность нескольких важных запросов до и после, в сопоставимых условиях. Не называйте первое медленное выполнение регрессией: кэши и статистика отличаются. Но и не списывайте устойчивое замедление на «новая версия прогреется». Сохранённый план запроса помогает обсуждать проблему предметно.

Сортировка тоже часть поведения базы

Если одновременно меняется операционная система, проверьте локали и поставщика правил сравнения текста. Один и тот же список фамилий или товаров может сортироваться иначе при другом окружении. Особенности объясняет документация collations PostgreSQL.

Возьмите небольшой набор с кириллицей, латиницей, разным регистром и цифрами. Сравните поиск, сортировку и ограничения уникальности, которые важны приложению. Зафиксируйте требуемое поведение до переключения, чтобы после него не спорить, какой порядок был «всегда».

При логическом восстановлении индексы создаются на новой стороне, но это не отменяет проверки смысла сравнения. Предупреждения о версиях правил сортировки требуют отдельного разбора по документации выбранной версии. Не исправляйте только отметку версии ради исчезновения сообщения, не выполнив необходимых действий с зависимыми объектами.

Окно переключения состоит из конкретных шагов

По итогам репетиции запишите реальное время выгрузки, передачи, восстановления и проверки. Добавьте запас и определите момент, после которого начинаете возврат. Время нужно измерить на своей базе; чужой рассказ о пяти минутах не является характеристикой вашего сервера.

Во время согласованного окна остановите все источники записи: веб-приложение, очереди, планировщики и интеграции. Убедитесь, что старая база больше не меняется. Сделайте финальную согласованную выгрузку и восстановите её на подготовленной новой стороне. Не используйте вчерашнюю репетиционную копию как сегодняшнюю рабочую.

Проверьте контрольные данные, права и подключение приложения. Переключите строку соединения, запустите небольшой контрольный сценарий и только затем возвращайте обычную нагрузку. Следите за ошибками соединений, временем запросов, блокировками, свободным диском и количеством фоновых задач.

Старую систему сохраните недоступной для случайной записи. Два одновременно работающих экземпляра с разными базами создают расхождение, которое никакая успешная миграция уже не объяснит.

Где заканчивается простой откат

Пока новая база не получила уникальные рабочие записи, возвращение к старой относительно понятно: остановить новую сторону, вернуть подключение и возобновить работу на исходном состоянии. После появления новых заказов этот путь теряет данные, если не предусмотрен обратный перенос.

Поэтому заранее решите, какие ошибки допускают быстрый возврат, а какие требуют исправления на новой версии. Запишите, кто принимает решение и как сохраняются операции, появившиеся после переключения. Фраза «бэкап же есть» не отвечает на вопрос о заказах за последние двадцать минут.

Успешный переезд завершается не удалением старого VPS в тот же вечер, а проверкой резервного копирования новой базы и восстановлением её свежей копии. Только после периода наблюдения можно выводить старую систему из эксплуатации. Версия PostgreSQL меняется за одно окно; уверенность в сохранности данных заслуживается несколькими проверенными действиями.