[
https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14964225#comment-14964225
]
Guozhang Wang commented on KAFKA-2017:
--------------------------------------
Another point worth considering is that for operations do we want to add the
ability in admin tools to query consumer assignment in addition to consumer
group metadata. Today the coordinator has to remember both of them in memory to
handle consumer requests, but we can probably clean it to reduce footprint
after the rebalance has full settled. But if we want to ad, for example, a
consumer group metadata request to return the group membership info as well as
the assignment for admin tools, then we may need to keep it in memory, and
moving forward on persistent storage. And if this data becomes very large
enough then Kafka might be a better place than ZK.
> Persist Coordinator State for Coordinator Failover
> --------------------------------------------------
>
> Key: KAFKA-2017
> URL: https://issues.apache.org/jira/browse/KAFKA-2017
> Project: Kafka
> Issue Type: Sub-task
> Components: consumer
> Affects Versions: 0.9.0.0
> Reporter: Onur Karaman
> Assignee: Guozhang Wang
> Fix For: 0.9.0.0
>
> Attachments: KAFKA-2017.patch, KAFKA-2017_2015-05-20_09:13:39.patch,
> KAFKA-2017_2015-05-21_19:02:47.patch
>
>
> When a coordinator fails, the group membership protocol tries to failover to
> a new coordinator without forcing all the consumers rejoin their groups. This
> is possible if the coordinator persists its state so that the state can be
> transferred during coordinator failover. This state consists of most of the
> information in GroupRegistry and ConsumerRegistry.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
