Миграция больших БД 1С с MSSQL Server на PostgreSQL

Описание методики миграции

1. Создание временной рабочей среды. Мы разворачиваем специальную инфраструктуру, которая позволяет разработчикам и тестировщикам без ограничения времени переносить и проверять данные, а также адаптировать 1С.
2. Поддержка новой БД в актуальном состоянии. Пока идёт миграция, данные в наследуемой и целевой базах синхронизируются. Это значит, что все текущие операции (продажи, заказы и т.д.) в реальном времени переносятся в новую базу PostgreSQL и процесс миграции не мешает повседневной деятельности.

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

Этап 1. Тестовая конвертация и функциональная адаптация

На данном этапе выполняется первичная конвертация БД в формат PostgreSQL и передача бизнес-пользователям для комплексной функциональной проверки и адаптации 1С для работы с PostgreSQL.

Этап 2. Внедрение системы репликации изменений данных БД MS SQL в БД PostgreSQL

Поскольку процесс конвертации для больших (>1 Тб) баз данных 1С может быть длительным (несколько часов или десятков часов), и выполняется в копии рабочей БД, то по его окончании требуется синхронизировать сформированную базу данных PostgreSQL с оперативными изменениями данных в наследуемой базе MS SQL, в которой продолжают работать пользователи 1С. И эту синхронизацию требуется выполнять непрерывно, пока не будут проведены все требуемые проверки базы данных PostgreSQL, вплоть до принятия решения по её вводу в эксплуатацию.

Для решения задачи синхронизации изменений между базами MS SQL и PostgreSQL мы применяем собственную «Платформу репликации баз данных DB Replication» (далее – DBR).

На рисунке представлена инфраструктура, временно (на период выполнения проекта миграции) разворачиваемая в рабочей системе 1С.

Пояснение к рисунку представлено в описании этапов 3 – 6.

Этап 3. Первая фаза формирования БД – конвертация в формат PostgreSQL

Процесс конвертации очень ресурсоемкий и выполняется на отдельном сервере – см. рисунок выше, сервер [MS-PRED-01], где разворачивается копия рабочей БД. Сама конвертация выполняется при помощи штатной утилиты ibcmd – поток данных «1». Длительность конвертации напрямую обусловлена объёмом данных наследуемой БД.

Рабочий процесс пользователей не прерывается, они продолжают работать в прежней базе MS SQL на сервере [MS-01]. При этом DBR непрерывно накапливает очередь изменений данных рабочей БД – поток данных «2». Очередь накапливается вплоть до окончания конвертациии всех последующих проверок.

Этап 4. Вторая фаза формирования БД – репликация изменений данных наследуемой базы MS SQL

После завершения первой фазы, запускается процесс прокачки накопленной очереди DBR в базе PostgreSQL – поток данных «3». Тем самым база PostgreSQL постепенно синхронизируется  по оперативным данным  с рабочей базой MS SQL.

Прокачка и применение очереди выполняется в течение нескольких часов (обычно сопоставимо с длительностью конвертации), после чего DBR переходит в режим онлайн-синхронизации и работает непрерывно на всех последующих фазах проекта, вплоть до момента ввода базы PostgreSQL в эксплуатацию.

Этап 5. Третья фаза формирования БД – комплексная проверка данных в базе PostgreSQL

После завершения второй фазы, копия сформированной и синхронизированной базы данных в формате PostgreSQL предоставляется пользователям 1С для комплексной проверки данных и функциональности – см. сервер [PG-02 (user-test)].

Длительность третьей фазы не ограничена ввиду постоянного поддержания целевой базы данных PostgreSQL на сервере [PG-01] в синхронном состоянии c наследуемой рабочей базой MS SQL, что обеспечивается работой DBR.

Этап 6. Ввод в эксплуатацию – переключение пользователей 1С в базу PostgreSQL

Непосредственно переключение пользователей 1С в новую и проверенную базу данных PostgreSQL выполняется в стандартное технологическое окно.

Несколько защитных механизмов от рисков миграции на PostgreSQL

Защита от критических функциональных рисков

Если реализованная заказчиком проверка была не достаточно эффективной и не позволила выявить критические ошибки, с которыми пользователи 1С столкнулись уже в новой рабочей базе PostgreSQL, и эти ошибки не удаётся быстро купировать и исправить, то пользователи могут быть переключены в исходную базу MS SQL без длительных прерываний работы системы и без потери введённых ими данных.

Эта возможность обеспечивается обратной репликацией – режимом работы DBR, при котором вводимые пользователями в базу PostgreSQL данные сразу же реплицируются в наследуемую базу MS SQL.

DBR – это резервный мост, по которому систему 1С без потери данных можно вернуть к первоначальной инфраструктуре на MS SQL, гарантированно без потери данных и без простоев.

Схема работы обратной репликации приведена на рисунке.

Таким образом, если в новой инфраструктуре и базе данных PostgreSQL что-то пойдёт по незапланированному сценарию, в любой момент можно откатиться обратно, пока работает обратная репликация.

Защита от рисков снижения производительности

На каждом этапе миграции для контроля состояния производительности всех серверов и баз данных, как в контуре MS SQL, так и в контуре PostgreSQL, мы используем систему мониторинга производительности серверов и баз данных PerfExpert.

PerfExpert позволяет максимально быстро определить любые источники проблем быстродействия систем (серверное оборудование, ПО, сетевую инфраструктуру, регламенты обслуживания баз данных, блокировки на уровне 1С и SQL, тяжёлые sql-запросы и многое другое) и принять меры по их устранению.

Ещё одним инструментом, который всегда у нас наготове и который может понадобиться в новой системе – это оптимизатор запросов QProcessing, при помощи которого можно налету, без изменения кода приложения, выборочно поменять характеристики отдельных тяжелых sql-запросов. В одной из наших статей на корпоративном блоге Хабр «Записки оптимизатора 1С (ч.12). СрезПоследних в 1C: Предприятие на PostgreSQL. Почему же так долго?» достаточно подробно описано решение проблемы падения производительности с помощью QProcessing на примере базы данных 1С на PostgreSQL, в которой использовались большие виртуальные таблицы типа СрезПоследних().

Стоимость проекта миграции базы данных 1С на PostgreSQL рассчитывается индивидуально и составляет не менее 900 000 ₽. Без НДС.

Заявки на расчёт стоимости следует отправлять на softpoint@softpoint.ru