Как обновить PostgreSQL для 1С

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

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

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

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

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

Далее сверьтесь с системными требованиями платформы 1С: фирма «1С» публикует перечень поддерживаемых СУБД и их версий для каждого релиза платформы. Например, старшие релизы платформы 8.3 работают с PostgreSQL более новых веток, тогда как старые релизы могут не поддерживать свежие версии СУБД. Установка неподдерживаемой версии приводит к ошибкам при создании базы или к нестабильной работе.

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

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

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

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

sudo -u postgres pg_dumpall -f /backup/pg_full_backup.sql

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

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

Выбор способа миграции данных

Существует два основных подхода к переносу данных на новую мажорную версию PostgreSQL, и выбор зависит от размера баз и допустимого времени простоя.

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

Второй способ — логическое восстановление из дампа: установка чистой новой версии и загрузка данных через psql из файла pg_dump. Способ надёжнее и проще для понимания, но на базах в десятки и сотни гигабайт занимает часы. Он же единственный вариант при смене разрядности ОС или переносе на другой сервер.

Установка новой версии PostgreSQL

На Linux новая мажорная версия PostgreSQL обычно устанавливается параллельно со старой — пакеты и каталоги данных разнесены по путям с номером версии. Это позволяет держать оба сервера на одной машине, запуская их на разных портах (старый на 5432, новый временно, например, на 5433).

Общий порядок действий на примере Debian/Ubuntu-подобных систем:

1. 1
   Остановите сеансы пользователей 1С и завершите работу сервера 1С:Предприятия
2. 2
   Сделайте полный дамп: pg_dumpall в файл на отдельном диске
3. 3
   Установите пакеты новой версии PostgreSQL (сервер, contrib, клиент)
4. 4
   Инициализируйте новый кластер данных, если установщик не сделал это автоматически
5. 5
   Перенесите данные выбранным способом (pg_upgrade или восстановление дампа)
6. 6
   Перенесите настройки из postgresql.conf и pg_hba.conf старой версии с учётом изменений параметров
7. 7
   Запустите новый сервер на порту 5432, выполните ANALYZE по всем базам
8. 8
   Проверьте подключение из консоли 1С и запуск типовых операций

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

Особое внимание уделите конфигурации: файлы postgresql.conf и pg_hba.conf из старой версии нельзя копировать в новую бездумно — часть параметров между мажорными версиями переименовывается или меняет смысл. Сравните файлы и перенесите только осмысленные настройки: объём shared_buffers, effective_cache_size, work_mem и параметры подключений, рекомендованные для 1С.

sudo -u postgres /usr/lib/postgresql/15/bin/pg_upgrade --old-bindir=/usr/lib/postgresql/12/bin --new-bindir=/usr/lib/postgresql/15/bin --old-datadir=/var/lib/postgresql/12/main --new-datadir=/var/lib/postgresql/15/main --check

Команда выше — пример запуска pg_upgrade в режиме проверки (--check): она ничего не меняет, но показывает, готовы ли кластеры к миграции. Всегда выполняйте проверочный прогон перед реальной миграцией.

Перенос настроек и подключение 1С к новому серверу

После миграции данных проверьте, что роли и права доступа перенесены корректно: pg_upgrade и pg_dumpall сохраняют пользователей, но пароли и членство в ролях стоит проверить вручную. Учётная запись, от имени которой сервер 1С подключается к СУБД, должна существовать и иметь прежние права.

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

После первого запуска обязательно выполните сбор статистики — ANALYZE по всем базам (pg_upgrade обычно подсказывает готовый скрипт). Без актуальной статистики планировщик PostgreSQL строит неэффективные планы запросов, и 1С будет работать заметно медленнее, что часто ошибочно принимают за «неудачное обновление».

Проверка результата и контрольные точки

Финальный этап — убедиться, что обновление прошло корректно и система готова к работе пользователей. Проверка занимает 15–30 минут, но избавляет от неприятных сюрпризов в разгар рабочего дня.

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

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

Типичные ошибки при обновлении PostgreSQL под 1С

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

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

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