[
https://issues.apache.org/jira/browse/KAFKA-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justine Olshan updated KAFKA-8872:
----------------------------------
Description:
Kafka currently uniquely identifies a topic by its name. This is generally
sufficient, but there are flaws in this scheme if a topic is deleted and
recreated with the same name. As a result, Kafka attempts to prevent these
classes of issues by ensuring a topic is deleted from all replicas before
completing a deletion. This solution is not perfect, as it is possible for
partitions to be reassigned from brokers while they are down, and there are no
guarantees that this state will ever be cleaned up and will not cause issues in
the future.
As the controller must wait for all replicas to delete their local partitions,
deletes can also become blocked, preventing topics from being created with the
same name until the deletion is complete on all replicas. This can mean that
downtime for a single broker can effectively cause a complete outage for
everyone producing/consuming to that topic name, as the topic cannot be
recreated without manual intervention.
Unique topic IDs could help address this issue by associating a unique ID with
each topic, ensuring a newly created topic with a previously used name cannot
be confused with a previous topic with that name.
was:
Kafka currently uniquely identifies a topic by its name. This is generally
sufficient, but there are flaws in this scheme if a topic is deleted and
recreated with the same name. As a result, Kafka attempts to prevent these
classes of issues by ensuring a topic is deleted from all replicas before
completing a deletion. This solution is not perfect, as it is possible for
partitions to be reassigned from brokers while they are down, and there are no
guarantees that this state will ever be cleaned up and will not cause issues in
the future.
As the controller must wait for all replicas to delete their local partitions,
deletes can also become blocked, preventing topics from being created with the
same name until the deletion is complete on all replicas. This can mean that
downtime for a single broker can effectively cause a complete outage for
everyone producing/consuming to that topic name, as the topic cannot be
recreated without manual intervention.
Unique topic IDs could help address this issue by associating a unique ID with
each topic, ensuring a newly created topic with a previously used name cannot
be confused with a previous topic with that name.
Related Issues:
KAFKA-10545
> Improvements to controller "deleting" state / topic Identifiers
> ----------------------------------------------------------------
>
> Key: KAFKA-8872
> URL: https://issues.apache.org/jira/browse/KAFKA-8872
> Project: Kafka
> Issue Type: Improvement
> Reporter: Lucas Bradstreet
> Priority: Major
>
> Kafka currently uniquely identifies a topic by its name. This is generally
> sufficient, but there are flaws in this scheme if a topic is deleted and
> recreated with the same name. As a result, Kafka attempts to prevent these
> classes of issues by ensuring a topic is deleted from all replicas before
> completing a deletion. This solution is not perfect, as it is possible for
> partitions to be reassigned from brokers while they are down, and there are
> no guarantees that this state will ever be cleaned up and will not cause
> issues in the future.
> As the controller must wait for all replicas to delete their local
> partitions, deletes can also become blocked, preventing topics from being
> created with the same name until the deletion is complete on all replicas.
> This can mean that downtime for a single broker can effectively cause a
> complete outage for everyone producing/consuming to that topic name, as the
> topic cannot be recreated without manual intervention.
> Unique topic IDs could help address this issue by associating a unique ID
> with each topic, ensuring a newly created topic with a previously used name
> cannot be confused with a previous topic with that name.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
