Итоги модуля 11: Multi-DC и Disaster Recovery
Модуль 11 закрывает тему межкластерной репликации в Kafka 4.0. Вы прошли путь от архитектуры MirrorMaker 2 до конкретных runbook’ов failover. Здесь — сводная таблица всего, что должно быть в голове при проектировании и эксплуатации Multi-DC Kafka.
Ключевые концепции: сводная таблица
Концепция — Ключевой конфиг — Типичное значение / Примечание
MirrorSourceConnectorОсновной коннектор репликации. Читает из source, пишет в target. Один task = одна или несколько партиций. Конфиг: dc1->dc2.enabled=true, dc1->dc2.topics=.* (регулярное выражение). Параллелизм: tasks.max.
tasks.maxМаксимальное число параллельных задач репликации. Рекомендация: равно числу партиций реплицируемых топиков. Влияет на RPO: больше tasks.max = меньше lag = ниже RPO.
dc1->dc2.topics = .*Регулярное выражение для фильтрации топиков. .* = все топики. orders|payments = только два топика. Используйте topics.exclude для исключения внутренних топиков MM2.
MirrorCheckpointConnectorКоннектор трансляции offset'ов. Периодически записывает маппинг (source-offset -> target-offset) в {source}.checkpoints.internal. Основа для корректного failover consumer groups.
emit.checkpoints.interval.secondsИнтервал записи checkpoint'ов. Default: 60 секунд. Checkpoint RPO = этот интервал. Для строгих SLA: снизить до 10-15 секунд. Нижний рекомендуемый предел: 10 секунд.
sync.group.offsets.enabled=trueАвтоматически commit'ит переведённые offset'ы на target-кластере. При включённом параметре failover не требует ручной трансляции через RemoteClusterUtils. Рекомендуется для продакшна.
MirrorHeartbeatConnectorМониторинг здоровья репликации. Записывает heartbeat записи каждые heartbeats.interval.seconds (default 1s). Replication latency = разница timestamp heartbeat и текущего времени на target-кластере.
heartbeats.interval.secondsИнтервал heartbeat записей. Default: 1 секунда. Достаточно для обнаружения проблем с репликацией за 1-5 секунд. Не снижать ниже 1 секунды.
heartbeat_age alert thresholdАлерт срабатывает если age последнего heartbeat превышает порог. Рекомендация: 30 секунд для warning, 60 секунд для critical. При heartbeat_age > 60s репликация остановлена.
DefaultReplicationPolicyПолитика именования по умолчанию. Добавляет псевдоним source-кластера как префикс: orders -> dc1.orders. Безопасна для active-passive. Проста в эксплуатации.
IdentityReplicationPolicyТопики сохраняют оригинальное имя: orders -> orders. Обязательна для active-active. Без неё потребители на target-кластере видят dc1.orders вместо orders.
topics.exclude = .*\\.internal,heartbeatsИсключение внутренних топиков MM2 из репликации. Критично для active-active: без этого исключения внутренние топики будут реплицироваться бесконечно. Обязательный параметр.
RPORecovery Point Objective = допустимая потеря данных в секундах. В контексте MM2: RPO = replication-latency-ms-avg в момент сбоя. Типично: 1-60 секунд. Снижается через: tasks.max, сетевую оптимизацию, выделенный Connect кластер.
RTORecovery Time Objective = время восстановления сервиса. Компоненты: обнаружение (1-5 мин) + DNS (1-10 мин) + трансляция offset'ов (0-2 мин) + перезапуск (1-5 мин). Типично: 5-20 минут.
Active-Active RTOВ Active-Active топологии RTO практически равен нулю: при сбое одного DC второй уже обслуживает трафик. Нет фазы failover. Ценой: operational сложность и необходимость стратегии конфликтов.
Ключевые JMX метрики MM2
| Метрика | MBean | Alert порог |
|---|---|---|
| Задержка репликации | kafka.mirror:type=MirrorSourceConnector,target=dc2 -> replication-latency-ms-avg | > 5000ms (warning), > 30000ms (critical) |
| Heartbeat age | Потребитель heartbeats топика, разница timestamp | > 30 сек (warning), > 60 сек (critical) |
| Checkpoint lag | kafka.connect:type=connector-task-metrics,connector=MirrorCheckpointConnector -> offset-commit-avg-time-ms | > 5000ms |
| Connector status | kafka.connect:type=connector-metrics,connector=MirrorSourceConnector -> status | != RUNNING |
| Byte rate | kafka.mirror:... -> byte-rate | < ожидаемого (падение = остановка репликации) |
Связь с предыдущими и последующими модулями
Модуль 11 строится на знаниях из всего курса и является обязательной предпосылкой для финального Модуля 13:
| Тема | Связанный модуль | Применение в Multi-DC |
|---|---|---|
| Репликация партиций, ISR | Модуль 01 | DR-кластер должен иметь свой собственный ISR, независимый от primary |
| Kafka Connect фреймворк | Модуль 05 | MM2 построен на Connect: REST API, задачи, мониторинг |
| Security: SASL/SSL | Модуль 09 | Cross-cluster аутентификация: MM2 нужны credentials для обоих кластеров |
| JMX мониторинг | Модуль 10 | MM2-специфичные MBeans дополняют broker и Connect мониторинг |
| Capstone architecture | Модуль 13 | MM2 DC-1->DC-2 репликация является частью финального дизайна |
Подготовка к Модулю 12
Модуль 12 переходит от операционных к архитектурным паттернам. Если Модуль 11 отвечал на вопрос “как сделать Kafka отказоустойчивой на уровне инфраструктуры”, Модуль 12 отвечает на вопрос “как проектировать приложения, которые используют Kafka правильно”.
Четыре паттерна Модуля 12 строятся на концепциях Kafka, которые вы уже изучили:
- Event Sourcing: append-only лог из Модуля 01 как event store
- CQRS: KTable и KStream из Модуля 07 как read-side read models
- Transactional Outbox: Kafka Connect из Модуля 05 как транспорт CDC-событий
- Saga Pattern: транзакции продюсера из Модуля 02 для атомарного управления сагой