Переход сервера 1С на новую версию PostgreSQL без потери баз

· 10 мин

Содержание

Обновить PostgreSQL для 1С можно тремя способами: утилитой pg_upgrade (быстро, подходит для больших баз), выгрузкой pg_dump с загрузкой в новый кластер (медленнее, зато надёжнее при смене ОС или локали) или через файл .dt из Конфигуратора (самый долгий, но не зависит от версий СУБД). Во всех трёх случаях новую версию ставят рядом со старой, а старую не удаляют, пока базы не проверены в работе.

Главное условие — новая сборка должна быть именно для 1С: с расширениями mchar, fulleq, fasttrun и поддержкой со стороны вашей версии платформы. Обычный PostgreSQL с сайта сообщества базу 1С не примет: при создании или загрузке информационной базы платформа сообщит об отсутствии нужных типов и функций.

1. Подготовка к обновлению PostgreSQL: совместимость и выбор способа

Начните с трёх проверок. Если хотя бы одна не проходит, обновление откладывается.

  • 🔍 Платформа поддерживает новую версию СУБД. У каждой версии платформы 8.3 есть список поддерживаемых версий PostgreSQL в системных требованиях. Номер платформы на сервере должен быть не ниже того, с которого заявлена поддержка нужной версии СУБД. Если нет — сначала обновляйте платформу на сервере и клиентах.
  • 📦 Есть дистрибутив сборки для 1С. Подходят сборка PostgreSQL из комплекта поставки 1С и Postgres Pro (Standard или Enterprise). Смешивать сборки разных поставщиков при pg_upgrade не стоит: набор расширений и их версии могут отличаться.
  • 💾 Хватит места на диске. Для pg_dump и обычного режима pg_upgrade нужно свободное место примерно в 2–2,5 раза больше текущего объёма каталога данных: старый кластер, новый кластер и дамп.

Узнать текущую версию и объём баз можно прямо в psql:

SELECT version();
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database ORDER BY pg_database_size(datname) DESC;

Какой способ выбрать

СпособКогда подходитПростой базРиски
pg_upgrade --linkОдна ОС, тот же сервер, базы от 100 ГБМинутыПосле запуска нового кластера вернуться на старый нельзя
pg_upgrade с копированиемОдна ОС, есть место на дискеДесятки минут на 100 ГБНужны одинаковые настройки локали
pg_dump / pg_restoreПереезд на другой сервер или ОС, смена локалиЧасы для крупных базДолго, но старый кластер остаётся нетронутым
Выгрузка .dt через КонфигураторПара небольших баз, нет навыков работы с консолью СУБДЧасыНужен монопольный доступ, на больших базах может не хватить памяти

Для типового сервера на 3–10 баз объёмом до 50 ГБ каждая чаще всего выбирают pg_upgrade в режиме копирования: он быстрый и оставляет старый кластер в целости для отката.

Спланируйте окно работ на нерабочее время. На всё время переноса базы будут недоступны пользователям.

2. Резервная копия баз перед обновлением СУБД

Делайте две независимые копии: средствами PostgreSQL и средствами 1С. Первая быстро восстанавливается, вторая не зависит от версии СУБД и пригодится, если что-то пойдёт не так с самим кластером.

Остановка работы пользователей

Перед копированием завершите сеансы. Удобнее всего установить блокировку начала сеансов в консоли кластера 1С на каждой базе, затем остановить службу сервера 1С.

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

Дамп средствами PostgreSQL

Сначала сохраните роли и пароли, они не входят в дамп отдельной базы:

pg_dumpall -U postgres --globals-only -f /backup/globals.sql

Затем каждую базу в сжатом формате:

pg_dump -U postgres -Fc -f /backup/buh_2025.dump buh_2025

На Windows те же команды запускаются из каталога bin установленной версии, например C:\Program Files\PostgreSQL\<версия>\bin. Пути к файлам дампа указывайте в кавычках, если в них есть пробелы.

Копия средствами 1С

Для каждой базы в Конфигураторе выполните Администрирование → Выгрузить информационную базу. Файл .dt проверяет целостность данных на уровне платформы, и его можно загрузить в любую поддерживаемую СУБД.

