Как «Яндекс.Деньги» мигрировали с Oracle на PostgreSQL

«Яндекс.Деньги» перевели часть финансового сервиса с СУБД Oracle на PostgreSQL без потерь и остановок в работе.

«Яндекс.Деньги» перевели часть сервиса с Oracle на PostgreSQL

О процессе миграции сотрудники «Яндекс.Денег» рассказали в блоге на «Хабрахабр».^[1]

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

Проект необходимо было завершить за три месяца. Команда миграции состояла из 4 человек - разработчики уровня Senior и специалисты DBA.

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

Обычно такие миграции выполняются с остановкой сервиса — в нерабочее время. Но в «Яндекс.Деньгах» платежи проходят круглосуточно, поэтому останавливать систему ради внутренних «оптимизаций» было нельзя. Фактически для этого компонента бизнес согласовал нам приостановку на одну-две минуты, без потери данных, - отмечают сотрудники «Яндекс.Денег».

В поисках подходящего инструмента специалисты компании собрали и отсеяли список продуктов для миграции: Oracle GoldenGate, SymmetricDS, Full Convert, Oracle to PostgreSQL Migration, ESF Database Migration Toolkit, Ora2Pg и SQLData Tool.Метавселенная ВДНХ 3.2 т

В результате были выбраны решения Ora2Pg для переноса схемы базы данных и SymmetricDS для миграции данных.

В ходе обкатки миграции на копии продакшн-базы, был найден целый набор «особенностей» и странностей в миграционном решении. PostgreSQL не корректно отрабатывал некоторые запросы, которые без проблем проходили в Oracle. Были сложности с транзакциями, с неправильной сортировкой выводимых значений и т.д. Тем не менее все эти недочеты были успешно решены.

Миграция данных была поэтапной — по заранее утвержденному списку из 50 таблиц. Переключение было сделано на уровне каждой таблицы в базе, что позволило достичь высокой гибкости и декомпозиции процесса. То есть в определенный момент, после переноса данных, для таблицы выставлялся специальный флаг, по которому сервис «Я.Денег» переключался на экземпляр данных в PostgreSQL.

В процессе миграции часть из 50 таблиц работала на Oracle, другая — на PostgreSQL. Здесь пригодился SymmetricDS, который мигрировал данные из Oracle в PostgreSQL и тем самым обеспечивал консистентность как для логики с перенесенными таблицами, так и для тех, что еще работали по старой схеме.

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

Но самым сложным было правильно подобрать момент переключения. Фактически у специалистов «Яндекс.Денег» было 3 варианта миграции, в зависимости от критичности и сложности таблицы:

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

2. На уровне дата центра (всего их 2). Способ для переноса критичных таблиц, при котором сначала переводится на PostgreSQL первый ЦОД, а в процессе его включения отключается второй (с Oracle). На время старта — остановки Oracle и PostgreSQL могли работать параллельно, поэтому тут и пригодились механизмы синхронизации и переключения данных. Простоя в работе сервисов при этом не было.

3. По методике «остаточного дожатия». Сохранение 2 экземпляров: Oracle для обработки опоздавших к переключению запросов и новый PostgreSQL. Новые задачи обрабатывались в новой базе, а старые удалялись после выполнения в оставшемся Oracle. Так переезжали очереди базы — автоплатежи, напоминалки и т.п.

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

Чуть позже оказалось, что SymmetricDS не синхронизирует таблицы объемом более 150 ГБ. Поэтому пришлось создать обходной вариант переноса на такие случаи. Кроме того, SymmetricDS не переносил поля CLOB\BLOB, если из-за них был превышен суммарный объем таблицы, поэтому пришлось писать ручные очереди миграции.

Столкнулись сотрудники «Яндекс.Денег» и с совсем экзотическими случаями, когда миграция с Oracle на PostgreSQL приводила к резкому проседанию производительности. В этом случае ничего не оставалось, кроме как вручную разбирать каждый отдельный инцидент. Например, для одной таблицы пришлось выделить поле CLOB в отдельную таблицу, перенести ее на SSD-диск и читать это поле только при необходимости.

Так как нужно было поддерживать одновременно активными старые и новые экземпляры БД, для новых был сделан запас по секвенциям, чтобы не происходило наслоения и попыток переноса в PostgreSQL дублирующихся ключей. То есть если в таблице последний ключ был 100, то при переносе к этому значению добавлялась еще 1000, чтобы SymmetricDS мог свободно синхронизировать ключи 101, 102 и все остальные без перезаписи новых данных.

За плановый квартал команда «Яндекс.Денег» перенесла 80% таблиц на PostgreSQL. Оставшиеся 20% — это большие таблицы (в среднем более 150 ГБ), включая сборную таблицу с объемными полями CLOB\BLOB. Все это пришлось доделывать вручную следующие 1,5 месяца. Тем не менее связка SymmetricDS и Ora2Pg сделала большую часть рутинной работы, что и требовалось по условиям задачи.

Читайте также

• Миграция с Oracle на альтернативные системы

Примечания