Переход на новую мажорную версию СУБД — это всегда ответственный шаг, требующий понимания совместимости версий и особенностей внутреннего устройства базы данных. В случае с PostgreSQL 12 и платформой 1С:Предприятие 8.3 многие пользователи сталкиваются с тем, что после обычного обновления службы базы данных перестают открываться или работают некорректно. Разберем подробно, почему это происходит и как правильно организовать процесс миграции, чтобы обеспечить стабильную работу системы.
Прежде чем приступать к техническим манипуляциям с сервером базы данных, проанализируем системные требования, предъявляемые фирмой 1С. Важно понимать, что PostgreSQL 12 привносит значительные изменения в работу с системными каталогами и механизмами оптимизации запросов.
Согласно официальным данным ИТС, полноценная поддержка PostgreSQL 12 была реализована в платформе 8.3.18 и старше. Хотя практический опыт некоторых администраторов показывает, что запуск возможен и на версии 8.3.16 или 8.3.17, использование этих версий в продуктивной среде крайне не рекомендуется. Основная причина кроется в механизме работы с временными таблицами. В ранних релизах платформы запросы 1С могут вызывать критические ошибки при попытке создания объектов в системном каталоге PostgreSQL 12, что приведет к аварийному завершению сеанса пользователя.
Поскольку формат хранения данных в PostgreSQL 12 не является обратно совместимым с версиями 10 или 11, простой запуск новой службы на старых файлах данных (каталог data) невозможен. Нам необходимо выполнить процедуру переноса информации. Рассмотрим три основных сценария.
— Выполняем полную выгрузку информационной базы в файл .dt из конфигуратора на старой версии PostgreSQL.
— Удаляем базу из списка серверов 1С и удаляем саму базу в старом PostgreSQL.
— Останавливаем старую службу, устанавливаем PostgreSQL 12 (обязательно с патчами от 1С).
— Создаем новую пустую базу данных в PostgreSQL 12 через консоль администрирования 1С.
— Загружаем файл .dt в созданную базу.
pg_dump именно от 12-й версии, указывая параметры подключения к старому серверу.
pg_dump -h localhost -U postgres -F c -b -v -f "my_base_dump.backup" my_database
После этого восстанавливаем данные в новую базу:
pg_restore -h localhost -U postgres -d my_new_database -v "my_base_dump.backup"
.dt может занять слишком много времени. В таком случае проанализируем использование утилиты pg_upgrade. Она позволяет обновить версию без полного копирования данных, если использовать ключ --link. При этом создаются жесткие ссылки на файлы данных, что сокращает время перехода до нескольких минут. Помните, что обе версии СУБД должны быть установлены на одном сервере одновременно в процессе миграции.
После того как данные успешно перенесены, необходимо выполнить тонкую настройку СУБД, так как параметры "по умолчанию" в 12-й версии могут негативно сказаться на производительности 1С.
Отключение JIT-компиляции:
Одним из главных нововведений 12-й версии стало включение Just-In-Time (JIT) компиляции запросов по умолчанию. Для аналитических запросов в хранилищах данных это благо. Однако 1С генерирует огромное количество коротких и быстрых OLTP-запросов. Накладные расходы на компиляцию такого запроса часто превышают время его выполнения. Выясним, как это отключить: в файле postgresql.conf установите параметр jit = off.
Оптимизация индексов и CTE:
PostgreSQL 12 значительно эффективнее работает с B-tree индексами. Вы заметите, что после переиндексации (команда REINDEX) индексы стали занимать на 20-40% меньше места на диске. Также PostgreSQL 12 научился делать inline для Common Table Expressions (оператор WITH). Это позволяет планировщику лучше оптимизировать сложные вложенные запросы, которые часто формирует динамический список или сложные отчеты в 1С.
Проанализируем ключевые параметры в postgresql.conf, которые критичны для стабильной работы 1С на 12-й версии:
shared_buffers: установите значение равным 25% от общего объема оперативной памяти сервера. Это обеспечит эффективное кэширование страниц данных.effective_cache_size: установите на уровне 50-75% от доступной RAM. Это подскажет планировщику, какой объем кэша доступен в операционной системе.max_parallel_workers_per_gather: рекомендуется ограничить это значение до 2 или 4. Слишком большое количество параллельных потоков на один запрос 1С может вызвать деградацию производительности из-за конкуренции за ресурсы.autovacuum: убедитесь, что автовакуум включен и настроен агрессивно (уменьшите autovacuum_vacuum_scale_factor), так как 1С активно создает и удаляет записи в таблицах итогов.Критически важный шаг после миграции:
Если вы использовали pg_upgrade или просто перенесли данные без полной перезагрузки, обязательно выполните команду ANALYZE для всех баз данных. Статистика в PostgreSQL 12 собирается иначе, и без актуальной статистики планировщик будет строить неоптимальные планы выполнения, что приведет к жутким тормозам интерфейса 1С.
Подводя итог, можно сказать, что переход на PostgreSQL 12 оправдан ради повышения производительности дисковой подсистемы и ускорения работы с индексами. Однако, чтобы не получить неработающую систему, всегда придерживайтесь правила: сначала обновляем платформу 1С до актуальной (не ниже 8.3.18), затем выполняем миграцию данных через .dt или pg_upgrade, и в завершение обязательно отключаем jit и обновляем статистику analyze. Только в такой последовательности переход будет бесшовным и принесет желаемый профит.