Не начинайте обновление, пока не убедились, что файлы копий созданы и имеют ненулевой размер. Хорошая практика — развернуть одну из копий в тестовую базу и открыть её.

3. Установка новой версии PostgreSQL рядом со старой

Старую версию не удаляйте. Новую ставьте в отдельный каталог и на другой порт, например 5433, чтобы оба кластера жили одновременно.

Windows

  1. Запустите установщик новой версии сборки для 1С.
  2. Укажите отдельный каталог программы и каталог данных.
  3. Порт задайте 5433, пароль пользователя postgres — такой же, как у старого кластера.
  4. Локаль выберите ту же, что у текущего кластера. Посмотреть её можно запросом SHOW lc_collate; в старом кластере.
  5. После установки проверьте, что служба новой версии запущена.

Linux

Пакеты сборки для 1С ставятся из полученного дистрибутива. После установки кластер инициализируется с явной локалью и кодировкой:

sudo -u postgres /usr/lib/postgresql/<версия>/bin/initdb \
  -D /var/lib/postgresql/<версия>/main \
  --locale=ru_RU.UTF-8 -E UTF8

Путь к initdb и каталогу данных зависит от пакета: в Debian и Ubuntu он обычно такой, в сборках Postgres Pro — свой. Проверить локаль системы можно командой locale -a | grep ru_RU. Если ru_RU.UTF-8 в списке нет, сгенерируйте её до initdb.

Проверка расширений

Подключитесь к новому кластеру и убедитесь, что расширения для 1С доступны:

SELECT name, default_version FROM pg_available_extensions
WHERE name IN ('mchar', 'fulleq', 'fasttrun');

Запрос должен вернуть три строки. Пустой результат значит, что поставлена не та сборка, — дальше идти нельзя.

4. Перенос баз 1С в новую версию PostgreSQL

Вариант А: pg_upgrade

Утилита переносит каталог данных целиком, со всеми базами и ролями. Оба кластера должны быть остановлены.

Сначала пробный прогон с ключом --check — он ничего не меняет, только ищет несовместимости:

sudo -u postgres /usr/lib/postgresql/<новая>/bin/pg_upgrade \
  -b /usr/lib/postgresql/<старая>/bin \
  -B /usr/lib/postgresql/<новая>/bin \
  -d /var/lib/postgresql/<старая>/main \
  -D /var/lib/postgresql/<новая>/main \
  --check

Если в конце вывода стоит Clusters are compatible, запускайте ту же команду без --check. Ключ --link вместо копирования создаёт жёсткие ссылки на файлы: перенос базы на 500 ГБ занимает минуты, но после запуска нового кластера старый использовать уже нельзя.

На Windows pg_upgrade запускают из каталога, куда у пользователя есть права на запись (утилита пишет туда журналы), и добавляют ключ -U postgres.

pg_upgrade не переносит postgresql.conf и pg_hba.conf. Настройки придётся перенести вручную — об этом в следующем разделе.

Вариант Б: pg_dump и pg_restore

Подходит, если старый и новый кластеры на разных серверах или если pg_upgrade --check ругается на локаль. Восстановите роли, затем каждую базу:

psql -U postgres -p 5433 -f /backup/globals.sql
pg_restore -U postgres -p 5433 -C -d postgres -j 4 /backup/buh_2025.dump

Ключ -C создаёт базу с тем же именем и владельцем, -j 4 распараллеливает загрузку на четыре потока. Число потоков ставьте не больше числа ядер процессора.

Вариант В: через файл .dt

Создайте в консоли кластера 1С новую базу, указав сервер баз данных с новым портом: в поле сервера СУБД пишут localhost port=5433. Затем в Конфигураторе этой базы выполните Администрирование → Загрузить информационную базу и выберите .dt. Для баз больше 20–30 ГБ способ неудобен: загрузка идёт часами.

Переключение порта

