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