[
https://issues.apache.org/jira/browse/KAFKA-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768628#comment-16768628
]
Murad M commented on KAFKA-7930:
--------------------------------
[~guozhang], definitely, that how it was done in the first place. Consider your
18 partitions topics as input, put them in appropriate `\-\-input-topics` and
`\-\-intermediate-topics`. Then run with `\-\-dry-run` and see that in first
section every partition is reported to be reset to expected offset, and miss
single line in the end stating that same one topic whose 18 partitions above
was reported to be reset, that it will be deleted. As result loose 120GB~ topic
which takes days to replay :)
Any way, at this point I would consider this as bug, because topic provided in
`\-\-input-topics` or `\-\-intermediate-topics` arguments is reported to be
reset AND reported to be deleted, then without `\-\-dry-run` (StreamsResetter
has no `\-\-execute` argument like `kafka-consumer-group.sh` btw) same topic
first being reset AND then deleted.
For sure it is mistake of user attention, but also definitely a misbehavior of
tool. Let's say user saw that it will be reset AND deleted, but topic is not
intended for deletion, because user knows that it is input topic and should be
treated as such, then what?
One way as suggested by [~mjsax] would be to switch from StreamsResetter to
`kafka-consumer-group.sh`, which is still unclear to me as per a), b) and c)
above. Does it do exactly same thing? Is it the way to go in this situation?
What if in the future, StreamsResetter will do also things which
`kafka-consumer-group.sh` would not be aware of?
> StreamsResetter makes "changelog" topic naming assumptions
> ----------------------------------------------------------
>
> Key: KAFKA-7930
> URL: https://issues.apache.org/jira/browse/KAFKA-7930
> Project: Kafka
> Issue Type: Improvement
> Components: streams, tools
> Affects Versions: 2.1.0
> Reporter: Murad M
> Priority: Major
> Labels: features, needs-kip, patch-available, usability
>
> StreamsResetter deletes the topics considered internal. Currently it just
> checks the naming as per
> [code|https://github.com/apache/kafka/blob/1aae604861068bb7337d4972c9dcc0c0a99c374d/core/src/main/scala/kafka/tools/StreamsResetter.java#L660].
> If assumption is wrong (either topic prefix or suffix), tool becomes useless
> if aware even dangerous if not. Probably better either:
> * naming assumption should be optional and supply internal topics with
> argument (--internal-topics)
> * deletion could be optional (--no-delete-internal)
> * ignore topics which are included in list of --input-topics
> Faced this, when was trying to reset applications with GlobalKTable topics
> named as *-changelog. Such topics sometimes are not desirable for deletion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
