Page History

...

• High Watermark.

  • In ISR, each server maintains a high watermark, which represents the highest offset of the replicated log known to be committed / durably stored.

  • Also, for consumers, only the message above the High Watermark is visible to them.

• Ack=1/all produce request. It defines when the Kafka server should respond to the produce request.

  • For ack=1 requests, the server should respond when the message is persisted in the leader’s local log.

  • For ack=all requests, the server should respond when the message is persisted in all the ISR members' local log and the size of the ISR member is larger than min ISR.

In order to have a message sent to the server being available for a consumer to fetch, there are 2 main steps. First, the produce request has to be acked by the server. This can be controlled by the produce request's ack requirement. Second, the replication is good enough to advance the HWM above the message. Notably, in the current system, min ISR is a factor only useful when accepting an ack=all request. It has no use in accepting ack=1 requests and the HWM advancement. This behavior complicates the durability model in a mixed type of requests workload.

We mostly want While we are seeking a solution to enhance the durability of the ack=all requests. In the scenario raised in the motivation section, the server may receive both ack=1 and ack=all messages , we are encountering difficulties in avoiding interference with the ack=1 messages. In the scenario raised in the motivation section, the server may receive ack=1 messages during T1 and advance High Watermark when during T1. During this period, the server will reject the ack=all requests due to not enough replicas to meet the min ISR, but it accepts the ack=1 requests. Also, because the leader is the only one in the ISR. Then, if we elect , it is allowed to advance the HWM to the end of its log. Let's say there is some extra info somewhere to let the controller choose broker 1 as the leader at T4 , though we can guarantee the safety of instead. Then there is no data loss for the ack=all messagesrequests, the High Watermark may move backward which causes further impacts on but the HWM stored on broker 1 is lower than broker 2. This can cause HWM to move backward and impacts the consumers.

To avoid the ack=1 message interference, we propose to enforce that High Watermark can only advance if the ISR size is larger or equal to min.insync.replicas. Here are some clarifications:

...

{
  "apiKey":69,
  "type": "request",
  "listeners": ["controllerbroker"],
  "name": "DescribeTopicRequest",
  "validVersions": "0",
  "flexibleVersions": "0+",
  "fields": [
    { "name": "Topics", "type": "[]DescribeTopicResponseTopic", "versions": "0+",
      "about": "The topics to fetch details for.", "fields": [
      { "name": "TopicId", "type": "uuid", "versions": "0+", "ignorable": true, "about": "The topic id." },
      { "name": "Name", "type": "string", "versions": "0+", "entityType": "topicName", "nullableVersions": "0+",
        "about": "The topic name." }
    ]}
]
}

...