1С на PostgreSQL: шесть граблей при миграции с MS SQL 2019
Переводим 1С:Предприятие с MS SQL 2019 на PostgreSQL 14 в производственной компании: несовместимые запросы, pg_1c, work_mem и другие неочевидные места.
1С:Предприятие на PostgreSQL - массовый переход с MS SQL на фоне санкций и роста числа сертифицированных сборок PostgreSQL
С начала года к нам пришло несколько запросов на одну и ту же тему: «MS SQL кончается, хотим 1С на PostgreSQL, когда можем начать». Один из проектов уже перешёл в боевую фазу - производственная компания, 1С:ERP, несколько десятков активных пользователей, база под 200 ГБ. Делимся тем, что реально встретилось по пути.
Кратко про контекст: Microsoft в 2022 году перестал продавать лицензии MS SQL в России, поддержка существующих установок формально продолжается, но продление корпоративных лицензий становится квестом. Параллельно растёт список сертифицированных сборок PostgreSQL для 1С - вендор выпускает специальные патченные версии через партнёрский портал. Так что движение идёт с двух сторон.
Точка старта
У клиента: 1С:ERP 2.5, MS SQL Server 2019 Standard, Windows Server 2019 на сервере СУБД. Цель: PostgreSQL 14 (сертифицированная сборка от 1С), Astra Linux 1.7 на новом сервере СУБД. 1С-сервер пока остаётся на Windows - это допустимая конфигурация, мигрируем только СУБД.
Спойлер: миграцию мы сделали, база работает. Но список граблей оказался предсказуемо длинным.
Шесть граблей
Первое - несовместимые T-SQL конструкции в запросах 1С. Платформа 1С генерирует SQL-запросы под конкретную СУБД. Большинство типовых запросов адаптированы и работают. Но если в конфигурации есть доработки, написанные разработчиками с расчётом на T-SQL специфику - начинаются проблемы. У клиента нашлись несколько внешних обработок с прямыми SQL-запросами через ПолучитьАдминистраторСессий и подобное. Их пришлось переписывать до перехода.
Второе - pg_1c, а не ванильный PostgreSQL. Это критичный момент, который часть команд пропускает. 1С работает только с патченными сборками PostgreSQL, которые называются pg_1c. Они содержат специфичные патчи для работы с платформой - в частности, изменённое поведение блокировок и ряд функций. Обычный PostgreSQL из репозитория дистрибутива формально не поддерживается, и на практике вылезают проблемы именно там, где кажется что «всё стандартное». Дистрибутивы pg_1c для Linux лежат на портале 1С, нужна активная лицензия.
Третье - work_mem и 1С-нагрузка не дружат по умолчанию. В MS SQL управление памятью под запрос настраивается глобально через max server memory. PostgreSQL устроен иначе: work_mem умножается на количество одновременных операций сортировки/хеш-джойнов. При типичной 1С-нагрузке с несколькими десятками сессий и тяжёлыми отчётами дефолтный work_mem = 4MB даёт прожорливые сортировки во временных файлах - база начинает активно писать в pgsql_tmp. Мы поставили work_mem = 64MB, но с оговоркой: при пиковой нагрузке потребление памяти считать надо отдельно, формула грубая.
Четвёртое - статистика и планировщик после загрузки данных. После переноса базы через штатный выгрузчик 1С (dt-файл) статистика в PostgreSQL нулевая. Автовакуум её соберёт, но не сразу. В первые часы после запуска планировщик строит дикие планы - полные сканы там, где должен быть индекс. Перед открытием доступа пользователям обязательно: ANALYZE по всем таблицам и проверка pg_stat_statements на первые тяжёлые запросы.
Пятое - локаль и коллации. MS SQL по умолчанию работает с Cyrillic_General_CI_AS. PostgreSQL при создании базы 1С нужна локаль ru_RU.UTF-8 и коллация ru-x-icu (или ru_RU.UTF-8 в зависимости от версии). Если база создана с неправильной коллацией - сортировки будут работать иначе, индексы могут не использоваться там, где ожидается. На Astra Linux 1.7 с нужными локалями проблем не было, но генерацию локали нужно проверять до создания кластера.
Шестое - 1С-клиенты и таймауты соединения. MS SQL терпимее к длинным транзакциям в интерактивных сессиях. PostgreSQL по умолчанию с statement_timeout не выставлен, но idle_in_transaction_session_timeout стоит настроить явно - иначе при падении клиента незакрытые транзакции держат блокировки долго. В 1С это проявляется в характерной картине: пользователь закрыл Excel с данными из 1С, не завершив транзакцию, и другие пользователи начинают ждать. С MS SQL это тоже было, но PostgreSQL на этом месте более заметен.
Что сейчас
База в продакшне вторую неделю. Жалоб на скорость нет, план-гид не понадобился. Больше всего времени съело не техническое переключение, а разбор доработок конфигурации и согласование окна для переноса данных.
Кому-то из читателей может казаться что задача «1С на PostgreSQL» сводится к нажатию кнопки «выгрузить/загрузить» - это не так. Это интеграционный проект с несколькими слоями проверки. Стандартная выгрузка через dt работает, но подготовка среды, настройка СУБД и тестирование конфигурации на новой базе занимают не меньше времени, чем сам перенос данных.