I have a use case that requires a 2 node deployment with a Kafka-backed service with the following constraints:
- All data must be persisted to node 1. If node 1 fails (regardless of the status of node 2), then the system must stop. - If node 2 is up, then it must stay in synch with node 1. - If node 2 fails, then service must not be disrupted, but as soon as it comes back up and rejoins ISR it must stay in synch. The deployment is basically a primary node and a cold node with real time replication, but no failover to the cold node. To achieve this I am considering adding a broker-level configuration option that would prevent a broker from becoming a leader for any topic partition it hosts - this would allow me to enforce that the cold node never take leadership for any topics. In conjunction with manipulating a topic's "min.insync.replicas" setting at runtime, I should be able to achieve the behavior desired (2 if both brokers up, 1 if the standby goes down). I know this sounds like an edgy use case, but does this sound like a reasonable approach? Are there any valid use cases around such a broker or topic level configuration (i.e. does this sound like a feature that would make sense to open a KIP against)?