Когда базы перенесены, проще всего поменять порты местами: старому кластеру дать 5433, новому — стандартный 5432. Тогда в консоли кластера 1С ничего править не нужно, все базы подключатся к новой СУБД сами. Порт задаётся параметром port в postgresql.conf, после изменения службу надо перезапустить.

5. Настройка postgresql.conf после обновления PostgreSQL

Откройте старый postgresql.conf и перенесите в новый всё, что меняли вручную. Слепо копировать файл целиком не стоит: в новых версиях часть параметров переименована или удалена, и служба может не запуститься.

Параметры, которые обычно настраивают под 1С:

ПараметрОриентирЗачем
shared_buffers25% ОЗУКэш страниц самой СУБД
effective_cache_size50–75% ОЗУПодсказка планировщику о кэше ОС
work_mem32–64 МБПамять на сортировки в одном запросе
maintenance_work_mem512 МБ – 2 ГБУскоряет VACUUM и создание индексов
max_locks_per_transaction256В базах 1С много таблиц, значения по умолчанию мало
max_connectionsПо числу сеансов с запасомКаждое соединение рабочего процесса 1С занимает слот

Пример для сервера с 32 ГБ ОЗУ: shared_buffers = 8GB, effective_cache_size = 24GB, work_mem = 64MB, maintenance_work_mem = 1GB.

Не забудьте pg_hba.conf: если сервер 1С стоит на другой машине, перенесите строки с разрешением доступа с его адреса.

Сбор статистики

После pg_upgrade обязательно соберите статистику. Утилита не переносит статистику планировщика, и первые часы запросы 1С будут работать в разы медленнее: отчёты, закрытие месяца , проведение документов.

vacuumdb -U postgres --all --analyze-in-stages

Ключ --analyze-in-stages сначала быстро собирает грубую статистику, а затем уточняет её. Базы становятся пригодными к работе уже после первого этапа. После pg_restore команду тоже стоит выполнить, хотя бы vacuumdb --all --analyze.

6. Проверка баз и откат на старую версию

Не открывайте базы пользователям сразу. Сначала короткий прогон проверок.

Проверка после обновления PostgreSQL
Выполнено: 0 / 8

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

Как откатиться

Откат зависит от способа переноса:

  • ↩️ pg_upgrade с копированием или pg_dump. Остановите новый кластер, верните старому порт 5432, запустите его. Базы окажутся в состоянии на момент начала работ. Всё, что пользователи успели внести в новую СУБД, придётся перенести вручную или выгрузкой.
  • ⛔ pg_upgrade --link. Если новый кластер хотя бы раз запускался, старый каталог данных испорчен. Откат только из резервной копии — дампа или .dt.

Старую версию держите неделю–две. Удаляйте её, когда закрыт хотя бы один отчётный период на новой СУБД. После pg_upgrade в каталоге запуска остаётся скрипт удаления старого кластера (delete_old_cluster.sh или .bat) — запускайте его, только когда откат точно не понадобится.

7. Ошибки при обновлении PostgreSQL для 1С

Диагностика: выберите симптом

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

Можно ли перескочить через несколько версий PostgreSQL сразу?
Да. И pg_upgrade, и pg_dump умеют переносить данные сразу через несколько основных версий. Ограничение одно: целевая версия должна поддерживаться вашей платформой 1С.
Нужно ли обновлять конфигурацию или платформу на клиентах?
Нет, если платформа на сервере уже поддерживает новую версию СУБД. Клиенты работают с сервером 1С, а не с PostgreSQL напрямую, поэтому смена версии СУБД для них незаметна.
Переносятся ли пользователи 1С и их пароли?
Да. Список пользователей информационной базы хранится в самой базе и переезжает вместе с данными любым из трёх способов.
Можно ли обновить минорную версию без переноса баз?
Да. Переход внутри одной основной версии, например с 15.3 на 15.8, — это замена программы поверх старой. Формат данных не меняется, достаточно остановить службу, поставить новую сборку и запустить снова.
Сколько длится обновление базы на 200 ГБ?
Ориентировочно: pg_upgrade с –link — 5–15 минут, с копированием — около часа на SSD, pg_dump и pg_restore — 3–6 часов. Плюс время на сбор статистики и проверки.