Как переносят базу под нагрузкой и не теряют записи

Пять фаз перехода

Двойная запись: где она ломается

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

async function save(record: Record) {
  // Источник правды на время перехода — старое хранилище.
  await legacy.save(record);

  try {
    await next.save(record);
  } catch (err) {
    // Не роняем запрос: пользователь не должен страдать от миграции,
    // о которой он не знает. Расхождение фиксируем и чиним фоном.
    metrics.increment('migration.dual_write.failed');
    await outbox.enqueue({ type: 'migration.resync', id: record.id });
  }
}

Сверка: контрольные суммы, а не выборочная проверка

Проверка «открыли десять записей, всё совпало» ничего не доказывает. Работающий приём — контрольные суммы по диапазонам: делим данные на интервалы, считаем агрегат по каждому в обоих хранилищах и сравниваем. Расхождение сразу локализуется, и построчно сравнивать нужно только подозрительный интервал.

select
  date_trunc('day', created_at) as bucket,
  count(*)                      as rows,
  sum(amount)                   as total,
  md5(string_agg(id::text || ':' || amount::text, ','
      order by id))             as checksum
from operation
where created_at < :cutoff
group by 1
order by 1;

Теневое чтение добавляет второй, независимый сигнал: система обслуживает запрос из старого хранилища, параллельно делает тот же запрос к новому и сравнивает результаты. Различия пишутся в лог. Это ловит то, чего не видит сверка данных, — расхождения в логике выборки: другой порядок сортировки, другое поведение при NULL, другое округление.

Что ломается на самом деле

Записи почти никогда не теряются целиком — теряется их смысл. Список ниже собран из того, что реально всплывает на сверке.

• Пустая строка против `NULL`. В старой базе «нет значения» записывалось как '', в новой — как NULL. Фильтры перестают находить записи, а отчёты тихо меняют цифры.
• Часовые пояса. Время хранилось без зоны и подразумевало локальную; в новой базе — timestamptz. Операции сдвигаются на несколько часов, и это видно только на границах суток — то есть в отчётах.
• Округление денег. float в старой системе и numeric в новой дают расхождение в копейки, которое накапливается и не сходится в итогах.
• Автоинкременты. Новое хранилище начинает нумерацию с единицы и наезжает на перенесённые идентификаторы. Счётчик выставляется явно, до включения записи.
• Уникальность. В старой базе накопились дубликаты, которых новая схема не допускает. Их нужно разобрать до переноса — это решение бизнеса, а не разработчика.

Как выглядит план отката

План отката — это не «вернём из бэкапа». Пока идёт двойная запись, откат означает переключение флага чтения обратно: старое хранилище всё это время оставалось полным и актуальным. Именно поэтому фаза двойной записи не сворачивается сразу после переключения — она стоит недорого и покупает возможность вернуться.