Сегодняшний пост – про миграцию большой базы данных 1С Предприятие с MS SQL Server на PostgreSQL. Тема перехода на PostgreSQL весьма популярна, и почти на каждой конференции по PG обязательно есть парочка докладов на эту тему. Почему же эта тема до сих пор злободневна? Или не все подводные камни еще раскрыты и найдены?

Когда мы начинали свой блог здесь на Хабре, наша первая статья была посвящена как раз задаче перевода больших баз данных MSSQL –> PostgreSQL. И первой причиной, из-за которой компании решаются на переход мы называли законодательство. А именно, необходимость для государственных и окологосударственных организаций, чьи информационные системы относятся к значимым объектам критической информационной инфраструктуры (ЗОКИИ) переводить свою работу на отечественное ПО. Прошло два года. И это всё еще основная причина. Поэтому новая СУБД, которую выбрал заказчик - одна из семейства PostgreSQL. Версия принципиально не важна.

Теперь почему это статья возникла. Если в первой статье мы описывали наше видение, то сейчас это практический кейс со своими нюансами. Поэтому, решили поделиться своим опытом, т.к. перевод любой многотерабайтной базы данных на новые платформы (версия СУБД, просто другая СУБД, платформа 1С) – это всегда стресс и очень большие риски простоя системы, а значит риски простоя бизнеса и денежных потерь.

Это не будет инструкция в стиле «делай раз», «делай два». Это будет про то, что большие базы в принципе очень тяжело и рискованно передвинуть (СУБД, платформа, окружение,…). И мы предлагаем собственный метод, как это сделать с гарантией отсутствия простоев бизнеса. Даже если что-то пойдет не так в «новой» системе, пользователи не должны страдать, а бизнес простаивать. Это главное!

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

• Большой объем базы данных. Значит любая новая итерация, связанная с архивированием, разворачиванием из архива, конвертаций данных, проверкой гипотез и т.п. – это долго или очень долго.

• Недостаточное по длительности технологическое окно – лишь несколько часов, в которое не укладывается даже первоначальная конвертация БД.

• Возможная неприемлемая деградация отклика от базы после перехода на PostgreSQL.

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

• Недостаточные аппаратные ресурсы, выделенные на новую систему. Например, оперативная память в PG будет потребляться гораздо бодрее, и, если у вас её было впритык на MS SQL, то на PG система просто умрет.

Из-за рисков проект может стать путём в один конец. Если в новой системе возникнут проблемы функционального, архитектурного характера или неприемлемая просадка производительности, особенно спустя несколько дней, то вернуться назад может быть очень проблематично. Последствия таких решений – простои бизнеса и даже потеря данных за эти несколько дней.

Что касается функциональных и технологических рисков, то они прогнозируемы и по большей части решаемы заранее на стендах. А вот маленькое тех. окно – это серьезно, и данное ограничение очень тяжело обойти, не усложнив проект и, тем самым, не нагородив новых подводных камней. Помним про путь в один конец! Вообще, именно размер технологического окна объясняет тот замечательный факт, что все большие изменения в инфраструктуре происходят когда? Правильно, в НГ праздники. Если ваш бизнес не сильно завязан на ритейл и/или вам не нужно 24/7 работающая система, то это именно тот промежуток времени, когда почти все трудящиеся отдыхают, а айтишники встречают Новый год хороводом вокруг серверов. Поэтому если не успели в НГ-праздники, то следующая попытка может быть… никогда не скоро. А системам 24/7 совсем тяжело с такими вот переходами и миграциями.

На том вступление завершаю. Перехожу к нашему проекту.

Исходные данные

• БД MS SQL объемом 10+ Тб.

• Количество пользователей: 1000+

• Размер технологического окна: 3-4 часа.

