...

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Describe the problems you are trying to solve.

Public Interfaces

Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.

A public interface is any change to the following:

• Binary log format

• The network protocol and api behavior

• Any class in the public packages under clientsConfiguration, especially client configuration

  • org/apache/kafka/common/serialization

  • org/apache/kafka/common

  • org/apache/kafka/common/errors

  • org/apache/kafka/clients/producer

  • org/apache/kafka/clients/consumer (eventually, once stable)

• Monitoring

• Command line tools and arguments

• Anything else that will likely break existing users in some way when they upgrade

Proposed Changes

...

As per the Tiered Storage feature introduced in KIP-405, the follower fetch protocol was modified for topics enabled with tiered storage. For such topics, the follower finds the offset and leader epoch, up to which the auxiliary state (i.e. leader epoch sequence, producer snapshot state) needs to be built from the leader. The follower then starts fetching the data from the leader starting from that offset. In the KIP, it was decided to use the local-log-start-offset as the offset for this purpose. Instead of the local-log-start-offset, we could also last-tiered-offset which would help the followers quickly catch up with the leader as it only needs to fetch the followers that are not moved to tiered storage. The disadvantage of using the last-tiered-offset is that this new follower would possess only a limited number of locally stored segments. Should it ascend to the role of leader, there is a risk of needing to fetch these segments from remote locations, potentially impacting broker performance.

There can be multiple ways to prevent such followers from transitioning to a leader role, such as having strict leader election criteria, wherein followers with limited locally stored segments are not allowed to become a leader, or having slightly relaxed criteria wherein other followers are preferred for leadership over this follower. Incorporating these preventing measures alongside the proposed utilization of last-tiered-offset can effectively balance the advantage of rapid follower synchronization and mitigate potential performance impacts on the broker, thereby optimizing the overall efficiency and reliability.

In this KIP, we will focus on the follower fetch using the last-tiered-offset.

Public Interfaces

Broker Configuration options

A new broker property will be added to enable/disable the feature of using last-tiered-offset in the follower fetch.

follower.fetch.last.tiered.offset.enable

• Type: Boolean
• Mode: Dynamically configurable as cluster-default for all brokers in the cluster.
• Description: Whether the last tiered offset should be used as the start offset for bootstrapping an empty follower
• Default value: False

Proposed Changes

The following diagram provides a visual representation of the leader topic partiton's log offsets.

Image Added

         Lx  = Local log start offset           L_z  = Local log end offset            L_y  = Last stable offset(LSO)

         R_y  = Remote log end offset / Last Tiered Offset      R_x  = Remote log start offset

    Lz >= Ly >= Lx and Ly >= Ry >= Rx

Let us quicky look at the current follower fetch protocol. An empty follower does the following:

• It starts with Fetch-Offset as 0 and requests data from this offset from the leader.
• The requested offset may or may not be a valid offset on the leader
  • Case 1: The requested offset is present on the leader
    • Leader responds with the data to the follower
    • Follower receives the data, appends records to the local disk, updates its Log-End-Offset and its Fetch-Offset
    • Follower requests data beginning from the new fetch offset
  • Case 2: The requested offset is not present on the leader. There are two possible scenarios here:
    • Case 2.1: The requested offset is lower than the earliest offset the leader knows
      • Leader response with OFFSET_OUT_OF_RANGE error
      • Follower fetches the earliest offset on the leader (Log-Start-Offset)
      • Follower updates its offsets
        • Log-Start-Offset → leader's Log-Start-Offset
        • Log-End-Offset → leader's Log-Start-Offset
        • Fetch-Offset → leader's Log-Start-Offset
      • Follower requests data from the new fetch offset.
    • Case 2.2: The requested offset is greater than or equal to the earliest offset the leader knows, but the offset has moved to tiered storage.
      • Leader responds with OFFSET_MOVED_TO_TIERED_STORAGE error (also returns its Log-Start-Offset)
      • Follower fetches the leader's Local-Log-Start-Offset
      • Follower builds the remote log auxiliary states for the leader offsets in the range [Log-Start-Offset,  Local-Log-Start-Offset]
      • Follower updates its offsets
        • Log-Start-Offset → Leader's Log-Start-Offset
        • Log-End-Offset → Leader's Local-Log-Start-Offset
        • Fetch-Offset → Leader's Local-Log-Start-Offset
      • Follower requests data from the new fetch offset.

We make the following changes to the follower-fetch protocol when the requested offset is not present on the leader (Case 2).

• Leader responds with either OFFSET_OUT_OF_RANGE or OFFSET_MOVED_TO_TIERED_STORAGE error
• Follower fetches the earliest offset on the leader (Log-Start-Offset), if not available in the leader response
• Follower fetches the last tierd offset on the leader (Last-Tiered-Offset)
• Follwer builds the remote log auxiliary states for the leader offsets in the range [Log-Start-Offset, Last-Tiered-Offset]
• Follower updates its offsets
  • Log-Start-Offset → Leader's Log-Start-Offset
  • Log-End-Offset → Last-Tiered-Offset + 1
  • Fetch-Offset → Last-Tiered-Offset + 1
• Follower requests data from the new fetch offset.

We shall also add a new API for the follower to be able to fetch the last-tiered-offset from the leader. The leader already keeps track of the highest offset that has been uploaded to the remote storage.

• The RLM task on the leader runs at frequent intervals to find new log segments that have become eligible for upload.
• When the task uploads a segment, it also updates the highest offset which has been uploaded to the remote storage.
• If the leader is newly elected, it may not have this information yet and will learn about the highest offset on remote only when a new segment is uploaded.
• We will modify the RLM task behaviour to update the highest offset information even if there are no new segments to upload. This ensures that the RLM task has this information ready even it is not able to find new segments eligible for upload.
• The new API returns the highest offset on the remote as the response to fetch last-tiered-offset

Compatibility, Deprecation, and Migration Plan

...