Как обновить PostgreSQL для 1С: подготовка, обновление и проверка

PostgreSQL — один из самых популярных серверов баз данных для работы с 1С: он бесплатен, стабилен и поддерживается платформой официально. Со временем любая версия PostgreSQL требует обновления: выходят исправления ошибок и уязвимостей, а старые ветки теряют поддержку. При этом обновление СУБД, на которой работает учётная система, — операция с повышенным риском: ошибка может привести к простою или потере данных.

Важно понимать ключевое ограничение: платформа 1С:Предприятие сертифицируется для работы с конкретными версиями PostgreSQL. Обновлять СУБД до произвольной свежей версии нельзя — сначала нужно свериться с системными требованиями вашей версии платформы 1С. Если платформа официально не поддерживает выбранную версию PostgreSQL, возможны ошибки при создании баз, реструктуризации и в штатной работе.

Различают два сценария обновления: минорное (например, с 15.4 на 15.7) и мажорное (с 14-й на 15-ю ветку). Минорное обновление выполняется простой заменой исполняемых файлов и обычно безопасно. Мажорное требует переноса данных, так как формат хранения между ветками несовместим. Ниже разобраны оба сценария.

Проверка совместимости версий PostgreSQL и платформы 1С

Первый шаг — узнать текущую версию PostgreSQL и определить целевую. Текущую версию можно посмотреть командой psql --version на сервере или SQL-запросом SELECT version();. Версию платформы 1С видно в консоли кластера серверов 1С или в меню «О программе» клиента.

Далее откройте системные требования вашей версии платформы 1С:Предприятие на портале вендора и найдите список поддерживаемых версий PostgreSQL. Обновляться нужно строго в пределах этого списка. Если требуется более новая ветка PostgreSQL, чем поддерживает платформа, сначала придётся обновлять саму платформу 1С.

Отдельный нюанс — сборка PostgreSQL. Для 1С рекомендуются специальные сборки, доступные на портале 1С, а также официальные сборки PostgreSQL и Postgres Pro. Сборки отличаются параметрами компиляции и набором расширений. При обновлении сохраняйте тот же «семейный» тип сборки, что был установлен изначально, иначе возможны проблемы с локалью и сортировкой.

Подготовка: резервное копирование и план отката

Резервная копия — обязательное условие. Для баз 1С на PostgreSQL делают два независимых типа копий: выгрузку информационной базы в файл .dt через конфигуратор и дамп на уровне СУБД через pg_dump или pg_dumpall. Два разных механизма страхуют друг друга: если один окажется повреждён, останется второй.

Команда для полного дампа кластера выглядит так:

pg_dumpall -U postgres -f /backup/full_cluster.sql

Перед началом работ завершите сеансы пользователей: в консоли кластера 1С снимите активные соединения и установите блокировку сеансов, чтобы никто не подключился во время обновления. Также остановите регламентные задания. Запишите текущие параметры postgresql.conf и pg_hba.conf — после мажорного обновления их придётся переносить вручную.

Проверьте, что резервная копия действительно читается: файл дампа должен иметь ненулевой размер, а в идеале — тестово разворачиваться на отдельной машине. Копия, пригодность которой не проверена, не считается планом отката.

1. 1
   Проверьте совместимость целевой версии PostgreSQL с платформой 1С
2. 2
   Заблокируйте сеансы и завершите соединения с базами
3. 3
   Сделайте выгрузку .dt и дамп pg_dumpall
4. 4
   Сохраните postgresql.conf и pg_hba.conf
5. 5
   Убедитесь, что на диске достаточно свободного места
6. 6
   Проверьте читаемость резервных копий

Минорное обновление PostgreSQL

Минорное обновление (изменение третьего числа в версии, например 15.4 → 15.7) не меняет формат данных и выполняется в лоб: останавливается служба PostgreSQL, устанавливаются новые пакеты той же ветки, служба запускается снова. Каталог данных остаётся прежним.

