Кластер Kafka: Устойчивость к отключению сети
У нас есть кластер кафка. И сеть. Ура. Сеть будет недоступна на всех стойках нашего дата-центра в течение 5-10 минут (!), Потому что этого требует техническое обслуживание. Меня беспокоит, что перерыв в работе Kafka слишком длительный, и он может так запутаться в своем состоянии, что не сможет восстановиться, как только сеть вернется в режим онлайн.
Это хорошая идея - просто закрыть кластер вниз, и если да, то как лучше всего отключить всех брокеров?
Это кластер kafka 0.10.0, работающий на 6 узлах, распределенных в разных стойках вокруг центра обработки данных.
Было бы неплохо просто выключить кластер
Возможно. Зависит от ваших требований к долговечности, если вы можете допустить потерю данных при восстановлении из этой сетевой изоляции. Будьте абсолютно уверены, что вы знаете, что происходит с вашей системой в сетевом разделе.
Проект Jepsen несколько лет назад испытал Кафку на своем пути. Нечистые выборы лидера были проблемой. Единственная синхронизированная реплика (ISR) могла оставаться лидером. Если эта последняя ISR была разделена на сеть или умерла, оставшиеся узлы выберут нового лидера, что приведет к потере данных. Я думаю, что это все еще значение по умолчанию до версии 0.11.
Полное выключение до сетевого события означает, что не может быть нечистого лидера из-за сетевого раздела. Чтобы упростить перенос раздела, посмотрите параметры managed.shutdown.enable и auto.leader.rebalance .
Чтобы выбрать надежность, рассмотрите возможность настройки так, чтобы для подтверждения записи требовалось большинство реплик, установив для подтверждения значение «все».
Когда производитель устанавливает для подтверждения значение «все» (или «-1»), мин. .insync.replicas указывает минимальное количество реплик, которые должны подтверждать запись чтобы запись считалась успешной. Если этот минимум не может быть встретились, то производитель вызовет исключение (либо NotEnoughReplicas или NotEnoughReplicasAfterAppend). При использовании вместе, min.insync.replicas и acks позволяют добиться большего гарантии долговечности. Типичный сценарий - создать тему с коэффициентом репликации 3 установите min.insync.replicas равным 2 и производят с акциями "все". Это гарантирует, что производитель повысит исключение, если большинство реплик не получают записи.
default.replication.factor=3
min.insync.replicas=2
# Default from 0.11.0
unclean.leader.election.enable=false
В вашей текущей сети, если вы выбираете согласованность, вы жертвуете доступностью. Не может быть большинства реплик, если никто из них не может разговаривать друг с другом. Вам решать, будет ли это время простоя достаточно дорогим, чтобы оправдать распределение кластера по нескольким доменам сбоя сети.
Сбой оказался не таким серьезным, как мы думали.
Кластер был оставлен на случай сбоя сети. Все клиенты kafka были отключены, поэтому перед отключением кластер был тихим. Отключение было около 3 минут. После возобновления работы в сети кластеру было разрешено повторно сходиться, и, похоже, он именно это и сделал. Был запрошен выбор предпочтительного лидера, и все брокеры / все темы вернулись в хорошее состояние. После стабилизации клиенты kafka были переведены в онлайн, и все заработало.
Итак ... в этой ситуации правильнее всего сделать так, чтобы успокоить кластер kafka, но не отключать ни одного из брокеров; пусть будет - поправится. Конечно, это предполагает, что вы можете компенсировать потерю данных во время простоя.