Kafka-backup: Потребительское смещение

Привет Имран,

Я пишу сообщение в блоге о резервном копировании и восстановлении тем Kafka в среде Kubernetes с другим проектом с открытым исходным кодом OpenEBS, предоставляющим базовое постоянное хранилище, подключенное к контейнеру.

Резервное копирование Kafka с использованием моментальных снимков файловой системы не так уж и просто. См. https://github.com/azapps/kafka-backup/blob/master/docs/Comparing_Kafka_Backup_Solutions.md для получения дополнительной информации об этом.

На данный момент я решил использовать разъем Spredfast S3, но мой друг Араш Каффаманеш указал мне на вашу работу. У меня было несколько вопросов.

Соединитель S3 выглядит совершенно нормально, если вам не нужно восстанавливать какие-либо смещения потребителей. Я глубоко погрузился в исходный код соединителя S3, прежде чем отклонить его как решение наших проблем, поскольку он не предоставляет этой важной функции, и его трудно расширить для обработки этого случая.

Как во время восстановления сообщить потребителю, с чего начать потребление?

В настоящее время единственный способ — просто удалить сегменты, которые не следует восстанавливать, и заново создать индекс. Скоро будет больше информации о том, как этого добиться. Если вам действительно нужно начать восстановление с очень определенного смещения, пожалуйста, откройте вопрос. Это не должно быть сложно реализовать.

Не могли бы вы поделиться дополнительными отличиями от коннектора spredfast?

Опять же, коннектор S3 не может синхронизировать смещения потребителей во время восстановления. На самом деле в текущей версии Kafka сделать это надежно просто невозможно. Благодаря работе @ryannedolan над Mirror Maker 2 скоро появится способ сделать это, и kafka-backup использует этот API. К счастью, это изменение совместимо даже с предыдущими версиями, и очень скоро появится документация по использованию kafka-backup таким образом.

Кроме того, S3 Connector поддерживает только S3. В настоящее время kafka-backup поддерживает только резервное копирование в файловую систему, а затем вы можете использовать любой инструмент, который хотите, чтобы переместить его в конечный пункт назначения. Я планирую добавить поддержку дополнительных бэкэндов для хранения, если в этом возникнет необходимость.

Кроме того, два проекта архитектурно очень похожи (на самом деле, разъем S3 вместе с Mirror Maker 2 вдохновил kafka-backup )

моя среда Kafka работает в Kubernetes. В идеале мне нужно хранилище резервных копий/восстановлений за пределами моего кластера, чтобы я мог вернуть его в случае сбоя.

Насколько я знаю, вы тоже пользуетесь Strimzi, у нас такая же резервная копия. Скоро я напишу в блоге, как сделать полную резервную копию Kafka и (не забывайте об этом!) Zookeeper на Kubernetes и Strimzi.

расположение резервной копии определяется target.dir , становится сложно управлять путем на узле, если используется среда Kubernetes.

Просто смонтируйте постоянный том, как всегда. Используйте контейнер с коляской, чтобы переместить его в конечный пункт назначения. Вы даже можете сохранить постоянный объем относительно небольшим, так как вы можете удалить старые сегменты и их индекс, как только они будут завершены. (Документация идет)

Если вы подождете еще несколько дней, я опубликую вводную запись в блоге, посвященную некоторым из ваших тем. Напишите мне письмо или попросите у @arashkaffamanesh черновик :wink:

Вклад @azapps уникален и великолепен, и я думаю, что все сообщество должно помочь сделать предложенную и реализованную резервную копию Kafka от @azapps стандартизированной частью экосистемы Kafka!

Нет ничего идеального, но эта реализация от @azapps блестящая!

Для протокола: поехали: https://medium.com/@anatolyz/introduction -kafka-backup-9dc0677ea7ee