Как перенести сервер 1С и базу данных с Windows и MS SQL на Linux и PostgreSQL?

← На главную

Миграция инфраструктуры 1С с операционной системы Windows Server и СУБД Microsoft SQL Server на Linux с СУБД PostgreSQL — распространенная задача при оптимизации лицензионных затрат и импортозамещении. Однако прямое копирование таблиц или конвертация резервных копий на уровне СУБД здесь невозможны. Разберем причины этих ограничений, подробно рассмотрим методику переноса данных в зависимости от размера базы и изучим сопутствующие настройки серверного окружения.

Почему невозможно прямое копирование данных между MS SQL и PostgreSQL

Проанализируем технические особенности хранения информации в различных СУБД, с которыми работает платформа 1С:Предприятие:

Смещение дат (Date Offset). В MS SQL для таблиц 1С традиционно используется смещение дат на 2000 лет. Это связано с историческим ограничением типа DATETIME в SQL Server (минимальное поддерживаемое значение — 01.01.1753). В PostgreSQL поддерживаются даты вплоть до нашей эры, поэтому платформа всегда устанавливает смещение 0. Попытка переноса «сырых» бинарных файлов или таблиц сторонними утилитами приведет к порче дат документов и проводок.
Внутреннее представление и форматы. Каждая СУБД использует собственную архитектуру страниц данных, метаданных и бинарных представлений полей. Преобразование структур данных на уровне физических файлов невозможно.
Связка платформы и драйверов. Сервер 1С под управлением Linux не имеет встроенных механизмов прямого соединения с MS SQL Server через Native Client. Таким образом, промежуточным звеном для трансляции данных всегда выступает сама платформа 1С.

Подготовка базы данных перед миграцией

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

Создадим полную резервную копию средствами СУБД MS SQL.
Запустим операцию «Тестирование и исправление информационной базы» через меню Администрирование — Тестирование и исправление в режиме Конфигуратор. Обязательно выберем пункты «Реструктуризация таблиц информационной базы» и «Проверка логической и ссылочной целостности». В MS SQL и PostgreSQL механизмы валидации уникальности индексов и пустых строк различаются, и скрытые логические ошибки, незаметные на MS SQL, прервут процесс импорта в PostgreSQL.
Выполним пересчет итогов регистров накопления и бухгалтерии.

Способ 1. Перенос баз небольшого и среднего объема через выгрузку DT

Если размер информационной базы составляет до 30–50 ГБ (как в случае базы 10 ГБ под управлением «1С:Бухгалтерия 3.0»), оптимальным и самым простым решением является использование технологического архива (файла .dt). Разберем процесс по шагам:

Выгрузка данных в Windows: завершим сеансы пользователей, запустим 64-разрядный «Конфигуратор», перейдем в меню Администрирование — Выгрузить информационную базу... и укажем путь для сохранения файла с расширением .dt. Использование именно 64-разрядного клиента критически важно, так как 32-разрядный процесс может завершиться аварийно с ошибкой нехватки адресного пространства памяти при сжатии больших объемов таблиц.
Подготовка СУБД PostgreSQL на Linux: убедимся, что установлена специализированная сборка PostgreSQL с патчами от 1С. Кластер баз данных должен быть инициализирован с локалью ru_RU.UTF-8. Создадим чистую базу данных через утилиту createdb или консоль администрирования кластера 1С.
Загрузка данных в Linux: создадим новую информационную базу в кластере серверов 1С на Linux, подключимся к ней через «Конфигуратор» и выполним команду Администрирование — Загрузить информационную базу..., выбрав ранее выгруженный файл .dt. Платформа самостоятельно создаст необходимые таблицы с правильным смещением дат и типами полей для PostgreSQL.

Оптимизация параметров PostgreSQL для ускорения загрузки

При загрузке тяжелых файлов .dt в PostgreSQL создаются миллионы строк и строятся индексы, что создает пиковую нагрузку на подсистему дискового ввода-вывода. Чтобы процесс загрузки не затянулся на десятки часов, временно изменим ключевые параметры в конфигурационном файле postgresql.conf:

Отключим сброс буферов на диск: fsync = off.
Отключим автоматический сбор мусора на время заливки: autovacuum = off.
Уменьшим интенсивность записи журнала упреждающей записи: wal_level = minimal, archive_mode = off, max_wal_senders = 0.
Увеличим контрольные точки и объем памяти для служебных операций: max_wal_size = 10GB, checkpoint_timeout = 30min, maintenance_work_mem = 2GB (или более, в зависимости от объема доступного ОЗУ).
Перезапустим службу СУБД и выполним загрузку базы данных через Конфигуратор.
Критически важный шаг: после успешной загрузки вернем все измененные параметры в их штатные безопасные значения, снова перезапустим PostgreSQL и выполним принудительный сбор статистики командой: ANALYZE VERBOSE; Без выполнения сбора статистики планировщик запросов PostgreSQL не сможет строить корректные планы выполнения, что приведет к катастрофическому падению производительности запросов 1С.

Способ 2. Миграция баз большого объема (от 100 ГБ и выше)

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

Создаем в целевом кластере на Linux чистую базу из файла конфигурации (.cf), выгруженного из рабочей базы.
Используем универсальную выгрузку и загрузку данных в формате XML с помощью встроенных обработок («Выгрузка и загрузка данных XML»). Выгрузку можно осуществлять порциями по периодам или отдельным метаданным (сначала справочники и константы, затем регистры сведений, документы и проводки).
Настраиваем синхронизацию данных через планы обмена: создаем узел обмена, фиксируем начальные изменения и передаем данные пакетами по протоколу EnterpriseData либо через веб-сервисы.
Перед миграцией целесообразно выполнить свертку информационной базы, закрыв старые неактуальные периоды, что позволит переносить только актуальные остатки и обороты за последние 2–3 года.

Важные системные особенности работы сервера 1С на Linux

После переноса данных необходимо учесть технические нюансы эксплуатации связки Linux + PostgreSQL:

Регистрозависимость путей: файловая система Linux различает строчные и заглавные буквы. Любой доработанный программный код, содержащий прямые пути с обратными слэшами вида C:\Exchange\file.txt, на стороне сервера вызовет критическую ошибку. Пути должны формироваться кроссплатформенно с использованием метода ПолучитьРазделительПути().
Отсутствие COM-соединений: в среде Linux отсутствует поддержка технологий COM/ActiveX. Если интеграции с внешними системами или обмен между базами работали через COMОбъект("V83.COMConnector"), такой функционал откажет. Интеграции необходимо перевести на REST API, HTTP-соединения или веб-сервисы.
Шрифты и рендеринг: сервер приложений 1С выполняет формирование печатных форм и отчетов на сервере. Для исключения искажений верстки документов в ОС Linux обязательно должны быть установлены шрифты Microsoft Core Fonts (пакет ttf-mscorefonts-installer или аналогичный) и графическая библиотека libfreetype.
Криптография: если в базе используется модуль «1С-Отчетность», необходимо развернуть сертифицированный криптопровайдер под Linux (например, КриптоПро CSP) и импортировать сертификаты в личное хранилище системного пользователя, под которым запущена служба сервера 1С (по умолчанию usr1cv8).
Управление памятью: для СУБД PostgreSQL рекомендуется отключить механизм Transparent Huge Pages (THP) на уровне ядра операционной системы, так как он вызывает скачки задержек ввода-вывода при интенсивной транзакционной нагрузке.