anchor.diff:  For high availability environments, it is advisable to increase the replication factor to at least 3 for topics and set the minimum number of in-sync replicas required to 1 less than the replication factor.
   For topics created using the `KafkaTopic` resource, the replication factor is set using `spec.replicas`.
   
  -For xref:data_durability[data durability], you should also set `min.insync.replicas` in your topic configuration and message delivery acknowledgments using `acks=all` in your producer configuration.
  +For xref:data_durability[data durability], you should also set `min.insync.replicas` in your _topic_ configuration and message delivery acknowledgments using `acks=all` in your _producer_ configuration.
   
   Use `replica.fetch.max.bytes` to set the maximum size, in bytes, of messages fetched by each follower that replicates the leader partition.
  -Change this value according to the average message size and throughput. When considering the total memory allocation required for read/write buffering, the memory available must also be able to accommodate the maximum replicated message size when multiplied by all followers. The size must also be greater than `message.max.bytes`, so that all messages can be replicated.
  -
  -In a production environment, to avoid accidental topic deletion resulting in data loss you can also disable deletion. You can temporarily enable it, delete topics and then disable it again.
  -If you wish to delete topics using the `KafkaTopic` resource, make sure that `delete.topic.enable` is enabled.
  +Change this value according to the average message size and throughput. When considering the total memory allocation required for read/write buffering, the memory available must also be able to accommodate the maximum replicated message size when multiplied by all followers.
  +
  +The `delete.topic.enable` property is enabled by default to allow topics to be deleted.
  +In a production environment, you should disable this property to avoid accidental topic deletion, resulting in data loss.
  +You can, however, temporarily enable it and delete topics and then disable it again.
  +If `delete.topic.enable` is enabled, you can delete topics using the `KafkaTopic` resource.
   
   [source,env]
   ----
  
positive.code: 
  == Managing logs with data retention policies
  
  Kafka uses logs to store message data. Logs are a series of segments.
  New messages are written to an _active_ segment, and never subsequently modified.
  The active segment is also read when serving fetch requests from consumers.
  Periodically, the active segment is _rolled_ to become read-only and a new active segment is created to replace it.
  There is only a single segment active at a time.
  Older segments are retained until they are eligible for deletion.
  
negative.code: Otherwise, if the log cleaner is not enabled, and there are no log retention limits, the log will continue to grow.
  
  If cleanup policy is set for log compaction, the _head_ of the log operates as a standard Kafka log, with writes for new messages appended in order.
  In the _tail_ of a compacted log, where the log cleaner operates, records will be deleted if another record with the same key occurs later in the log.
  Messages with null values are also deleted.
  If you're not using keys, you can't use compaction because keys are needed to identify related messages.
  While Kafka guarantees that the latest messages for each key will be retained, it does not guarantee that the whole compacted log will not contain duplicates.
  
  .Log showing key value writes with offset positions before compaction
  image::tuning/broker-tuning-compaction-before.png[Image of compaction showing key value writes]
  
  Using keys to identify messages, Kafka compaction keeps the latest message (with the highest offset) for a specific message key, eventually discarding earlier messages that have the same key.
  In other words, the message in its latest state is always available and any out-of-date records of that particular message are eventually removed when the log cleaner runs.
  You can restore a message back to a previous state.
  
  Records retain their original offsets even when surrounding records get deleted.
  Consequently, the tail can have non-contiguous offsets.
  When consuming an offset that's no longer available in the tail, the record with the next higher offset is found.
  
  .Log after compaction
  image::tuning/broker-tuning-compaction-after.png[Image of compaction after log cleanup]
  