Автор: Дмитрий Емельянов (Altenar) · Видео с мероприятий {speach!}
В 39-минутном докладе Дмитрий Емельянов, тимлид группы разработки в Altenar, рассказывает об аварии, которая началась почти как анекдот: команда настраивала новый бэкап Kafka — и именно в этот момент потеряла Kafka. Но самое интересное случилось не во время аварии, а после, когда кластер уже удалось восстановить.
В системе Altenar некоторые топики были не просто транспортом между микросервисами, а единственным источником истины. При запуске сервисы перечитывали их, собирали состояние в памяти и затем продолжали работать с ним. Kafka реплицировалась между брокерами, а раз в сутки её файлы дополнительно копировали с одного диска на другой. Восстановление этих копий не проверяли: для этого пришлось бы останавливать stage, мешать работе QA и откладывать бизнес-фичи.
Когда Kafka исчезла, после восстановления из свежего бэкапа в ней не хватало части партиций. Копия двухдневной давности поднялась успешно: топики на месте, сервисы запускаются, объём данных выглядит правдоподобно. Казалось бы, инцидент закончен. На самом деле система только что раскололась во времени: база осталась в настоящем, а Kafka вернулась на два дня назад.
Кому смотреть: разработчикам и архитекторам, у которых Kafka хранит состояние системы, а рядом существуют базы, кэши или другие независимо восстанавливаемые хранилища.
Из этого можно взять в работу: проверять не только то, поднимается ли Kafka из копии, но и то, сможет ли после отката продолжить работу вся система. Особенно важно заранее понимать, как устранять рассинхронизацию между хранилищами, восстановленными на разные моменты времени.