1С на Linux с PostgreSQL: установка, настройка и грабли миграции с MS SQL

Перевод 1С с Windows и MS SQL на Linux с PostgreSQL перестал быть экзотикой — теперь это обычная задача квартала. Технически переезд несложный, но он щедро усыпан мелочами, каждая из которых стоит нескольких часов. Собрал то, что мы набили на десятке миграций: от выбора сборки до вещей, которые перестают работать на следующий день.

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

Реальных вариантов три:

• Сборка от 1С — выкладывается на портале вместе с платформой. Бесплатна для владельцев лицензий, версии выходят с задержкой относительно апстрима.
• Postgres Pro — коммерческая российская сборка, есть редакции Standard и Enterprise. Платная, зато с поддержкой и в реестре отечественного ПО.
• Сборки от дистрибутивов российских ОС — Астра, РЕД ОС и прочие поставляют свои варианты.

Наш выбор по умолчанию для коммерческого клиента без требований по реестру — сборка от 1С. Она бесплатна и покрывает всё, что нужно офису до сотни пользователей. Postgres Pro берём, когда есть формальное требование по импортозамещению либо база переваливает за 300–500 ГБ и нужна поддержка вендора.

Версию выбираем не самую свежую, а ту, которая явно указана как совместимая с вашей версией платформы 1С. Матрица совместимости публикуется, и отступать от неё не стоит: несовместимая пара даёт странные ошибки на ровном месте.

Самая дорогая ошибка установки. Исправляется только пересозданием кластера баз данных, то есть с потерей всего.

Кластер PostgreSQL инициализируется с определённой локалью и кодировкой. Для 1С нужны ru_RU.UTF-8 и кодировка UTF8. Если система установлена с локалью C или en_US, initdb унаследует её, и вы получите неправильную сортировку кириллицы: в списках контрагентов «Ёлкин» окажется не там, где ожидает бухгалтер, а поиск по подстроке начнёт вести себя странно.

# перед установкой убеждаемся, что локаль есть в системе
locale -a | grep ru_RU

# инициализация кластера с нужными параметрами
/usr/pgsql-16/bin/initdb -D /var/lib/pgsql/16/data \
  --locale=ru_RU.UTF-8 --encoding=UTF8 --data-checksums

Флаг --data-checksums добавляю всегда. Он даёт контрольные суммы страниц данных — небольшая нагрузка на процессор в обмен на раннее обнаружение повреждений на диске. Включить его потом на живом кластере штатно нельзя.

Проверить, что получилось:

psql -c "SHOW lc_collate;" -c "SHOW server_encoding;"

Если увидели что-то кроме ru_RU.UTF-8 и UTF8 — останавливайтесь и переделывайте сейчас, пока база пустая.

Порядок отличается от Windows, и пара шагов не очевидна.

Пакеты платформы ставятся из архива с портала. Сервер работает от пользователя usr1cv8, который создаётся при установке. Служба управляется через systemd.

systemctl enable --now srv1cv83
systemctl status srv1cv83
ss -tlnp | grep -E '154[01]|15[6-9][0-9]'

Что часто забывают:

Шрифты. Серверу 1С нужны шрифты для формирования печатных форм и табличных документов. На минимальной установке Linux их нет, и отчёты будут собираться криво либо падать. Ставим fontconfig и набор шрифтов, включая метрически совместимые с MS. Это первое, что мы проверяем при жалобе «печатные формы разъезжаются».

Лимиты. Дефолтные ограничения на число открытых файлов и процессов малы для сервера 1С. Правим в /etc/security/limits.conf либо в unit-файле службы: nofile хотя бы 65536, nproc — 16384.

SELinux и firewalld. На RHEL-подобных системах оба включены по умолчанию. Порты 1540, 1541 и диапазон 1560–1591 надо открыть явно, а SELinux — либо настроить контексты, либо перевести в permissive на время отладки, не забыв вернуть.

firewall-cmd --permanent --add-port=1540-1541/tcp
firewall-cmd --permanent --add-port=1560-1591/tcp
firewall-cmd --reload

Прямого переноса файлов между MS SQL и PostgreSQL не существует. Переезд идёт только через платформу.

1. На старом сервере выгружаем базу в .dt из конфигуратора. Нужен монопольный доступ.
2. На новом сервере создаём пустую базу в кластере 1С с типом СУБД PostgreSQL.
3. Загружаем .dt.
4. Запускаем тестирование и исправление с проверкой логической целостности.
5. Обновляем статистику и делаем полный анализ.

Время. База 60 ГБ на MS SQL выгружается в .dt около сорока минут, файл получается 8–12 ГБ, загрузка в PostgreSQL занимает от двух до пяти часов. Планируйте выходные, а не вечер.

Ускорить загрузку можно временными настройками PostgreSQL — на время миграции отключаем fsync, поднимаем maintenance_work_mem, увеличиваем max_wal_size. Обязательно вернуть обратно после загрузки: работать в бою с выключенным fsync означает потерять базу при первом же отключении питания.

-- ТОЛЬКО на время миграции
ALTER SYSTEM SET fsync = off;
ALTER SYSTEM SET full_page_writes = off;
ALTER SYSTEM SET maintenance_work_mem = '2GB';
SELECT pg_reload_conf();

И сразу заведите себе напоминание вернуть значения. Мы однажды нашли у клиента боевую базу, работавшую с fsync = off одиннадцать месяцев. Повезло.

PostgreSQL из коробки настроен консервативно и на сервере с 64 ГБ будет использовать смешную долю памяти.

