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

Николай Ижиков — 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'ом.