Мигрировать базу данных на 10 ТБ с нулевым простоем: каков план?

Question

IT Interview Practice · Accepted Answer

**Пишите одновременно в старую и новую (dual-write), заполняйте историю в фоне (backfill), используйте CDC для догона хвоста, проверяйте через shadow-чтения, затем атомарно переключите чтения — с путём отката на каждом шаге.** Вы никогда не останавливаете приложение; вы держите обе базы параллельно, пока новая не окажется доказуемо идентичной, затем делаете cutover.

## Архитектура

```text
        ┌── write ──▶ OLD DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NEW DB ◀──── backfill job (historical rows)
                        │
   shadow reads (compare OLD vs NEW) ─▶ diff metrics ─▶ atomic cutover ─▶ NEW is truth
                                                          (flip flag; rollback = flip back)
```

## Как это работает

1. **Dual-write.** Приложение пишет каждое изменение в OLD и NEW. Новые строки синхронны с этого момента; недостаёт только истории.
2. **Backfill.** Фоновый джоб копирует исторические строки батчами (с троттлингом для защиты прода). Используйте `INSERT ... ON CONFLICT DO NOTHING`, чтобы он был идемпотентным и безопасным для перезапуска.
3. **Догон через CDC.** Dual-write может пропустить строки, записанные во время включения. **Debezium**, стримящий WAL/binlog OLD DB, переигрывает каждое изменение, закрывая зазор, который backfill не может.
4. **Shadow-чтения.** Читайте из NEW параллельно с OLD, **сравнивайте результаты** и выдавайте diff-метрику. Ноль расхождений со временем = NEW заслуживает доверия.
5. **Cutover.** Переключите feature flag, чтобы чтения (затем записи) шли в NEW. Это изменение конфига, а не деплой — мгновенно и **обратимо переключением назад**.

## Взгляд с точки зрения интервью

Интервьюер хочет узнать, **как вы гарантируете отсутствие потери данных и простоя** и есть ли у вас **откат**. Хорошие ответы упоминают dual-write; отличные добавляют **CDC для ловли гоночного окна**, **shadow-чтения для проверки перед доверием** и **атомарное обратимое переключение флага**. Классическая ловушка — «backfill, затем переключение» без верификации: вы обнаруживаете расхождение после того, как в него упёрлись пользователи, без пути назад.

## Компромиссы и сбои

- **Консистентность dual-write.** Если запись в NEW не удалась, а в OLD удалась, они расходятся. Сделайте OLD авторитетной и дайте CDC чинить NEW, а не проваливайте запрос пользователя.
- **Стоимость и сложность.** Держать две базы + CDC + backfill дорого и операционно тяжело — оправдано только для больших критичных хранилищ.
- **Изменения схемы** во время миграции умножают риск; заморозьте схему до cutover.
- **Нагрузка backfill.** Нетроттлированный backfill может насытить I/O прода и вызвать простой — противоположность цели; батчите и лимитируйте темп.
- **Окно отката.** Продолжайте dual-write (теперь NEW→OLD) в течение дней после cutover, чтобы можно было переключиться назад, если всплывёт скрытый баг. Только затем выводите OLD из эксплуатации.
- **Когда не нужно:** малой БД с окном обслуживания это не нужно — 30-минутный `pg_dump`/restore проще и безопаснее CDC-пайплайна.

Архитектура

Как это работает

Взгляд с точки зрения интервью

Компромиссы и сбои

Похожие вопросы