Николай Ижиков — One More Way to Make Backup in Ignite

Сложность: 3/3 (Обязательно к прослушиванию, если вам интересна работа с OLTP-нагрузкой и технические подробности снятия бэкапов)

Николай Ижиков, Platform V DataGrid Tech Lead, а также контрибьютор в Apache Kafka и участник PMC Apache ignite, рассказывает нам, как реализованы бэкапы в Platform V DataGrid, а главное — про cache dumps.

YouTube: https://www.youtube.com/watch?v=A3EkvdGK4Jg
VK Видео: https://vkvideo.ru/video-147464741_456239442

🔍 Условия:
Кластер процессинга: 32 узла, 700 ГБ RAM на узел, 40к RPS на узел.
Кластер токенизатора: 5 узлов, 550 ГБ RAM на узел, 500к RPS.

⚙️Падение СУБД

1️⃣ Однонодовая СУБД — после падения приложение не работает, Запросы не обслуживаются, данные теряются при простое.
2️⃣ Распределенная СУБД — спектр последствий разный. Может снижаться перфоманс, может теряться часть данных.

⚙️Метрики восстановления после аварии

Recovery Point Objective — целевая точка восстановления, после которой мы теряем данные. Мы оцениваем время, в течение которого мы теряем данные за этой точкой.

Recovery Time Objective — с её помощью мы оцениваем время, затраченное на восстановление системы после аварии.

🛠 Способы формирования бэкапов (рекомендуется изучить презентацию к докладу):

1️⃣ Apache Ignite: ребаланс данных, позволяет сохранить данные, если количество упавших нод меньше бэкап-фактора.

2️⃣ DataGrid: при ребалансе данных распределение партиций такое, что у стойки есть дублер. Позволяет восстановиться при падении стойки.

3️⃣ Apache Ignite: CDC обеспечивает асинхронную логическую репликацию данных. RPO ➡️ секунды, RTO ➡️ 0. Данные реплицируются в другой кластер через WAL, доступ к данным открывается после перемещения сегмента в архив. Из-за этого RPO сдвигается.

4️⃣ Data Grid: Online CDC внутри ноды есть буфер данных, который наполняется событиями и из него данные стримятся в соседний кластер. RPO ➡️ 0, RTO ➡️ 0. Растет потребление памяти, при переполнении используется классический CDC через WAL.

5️⃣ Снапшоты в Apache Ignite: системный процесс PME делает stop the world. Начатые транзакции заканчиваются, новые стоят на паузе. В этот момент происходит копирование партиций, изменения пишутся отдельно, после снятия резервной копии изменения накладываются поверх снимка. RPO ➡️ часы, RTO ➡️ 0

6️⃣ Apache Ignite: инкрементальный снапшот снимает только изменения в данных, но часто. Система не блокируется. RPO ➡️ минуты, RTO ➡️ минуты. В докладе даны ссылки на статьи по этому механизму.

🔮 Cache dump

📝Задачи и качества метода:
1️⃣ консистентный бэкап in-memory кэшей с учетом транзакций без прерывания пользовательской нагрузки;
2️⃣ Восстановление данных на любую топологию;
3️⃣ Поддержка CLI;
4️⃣ API offline обработка

⚙️⚙️ Механизм снятия дампа:
1️⃣ Stop the world
2️⃣ Данные консистентны; запуск писателей дампа
3️⃣ Для сохранения консистентности установка listener'ов на изменения кэша
4️⃣ Запуск транзакций
5️⃣ Итерация по партициям и запись row by row
6️⃣ Запись данных listener'ом

🪛 Тонкости:
1️⃣ Откатиться, если где-то ошибка — Distributed Process.
2️⃣ Не перегрузить ноды системным процессом - прежде всего операции пользователя.
3️⃣ Запоминание изменений каждого ключа — это дорого по памяти.

📝 Эффективная фильтрация:
1️⃣ Итератор по партиции не транзакционный
Listener должен сохранить entry до изменения
2️⃣ Итератор сортированный (B+дерево)
3️⃣ У каждой записи есть уникальная версия. Версия выдается на primary.

❔Ответы на вопросы:

Q: cache dump можно снимать не только для in-memory cache, но и для персистентного кэша?
A: Можно, вопрос целесообразности. Для persistent cache есть более подходящие способы.
Q: Уточнение по процессу: если версия ключа более новая, то итератор её пропускает. Как все значения ключей попадают в запись бэкапа?
A: Если версия старше версии в момент снятия, то эти данные либо пришли после запуска процесса снятия бэкапа, либо старые данные были изменены во время снятия и эти изменения записаны listener'ом.