#apache-kafka #confluent-platform #cdc #ibm-infosphere #ibm-data-replication
#apache-kafka #платформа confluent #cdc #ibm-infosphere #ibm-репликация данных
Вопрос:
Мы пытаемся измерить задержку записи сообщений в Infosphere CDC- настройка Confluent kafka. У нас есть фиктивная таблица, и будут выполняться фиктивные транзакции.
Поток данных- таблица MF DB2 -> IIDR -> Раздел Kafka
(Для Kafka производителем является iidr)
Какой может быть правильный способ определить задержку записи выборочных транзакций без какого-либо инструмента корпоративного мониторинга? Можем ли мы проверить журналы на наличие записей и учесть временную метку каждой транзакции и сравнить с журналами транзакций cdc, чтобы определить задержку записи?
PS- У меня настроен jconsole для сбора показателей kafka. Но как мы можем определить задержку записи конкретного потока CDC в тему kafka?
Спасибо!
Комментарии:
1. Что вы подразумеваете под задержкой выборочных транзакций? В Kafka или во всей транзакции? Если вам просто нужна задержка в Kafka, взгляните на это
2. Это означает, что как только мы выполним несколько транзакций (скажем, 50) в исходном коде DB2, сколько времени потребуется для получения подтверждений на запись в Kafka? Поток данных будет db2-> IIDR (CDC)->Kafka.
3. В идеале нам нужна задержка всей транзакции. Но даже если мы узнаем задержку в kafka, мы можем оценить общую задержку транзакции с помощью времени отклика в журналах IIDR (CDC).
Ответ №1:
(К вашему сведению: я работаю в IBM и, в частности, над продуктом IDR CDC)
Встроенные KCOPs (процессоры пользовательских операций Kafka) в продукте репликации IDR не предоставляют аргумент timestamp при создании записей производителя Kafka. Это также имеет место, если вы используете поведение по умолчанию без KCOP.
Таким образом, Kafka при получении каждой записи производителя сгенерирует временную метку и свяжет ее с записью. Это значение временной метки включается в запись потребителя при чтении сообщения.
Это можно сравнить со временем, сгенерированным из источника, путем вычитания. Существует поле управления журналом временных меток, которое может быть реплицировано с данными строки. В некоторых источниках, например Db2 LUW, она представляет время фиксации транзакции. В некоторых случаях представляет время, когда эта конкретная строка была добавлена в журнал.
В целом я бы сказал, что задержку лучше всего учитывать с момента фактического вступления фиксации в силу, но это зависит от того, что вы хотите понять.
Я полагаю, что в DB2 Z каждое из них соответствует времени записи в журнале операции, вы могли бы сделать грубое приближение, используя временную метку последней операции в транзакции. При этом игнорируется величина задержки между записью последней транзакции и фактической фиксацией, но обычно они довольно близки.
IDR действительно предлагает запросы на улучшение функций, поэтому, пожалуйста, не стесняйтесь обращаться в службу поддержки или сюда, если вы хотите увидеть улучшение.
С уважением,