diff options
| author | galaxycrab <[email protected]> | 2022-12-01 11:57:46 +0300 |
|---|---|---|
| committer | galaxycrab <[email protected]> | 2022-12-01 11:57:46 +0300 |
| commit | 760ddc6f72eee80407863ad3dd82fc4dd6c3d18b (patch) | |
| tree | ae86f04b4dfe97e418a0af510d55125e97779fb6 /library/cpp/threading/blocking_queue/blocking_queue.cpp | |
| parent | d0eadfe2f1ebc3ec61ae8d275058df50faf6adca (diff) | |
Add logging to write actor. Fix early checkpoint save. Fix loading incorrect checkpoint
Пофиксил вытаскивание из базы некорректного номера чекпоинта. В итоге мы восстанавливались из чекпоинта, который был не последним. При этом новую порцию данных мы читали из PQ, так как коммитили туда офсеты, а записывали в выходной топик актуальные данные по старым офсетам, что приводило к потере данных. На этом фэйлился тест `test_recovery_mz.py::TestRecovery::test_recovery`.
Второй баг был в PQ write actor. Если в нём мы вызывали SendData сначала с одним сообщением, потом, до подтверждения его записи, вызывался метод SendData с чекпоинтом, то при условии пустого буффера вот тут https://a.yandex-team.ru/arcadia/ydb/library/yql/providers/pq/async_io/dq_pq_write_actor.cpp?rev=rXXXXXX#L158 мы сразу сохраняли стейт с некорректным офсетом (не учитывая ещё не подтверждённый офсет). В итоге мы также затем при загрузке из такого чекпоинта могли терять данные на дедупликации, так как сообщение должно было идти до чекпоинта: ридер читал следующие сообщения, а записывали мы их по неправильному офсету. На этом валился тест `test_recovery.py::TestRecovery::test_recovery`.
Также перед записью в PQ в тестах стал дожидаться zero checkpoint, так как это гарантирует нам, что ридеры не отсеят сообщения по времени своего старта.
Diffstat (limited to 'library/cpp/threading/blocking_queue/blocking_queue.cpp')
0 files changed, 0 insertions, 0 deletions