• Несколько попыток самостоятельного перехода (своими силами Заказчика), завершившиеся неудачей. Причины:

  • Слишком долго. Бизнес не может согласовать простой в несколько дней.

  • Было несколько неудачных попыток конвертации утилитой ibcmd из-за явных недочетов планирования и "неучтенок" - то памяти не хватало, то дискового пространства (например, для журнала транзакций), то из-за несогласованности действий сервер не вовремя перезагрузили и т.п.

  • Первоначальная конвертация утилитой ibcmd даже в многопоточном режиме (50 потоков) работает двое-трое суток, причем нестабильно – может упасть в любой момент. Утилита непредсказуемо падает (прерывается) в самые разные моменты. Иногда через несколько часов, иногда через сутки после старта. При этом никакой внятной ошибки нет. А ее повторный запуск без каких бы то ни было изменений в настройках и окружении может пройти вполне успешно. Это принципиально ограничивает возможности по согласованию такого неординарного технологического окна.

  • Сохраняются ненулевые риски неприемлемого снижения производительности, из-за которого может потребоваться вернуться обратно в MS SQL. Имеется в виду, что никакое предварительное тестирование (а его конечно проводили) не может воспроизвести точно боевую нагрузку и не покроет всего функционала. А проблемы там заведомо есть - множество запросов в PG сильно проседают по скорости и возрастают по потреблению ресурсов. Соответственно они требуют оптимизации. Какие-то можно переписать на стороне 1С, а какие-то придется оптимизировать другими методами.

Итого проект подразумевает решение трех глобальных задач:

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

2. Необходимо гарантировать работу пользователей в части производительности не хуже, чем было на MS SQL. То есть каким-то образом защититься от возможных провалов по производительности и сбоев функциональности в новой базе данных.

3. Обеспечение временной гарантии на откат в случае форс-мажора.

Проект выполнялся совместно с заказчиком. Заказчик отвечал за функциональное тестирование и адаптацию кода приложения под особенности работы 1С в Linux+PostgreSQL, а также за первичную конвертацию с помощью ibcmd. Софтпоинт отвечал за синхронизацию оперативных изменений между рабочей базой на MS SQL и целевой базой на PostgreSQL, и за производительность. Итого, функциональные риски – на заказчике, риски просадки производительности и возможных простоев пользователей – на Софтпоинт. Потому всё, что касается функциональной адаптации я опущу.

Методика миграции

Этап 1. Конвертация и тестирование

Поскольку заказчик уже предпринимал попытки миграции, то в целом система была уже подготовлена к переходу, код 1С более или менее вычищен. Оставалась нерешенной проблема длительности первоначальной конвертации плюс время на проверку ее успешности и готовности БД к переключению пользователей на нее. Длительность этой процедуры, если свести к минимуму проверки, составляла около 3 суток. Железо мощное, многопоточность используется, но быстрее не получается. Плюс "отягчающий" фактор – конвертация может падать и могут потребоваться повторные попытки (причем не одна).

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

Схематично процесс миграции представлен на рисунке ниже. Схема несколько упрощена по сравнению с реальной, чтобы лишние детали не отвлекали от сути процесса.

Для первичной конвертации свежая копия рабочей базы данных была развернута на сервере [MS-PRED-01], и утилита ibcmd работала именно с ней (зеленая пунктирная стрелка на схеме). Поскольку рабочий процесс пользователей не прерывался, то в параллель с конвертацией платформа DBR начинает накапливать очередь изменений из рабочей БД (фиолетовая широкая стрелка на схеме) в базе данных репликации. Вплоть до окончания работы ibcmd и всех проверок.

После завершения этапа первоначальной конвертации команда специалистов заказчика выполнила комплекс проверок:

• Сверили данные в сконвертированной базе PostgreSQL [PG-01] с контрольной базой формата MS SQL [MS-PRED-01].

• Развернули копию сконвертированной базы PostgreSQL [PG-02] и выполнили в ней ограниченное функциональное тестирование.

После завершения этапа верификации на стороне контура PostgreSQL запустили прокачку очереди (зеленая широкая стрелка на схеме). Обратите внимание, таких зеленых стрелок две. Одна – основная, которая преобразовывает изменения из формата MS в формат PG и передает их в целевую базу на PostgreSQL. А вторая ведёт на сервер MS SQL [MS-NEW-01], который использовался как эталон для оценки времени задержки прокачки очереди на сервере [PG-01]. Дело в том, что было замечено, что временами очередь в PG прокачивается с большей, чем следовало бы, задержкой. Было подозрение на большой поток. Но причина оказалась в некоторых sql-запросах транспортной системы, с которыми оптимизатор PG не справлялся. Эти запросы удалось оперативно оптимизировать под условия PG и устранить задержку.  В результате получили скорость доставки изменений в [PG-01] не хуже, чем в [MS-NEW-01]. Про оптимизатор запросов PG будет чуть ниже поподробнее. После проведения замеров и исправления ситуации с оптимизатором запросов сервер [MS-NEW-01] был отключен. Это был временный этап, лишь для оценки скорости репликации MS –> PG, по сравнению со скоростью MS –> MS.

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

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

