-
Notifications
You must be signed in to change notification settings - Fork 51
docs: 26.2 What's New entries for shipped features (DOC-2395) #1828
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: beta
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27,12 +27,42 @@ Redpanda can now export a cluster health summary as Prometheus metrics, so you c | |
|
|
||
| To enable them, set xref:reference:properties/cluster-properties.adoc#health_monitor_metrics_enabled[`health_monitor_metrics_enabled`] to `true` and restart your brokers. See xref:manage:monitoring.adoc#cluster-health[Cluster health] for the available metrics and query patterns. | ||
|
|
||
| == Shadowing: migrate schemas from Confluent Schema Registry | ||
|
|
||
| Shadowing can now replicate schemas over the Schema Registry HTTP API, including from a Confluent Schema Registry. A shadow link continuously replicates subjects, versions, and compatibility settings into the shadow cluster's Schema Registry, so your applications keep working after cutover without a separate schema migration step. You can also replicate only selected contexts or subjects, and map source contexts to different destination contexts. | ||
|
|
||
| See xref:manage:disaster-recovery/shadowing/migrate-schemas-confluent.adoc[Migrate Schemas from Confluent]. | ||
|
|
||
| == Shadowing: role synchronization | ||
|
|
||
| Shadow links can now replicate RBAC roles from the source cluster to the shadow cluster, alongside topics, ACLs, consumer group offsets, and Schema Registry data. Configure role filters to select which roles to sync, so authorization is already in place on the shadow cluster when you fail over. | ||
|
|
||
| See xref:manage:disaster-recovery/shadowing/setup.adoc#role-filtering[Configure Shadowing]. | ||
|
|
||
| == Kafka 4.x client compatibility | ||
|
|
||
| Redpanda version 26.2 validates a broader set of non-Java Apache Kafka® clients at their current versions that support Kafka 4.x, in addition to the Apache Kafka Java client. Newly validated clients include `confluent-kafka-go` and Sarama for Go, and `kafka-python` and `confluent-kafka-python` for Python. Validation confirms connectivity and correctness across core Kafka APIs, such as produce, consume, and transaction operations. | ||
|
|
||
| See xref:develop:kafka-clients.adoc[Kafka Compatibility] for the full list of validated clients and known exceptions. | ||
|
|
||
| == Fetch read coalescing | ||
|
|
||
| When many consumers fetch the same partitions, each broker repeats the same read work for every consumer. Fetch read coalescing merges these redundant reads on each shard, reducing read CPU and fetch-response memory under high consumer fan-out. This Enterprise feature is disabled by default: enable it with the `kafka_fetch_read_coalescing_enabled` cluster property. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 'memory consumption'
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ^^ Not sure where this applies @mattschumpert ? Do you want the heading revised here on line 30? Seems unrelated. |
||
|
|
||
| See xref:manage:cluster-maintenance/fetch-read-coalescing.adoc[Fetch Read Coalescing]. | ||
|
|
||
| == Per-entity client quota metrics | ||
|
|
||
| Aggregate quota metrics can confirm that throttling is happening, but not which client is throttled. Redpanda can now label throttle-time and throughput metrics with the identity of the throttled entity, so you can identify throttled clients by name and right-size quota values based on observed use. These metrics are disabled by default: enable them with the `kafka_per_entity_quota_metrics` cluster property. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "Aggregate quota metrics can confirm that throttling is happening at a broker level, but don't reveal which user, client, or group of clients is utilizing a quota, and/or being throttled. Redpanda can now label throttle-time and throughput metrics with the identity of the throttled entity, so you can identify throttled users and clients by name and right-size quota values based on observed use. These metrics are disabled by default: enable them with the (you may also want to update this language in the feature docs page @Feediver1 )
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same for this one @mattschumpert --which feature does this apply to? It's right after the Shadowing: role synchronization heading, but refers to metrics.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah--so it looks like it applies to == Per-entity client quota metrics below, on line 54. Right? |
||
|
|
||
| See xref:manage:cluster-maintenance/manage-throughput.adoc#track-quota-use-per-entity[Manage Throughput]. | ||
|
|
||
| == Cloud Topics enabled by default | ||
|
|
||
| Cloud Topics no longer require a separate cluster property. When cloud storage is enabled for your cluster (xref:reference:properties/object-storage-properties.adoc#cloud_storage_enabled[`cloud_storage_enabled`] set to `true`), you can create Cloud Topics directly. The `cloud_topics_enabled` cluster property is deprecated. | ||
|
|
||
| See xref:develop:manage-topics/cloud-topics.adoc[Manage Cloud Topics]. | ||
|
|
||
| == Tiered Storage v2 | ||
|
|
||
| Tiered Storage is now available in two versions. Tiered Storage v2 (`tiered_v2`) adds full compaction support for topics stored in object storage: compaction runs on the data in object storage rather than on local data only, eventually retains only the latest value for each key across the entire partition, and removes tombstone records after the retention period configured by `delete.retention.ms`. Topics using Tiered Storage v2 can also be converted to and from Cloud Topics. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Feediver1
Let's add "Both Confluent Cloud and Confluent Platform are supported"