Блог

Главная - Вопросы по программированию - Сообщения Mongodb Kafka, не просматриваемые по темам

Сообщения Mongodb Kafka, не просматриваемые по темам

#mongodb #apache-kafka #apache-kafka-connect #mongodb-kafka-connector

#mongodb #apache-kafka #apache-kafka-connect #mongodb-kafka-connector

Вопрос:

Я столкнулся с тем, что моя тема, несмотря на запуск и работу, не регистрирует события, происходящие в моем MongoDB.

Каждый раз, когда я вставляю / изменяю запись, я больше не получаю журналы из kafka-console-consumer команды.

Может быть, есть способ очистить кэш / смещение Кафки? Подключение к источнику и приемнику запущено и запущено. Весь кластер также исправен, дело в том, что все работало как обычно, но каждые пару недель я вижу, что это возвращается или когда я вхожу в свое облако Mongo из другого места.

--partition 0 параметр не помог, изменился retention_ms на 1 too.

введите описание изображения здесь

введите описание изображения здесь

Я проверил состояние обоих соединителей и получил RUNNING :

curl localhost:8083/connectors | jq
введите описание изображения здесь

curl localhost:8083/connectors/monit_people/status | jq
введите описание изображения здесь

При запуске docker-compose logs connect я обнаружил:

     WARN Failed to resume change stream: Resume of change stream was not possible, as the resume point may no longer be in the oplog. 286

If the resume token is no longer available then there is the potential for data loss.
Saved resume tokens are managed by Kafka and stored with the offset data.
 
When running Connect in standalone mode offsets are configured using the:
`offset.storage.file.filename` configuration.
When running Connect in distributed mode the offsets are stored in a topic.

Use the `kafka-consumer-groups.sh` tool with the `--reset-offsets` flag to reset offsets.

Resetting the offset will allow for the connector to be resume from the latest resume token. 
Using `copy.existing=true` ensures that all data will be outputted by the connector but it will duplicate existing data.
Future releases will support a configurable `errors.tolerance` level for the source connector and make use of the `postBatchResumeToken

Комментарии:

1. Ты скучаешь --from-beginning ? В противном случае вы будете читать только новые сообщения. И как вы проверяете работоспособность разъема? Исправный / исправный есть только проверка работоспособности http-сервера connect, ни один отдельный соединитель не работает

2. Я не использовал --from-beginning at, который также работал в прошлом. Я бежал curl localhost:8083/connectors | jq с curl localhost:8083/connectors/monit_people/status | jq и статус есть RUNNING

3. Какой разъем mongo вы используете? Останавливаются ли ваши изображения docker в какой-либо момент в этот период «каждые пару недель»? Если это так, и вы не используете монтирование томов, то да — Docker удаляет данные Kafka

4. Вы также можете искать ошибки в docker-compose logs connect

5. Соединители: https://www.confluent.io/hub/mongodb/kafka-connect-mongodb и https://www.confluent.io/hub/snowflakeinc/snowflake-kafka-connector . Когда я заканчиваю обучение, я просто помещаю docker imagie с docker container stop $(docker container ls -a -q -f "label=io.confluent.docker")

Ответ №1:

Проблема требует больше практики с платформой Confluent, поэтому на данный момент я перестроил всю среду, удалив весь контейнер с:

docker system prune -a -f --volumes

docker container stop $(docker container ls -a -q -f "label=io.confluent.docker") .

После запуска docker-compose up -d все работает и работает.