Переход с MS SQL на PostgreSQL — это не просто смена одной программы на другую, а полноценная миграция инфраструктуры данных. Чаще всего это продиктовано необходимостью импортозамещения, экономией на лицензиях или требованиями безопасности. В этой статье мы подробно разберем, как выполнить этот переход максимально безболезненно, сохранив все данные, включая журнал регистрации, и обеспечив стабильную работу пользователей.
Начнем с самого важного правила: прямой перенос данных между MS SQL и PostgreSQL на уровне таблиц базы данных невозможен. СУБД имеют разные архитектуры, типы данных и механизмы работы с индексами. Единственный надежный и поддерживаемый вендором способ — использование механизма выгрузки/загрузки информационной базы через файл .dt.
Рассмотрим последовательность действий на стороне MS SQL:
.dt в надежное место.Проанализируем ситуацию с размером файла: если ваша база весит сотни гигабайт, выгрузка может занять длительное время. В таких случаях критично наличие свободного места на диске и стабильность работы сервера приложений.
Важно понимать, что «ванильная» версия PostgreSQL, скачанная с официального сайта разработчика, не подходит для корректной работы с 1С. Платформа 1С:Предприятие требует наличия специфических патчей (поддержка блокировок, оптимизация запросов). Рекомендуем использовать сборки от компании 1С или Postgres Pro.
Разберем основные параметры файла postgresql.conf, которые необходимо настроить перед загрузкой данных:
standard_conforming_strings = off — обязательный параметр для 1С, иначе возникнут ошибки при записи строк.escape_string_warning = off — отключает предупреждения об экранировании строк.shared_buffers — установим на уровне 25% от общего объема оперативной памяти сервера.max_locks_per_transaction — для крупных баз (например, 1С:ERP или УТ 11) значение стоит поднять до 256 или 512.Выясним причину, почему нельзя просто поменять настройки в существующей базе в консоли администрирования. Сервер 1С хранит внутренние идентификаторы (GUID) метаданных и привязывает к ним кэш и настройки. Попытка «подменить» СУБД «на лету» в одной и той же записи кластера часто приводит к нестабильной работе.
Выполним следующие шаги:
Теперь, когда у нас есть пустая оболочка, запустим 1С в режиме Конфигуратор и выполним загрузку файла .dt через меню Администрирование — Загрузить информационную базу.
Один из самых частых вопросов при переезде: как не потерять историю действий пользователей? Как мы выяснили, журнал регистрации хранится отдельно от базы данных SQL — в папке srvinfo на сервере 1С. Однако при создании новой базы в кластере ей присваивается новый уникальный идентификатор (ID), и сервер создает для нее пустую папку журнала.
Рассмотрим алгоритм переноса журнала:
C:\Program Files\1cv8\srvinfo\reg_1541\ (путь может отличаться в зависимости от настроек).1Cv8Log.1Cv8Log в аналогичную папку нового GUID..lgp), достаточно простого копирования файлов.Проанализируем технический нюанс, упомянутый в обсуждении: работа механизма RLS (Row Level Security) на PostgreSQL. Планировщик запросов Postgres строит планы иначе, чем MS SQL, что может приводить к катастрофическому падению скорости при открытии списков документов.
Для решения этой проблемы мы рекомендуем:
ANALYZE. В PostgreSQL статистика играет критическую роль для выбора оптимального плана запроса.Посмотрим на пример кода, который может помочь, если стандартные механизмы формы тормозят при включенном RLS (использование события ПриПолученииДанныхНаСервере для ручного управления выборкой):
&НаСервере
Процедура СписокПриПолученииДанныхНаСервере(ИмяЭлемента, Настройки, АльтернативнаяИнтерпретация, Параметры)
// Установка параметров запроса для оптимизации выборки под Postgres
Настройки.ПараметрыДанных.УстановитьЗначениеПараметра("ТекущаяДата", ТекущаяДата());
КонецПроцедуры
После завершения миграции крайне важно очистить кэш на всех рабочих станциях пользователей. Старый кэш, содержащий структуру таблиц MS SQL, будет конфликтовать с новой структурой. Самый простой способ — удалить базу из списка в стартере 1С и добавить её заново (это сбросит локальный путь к кэшу).
Также не забудем про регламентные операции в PostgreSQL. В отличие от MS SQL, где настройка планов обслуживания интуитивно понятна, в Postgres необходимо убедиться, что включен и корректно настроен autovacuum. Без него база быстро «распухнет» из-за накопления старых версий строк, что приведет к замедлению всей системы.
Рассмотрим шаги по проверке после переноса:
Таким образом, мы видим, что переход на PostgreSQL требует системного подхода, но при правильной настройке параметров СУБД и очистке кэша система будет работать не менее стабильно, чем на проприетарных решениях.