[ https://issues.apache.org/jira/browse/KAFKA-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959266#comment-14959266 ]
Joel Koshy commented on KAFKA-2017: ----------------------------------- bq. But if we really want to have group metadata persisted in 0.9 and don't want to miss the planned release again. Yes I think we definitely need it in 0.9 - so if people really think it is expedient and less prone to error to do it in ZK then maybe that is what we should do but I'm not sure if everyone is convinced about that. I don't think migration will be painful since it is all server-side - although for a dual-write migration scheme to work you would need some sequence number as well in each persisted state entry (e.g., for offsets we use the offset itself) in order to decide which one is more recent. > 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)