#apache-kafka-streams
#apache-kafka-streams
Вопрос:
в StreamsConfig есть параметр STATE_CLEANUP_DELAY_MS_CONFIG, который указывает «Количество времени в миллисекундах, которое необходимо подождать перед удалением состояния при миграции раздела. Будут удалены только каталоги состояний, которые не были изменены, по крайней мере state.cleanup.delay.ms , для «;
У нас есть несколько каталогов состояния из-за перебалансировки, развертывания и т. Д. В файловой системе
- Это очистит эти каталоги? Я попробовал этот параметр, перезапустил потребителя, но старые каталоги состояния все еще существуют
Ответ №1:
Обратите внимание, что потоки Kafka будут удалять только каталоги задач, которые вложены внутри state.dir , и только для текущего приложения. Таким образом, если у вас есть несколько каталогов состояний, потому что вы изменили application.id , вам нужно будет удалить старые каталоги состояний вручную.
Комментарии:
1. Согласно журналам kafka текущие активные задачи: [1_3, 2_2, 0_5, 1_4, 2_3, 0_6, 1_5] и затем я получаю сообщения о том, что удаление устаревшего каталога состояния 0_5 для задачи 0_5 по истечении 60555 мс (задержка очистки составляет 60000 мс) завершается неудачно из-за того, что контрольная точка tem не найдена. Также я не смог найти каталог задач 0_5 в каталоге состояния. Почему он пытается удалить каталог задач, который активен? и почему нет каталога задач для задачи 0_5 в каталоге состояний
2. Кроме того, когда одна машина (потребитель) выходит из строя, задачи распределяются по другим узлам в соответствии с журналами. Но я не смог найти новые каталоги задач. Например, узел 1 говорит [0_0, 0_1, 1_0, 0_2, 1_1, 2_0, 0_3, 1_3, 0_5, 1_4] активные задачи после назначения раздела, но на этом компьютере нет каталогов, вложенных с именем 0_ в каталог состояния.
3. Существует известная ошибка: issues.apache.org/jira/browse/KAFKA-5998 для контрольной точки проблема не найдена. Может быть, ты попал в точку. Что касается второй части, я не уверен, что атм. Звучит подозрительно, но трудно сказать, почему каталоги задач не создаются…
4. прошло 1110471мс (задержка очистки составляет 600000 мс) Очистка происходит намного позже заданной задержки. Является ли это нормальным поведением? Кроме того, какова максимальная задержка, которая может произойти?
5. если у нас есть StickyAssignor, будет ли по-прежнему выполняться очистка? Как и в предположим, если через 5 часов наш потребитель снова заработает, то произойдет перемещение каталога состояния?