Миграция без боли и даунтайма: как мы перевозили данные с MongoDB на PostgreSQL
Всем привет! Меня зовут Андрей, я бэкенд‑разработчик ядра Яндекс Диска. В индустрии я уже около 15 лет и повидал некоторое ПО. Последние три года занимаюсь ядром файловой системы — всем, что связано с метаданными о файлах.
Однажды мы в Диске переносили общие данные из шардированного MongoDB в шардированный же PostgreSQL. После переноса пользовательских данных у нас осталась часть данных про общие папки.Их было сложно изолировать внутри шарда пользователя, и они остались в общей БД на MongoDB, которую мы так и назвали — CommonDB. Спустя время мы заметили, что общая БД не справляется с нагрузкой: все запросы перед выполнением должны были сначала получить информацию об общих папках, и только после этого они начинали работать. Поэтому надо было дублировать информацию ближе к другим данным пользователей — на их шарды.
Однако при дублировании важно было избежать распределённых транзакций, так как они снижают общую производительность. Также проблемой был сам процесс перехода: у нас сотни миллионов пользователей, которые не должны были ощущать процесс перехода и потерять доступ к своим данным. При этом надо было выкатывать изменения не сразу на 100%, а частично, с возможностью в любой момент отключить функциональность. При выкатке также нельзя было допустить даунтайм.
В статье я хочу поделиться опытом этой масштабной миграции. Под катом покажу, как вообще устроены сложные миграции и как к ним подходить. А также перечислю те пункты, на которые нужно обратить внимание, если вам предстоит миграция под нагрузкой.
