[
https://issues.apache.org/jira/browse/KAFKA-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731629#comment-14731629
]
Gwen Shapira commented on KAFKA-2510:
-------------------------------------
[~jkreps] I agree that this capability is important to some uses cases.
I also think that preventing sysadmins from accidentally losing data on an
entire cluster can be an important thing to support.
Which is why I think it should be configurable (like delete.topic.enable and
unsafe.leader.election) - there are legit tradeoffs.
> Prevent broker from re-replicating / losing data due to disk misconfiguration
> -----------------------------------------------------------------------------
>
> Key: KAFKA-2510
> URL: https://issues.apache.org/jira/browse/KAFKA-2510
> Project: Kafka
> Issue Type: Bug
> Reporter: Gwen Shapira
>
> Currently Kafka assumes that whatever it sees in the data directory is the
> correct state of the data.
> This means that if an admin mistakenly configures Chef to use wrong data
> directory, one of the following can happen:
> 1. The broker will replicate a bunch of partitions and take over the network
> 2. If you did this to enough brokers, you can lose entire topics and
> partitions.
> We have information about existing topics, partitions and their ISR in
> zookeeper.
> We need a mode in which if a broker starts, is in ISR for a partition and
> doesn't have any data or directory for the partition, the broker will issue a
> huge ERROR in the log and refuse to do anything for the partition.
> [~fpj] worked on the problem for ZK and had some ideas on what is required
> here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