Про work_mem стоит сказать отдельно, потому что это самый частый способ уронить сервер. Значение действует не на сессию, а на каждую операцию сортировки или хеширования внутри запроса. Сложный отчёт 1С может породить десяток таких операций. Умножьте на сорок одновременных пользователей — и 256 МБ, казавшиеся скромными, превращаются в требование в сотню гигабайт.

Мы начинаем с 64 МБ на офис до 50 человек и поднимаем адресно, если видим в логе временные файлы. Включить их логирование обязательно:

log_temp_files = 0   # писать в лог все временные файлы

Huge pages на Linux дают заметный выигрыш при больших shared_buffers. Включаются в паре: huge_pages = try в PostgreSQL и резервирование страниц в ядре через vm.nr_hugepages.

Механизм, с которым администраторы, пришедшие из мира MS SQL, сталкиваются впервые и обычно недооценивают.

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

Если автовакуум не успевает, происходит раздувание: таблица на миллион строк физически занимает как таблица на пять миллионов, запросы читают лишние страницы, всё замедляется постепенно и незаметно.

Дефолтные настройки рассчитаны на маленькие базы. Для 1С мы делаем автовакуум агрессивнее:

autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
autovacuum_vacuum_cost_limit = 2000

Смысл: чаще просыпаться, срабатывать при 5 % изменённых строк вместо дефолтных 20 %, не тормозить себя лимитом стоимости.

Проверить раздувание по конкретным таблицам:

SELECT relname, n_live_tup, n_dead_tup,
       round(100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0), 1) AS dead_pct,
       last_autovacuum
FROM pg_stat_user_tables
WHERE n_dead_tup > 10000
ORDER BY dead_pct DESC LIMIT 20;

Устойчивое значение dead_pct выше 20 % на крупных таблицах — сигнал, что автовакуум не справляется.

Windows-администратор привык, что дисковая подсистема — это про RAID и про то, куда положить файлы. На Linux добавляется слой файловой системы и её параметров, и он влияет заметно.

Файловая система. Мы используем XFS для каталога данных PostgreSQL. Она лучше ext4 держит параллельную запись множеством потоков, а именно так ведёт себя учётная нагрузка. Разница на наших замерах — порядка 10–15 % на записи при 30 одновременных сеансах.

Монтирование. Опция noatime убирает обновление времени доступа при каждом чтении файла. Для базы это чистая экономия операций записи, ничего не стоящая.

/dev/mapper/vg0-pgdata  /var/lib/pgsql  xfs  defaults,noatime  0 0

Планировщик ввода-вывода. На NVMe правильное значение — none: диск сам разберётся лучше ядра. На обычных SSD за RAID-контроллером — mq-deadline. Дефолтный на многих дистрибутивах bfq оптимизирован под десктоп и на серверной нагрузке даёт лишние задержки.

cat /sys/block/nvme0n1/queue/scheduler
echo none > /sys/block/nvme0n1/queue/scheduler   # закрепить через udev-правило

Разнос файлов. Каталог данных, WAL и временные файлы стоит разводить по разным томам, если есть возможность. WAL пишется последовательно и мелкими порциями, данные — случайно и крупными. На одном шпинделе они мешают друг другу; на NVMe разница меньше, но на нагруженной базе видна.

# WAL на отдельный том — делается при инициализации
initdb -D /var/lib/pgsql/16/data -X /var/lib/pgsql/16/wal ...

Swap. Уменьшаем vm.swappiness до 1–10. PostgreSQL крайне плохо переносит вытеснение своих буферов в swap: задержки вырастают на порядки, а причина совершенно не очевидна из графиков нагрузки на процессор.

sysctl -w vm.swappiness=5
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=90

Последние две строки защищают от того, что OOM-killer выберет своей жертвой основной процесс PostgreSQL. Такое случается, и выглядит это как внезапная смерть СУБД без единой записи в её собственном логе — сообщение будет в dmesg.

Список вещей, которые работали на Windows и перестают на Linux. Их стоит проверить до переезда, а не после.

• Внешние компоненты, собранные только под Windows. Сканеры штрихкодов, торговое оборудование, некоторые интеграции. Нужна версия под Linux от вендора, и она есть не всегда.
• COM-соединения и всё, что через них работало. Обмены с внешними системами через COM придётся переписывать на HTTP-сервисы или OData.
• Печать через COM в Word и Excel. Формирование документов внешними приложениями Microsoft на Linux не работает. Типовые механизмы 1С формируют файлы сами, а вот самописные обработки — нет.
• Криптография. КриптоПро под Linux существует, но настройка контейнеров и работа с токенами отличается. Отдельная задача с собственным сроком.
• Windows-аутентификация в базе. На Linux она возможна через Kerberos с настройкой keytab, но это не «поставил галку».
• Сетевые пути вида \\server\share в настройках обменов и выгрузок. Меняются на смонтированные каталоги.

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

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

Можно ли перенести базу 1С с MS SQL на PostgreSQL напрямую?

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

Подойдёт ли обычный PostgreSQL из репозитория дистрибутива?

Нет, платформе нужны патчи, которых в ванильной сборке нет. Берите сборку от 1С с портала, Postgres Pro или сборку из вашей российской ОС — и обязательно сверяйтесь с матрицей совместимости версий.

Насколько PostgreSQL медленнее MS SQL для 1С?

На нагрузке офиса до сотни пользователей разница в пределах погрешности при корректной настройке памяти и автовакуума. Заметное отставание обычно означает, что параметры остались дефолтными либо автовакуум не справляется и таблицы раздуло.

Что чаще всего ломается после перехода на Linux?

Не СУБД, а периферия: внешние компоненты торгового оборудования, обмены через COM, формирование файлов через Word и Excel, работа с криптографией. Всё это надо проверить на тестовом контуре заранее.