[
https://issues.apache.org/jira/browse/KAFKA-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534928#comment-16534928
]
Randall Hauch commented on KAFKA-7138:
--------------------------------------
Up to this point we've always made the defaults reflect a production value,
since we have had people that don't change the defaults and get into trouble in
production usage. We already have a number of replication factor settings, and
they all default to '3', and IMO we need to be consistent.
What we probably should do is to include more commented out properties w/
comments in the configurations or, as with the other replication factor
properties, set them to 1 in the properties files and include a comment that
they should be changed to at least '3' for production usage.
Ideally, we might consider introducing separate development or quickstart
oriented properties files that are good to use for minimal clusters that devs
typically run locally, and then change the existing files to be more
production-oriented -- tho the latter means we'd have to change system tests to
use the quickstart-oriented config files.
> Kafka Connect - Make errors.deadletterqueue.topic.replication.factor default
> consistent
> ---------------------------------------------------------------------------------------
>
> Key: KAFKA-7138
> URL: https://issues.apache.org/jira/browse/KAFKA-7138
> Project: Kafka
> Issue Type: Bug
> Reporter: Robin Moffatt
> Priority: Minor
>
> {{errors.deadletterqueue.topic.replication.factor}} defaults to RF 3
> The standard out of the box config files override the RF for
> {{offset.storage.replication.factor}} (and {{config}} and {{status}}) to 1
> To make the experience consistent for users (especially new users, running a
> single-node dev environment), the default RF in effect for
> {{errors.deadletterqueue.topic.replication.factor}} should also be 1.
> It would make it easier for devs getting started on single-node setups.
> For prod people should be actively configuring this stuff anyway, this would
> get included in that.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
