[
https://issues.apache.org/jira/browse/KAFKA-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133838#comment-15133838
]
Arkadiusz Firus commented on KAFKA-3206:
----------------------------------------
[~xiaotao183] The "unclean.leader.election.enable" property was not set, which
means it had default value - true. But the documentation does not say a word
that not setting this property can lead to inconsistent state between nodes. In
my humble opinion, when a node is becoming available it should synchronized its
state with the current leader.
I do not expect that Kafka do not loose any records during partitioning
(according to CAP theorem we need to choose availability or consistency) but
when everything backs to normal (which means all nodes are up) the state should
be reconsolidated.
> No reconsiliation after partitioning
> ------------------------------------
>
> Key: KAFKA-3206
> URL: https://issues.apache.org/jira/browse/KAFKA-3206
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 0.9.0.0
> Reporter: Arkadiusz Firus
>
> Kafka topic partition could be in an inconsistent state where two nodes see
> different partition state.
> Steps to reproduce the problem:
> 1. Create topic with one partition and replication factor 2
> 2. Stop one of the Kafka nodes where that partition resides
> 3. Send following messages to that topic:
> ABC
> BCD
> CDE
> 3. Stop the other Kafka node
> Currently none of the nodes should be running
> 4. Start first Kafka node - this node has no records
> 5. Send following records to the topic:
> 123
> 234
> 345
> 6. Start the other Kafka node
> The reconciliation should happen here but it does not.
> 7. When you read the topic you will see
> 123
> 234
> 345
> 8. When you stop the first node and read the topic you will see
> ABC
> BCD
> CDE
> This means that the partition is in inconsistent state.
> If you have any questions please feel free to e-mail me.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
