[ https://issues.apache.org/jira/browse/ZOOKEEPER-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar resolved ZOOKEEPER-313. ------------------------------------- Resolution: Duplicate Assignee: Mahadev konar sunanda, i am makring this as a duplicate of ZOOKEEPER-251. I have openened ZOOKEEPER-335 for logging the new leader election txn. Please feel free to reopen if that is not the case. > Problem with successive leader failures when no client is connected > -------------------------------------------------------------------- > > Key: ZOOKEEPER-313 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-313 > Project: Zookeeper > Issue Type: Bug > Components: server > Affects Versions: 3.0.0, 3.0.1 > Environment: all > Reporter: Sunanda Bera > Assignee: Mahadev konar > Fix For: 3.1.1 > > > Steps to reproduce: > Create a 3 node cluster . Run some transactions and then stop all clients. > Make sure no other clients connect for the duration of the test. > Let L1 be the current leader. Bring down L1. Let L2 be the leader chosen. > Let the third node be N3. Note that this will increase the txn id for N3's > snapshot without any transaction being logged. Now bring up L1 -- same will > happen for L1. Now bring down L2. > Both N3 and L1 now have snapshots with a transaction id greater than the last > logged transaction. Whoever is elected leader will try to restore its state > from the filesystem and fail. > One easy workaround is obviously to change the FileTxnSnapLog not to save a > snapshot if zxid > last logged zxid. The correct solution is possibly to log > a transaction for leader election as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.