[
https://issues.apache.org/jira/browse/ZOOKEEPER-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-313:
-----------------------------------
Fix Version/s: 3.1.1
> 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
> 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.
