[ https://issues.apache.org/jira/browse/KAFKA-9166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colin McCabe resolved KAFKA-9166. --------------------------------- Fix Version/s: 2.8.0 Resolution: Duplicate Closing as duplicate of KAFKA-10435 > Implement MetadataFetch API > --------------------------- > > Key: KAFKA-9166 > URL: https://issues.apache.org/jira/browse/KAFKA-9166 > Project: Kafka > Issue Type: Sub-task > Components: controller > Reporter: Viktor Somogyi-Vass > Assignee: Colin McCabe > Priority: Major > Fix For: 2.8.0 > > > Brief description of the ask is mentioned in KIP-500's > [BrokerMetadataManagement|https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum#KIP-500:ReplaceZooKeeperwithaSelf-ManagedMetadataQuorum-BrokerMetadataManagement] > Instead of the controller pushing out updates to the other brokers, those > brokers will fetch updates from the active controller via the new > MetadataFetch API. > A MetadataFetch is similar to a fetch request. Just like with a fetch > request, the broker will track the offset of the last updates it fetched, and > only request newer updates from the active controller. > The broker will persist the metadata it fetched to disk. This will allow the > broker to start up very quickly, even if there are hundreds of thousands or > even millions of partitions. (Note that since this persistence is an > optimization, we can leave it out of the first version, if it makes > development easier.) > Most of the time, the broker should only need to fetch the deltas, not the > full state. However, if the broker is too far behind the active controller, > or if the broker has no cached metadata at all, the controller will send a > full metadata image rather than a series of deltas. -- This message was sent by Atlassian Jira (v8.3.4#803005)