Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Current state: Under Discussion

Discussion thread: TODO https://lists.apache.org/thread/ww67h9d4xvgw1f7jn4zxwydmt8x1mq72

JIRA

Jira
serverASF JIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId5aa69414-a9e9-3523-82ec-879b028fb15b
keyKAFKA-14286

...

Configuration

The property metadata.log.max.snapshot.interval.ms will be added to the Kafka server configuration. This is the maximum amount of time that Kafka will wait to generate a snapshot if there are records in the log that are not included in the latest snapshot. The default value for this property will be an hour. A value of zero, disables time based snapshot generation.

...

Both the KRaft brokers and controllers will generate a snapshot if there is a record in the log that is newer than the latest snapshot and has an append time older than metadata.log.max.snapshot.interval.ms milliseconds ago.

This change and implementation needs to consider the two existing reasons for generating a snapshot. First, KIP-630: Kafka Raft Snapshot added support for generating snapshots when there are metadata.log.max.record.bytes.between.snapshots bytes in the log that are not included in the latest snapshot. Second, KIP-778: KRaft to KRaft Upgrades added support for generating snapshot when the metadata version changes. If a snapshot is generated for any of these reasons, the counter for time-based and byte-based snapshots should be reset to avoid generating extra snapshots.

Compatibility, Deprecation, and Migration Plan

...

No alternative design or implementation where were considered.