Этап 2. Переключение пользователей на PG

После выполнения всех функциональных и нагрузочных тестов система готова к запуску в нее пользователей. Данные между серверами [MS-01] и [PG-01] синхронны и поддерживаются в синхронном состоянии до момента переключения пользователей на новую СУБД. Само переключение и сопутствующие мероприятия можно выполнить уже в обычное тех.окно. Так что, пользователи просто утром заходят в новую старую систему и радуются.

Но риски просадки производительности всё еще сохраняются! Они могут всплыть сразу (пользователей, как ни крути, много), а могут и отложено - через несколько дней, неделю (бизнес-процессы и технологические процессы в базе, как правило, растянуты по времени).

Чтобы закрыть эти риски применялось два решения.

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

Схема работы обратной репликации:

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

 Второе решение – Data Cluster, который стал необходим после ввода системы в промышленную эксплуатацию. Выполняет две задачи:

а)       Балансировка (распределение) sql-запросов между двумя нодами кластера PostgreSQL. Кластер создан штатными механизмами (типа AlwaysOn в MS). А вот балансировка выполняется при помощи Data Cluster, который обеспечивает выполнение одной части sql-запросов на основной ноде [PG-01], а другой – на дополнительной [PG-02].

б)      Модификация sql-запросов на лету. Помните, выше было про необходимость оптимизации запросов другими методами, нежели на стороне 1С? Вот это оно. Те запросы, которые выполняются долго и очень долго из-за того, что оптимизатор выбирает неверный план выполнения, можно оптимизировать на лету, подставив правильные хинты или методы соединения таблиц.

Поэтому обратная схема на самом деле выглядит вот так:

Некоторые особенности и ограничения на проекте

Понятно, что не всё так гладко проходит, как запланировано. Поэтому тут я опишу некоторые вещи, на которые стоит обращать внимание. Писать буду со стороны СУБД, т.к. весь перенос разработан и работает на уровне таблиц базы данных. Никаких штатных/нештатных обработок на уровне платформы 1С не использовалось.

1. Обязательное введение моратория на крупные изменение конфигурации 1С на весь период переезда и даже опытной эксплуатации. Вроде бы очевидно, но упомянуть надо.

2. На период первичной конвертации отключить в регламентах администрирования ограничения на длительность пользовательских сеансов - для тех сеансов, которые будут использоваться для конвертации утилитой ibcmd. Вроде бы очевидно, но об это регулярно спотыкаются.

3. Возможное различие в порядке следования колонок таблиц 1С в MS SQL и PostgreSQL. В некоторых таблицах 1С колонки, соответствующие одним и тем же реквизитам, стоят на разных позициях в таблице (например, в MS - в конце таблицы, а в PG - в середине). Не то чтобы это какая-то критичная проблема, а для большинства – это вообще не проблема. Но для алгоритмов репликации это было важно. Пришлось выпускать патч для DBR.
   
   Ситуация с изменением последовательности колонок происходит, если в наследуемой системе использовалась реструктуризация 2.0, при которой новые колонки добавляются в конец списка. А утилита ibcmd при конвертации изменила порядок колонок в таких таблицах на «умолчательный». Поскольку база PG создавалась с нуля, эти таблицы получили «обычную» последовательность колонок.
   Возможно, кому-то, кто работает напрямую с sql-таблицами 1С, эта информация и пригодится.

4. Различие в составе индексов MS и PG. При конвертации в PG фактически происходит полная реструктуризация – все индексы создаются заново, тем самым все индексы приходят в соответствие с версией платформы 1С. А в MS SQL если таблица не перестраивалась, то она сколь угодно долго может сохранять старые индексы. В итоге вроде бы в PG индексы есть, но у них может отличаться порядок и даже состав полей. Поэтому план выполнения запроса может быть совсем не тем, что был в MS SQL и запрос выполняться долго, отъедать много памяти, нагружать избыточно диски. Работа оптимизатора в PG – отдельная история, об этом далее.

5. Неоптимальная работа оптимизатора запросов PG, влияющая на скорость применения транзакций, приходящих по Репликации. Это как раз стало очень хорошо видно после установки «эталонной» реплики [MS-NEW-01] – репликация MS-MS за многие годы отлажена и вылизана, поэтому и бралась как эталон.

   Причина деградации длительности некоторых запросов на стороне PG заключалась в том, что оптимизатор запросов PG зачастую ошибается, если в запросе присутствую условия «OR» или «ISNULL». Например, он может выбирать способ соединения таблиц через NESTED LOOPS, хотя было бы на порядок более быстро через HASH JOIN (думаю, эта проблема многим знакома, она неоднократно освещена в интернете). Эти неоптимальности на столь высоком трафике критически замедлили применение входящей очереди.

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

