Skip to content

Commit 8d3ee2f

Browse files
committed
edits from Matt's review
1 parent 954b6e7 commit 8d3ee2f

File tree

1 file changed

+17
-15
lines changed

1 file changed

+17
-15
lines changed

modules/get-started/pages/whats-new.adoc

Lines changed: 17 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -7,17 +7,21 @@ This topic includes new content added in version {page-component-version}. For a
77
* xref:redpanda-cloud:get-started:whats-new-cloud.adoc[]
88
* xref:redpanda-cloud:get-started:cloud-overview.adoc#redpanda-cloud-vs-self-managed-feature-compatibility[Redpanda Cloud vs Self-Managed feature compatibility]
99
10-
== Tombstone removal
10+
== Leader pinning
1111

12-
Redpanda now supports the Kafka `delete.retention.ms` topic configuration. You can specify how long Redpanda keeps xref:manage:cluster-maintenance/compaction-settings.adoc#tombstone-record-removal[tombstone records] for compacted topics by setting `delete.retention.ms` at the topic level, or `tombstone_retention_ms` at the cluster level.
12+
For a Redpanda cluster deployed across multiple availability zones (AZs), xref:develop:produce-data/leader-pinning.adoc[leader pinning] ensures that a topic's partition leaders are geographically closer to clients. Leader pinning can lower networking costs and help guarantee lower latency by routing produce and consume requests to brokers located in certain AZs.
1313

1414
== Mountable topics
1515

1616
For topics with Tiered Storage enabled, you can unmount a topic to safely detach it from a cluster and keep the topic data in the cluster's object storage bucket or container. You can mount the detached topic to either the same origin cluster, or a different one. This allows you to hibernate a topic and free up system resources taken up by the topic, or migrate a topic to a different cluster. See xref:manage:mountable-topics.adoc[Mountable topics] for details.
1717

18-
== Leader pinning
18+
== Intra-broker partition balancing
1919

20-
For a Redpanda cluster deployed across multiple availability zones (AZs), xref:develop:produce-data/leader-pinning.adoc[leader pinning] ensures that a topic's partition leaders are geographically closer to clients. Leader pinning can lower networking costs and help guarantee lower latency by routing produce and consume requests to brokers located in certain AZs.
20+
xref:manage:cluster-maintenance/cluster-balancing.adoc#intra-broker-partition-balancing[Intra-broker partition balancing], which balances partitions across cores within a Redpanda broker, has moved out of beta and is supported for production clusters.
21+
22+
== Tombstone removal
23+
24+
Redpanda now supports the Kafka `delete.retention.ms` topic configuration. You can specify how long Redpanda keeps xref:manage:cluster-maintenance/compaction-settings.adoc#tombstone-record-removal[tombstone records] for compacted topics by setting `delete.retention.ms` at the topic level, or `tombstone_retention_ms` at the cluster level.
2125

2226
== Debug bundles in Redpanda Console
2327

@@ -33,6 +37,14 @@ Redpanda now supports declarative management of users and access control lists (
3337

3438
To learn more, see the xref:manage:kubernetes/security/authentication/k-user-controller.adoc[User custom resource documentation].
3539

40+
== Backfill partitions
41+
42+
When running xref:manage:cluster-maintenance/nodewise-partition-recovery.adoc[node-wise partition recovery], it's possible that there may be more recent data (a higher offset) available in Tiered Storage. Redpanda attempts to recover partition data from object storage, recovering the latest offset available for a partition in either storage tier (local or object storage). This allows for the maximum amount of data to be recovered in all cases, even for topics with a replication factor of 1, where no replicas remain in local storage.
43+
44+
== Configure access to object storage with a KMS key
45+
46+
Users on AWS or GCP with strict data compliance requirements can manage and store encryption keys separately from their cloud provider with a xref:manage:tiered-storage.adoc#configure-object-storage[customer-managed Key Management Service (KMS) key].
47+
3648
== Licensing updates
3749

3850
This release includes several updates to xref:get-started:licensing/overview.adoc[Redpanda's licensing system] to both improve transparency and make it easier to manage licenses across Redpanda clusters and Redpanda Console.
@@ -45,17 +57,7 @@ This release includes several updates to xref:get-started:licensing/overview.ado
4557

4658
- *Unified license management in Redpanda Console*: You can now upload and apply a single license key for both Redpanda Console and the connected Redpanda cluster through the Redpanda Console UI. Any existing license key is overridden by the new one.
4759

48-
== Backfill partitions
49-
50-
When running xref:manage:cluster-maintenance/nodewise-partition-recovery.adoc[node-wise partition recovery], it's possible that there may be more recent data (a higher offset) available in Tiered Storage. Redpanda attempts to recover partition data from object storage, recovering the latest offset available for a partition in either storage tier (local or object storage). This allows for the maximum amount of data to be recovered in all cases, even for topics with a replication factor of 1, where no replicas remain in local storage.
51-
52-
== Configure access to object storage with a KMS key
53-
54-
Users on AWS or GCP with strict data compliance requirements can manage and store encryption keys separately from their cloud provider with a xref:manage:tiered-storage.adoc#configure-object-storage[customer-managed Key Management Service (KMS) key].
55-
56-
== Intra-broker partition balancing
57-
58-
xref:manage:cluster-maintenance/cluster-balancing.adoc#intra-broker-partition-balancing[Intra-broker partition balancing], which balances partitions across cores within a Redpanda broker, has moved out of beta and is supported for production clusters.
60+
- *30 day trial Enterprise license*: Starting with version 24.3, new Redpanda clusters automatically receive a trial license that's valid for 30 days, allowing unrestricted use of Enterprise features. This evaluation period begins when the cluster is created for the first time. After this period expires, inactive Enterprise features are disabled, and active features enter a restricted state.
5961

6062
== New commands
6163

0 commit comments

Comments
 (0)