На Linux с пакетным менеджером это обычно выглядит как обновление пакетов и перезапуск службы. На Windows — запуск инсталлятора новой минорной версии поверх существующей установки с последующим перезапуском службы. Перед этим всё равно нужна резервная копия: минорные обновления редко ломают данные, но исключения бывали.

После запуска проверьте версию командой SELECT version(); и убедитесь, что базы 1С доступны. Минорное обновление обычно занимает минуты, и окно простоя можно уложить в нерабочее время без сложной организации.

Мажорное обновление: два рабочих способа

Мажорное обновление (переход между ветками, например с 14-й на 15-ю) требует переноса данных, потому что внутренний формат хранения меняется. Есть два основных способа: логическая выгрузка через дамп и бинарный перенос через pg_upgrade.

Обновление через дамп и восстановление

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

Порядок такой: установите новую версию PostgreSQL параллельно со старой (на другой порт или в другой каталог), выполните pg_dumpall или pg_dump каждой базы новой версией утилит, затем загрузите дамп в новый кластер через psql. После загрузки перенесите настройки из старых postgresql.conf и pg_hba.conf, не копируя файлы целиком — синтаксис параметров между версиями может отличаться.

Обновление через pg_upgrade

Утилита pg_upgrade переносит кластер на новую версию значительно быстрее, особенно в режиме --link, когда файлы данных не копируются, а связываются жёсткими ссылками. Для больших баз 1С это часто единственный приемлемый по времени вариант.

Ограничения: обе версии PostgreSQL должны быть установлены на одном сервере, обе службы на время обновления останавливаются, а при использовании --link старый кластер после успешного обновления запускать нельзя — это повредит данные нового. Перед запуском pg_upgrade обязательно выполните проверку совместимости с ключом --check.

Особенности для разных операционных систем

На Linux-дистрибутивах (Debian, Ubuntu, CentOS, Astra Linux) новые мажорные версии PostgreSQL ставятся из репозиториев параллельно со старой, каждая со своим каталогом данных и портом. Это удобно: старый кластер остаётся нетронутым до момента переключения. Управление кластерами выполняется штатными средствами пакетов или pg_ctl.

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

В обоих случаях обратите внимание на локаль и правила сортировки нового кластера: они должны совпадать с параметрами старого, иначе индексы по строковым полям могут работать некорректно, а 1С — выдавать ошибки сортировки.

Проверка работы 1С после обновления

После обновления сначала проверьте саму СУБД: служба запущена, кластер принимает подключения, список баз (\l в psql) содержит все базы 1С. Затем выполните ANALYZE; для каждой базы — это обновит статистику планировщика, без чего запросы могут временно работать медленно.

Далее проверьте на стороне 1С: база открывается в конфигураторе и в пользовательском режиме, проходят типовые операции — проведение документа, формирование отчёта, обмен данными. Если используется сервер 1С, проверьте, что в свойствах информационной базы в консоли кластера указаны правильные параметры подключения (сервер, порт), особенно если новая версия PostgreSQL работает на другом порту.

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

Типичные ошибки и как их избежать

Самая частая ошибка — обновление без проверки совместимости с платформой 1С. Симптомы: база не создаётся, падает реструктуризация, ошибки при обновлении конфигурации. Лечение одно — откат на поддерживаемую версию PostgreSQL.

Вторая группа ошибок связана с настройками: администратор переносит данные, но забывает postgresql.conf и pg_hba.conf. В результате новый кластер работает с параметрами по умолчанию: малый объём shared_buffers, ограниченные подключения, закрытый сетевой доступ. 1С при этом либо не подключается, либо заметно тормозит.

Третья типичная ситуация — запуск старого кластера после pg_upgrade --link. Это повреждает данные нового кластера, и спасает только резервная копия. Сразу после успешного обновления отключите автозапуск старой службы.

Если база крупная, обновление впервые выполняется вашими силами или простой недопустим — разумно сначала отрепетировать процедуру на тестовом стенде с копией реальной базы. Это покажет реальную длительность операции и выявит проблемы до боевого запуска.

Частые вопросы