Дублирование ивентов PgQ

С недавних пор возникла ситуация, когда pgq создает дублирующие батчи. Имеются ввиду батчи с разными batch_id, но содержащие идентичные ивенты.

Консумер читает батч и процессит ивенты поодному, вызывая pgq_ext.set_event_done() после обработки каждого ивента( и конечно проверяет is_even_done перед обработкой). После обработки всех ивентов батча, консумер выполняет finish_batch() и берет следующий.

Когда возникает проблема, консумер обрабатывает все ивенты батча 1, делает finish_batch(), finish_batch говорит "WARNING: finish_batch: batch 1 not found", после этого консумер берет батч 2, который содержит все ивенты, уже обработанные в батче 1( тот же event_id, тот же пейлоад)

Сталкивался ли кто то с такой ситуацией?

Есть подозрение, что виновата нестабильность времени на сервере, оказалось ntp был поломан. Мониторим пока.

Кактуз,

а какая версия skytools?

Версия 3.1.5, если точнее то версия deb пакета 3.1.5-1.pgdg70+1

# SELECT pgq_ext.version();
 version 
---------
 3.1
(1 row)
# SELECT version();
                                           version                                            
----------------------------------------------------------------------------------------------
 PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.7.2-5) 4.7.2, 64-bit
(1 row)

починка ntp проблемы не решила.

Кактуз,

> консумер

какой конкретно консумер?

"finish_batch: batch % not found"
это говорит о том, что батча такого не было вам выдано.

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

и штатно ли работал сервер - база - консумер перед возникновением "дублирования"?
и еще всё таки уточните, как вы видите, что "тот же event_id, тот же пейлоад"?
ну и какую задачу реашет косумер в общем?

Misha Tyurin,

Консумер самописный, он логгирует каждый полученный батч и каждый евент батча. Точно известно что батч ему был выдан.

Misha Tyurin
и штатно ли работал сервер - база - консумер перед возникновением "дублирования"? и еще всё таки уточните, как вы видите, что "тот же event_id, тот же пейлоад"? ну и какую задачу реашет косумер в общем?

Все работало штатно.
Я вижу в логах что консумер вычитывает евенты батча, обрабатывает их(он логирует евенты и отсылает их на REST API удаленной системы), после этого finish_batch дает вышеописанный ворнинг. Следующий батч содержит эти же евенты(такие же ev_id, и такой же пайлоад). Отмечу что удаленная система ведет логи, и эти логи потдверждают вышеописанный сценарий.

Misha Tyurin,

предположим, что кроме триггерной репликации, наши сервера имеют горячие стендбаи (оба--два, и подписчик и публикатор)
предположим, далее, что батч (его приём) накатан на упавший впоследствии праймари подписчика. (ну например).
а на стендбай подписчика -- нет (по какой-то причине).
Может ли в результате батч очиститься из очереди (на паблишере) , а на запущенном в кач-ве праймери стендбае считаться ненакаченным ?

-- очень похоже на такую историю.
(как вариант -- подписчик упал отработав , но не закоммитив накатку батча [батарейка сдохла], а паблишер почему-то её отработал, без всяких стендбаев и т.п. --Имеем -- на подписчике требуется батч, на публикаторе его нет).