6. Высокий трафик изменений данных, идущий по Репликации, в том числе особо крупные транзакции, в каждой из которых содержатся сотни тысяч и миллионы элементарных операций. Был риск того, что применение такого потока изменений в базе ПГ, с учетом ее объёма, будет слишком медленным.

   Решение:
   Чтобы иметь возможность объективного сравнения, к контуру обмена репликации была подключена третья база-получатель в формате MS на сервере [MS-NEW-01]. Эта база получала в точности тот же трафик изменений, что и база ПГ.
   Сравнение показало, что в большинстве случаев скорость применения очереди в ПГ не хуже, чем в МС – за исключением тех случаев, когда оптимизатор запросов ПГ ошибается с планом выполнения, но эта проблема была решена (пункт выше).

7. Еще один момент по поводу плана запроса. PostgreSQL крайне тоскливо работает с виртуальными таблицами 1С типа СрезПоследних(). Имейте это в виду, т.к. на больших периодических регистрах сведения вы можете получить существенную просадку производительности. Об этом писал в прошлой статье, но не грех повторить – статья родилась как раз по следам проекта миграции. Так что, использование QProcessing (входит в состав Data Cluster PG) было необходимостью.

8. По аппаратным ресурсам лучше сразу заложить запас с коэффициентом 1,5. Это касается как дисковой подсистемы, так и процессора, а, особенно, оперативной памяти.

9. Если у вас есть свои индексы, созданные не в 1С, то не забудьте их отзеркалить в PostgreSQL. В ручном режиме. Это важно, ibcmd их не перенесет! А эти индексы могут быть критически важны для производительности базы PG.

10. Во время конвертации базы журнал транзакций на PG может в моменте раздуваться сильно больше обычных показателей (дисковое пространство), в частности, при построении тяжелых индексов. А если настроено полное журналирование, то журнал может резко расти и при прочих операциях. Например, если включен кластер и, не важно по каким причинам, остановится синхронизация нод кластера, то журнал начнет резко расти.

Заключение

Надеюсь, мне удалось показать наш подход к миграции больших баз данных на другие платформы. В частности, с MS SQL на PostgreSQL. Итак, на что обращаем внимание.

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

2. Аппаратные ресурсы. PostgreSQL может легко сожрать оперативную память и диски. Много про это писали в цикле статей про память в PostgreSQL. Поэтому, чтобы миграция прошла спокойно, и пользователи в первые часы работы не нервничали, заложите объем памяти не менее 1.5х от MS SQL. Позднее можно будет уменьшить выделенные ресурсы, если окажется, что они избыточны, но аргументированно, с анализом профиля нагрузки.

3. Тщательная проверка настроек оборудования и ПО непосредственно перед моментом перехода. Например, забытые и неперенесенные из MS индексы могут легко положить работу всех пользователей.

4. Технологическое окно. Оно, как правило, очень маленькое по сравнению с масштабом задачи. У некоторых его нет вообще. Соответственно нужно проработать до мельчайших шагов сценарий переключения пользователей с одной ИС на другую. Нюансов много может быть: настройки в базах 1С поменять, фоновые задания включить/отключить, какие-то внешние интеграции переключить/выполнить, специальные индексы построить, ярлыки переключить. Да много чего еще может быть, что нельзя забыть. За каждым, даже маленьким, шажком должен стоять ответственный, иначе это 100% будет забыто и не выполнено.

Спасибо, что дочитали до конца. Возможно, при прочтении вы узнали свои проблемы, с которыми сталкивались при переходе из MS SQL Server в PostgreSQL и не смогли полностью решить на тот момент. Мы на задачах миграции (разной миграции!) уже более 10 лет, технология и мы непрерывно совершенствуются. Не стесняйтесь, пишите, звоните.

Другие наши статьи на тему миграции данных:

1. Гетерогенная распределенная система как способ миграции больших и не очень баз данных с MSSQL Server на PostgreSQL

2. Миграция с MSSQL Server на PostgreSQL. Предпосылки

3. Миграция терабайтной базы 1С: УПП с платформы 1C 8.1 на 8.3