You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Jay Kreps (JIRA)" <ji...@apache.org> on 2015/02/08 00:17:34 UTC
[jira] [Resolved] (KAFKA-1050) Support for "no data loss" mode
[ https://issues.apache.org/jira/browse/KAFKA-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jay Kreps resolved KAFKA-1050.
------------------------------
Resolution: Fixed
I think both of these are done on other tickets.
> Support for "no data loss" mode
> -------------------------------
>
> Key: KAFKA-1050
> URL: https://issues.apache.org/jira/browse/KAFKA-1050
> Project: Kafka
> Issue Type: Task
> Reporter: Justin SB
> Assignee: Neha Narkhede
>
> I'd love to use Apache Kafka, but for my application data loss is not acceptable. Even at the expense of availability (i.e. I need C not A in CAP).
> I think there are two things that I need to change to get a quorum model:
> 1) Make sure I set request.required.acks to 2 (for a 3 node cluster) or 3 (for a 5 node cluster) on every request, so that I can only write if a quorum is active.
> 2) Prevent the behaviour where a non-ISR can become the leader if all ISRs die. I think this is as easy as tweaking core/src/main/scala/kafka/controller/PartitionLeaderSelector.scala, essentially to throw an exception around line 64 in the "data loss" case.
> I haven't yet implemented / tested this. I'd love to get some input from the Kafka-experts on whether my plan is:
> (a) correct - will this work?
> (b) complete - have I missed any cases?
> (c) recommended - is this a terrible idea :-)
> Thanks for any pointers!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)