anchor.diff:  ----
   
   *Do not reduce these settings in production.*
  -You can increase the settings in production.
  -If you are testing in a single broker environment, you might want to reduce the settings as an exception.
  +You can increase the settings in a _production_ environment.
  +As an exception, you might want to reduce the settings in a single-broker _test_ environment.
   
   == Improving request handling throughput by increasing I/O threads
   
  
positive.code: [source,env]
  ----
  # ...
  log.cleaner.io.max.bytes.per.second= 1.7976931348623157E308
  # ...
  ----
  
  
negative.code: #...
  ----
  
  The percentage leader imbalance for a broker is the ratio between the current number of partitions for which the broker is the current leader and the number of partitions for which it is the preferred leader.
  You can set the percentage to zero to ensure that preferred leaders are always elected, assuming they are in sync.
  
  If the checks for rebalances need more control, you can disable automated rebalances. You can then choose when to trigger a rebalance using the `kafka-leader-election.sh` command line tool.
  
  NOTE: The Grafana dashboards provided with Strimzi show metrics for under-replicated partitions and partitions that do not have an active leader.
  
  [id='con-broker-config-properties-unclean-{context}']
  == Unclean leader election
  
  Leader election to an in-sync replica is considered clean because it guarantees no loss of data. And this is what happens by default.
  But what if there is no in-sync replica to take on leadership? Perhaps the ISR (in-sync replica) only contained the leader when the leader's disk died. If a minimum number of in-sync replicas is not set, and there are no followers in sync with the partition leader when its hard drive fails irrevocably, data is already lost.
  Not only that, but _a new leader cannot be elected_ because there are no in-sync followers.
  
  You can configure how Kafka handles leader failure:
  
  