Hello James, Many thanks for your quick response and pointing out the associated JIRA.
Happy to dig a bit on the function paths affected by a consistency check on these parameters, as explained in the ticket, and see what could be done (or not). Thanks, Alexandre Le mer. 14 août 2019 à 06:11, James Cheng <wushuja...@gmail.com> a écrit : > Alexandre, > > You are right that this is a problem. There is a JIRA on this from a while > back. > > https://issues.apache.org/jira/plugins/servlet/mobile#issue/KAFKA-4680 > > I don’t think anyone is currently working on it right now. > > -James > > Sent from my iPhone > > > On Aug 13, 2019, at 1:17 AM, Alexandre Dupriez < > alexandre.dupr...@gmail.com> wrote: > > > > Hello all, > > > > We run into a scenario where we had misconfigured the replication factor > > and the minimum in-sync replicas count in such a way that the replication > > factor (either default or defined at the topic level) is strictly lower > > than the property min.insync.replicas. > > > > We observed broker metrics reporting UnderReplicatedPartitions = 0 and > > UnderMinPartitionIsrCount > 0, and the topic’s partitions were > unavailable > > for producers (with ack=all) and consumers. > > > > Since it seems to be impossible in this scenario to ever reach the number > > of in-sync replicas, making partitions permanently unavailable, it could > be > > worth to prevent this misconfiguration to make its way to the broker, > e.g. > > a check could be added when a topic is created to ensure the replication > > factor is greater than or equals to the minimum number of in-sync > replicas. > > > > I may have missed something though. What do you think? > > > > Thank you, > > Alexandre >
