|
|
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
С недавних пор возникла ситуация, когда 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, тот же пейлоад) Сталкивался ли кто то с такой ситуацией? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2015, 19:27 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Есть подозрение, что виновата нестабильность времени на сервере, оказалось ntp был поломан. Мониторим пока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2015, 18:27 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, а какая версия skytools? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2015, 17:28 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Версия 3.1.5, если точнее то версия deb пакета 3.1.5-1.pgdg70+1 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2015, 18:59 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
починка ntp проблемы не решила. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2015, 19:02 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, > консумер какой конкретно консумер? "finish_batch: batch % not found" это говорит о том, что батча такого не было вам выдано. опишите подробно схему, с указанием, кто куда и через что подключается, что за консумер, и как вы его запускаете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 04:18 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
и штатно ли работал сервер - база - консумер перед возникновением "дублирования"? и еще всё таки уточните, как вы видите, что "тот же event_id, тот же пейлоад"? ну и какую задачу реашет косумер в общем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 04:32 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin, Консумер самописный, он логгирует каждый полученный батч и каждый евент батча. Точно известно что батч ему был выдан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 16:20 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha Tyurinи штатно ли работал сервер - база - консумер перед возникновением "дублирования"? и еще всё таки уточните, как вы видите, что "тот же event_id, тот же пейлоад"? ну и какую задачу реашет косумер в общем? Все работало штатно. Я вижу в логах что консумер вычитывает евенты батча, обрабатывает их(он логирует евенты и отсылает их на REST API удаленной системы), после этого finish_batch дает вышеописанный ворнинг. Следующий батч содержит эти же евенты(такие же ev_id, и такой же пайлоад). Отмечу что удаленная система ведет логи, и эти логи потдверждают вышеописанный сценарий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 16:24 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin, предположим, что кроме триггерной репликации, наши сервера имеют горячие стендбаи (оба--два, и подписчик и публикатор) предположим, далее, что батч (его приём) накатан на упавший впоследствии праймари подписчика. (ну например). а на стендбай подписчика -- нет (по какой-то причине). Может ли в результате батч очиститься из очереди (на паблишере) , а на запущенном в кач-ве праймери стендбае считаться ненакаченным ? -- очень похоже на такую историю. (как вариант -- подписчик упал отработав , но не закоммитив накатку батча [батарейка сдохла], а паблишер почему-то её отработал, без всяких стендбаев и т.п. --Имеем -- на подписчике требуется батч, на публикаторе его нет). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 16:31 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
общая логика работы такова: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 16:34 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
КактузMisha Tyurinи штатно ли работал сервер - база - консумер перед возникновением "дублирования"? и еще всё таки уточните, как вы видите, что "тот же event_id, тот же пейлоад"? ну и какую задачу реашет косумер в общем? Все работало штатно. Я вижу в логах что консумер вычитывает евенты батча, обрабатывает их(он логирует евенты и отсылает их на REST API удаленной системы), после этого finish_batch дает вышеописанный ворнинг. Следующий батч содержит эти же евенты(такие же ev_id, и такой же пайлоад). Отмечу что удаленная система ведет логи, и эти логи потдверждают вышеописанный сценарий. вам надо иисчислить потерянный батч, и катануть его дельту руками, и удалить его с подписчика. штатно это делается ресинком, но очень дорого (COPY all на диск + сравнение) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 16:34 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
интересуюсьвам надо иисчислить потерянный батч, и катануть его дельту руками, и удалить его с подписчика. штатно это делается ресинком, но очень дорого (COPY all на диск + сравнение) У меня нет репликации. У меня консумер другим занимается, прочитайте внимательно. Проблема в том наш консумер обрабатывает евенты батча, его евенты магическим образом перемещаются в следующий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 16:38 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, да , я уже поудмал, что у вас не репликация. под руками нет установленного pgq, -- если я верно помню -- там эти сообщения могут выкидывать plpgsql хранимки pgq-ных схем . если так -- почитайте тексты-- там станет ясно, что на самом деле у вас происходит (а не то, что вы об этом думаете). если не так -- то придется в исходники pgq лезть -- а это уже сложнее. я всё таки думаю, что у вас рассогласованное состояние публикатора и подписчика. и таково оно, поскольку где-то (на чьей-то стороне) не закоммитили очередную порцию. (там таки нет диспетчера распределенных транз. или я не прав ? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 17:51 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, по вашему описанию и псевдокоду сложно что-то сказать определенно, так как очень много всего не известного. у вас вероятно финиш батч не прошел где-то. обращаю внимание тогда на этот кусок https://github.com/markokr/skytools/blob/master/sql/pgq/functions/pgq.finish_batch.sql WARNING: finish_batch... такой варнинг -- это вот так как не нашли. но если смотреть https://github.com/markokr/skytools/blob/master/sql/pgq/functions/pgq.next_batch.sql -- has already active batch if batch_id is not null then return; end if; то выглядит так, как будто у вас код где-то консумера развалился или что-то где-то "переключалось" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 18:35 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin, > у вас вероятно финиш батч не прошел где-то. это ни при чем. надо смотреть как вы с транзакциями в вашем консумере обращаетесь. почти уверен что, вы 1) открывайте транзакцию в источнике и получаете next_batch 2) ! далее не закрываете её 3) что-то делает в приемнике 4) делаете финиш в источнике 5) закрываете транзакцию в источинике вы из питона работаете? вы уверены, что понимаете как организовали транзакции ваши на обоих концах? там в питоне абстракции курсора-коннекта-транзакции всё замучено слегка. и вот у вас код где-то "вылетел" между 1 и 5. а так как сиквенс не транзакционен вы имеете айди новое батча, а события старые. --- ууух, это была заявка на вангу года уже в январе! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 18:45 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
точнее, по вашему "логу", вылетает у вас между 1 и 4; т. е. вы делаете финиш уже того, что "отпало" и не закомитилось. у вас кстати источник и приемник pgq -- это разные базы? и в каком месте и по какому принципу идет в консумере работа с "удаленная система"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 19:01 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha TyurinMisha Tyurin, > у вас вероятно финиш батч не прошел где-то. это ни при чем. надо смотреть как вы с транзакциями в вашем консумере обращаетесь. почти уверен что, вы 1) открывайте транзакцию в источнике и получаете next_batch 2) ! далее не закрываете её 3) что-то делает в приемнике 4) делаете финиш в источнике 5) закрываете транзакцию в источинике вы из питона работаете? вы уверены, что понимаете как организовали транзакции ваши на обоих концах? там в питоне абстракции курсора-коннекта-транзакции всё замучено слегка. и вот у вас код где-то "вылетел" между 1 и 5. а так как сиквенс не транзакционен вы имеете айди новое батча, а события старые. --- ууух, это была заявка на вангу года уже в январе! консумер - приложение на руби, которое читает евенты из postgresql. Работа с pgq написана максимально низкоуронево, никакой динамической генерации sql нет. Потребитель - REST API, с которым происходит работа по http. Для каждого евента в батче, приложение дергает REST API. Если происходит ексепшн любого рода(проблемы с сетью, http ответ отличается от 200OK) приложение падает и отсылает емейл с бектрейсом, и автоматически работу не возобновляет. В случае возникновения проблемы, код между 1 и 5 не вылетает, эксепшнов не происходит, это подтверждается логами на стороне API и логами postgresql где тоже не видно эксепшнов. Еще раз уточняю что каждый евент метится обработанным путем вызова set_event_done(), кроме того все выполняется в "режиме автокоммита", то есть явно не вызывается begin/commit, то есть каждый вызов sql - внутри своей транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 20:57 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, нет, не так. > логами postgresql где тоже не видно эксепшнов при роллбеке никакого експешина не происходит. вы просто не коммитете next_batch(). как уж это происходит, это вам разбираться. отлаживайте свой код на руби. еще раз повторю вопрос: у вас источник и приемник -- это одна и та же база? это может быть важно опять же для понимания как у вас транзакция открывается/закрывается. -- я могу вам предложить отладку на увроне pg 1) мониторте http://www.postgresql.org/docs/9.4/static/monitoring-stats.html#PG-STAT-DATABASE-VIEW xact_rollback 2) ! включите логи запросов на сесии работы с pgq ! --- и вы увидете как у ваз вызывается get_next_batch() и get_events() -- там будет видно, одна и та же ли это транзакция http://www.postgresql.org/docs/9.4/static/runtime-config-logging.html %x Transaction ID (0 if none is assigned) и еще вам можно оч много вариантов предложить, но пока это попробуйте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 21:55 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha TyurinКактуз, нет, не так. > логами postgresql где тоже не видно эксепшнов при роллбеке никакого експешина не происходит. вы просто не коммитете next_batch(). как уж это происходит, это вам разбираться. отлаживайте свой код на руби. еще раз повторю вопрос: у вас источник и приемник -- это одна и та же база? это может быть важно опять же для понимания как у вас транзакция открывается/закрывается. -- я могу вам предложить отладку на увроне pg 1) мониторте http://www.postgresql.org/docs/9.4/static/monitoring-stats.html#PG-STAT-DATABASE-VIEW xact_rollback 2) ! включите логи запросов на сесии работы с pgq ! --- и вы увидете как у ваз вызывается get_next_batch() и get_events() -- там будет видно, одна и та же ли это транзакция http://www.postgresql.org/docs/9.4/static/runtime-config-logging.html %x Transaction ID (0 if none is assigned) и еще вам можно оч много вариантов предложить, но пока это попробуйте Я уже несколько раз написал, что приемник это HTTP REST API - это не база данных, а внешний сервис, работающий по протоколу http, он не поддерживает транзакции и атомарно обрабатывает только один запрос. Именно потому евенты обрабатываются поодному. Транзакции у меня не открываются/закрываются явно(приложение не вызывает begin/commit). Каждый вызов любой хранимки связанной с pgq происходит в своей транзакции, которая неявно начинается и коммитится, в одной транзакции выполняется только один statement. Я отлично знаю про возможности логгирования pg, проблема в том что на данный момент несколько сложно записать логи по причине их объема, а проблема повторяется нечасто и только с одним инстансом. В тестовом окружении, с теми же версиями кода проблема не повторяется. Логгирование SQL, в тестовом окружении не показывает ни единого begin/commit/rollback которые выполняло бы приложение. Код: sql 1. 2. 3. 4. 5. 6. 54cd2eba.7aa8 - id сессии, а не транзакции. Ваш посыл я понял - next_batch() незакоммичен, а get_batch_events сработал потому что был с ним в единой транзакции, я в 100500й раз проверю этот вариант, но сложно проверить что один и тот же код внезапно стал явно начинать транзакции, если он был написаен чтобы этого не делать, и в тестовом окружении этого не делает. Не пишите пожалуйста очевидных вещей типа, как логгировать запросы в пг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 22:47 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin, Специально логи с тестового окружения, где работает этот же код. log_line_prefix = '%m-%u-%h@%d-%c-%x-%v ' У каждой строки свой virtual transaction id. transaction_id везде 0, тк явно транзакция не начата. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 22:59 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, у вас одна база. тааак. а через что и как вы коннектитись к pg? есть ли разница между боевым окружением и тестовым? какая там среда, библиотеки? как там "автокоммит" выставляется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 23:27 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha TyurinКактуз, у вас одна база. тааак. а через что и как вы коннектитись к pg? есть ли разница между боевым окружением и тестовым? какая там среда, библиотеки? как там "автокоммит" выставляется? Автокоммит по дефолту, используется ActiveRecord, но вся работа с pgq сделана сырыми запросами, без всякого "интеллекта" фреймворка. Разница продакшна и сендбокса только в данных и нагрузке. Ну и в том что на одном из продакшн инстансов наблюдается вышеописанная проблема. Когда проблема возникла я сразу начал проверять именно приложение, однако в нем проблем на нашел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 23:36 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, ну пока не сильно картина проясняется. > на одном из продакшн инстансов вот там и надо логи смотреть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2015, 23:59 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
SELECT pgq.next_batch('routeserver', 'routeserver') SELECT pgq.next_batch('routeserver', 'routeserver') SELECT * FROM pgq.get_batch_events(185641) WHERE pgq_ext.is_event_done('routeserver', 185641, ev_id) = false ORDER BY ev_id SELECT pgq.finish_batch(185641) SELECT pgq.next_batch('routeserver', 'routeserver') SELECT pgq.next_batch('routeserver', 'routeserver') вот это тоже у вас какой-то интересный пример. это реальный лог? где обработка то событий? или вы её вы просто не привели? батч айди вернулся, а события уже все были отработаны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 01:11 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Misha TyurinSELECT pgq.next_batch('routeserver', 'routeserver') SELECT pgq.next_batch('routeserver', 'routeserver') SELECT * FROM pgq.get_batch_events(185641) WHERE pgq_ext.is_event_done('routeserver', 185641, ev_id) = false ORDER BY ev_id SELECT pgq.finish_batch(185641) SELECT pgq.next_batch('routeserver', 'routeserver') SELECT pgq.next_batch('routeserver', 'routeserver') вот это тоже у вас какой-то интересный пример. это реальный лог? где обработка то событий? или вы её вы просто не привели? батч айди вернулся, а события уже все были отработаны? Это реальный лог. Я уже не в первый раз пишу, что обработка это отсылка http запросов на удаленный сервер. Происходит она между Код: sql 1. и Код: sql 1. Естественно что в логи постгреса не пишется ничего связанного с http. set_event_done() тут не используется, тк в этом батче был только один евент. В случае когда в одном батче много евентов, используется set_event_done() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 16:37 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, > set_event_done() тут не используется, тк в этом батче был только один евент чет как-то сложно всё у вас. ждем логи... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2015, 17:41 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
КактузС недавних пор возникла ситуация, когда 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, тот же пейлоад) Сталкивался ли кто то с такой ситуацией? кактус, вы исходник-то читали? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. -- откуда мораль, вам просто нечего тут апдейтить ( в pgq.subscription нет батча where sub_batch = x_batch_id;). Почему это проиходит -- вопрос к вам, а не к pgq. я например в вашем псевдокоде вижу, что вы берете pgq.get_next_batch() а там, битым словом, (через pgq.next_batch_info<<--pgq.next_batch_custom) -- тащится именно pgq.subscription.sub_batch Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. -- откуда ровно 2 3 версии -- 1. где-то в середине между {=pgq.get_next_batch()} и {pgq.finish_batch()} вы прибиваете (дропаете, или апдейтите ему id) этот sub_batch = x_batch_id; в pgq.subscripton-е. [маловероятно, но вчитайтесь в process()] 2. вы читаете незакоммиченный next_batch в одной транзакции (так и незакомиченной|или rollback-нутой), а финишируете - в другой (где тот-же батч не виден в subscription). [наиболее вероятно, но вы божитесь, что это не так] 3. вы, в прикладухе (см. ваш код), теряете значние x_batch_id, и передаете в финиш то, чего там нет и не было на момент get_. т.ч. посмотрите на ВАШ код внимательнее -- кто-то пришибает вам батч [или портит его id] между get и finish. есть фантазия 4. -- вы берете батч в одной базульке, а пытаетесь финишировать в другой, но у вас якобы нет второй бд как-то так. ах, да, -- версия 5.: у вас множественные обработчики очереди. И один из них успевает отработать батч (а pgq успевает от него избавиться в subscription) -- и только тут второй обработчик той же очереди подходит к финишу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 10:36 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
интересуюсь-- откуда ровно 2 3 версии -- 1. где-то в середине между {=pgq.get_next_batch()} и {pgq.finish_batch()} вы прибиваете (дропаете, или апдейтите ему id) этот sub_batch = x_batch_id; в pgq.subscripton-е. [маловероятно, но вчитайтесь в process()] 2. вы читаете незакоммиченный next_batch в одной транзакции (так и незакомиченной|или rollback-нутой), а финишируете - в другой (где тот-же батч не виден в subscription). [наиболее вероятно, но вы божитесь, что это не так] 3. вы, в прикладухе (см. ваш код), теряете значние x_batch_id, и передаете в финиш то, чего там нет и не было на момент get_. т.ч. посмотрите на ВАШ код внимательнее -- кто-то пришибает вам батч [или портит его id] между get и finish. есть фантазия 4. -- вы берете батч в одной базульке, а пытаетесь финишировать в другой, но у вас якобы нет второй бд как-то так. ах, да, -- версия 5.: у вас множественные обработчики очереди. И один из них успевает отработать батч (а pgq успевает от него избавиться в subscription) -- и только тут второй обработчик той же очереди подходит к финишу Исходники я читал. Ваши версии очевидны, они выше уже обсуждались и были проверены. Приложение-консумер точно не портит pgq.subscripton, мы уже копаем в сторону других клиентов базы(мне эта версия кажется наиболее вероятной) ну и идем в сторону "записать гору SQL логов с продакшна". Когда это получится, надеюсь что-то будет видно. Сообщу о результатах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 16:03 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
КактузПриложение-консумер точно не портит pgq.subscripton<>.этого мало. у вас есть защита от запуска 2-х (и более) экземляров консумера ? //"они оба не портят", но второй экземпляр будет именно так ругаться -- если до него первый отфиниширует,и батч будет почикан из pgq.subscription ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 16:28 |
|
||
|
Дублирование ивентов PgQ
|
|||
|---|---|---|---|
|
#18+
Кактуз, Зачем гору логов ?? Сделайте логи только на сессии работы с pgq ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2015, 18:29 |
|
||
|
|

start [/forum/topic.php?all=1&fid=53&tid=1998202]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
178ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 465ms |

| 0 / 0 |
