Миграция больших Cassandra-кластеров: snapshot, репликация и отказ от лишней истории

Cassandra хорошо масштабируется, но миграция большого кластера редко бывает простой. Пока данных немного, кажется, что достаточно снять snapshot и перенести файлы. Когда объём становится терабайтами или петабайтами, появляются ограничения сети, compaction, consistency, downtime и стоимость переноса исторических данных.

План миграции должен начинаться не с команды копирования, а с вопроса: какие данные действительно нужно переносить и какой уровень риска допустим?

Snapshot-подход

Snapshot удобен, когда объём данных умеренный и допустимо окно переноса. Он даёт понятную точку во времени, но требует:

• места для snapshot;
• времени на копирование;
• совместимости версий;
• проверки schema;
• восстановления SSTables;
• контроля compaction после загрузки.

Для больших кластеров копирование snapshot может занять слишком долго. За это время исходный кластер продолжит принимать записи, и нужно будет догонять изменения.

Междатацентровая репликация

Если Cassandra-кластер можно расширить новым DC, миграция через replication часто безопаснее. Новый датацентр подключается к ring, данные постепенно реплицируются, затем traffic переводится на новую сторону.

Плюсы:

• меньше downtime;
• данные догоняются постепенно;
• можно контролировать cutover;
• проще откатиться до переключения.

Минусы:

• нагрузка на сеть;
• сложность настройки replication factor;
• долгий bootstrap;
• риск перегрузить старый кластер.

Не вся история нужна

Иногда лучший способ миграции — не переносить всё. Старые данные можно оставить в archive, пересчитать, выгрузить в object storage или перенести только hot диапазон.

Это особенно актуально, если historical data редко читается, но занимает большую часть storage. Миграция — хороший момент пересмотреть retention policy.

Consistency и cutover

Перед переключением нужно понимать:

• все ли данные синхронизированы;
• какой lag допустим;
• какие consistency levels используются;
• как переключаются clients;
• можно ли писать в оба кластера;
• что будет с конфликтами.

Dual-write кажется простым, но создаёт сложные edge cases. Лучше избегать его, если нет строгой схемы reconciliation.

Наблюдаемость

Во время миграции нужны метрики:

• streaming throughput;
• pending compactions;
• dropped mutations;
• read/write latency;
• disk usage;
• repair status;
• hinted handoff;
• network saturation;
• GC pauses.

Без этих метрик миграция большого кластера превращается в ожидание неизвестного результата.

Rollback

Rollback нужно спланировать до cutover. Если clients уже пишут в новый кластер, откат сложнее. Поэтому стоит иметь этапы:

1. подготовка нового кластера;
2. sync;
3. read-only проверка;
4. canary traffic;
5. cutover;
6. окно наблюдения;
7. отключение старого кластера только после стабилизации.

Итог

Миграция Cassandra — это проект управления риском. Snapshot подходит не всегда, междатацентровая репликация требует аккуратности, а перенос всей истории может быть экономически бессмысленным.

Хороший план учитывает объём данных, consistency, compaction, наблюдаемость и rollback. Тогда миграция становится контролируемой инженерной операцией, а не ночным копированием файлов на удачу.