THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Today, Kafka uniquely identifies a topic by its name. This is generally sufficient , but however there are flaws in with this scheme if when a topic is deleted and recreated with the same name. Kafka currently attempts to prevent issues resulting from stale topics by ensuring a topic is fully deleted from all replicas before completing a deletion. This solution is imperfect, as it is possible for partitions to be reassigned away from brokers while they are down , and there are no guarantees that this state will ever be cleaned up.
When a topic deletion is performed , the controller must wait for all brokers to delete their local replicas. This blocks creation of a topic with the same name as a deleted topic until all replicas have successfully deleted the topic's data. 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 if a topic cannot be recreated without manual intervention.
...
No changes to public interfaces will be made in this release. However, it may be dangerous to use older versions of Kafka tools with new broker versions when using their --zookeeper flags. Use of older tools in this way is not supported today.
Proposed Changes
Topic IDs will be represented using with 64 bit v4 UUIDs. A UUID with all bits as 0 will be reserved as a null UUID as the Kafka RPC protocol does not allow for nullable fields. When printed or stored as a string, topic IDs will be converted to base64 string representation.
...
| value | enum | description |
|---|---|---|
| 0 | UNSPECIFIED | Unspecified type. Default Defaults to incremental / previous behavior. |
| 1 | INCREMENTAL | A LeaderAndIsrRequest that is not guaranteed to contain all topic partitions assigned to a broker. |
2 | FULL | A full LeaderAndIsrRequest containing all partitions the broker is a replica for. |
When type = FULL, the broker can is able to reconcile its local state on disk with the request. Any partition not contained in this request and present on local disk can be staged for deletion. There are two such types of stale request.
...
Reconciliation may also be necessary if type = INCREMENTAL and the topic ID set on a local partition does not match the topic ID contained in the request. A TopicPartition with the same name and a different topic ID by implies that the local topic partition is stale, as the topic must have been deleted to create a new topic with a different topic ID.
When type = UNSPECIFIED, the request will be treated in a way that allows for backwards compatibility with older request types.
Deletion
Deletion of stale partitions triggered by LeaderAndIsrRequest(s) will take place by:
...
To avoid issues where requests are made to stale partitions, a topic_id field will be added to fence reads from deleted topics. Note that the leader epoch is not sufficient for preventing these issues, as the partition leader epoch is reset when a topic is deleted and recreated.
...