Перевод бд с MS SQL на Postgresql

Проблематика: перевод большой бд с MSSQL на Postgresql

Важным трендом последних лет в российских ИТ является импортозамещение в области программного обеспечения. В частности, всё большее число компаний предпринимают шаги в сторону перевода своих баз данных с коммерческого зарубежного ПО на отечественные разработки или на свободно распространяемое ПО.

Один из подобных сценариев – это перевод БД с Microsoft SQL Server на PostgreSQL. Задача очень нетривиальная – сложная в реализации и обладающая рядом серьёзных рисков. Один из основных рисков заключается в том, что с переходом на PostgreSQL может значительно просесть производительность БД и ухудшиться отклик для пользователей.

Для сравнительно небольших и не сильно нагруженных баз данных эти риски не так уж велики. Но чем больше база и выше нагрузка, тем серьёзнее риски. Условно говоря, перевести на PostgreSQL низко нагруженную базу данных размером 50 Гб с 10-ю пользователями и какой-либо не особо сложной конфигурацией 1С – задача вполне подъемная и понятная. И другое дело – перевод высоконагруженной базы, скажем, в 2 Тб объёмом с 500-ми пользователей и сложной комплексной конфигурацией 1С. В таких условиях риски поднимаются до критических значений, и задача перехода предельно усложняется. Почему? Рассмотрим основные моменты.
Чем обусловлены риски?

         Длительность и сложность переноса данных и их верификации

Если база имеет объем в сотни гигабайт или терабайты, то процесс переноса данных из MSSQL в PostgreSQL может занять много часов или даже дней. Запомним этот факт. Пока оставляем за скобками, как именно может быть реализован этот перенос - варианты есть (как минимум – через DT), но сейчас нас больше интересует длительность. Она в любом случае очень большая.

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

Технологическое окно нужной длительности в большинстве случаев организовать невозможно, пользователи должны работать всё то время, пока идет перенос и проверка. За это время пользователи внесут в данные массу изменений. Значит, нужна какая-то система обмена между MSSQL и PostgreSQL, способная определять «дельту» изменений данных и передавать ее в PostgreSQL. По условиям задачи у нас очень крупная высоконагруженная база, и поток изменений будет очень большой. Это означает повышенные требования к системе обмена. Она должна обладать высокой пропускной способностью, не должна привносить дополнительную нагрузку на рабочую базу, не должна создавать блокировки для пользователей. Тем самым спектр выбора подходящей технологии сокращается, и усложняется реализация такого механизма. 
      
       Сложность функционального и нагрузочного тестирования в PostgreSQL

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

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

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

Что же делать?

Итак, при переводе крупной высоконагруженной базы на PostgreSQL образуется клубок взаимосвязанных проблем, и его необходимо распутать, ведь права на ошибку нет. Когда в базе работает множество пользователей, и на неё завязаны бизнес-критичные процессы, нельзя допустить остановки системы, порчи данных, существенной просадки производительности. В идеале переход на новую СУБД должен быть на 100% надежным и без «сюрпризов».

Но как этого добиться?

Для решения этой задачи мы предлагаем методику, основанную на использовании технологии обмена данными DBReplication.
 
Ключевые характеристики DB Replication

DB Replication обладает рядом особенностей, позволяющих эффективно решать задачу обмена данными между базами MSSQL и PostgreSQL в высоконагруженной системе:

• DB Replication позволяет передавать данные между базами 1С с одинаковой конфигурацией из MSSQL в PostgreSQL и обратно, направление обмена можно переключать

• DB Replication не создает существенной дополнительной нагрузки на оборудование и не создает блокировок пользователям

• Обладает очень высокой пропускной способностью и скоростью доставки данных

• Программный комплекс DB Replication уже готов к использованию «из коробки», его легко установить и настроить

• Не требуются изменения в конфигурации 1С и прикладной логике

• Внедряется и работает незаметно для пользователей

Решение: методика с использованием DB Replication

Для наглядности, представим основные подзадачи перехода на PostgreSQL в виде таблицы и отметим, какие из них помогает решить DB Replication

№	Этап работ / подзадача	Комментарий	Применимость DB Replication
1	Развернуть пустую базу 1С на PostgreSQL (только конфигурация 1С)	Штатными средствами (из cf)	-
2	Скопировать массив исторических данных вPostgreSQL	Существуют разные варианты реализации этого этапа. DB Replication тоже можно применить, но ограниченно	Применение DB Replication допустимо с ограничениями:   - Для баз размером до ~100 Гб – можно копировать все данные   - Для более крупных баз – можно копировать отдельные объекты разумного объёма
3	Всесторонне проверить качество данных в PostgreSQL	Методика проверки индивидуальна, выполняется профильными специалистами 1С	-
4	Синхронизировать оперативные изменения данных, которые вносят пользователи на стороне MSSQL в то время, когда происходят основной перенос исторических данных и последующая проверка данных	-	DB Replication эффективно решает эту задачу
5	В момент перевода пользователей в PostgreSQL переключить направление обмена в обратную сторону: из Postgresql в MSSQL	Это подстраховка на случай, если в базе PostgreSQL возникнут проблемы. Можно будет вернуться в MSSQL без потери данных.	DB Replication эффективно решает эту задачу

Чем помогает DB Replication при переходе на PostgreSQL?

DB Replication эффективно и просто решает одну из ключевых подзадач - синхронизацию оперативных изменений, даже если поток этих изменений очень высок.

В случае баз данных объёмом до ~100Гб с помощью DB Replication можно синхронизировать не только оперативные данные, но и весь массив данных целиком.

DB Replication позволяет в момент перевода пользователей в PostgreSQL переключить направление обмена данными в обратную сторону – из PostgreSQL в MSSQL. Это дает дополнительную подстраховку: если в базе PostgreSQL выявятся какие-то проблемы, то пользователей можно быстро вернуть в базу MSSQL без потери данных, введенных, пока они работали в PostgreSQL.

Таким образом, эта методика на порядок упрощает задачу перехода на PostgreSQL и сводит практически к нулю риски. Переход на PostgreSQL получается контролируемым, с подстраховкой, без простоев системы и без потерь данных.