У нас есть кластер кафка. И сеть. Ура. Сеть будет недоступна на всех стойках нашего дата-центра в течение 5-10 минут (!), Потому что этого требует техническое обслуживание. Я обеспокоен тем, что kafka слишком долго не может правильно обработать отключение, и что он может настолько запутаться в своем состоянии, что не сможет восстановиться после того, как сеть снова будет в сети.
Это хорошая идея - просто выключить кластер, и если да, то как лучше всего отключить всех брокеров?
Это кластер kafka 0.10.0, работающий на 6 узлах, распределенных в разных стойках вокруг центра обработки данных.
В итоге отключение оказалось не таким серьезным, как мы думали.
Кластер был отключен из-за сбоя сети. Все клиенты kafka были отключены, поэтому кластер был тихим до отключения. Отключение было около 3 минут. После того, как кластер вернулся в сеть, ему было разрешено снова сходиться, и, похоже, он именно это и сделал. Был запрошен выбор предпочтительного лидера, и все брокеры / все темы вернулись в хорошее состояние. После стабилизации клиенты kafka были переведены в онлайн, и все заработало.
Итак ... в этой ситуации правильнее всего сделать тихий кластер kafka, но не отключать ни одного из брокеров; пусть будет - поправится. Конечно, это предполагает, что вы можете компенсировать потерю данных во время простоя.
Хорошая идея - просто выключить кластер?
Может быть. Зависит от ваших требований к долговечности, если вы можете допустить потерю данных при восстановлении из этой сетевой изоляции. Будьте абсолютно уверены, что вы знаете, что происходит с вашей системой в сетевом разделе.
Проект Jepsen испытал Kafka несколько лет назад. Выборы нечистого лидера была проблема. Единственная синхронизированная реплика (ISR) могла оставаться лидером. Если последняя ISR была разделена на сеть или умерла, оставшиеся узлы выберут нового лидера, что приведет к потере данных. Я думаю, что это значение по умолчанию до версии 0.11.
Полное выключение до сетевого события означает, что не может быть нечистого лидера из-за раздела сети. Посмотри на controlled.shutdown.enable и auto.leader.rebalance параметры, упрощающие перенос разделов.
Чтобы выбрать надежность, рассмотрите возможность настройки так, чтобы для подтверждения записи требовалось большинство реплик, установив для подтверждения значение «все».
Когда производитель устанавливает для подтверждений значение «все» (или «-1»), min.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
В вашей текущей сети, если вы выбираете согласованность, вы жертвуете доступностью. Не может быть большинства реплик, если никто из них не может разговаривать друг с другом. Вам решать, будет ли это время простоя достаточно дорогим, чтобы оправдать распределение кластера по нескольким доменам сбоя сети.