Переезжаем на облачную базу данных PostgreSQL

Сценарии миграции

У бизнеса есть три сценария миграции на PostgreSQL. В первом сценарии, если говорить именно об Oracle, исходная база данных (БД) остается, тогда как внутренний функционал переносится на PostgreSQL: в приложении меняются запросы к новой базе данных, а функционал полностью покрывается тестами для сравнения результатов в обеих СУБД. Это сценарий обычно выбирают компании с ограниченной бизнес-логикой на Oracle. Он позволяет быстро перейти на PostgreSQL.

Во втором варианте логика БД по максимуму переносится из Oracle в приложение, затем код переписывается и данные из Oracle потом просто перетаскиваются в PostgreSQL. Это более длительный, но простой в реализации сценарий.

На выбор сценария влияет несколько факторов:

• Размер базы данных, который определяет время простоя при миграции. Чем БД больше, тем больше времени придется потратить на внутреннюю оптимизацию системы.
• Функционал, не имеющий аналога в PostgreSQL. Если в коде приложения есть функционал, который нельзя перенести напрямую, придется пойти по пути изменения логики.
• Объем систем, взаимодействующих с мигрируемым приложением. Чем больше объем кода и чем масштабней пул приложений, работающих с мигрируемой системой, тем сложнее перенести внутренний функционал из Oracle в PostgreSQL «как есть».

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

В любом случае, без ручного труда не обойтись. Даже с такими инструментами как Oracle GoldenGate, Full Convert и Ora2Pg администраторам приходится вручную проверять автоматически конвертированный код и покрывать приложение unit-тестами.

Этапы миграции

В каждом из сценариев переезда на облачную базу данных PostgreSQL отправной точкой становится подготовительный этап. Дальше набор шагов и их последовательность может отличаться. Мы рассмотрим основные этапы миграции применительно к третьему, промежуточному варианту переезда.

1. Подготовка

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

2. Развертывание тестовой среды

Разворачивается тестовая база данных в облаке, на нее переносится структура БД и конвертированные данные. Для конвертации процедур и функций на язык для СУБД PostgreSQL используются специальные утилиты. Например, ora2pg, которая отлично справляется с черновой миграцией серверной логики. Чтобы убедиться, что бизнес-логика перенесена без изменений и функционал работает корректно, тестами покрывается минимум 80% новой системы. Это важно, чтобы как следует обкатать миграцию на тестовом стенде.

3. Перенос процедур

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

4. Тестирование

Разворачивают новую базу, запускают приложение и переносят данные из Oracle. Если все сделано корректно, система полностью заработает в тестовом режиме. На этом же этапе проверяется среднее время ответа для СУБД Oracle и PostgreSQL.

5. Переключение на боевую среду

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

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

Ожидания и реальность миграции на облачную базу данных PostgreSQL

PostgreSQL — самостоятельная система с поддержкой языков программирования pl/perl, pl/python, pl/tcl и других. Благодаря схожести языков PL/SQL и pgplsql, миграция проходит относительно несложно. Однако PostgreSQL — не клон и на аналог Oracle, поэтому не всегда получается перенести систему один в один. И не всегда удается достичь целевых значений быстродействия. Кроме того, у PostgreSQL нет решения для сжатия, поэтому БД, которая в Oracle весила 1 Тб, здесь будет весить 2 Тб. Также у PostgreSQL есть ряд специфических  нюансов, которые часто требуют «ручного» тюнинга во время и после миграции.

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

Предлагаем экспертизу опытных администраторов, устанавливаем и настраиваем СУБД, поддерживаем базу во время и после переезда силами команды сертифицированных специалистов. Чтобы определиться с бюджетом и сроками миграции, посмотрите услуги в составе автономных/кластерных решений DBaaS и закажите расчет: разберемся в специфике системы, примерим разные варианты и предложим технически и финансово комфортное решение для вашего бизнеса.