diff --git a/modules/deploy/partials/high-availability.adoc b/modules/deploy/partials/high-availability.adoc index 5801bf4f76..c782271e3e 100644 --- a/modules/deploy/partials/high-availability.adoc +++ b/modules/deploy/partials/high-availability.adoc @@ -111,7 +111,7 @@ endif::[] A multi-region deployment is similar to a multi-AZ deployment, in that it needs at least three regions to counter the loss of a single region. Note that this deployment strategy increases latency due to the physical distance between regions. In addition to higher produce and end-to-end latency and increased costs, multi-region deployments require careful tuning. Redpanda recommends that you work closely with Redpanda’s Customer Success team when implementing a multi-region deployment. Also consider the following strategies to mitigate these challenges: -* Configure xref:develop:produce-data/leader-pinning.adoc#configure-leader-pinning[leader pinning] to ensure that topic partition leaders are geographically closer to clients. This can help lower network costs and latency by routing produce requests to brokers located in specific AZs. +* Configure xref:develop:produce-data/leader-pinning.adoc[leader pinning] to ensure that topic partition leaders are geographically closer to clients. This can help lower network costs and latency by routing produce requests to brokers located in specific AZs. * If your produce latency exceeds your requirements, you can configure producers to have `acks=1` instead of `acks=all`. This reduces latency by only waiting for the leader to acknowledge, rather than waiting for all brokers to respond. However, using this configuration can decrease message durability. If the partition leader goes offline, you may lose any messages that are acknowledged but not yet replicated. === Multi-cluster deployment diff --git a/modules/develop/pages/produce-data/leader-pinning.adoc b/modules/develop/pages/produce-data/leader-pinning.adoc index 2d88adab35..a3c4de5be4 100644 --- a/modules/develop/pages/produce-data/leader-pinning.adoc +++ b/modules/develop/pages/produce-data/leader-pinning.adoc @@ -1,10 +1,21 @@ -= Leader Pinning -:description: Learn about leader pinning and how to configure a preferred partition leader location based on cloud availability zones or regions. += Configure Leader Pinning +:description: Learn about Leader Pinning and how to configure a preferred partition leader location based on cloud availability zones or regions. +:page-topic-type: how-to +:personas: streaming_developer, platform_admin +:learning-objective-1: Configure preferred partition leader placement using rack labels +:learning-objective-2: Configure ordered rack preference for priority-based leader failover +:learning-objective-3: Identify conditions where Leader Pinning cannot place leaders in preferred racks // tag::single-source[] -Produce requests that write data to Redpanda topics go through the topic partition leader, which syncs messages across its follower replicas. For a Redpanda cluster deployed across multiple availability zones (AZs), leader pinning ensures that a topic's partition leaders are geographically closer to clients, which helps decrease networking costs and guarantees lower latency. +Produce requests that write data to Redpanda topics route through the topic partition leader, which syncs messages across its follower replicas. For a Redpanda cluster deployed across multiple availability zones (AZs), Leader Pinning ensures that a topic's partition leaders are geographically closer to clients, which helps decrease networking costs and guarantees lower latency. -If consumers are located in the same preferred region or AZ for leader pinning, and you have not set up xref:develop:consume-data/follower-fetching.adoc[follower fetching], leader pinning can also help reduce networking costs on consume requests. +If consumers are located in the same preferred region or AZ for Leader Pinning, and you have not set up xref:develop:consume-data/follower-fetching.adoc[follower fetching], Leader Pinning can also help reduce networking costs on consume requests. + +After reading this page, you will be able to: + +* [ ] {learning-objective-1} +* [ ] {learning-objective-2} +* [ ] {learning-objective-3} ifndef::env-cloud[] == Prerequisites @@ -14,61 +25,128 @@ ifndef::env-cloud[] include::shared:partial$enterprise-license.adoc[] ==== -Before you can enable leader pinning, you must xref:manage:rack-awareness.adoc#configure-rack-awareness[configure rack awareness] on the cluster. If the config_ref:enable_rack_awareness,true,properties/cluster-properties[] cluster configuration property is set to `false`, leader pinning is disabled across the cluster. +Before you can enable Leader Pinning, you must xref:manage:rack-awareness.adoc#configure-rack-awareness[configure rack awareness] on the cluster. If the config_ref:enable_rack_awareness,true,properties/cluster-properties[] cluster configuration property is set to `false`, Leader Pinning is disabled across the cluster. endif::[] ifndef::env-cloud[] -== Configure leader pinning +== Set leader rack preferences -You can use both a topic configuration property and a cluster configuration property to configure leader pinning. +You can use both a topic configuration property and a cluster configuration property to configure Leader Pinning. -You can set the topic configuration property for individual topics only, or set the cluster-wide configuration property that will enable leader pinning by default for all topics. You can also use a combination in which a default setting applies across the cluster, and you toggle the setting on or off for specific topics. +You can set the topic configuration property for individual topics only, or set the cluster-wide configuration property that enables Leader Pinning by default for all topics. You can also use a combination in which a default setting applies across the cluster, and you toggle the setting on or off for specific topics. This configuration is based on the following scenario: you have Redpanda deployed in a multi-AZ or multi-region cluster, and you have configured each broker so that the config_ref:rack,true,properties/broker-properties[] configuration property contains racks corresponding to the AZs: -* Set the topic configuration property xref:reference:properties/topic-properties.adoc#redpandaleaderspreference[`redpanda.leaders.preference`]. The property accepts the following string values: +* Set the topic configuration property xref:reference:properties/topic-properties.adoc#redpanda-leaders-preference[`redpanda.leaders.preference`]. The property accepts the following string values: + -- -** `none`: Opt out the topic from leader pinning. +** `none`: Disable Leader Pinning for the topic. ** `racks:[,,...]`: Specify the preferred location (rack) of all topic partition leaders. The list can contain one or more racks, and you can list the racks in any order. Spaces in the list are ignored, for example: `racks:rack1,rack2` and `racks: rack1, rack2` are equivalent. You cannot specify empty racks, for example: `racks: rack1,,rack2`. If you specify multiple racks, Redpanda tries to distribute the partition leader locations equally across brokers in these racks. +** `ordered_racks:[,,...]`: (Supported in Redpanda version 26.1 or later) Specify the preferred racks in priority order. Redpanda places leaders in the first listed rack when available, failing over to each subsequent rack when higher-priority racks are unavailable. If all listed racks are unavailable, leaders fall back to any other available brokers. Brokers with no rack assignment are treated as lowest priority. + -To find the rack identifier, run `rpk cluster info`. +Use `ordered_racks` for multi-region deployments with a primary region for leaders and explicit failover to a disaster recovery site. -- + This property inherits the default value from the cluster property `default_leaders_preference`. ++ +To find the rack identifiers of all brokers, run: ++ +[,bash] +---- +rpk cluster info +---- ++ +To set the topic property: ++ +[,bash] +---- +rpk topic alter-config --set redpanda.leaders.preference=ordered_racks:, +---- -* Set the cluster configuration property config_ref:default_leaders_preference,true,properties/cluster-properties[], which specifies the default leader pinning configuration for all topics that don’t have `redpanda.leaders.preference` explicitly set. It accepts values in the same format as `redpanda.leaders.preference`. Default: `none` +* Set the cluster configuration property config_ref:default_leaders_preference,true,properties/cluster-properties[], which specifies the default Leader Pinning configuration for all topics that don’t have `redpanda.leaders.preference` explicitly set. It accepts values in the same format as `redpanda.leaders.preference`. Default: `none` + This property also affects internal topics, such as `__consumer_offsets` and transaction coordinators. All offset tracking and transaction coordination requests get placed within the preferred regions or AZs for all clients, so you see end-to-end latency and networking cost benefits. ++ +To set the cluster property: ++ +[,bash] +---- +rpk cluster config set default_leaders_preference ordered_racks:, +---- -If there is more than one broker in the preferred AZ (or AZs), leader pinning distributes partition leaders uniformly across brokers in the AZ. +If there is more than one broker in the preferred AZ (or AZs), Leader Pinning distributes partition leaders uniformly across brokers in the AZ. endif::[] ifdef::env-cloud[] -== Configure leader pinning +== Set leader rack preferences -Configure leader pinning if you have Redpanda deployed in a multi-AZ or multi-region cluster and your ingress is concentrated in a particular AZ or region. +Configure Leader Pinning if you have Redpanda deployed in a multi-AZ or multi-region cluster and your ingress is concentrated in a particular AZ or region. -Use the topic configuration property `redpanda.leaders.preference` to configure leader pinning for individual topics. The property accepts the following string values: +Use the topic configuration property `redpanda.leaders.preference` to configure Leader Pinning for individual topics. The property accepts the following string values: -** `none`: Opt out the topic from leader pinning. +** `none`: Disable Leader Pinning for the topic. ** `racks:[,,...]`: Specify the preferred location (rack) of all topic partition leaders. The list can contain one or more racks, and you can list the racks in any order. Spaces in the list are ignored, for example: `racks:rack1,rack2` and `racks: rack1, rack2` are equivalent. You cannot specify empty racks, for example: `racks: rack1,,rack2`. If you specify multiple racks, Redpanda tries to distribute the partition leader locations equally across brokers in these racks. +** `ordered_racks:[,,...]`: (Supported in Redpanda version 26.1 or later) Specify the preferred racks in priority order. Redpanda places leaders in the first listed rack when available, failing over to each subsequent rack when higher-priority racks are unavailable. If all listed racks are unavailable, leaders fall back to any other available brokers. Brokers with no rack assignment are treated as lowest priority. ++ +To find the rack identifiers of all brokers, run: ++ +[,bash] +---- +rpk cluster info +---- ++ +To set the topic property: + -To find the rack identifier, run `rpk cluster info`. +[,bash] +---- +rpk topic alter-config --set redpanda.leaders.preference=ordered_racks:, +---- -If there is more than one broker in the preferred AZ (or AZs), leader pinning distributes partition leaders uniformly across brokers in the AZ. +If there is more than one broker in the preferred AZ (or AZs), Leader Pinning distributes partition leaders uniformly across brokers in the AZ. endif::[] -== Leader pinning failover across availability zones +== Limitations + +Leader Pinning controls which replica is elected as leader, and does not move replicas to different brokers. If all of a topic's replicas are on brokers in non-preferred racks, no replica exists in the preferred racks to elect as leader, and Redpanda may elect a non-preferred leader indefinitely. + +For example, consider a cluster deployed across four racks (A, B, C, D) with Leader Pinning configured as `ordered_racks:A,B,C,D`. With a replication factor of 3, rack awareness can only place replicas in three of the four racks. If the highest-priority rack (A) does not receive a replica, no replica exists there to elect as leader, and Redpanda may elect a non-preferred leader indefinitely. + +ifndef::env-cloud[] +To prevent this scenario: + +* Enable config_ref:enable_rack_awareness,true,properties/cluster-properties[`enable_rack_awareness`] to distribute replicas across racks automatically. +* Ensure the topic's replication factor at least equals the total number of racks in the cluster, so every rack, including the highest-priority rack, receives a replica. +* If needed, manually reassign replicas to ensure the highest-priority rack receives one. Note that the partition balancer may move replicas again after manual reassignment. + +endif::[] +ifdef::env-cloud[] +To prevent this scenario, ensure the topic's replication factor at least equals the total number of racks in the cluster, so every rack, including the highest-priority rack, receives a replica. + +endif::[] + +== Leader Pinning failover across availability zones + +If there are three AZs: A, B, and C, and A becomes unavailable, the failover behavior with `racks` is as follows: + +* A topic with `A` as the preferred leader AZ will have its partition leaders uniformly distributed across B and C. +* A topic with `A,B` as the preferred leader AZs will have its partition leaders in B. +* A topic with `B` as the preferred leader AZ will have its partition leaders in B as well. + +=== Failover with ordered rack preference + +With `ordered_racks`, the failover order follows the configured priority list. Leaders move to the next available rack in the list when higher-priority racks become unavailable. + +For a topic configured with `ordered_racks:A,B,C`: -If there are three AZs: A, B, and C, and A becomes unavailable, the failover behavior is as follows: +* A topic with `A` as the first-priority rack will have its partition leaders in A. +* If A becomes unavailable, leaders move to B. +* If A and B become unavailable, leaders move to C. +* If A, B, and C all become unavailable, leaders fall back to any available brokers. -* A topic with "A" as the preferred leader AZ will have its partition leaders uniformly distributed across B and C. -* A topic with "A,B" as the preferred leader AZs will have its partition leaders in B. -* A topic with “B” as the preferred leader AZ will have its partition leaders in B as well. +If a higher-priority rack recovers and the topic's replication factor ensures that rack receives a replica, Redpanda automatically moves leaders back to the highest available preferred rack. == Suggested reading diff --git a/modules/get-started/pages/release-notes/redpanda.adoc b/modules/get-started/pages/release-notes/redpanda.adoc index 34765f5ded..16805e4ded 100644 --- a/modules/get-started/pages/release-notes/redpanda.adoc +++ b/modules/get-started/pages/release-notes/redpanda.adoc @@ -7,171 +7,7 @@ This topic includes new content added in version {page-component-version}. For a * xref:redpanda-cloud:get-started:whats-new-cloud.adoc[] * xref:redpanda-cloud:get-started:cloud-overview.adoc#redpanda-cloud-vs-self-managed-feature-compatibility[Redpanda Cloud vs Self-Managed feature compatibility] -NOTE: Redpanda v25.3 introduces breaking schema changes for Iceberg topics. If you are using Iceberg topics and want to retain the data in the corresponding Iceberg tables, review xref:upgrade:iceberg-schema-changes-and-migration-guide.adoc[] before upgrading your cluster, and follow the required migration steps to avoid sending new records to a dead-letter queue table. +== Ordered rack preference for Leader Pinning -== Iceberg topics with GCP BigLake +xref:develop:produce-data/leader-pinning.adoc[Leader Pinning] now supports the `ordered_racks` configuration value, which lets you specify preferred racks in priority order. Unlike `racks`, which distributes leaders uniformly across all listed racks, `ordered_racks` places leaders in the highest-priority available rack and fails over to subsequent racks only when higher-priority racks become unavailable. -A new xref:manage:iceberg/iceberg-topics-gcp-biglake.adoc[REST catalog integration] with Google Cloud BigLake allows you to add Redpanda topics as Iceberg tables in your data lakehouse. - -See xref:manage:iceberg/use-iceberg-catalogs.adoc[] for details on configuring Iceberg REST catalog integrations with Redpanda. - -== Shadowing - -Redpanda v25.3 introduces xref:deploy:redpanda/manual/disaster-recovery/shadowing/index.adoc[], an enterprise-licensed disaster recovery solution that provides asynchronous, offset-preserving replication between distinct Redpanda clusters. Shadowing enables cross-region data protection by replicating topic data, configurations, consumer group offsets, ACLs, and Schema Registry data with byte-level fidelity. - -The shadow cluster operates in read-only mode while continuously receiving updates from the source cluster. During a disaster, you can failover individual topics or an entire shadow link to make resources fully writable for production traffic. See xref:deploy:redpanda/manual/disaster-recovery/shadowing/failover-runbook.adoc[] for emergency procedures. - -Shadowing includes comprehensive metrics for monitoring replication health. See xref:manage:disaster-recovery/shadowing/monitor.adoc[] and xref:reference:public-metrics-reference.adoc#shadow-link-metrics[Shadow Link metrics reference]. - -== Connected client monitoring - -You can view details about Kafka client connections using `rpk` or the Admin API ListKafkaConnections endpoint. This allows you to view detailed information about active client connections on a cluster, and identify and troubleshoot problematic clients. For more information, see the xref:manage:cluster-maintenance/manage-throughput.adoc#view-connected-client-details[connected client details] example in the Manage Throughput guide. - -== New Admin API style - -Redpanda v25.3 introduces a new API style for the Admin API, powered by https://connectrpc.com/docs/introduction[ConnectRPC]. New Redpanda features and operations in v25.3 are available as ConnectRPC services, allowing you to use autogenerated Protobuf clients in addition to using HTTP clients such as `curl`. - -Use the new ConnectRPC endpoints with the following v25.3 features: - -* Shadowing -* Connected client monitoring - -Existing Admin API endpoints from versions earlier than 25.3 remain supported, and you can continue to use them as usual. See xref:manage:use-admin-api.adoc[Manage Redpanda with the Admin API] to learn more about Admin API, and the link:/api/doc/admin/v2/[Admin API reference] to view the new endpoints. - -== Schema Registry import mode - -Redpanda Schema Registry now supports an import mode that allows you to import existing schemas and retain their current IDs and version numbers. Import mode is useful when migrating from another schema registry. - -Starting with this release, import mode must be used when importing schemas. Read-write mode no longer allows specifying a schema ID and version when registering a schema. -See xref:manage:schema-reg/schema-reg-api.adoc#set-schema-registry-mode[Use the Schema Registry API]. - -== Security report - -You can now generate a security report for your Redpanda cluster using the link:/api/doc/admin/operation/operation-get_security_report[`/v1/security/report`] Admin API endpoint. The report provides detailed information about TLS configuration, authentication methods, authorization status, and security alerts across all Redpanda interfaces (Kafka, RPC, Admin, Schema Registry, HTTP Proxy). - -== Topic identifiers - -Redpanda v25.3 implements topic identifiers using 16 byte UUIDs as proposed in https://cwiki.apache.org/confluence/display/KAFKA/KIP-516%3A+Topic+Identifiers[KIP-516^]. - -== Shadowing metrics - -Redpanda v25.3 introduces comprehensive xref:reference:public-metrics-reference.adoc#shadow-link-metrics[Shadowing metrics] for monitoring disaster recovery replication: - -* xref:reference:public-metrics-reference.adoc#redpanda_shadow_link_client_errors[`redpanda_shadow_link_client_errors`] - Track Kafka client errors during shadow link operations -* xref:reference:public-metrics-reference.adoc#redpanda_shadow_link_shadow_lag[`redpanda_shadow_link_shadow_lag`] - Monitor replication lag between source and shadow partitions -* xref:reference:public-metrics-reference.adoc#redpanda_shadow_link_shadow_topic_state[`redpanda_shadow_link_shadow_topic_state`] - Track shadow topic state distribution across links -* xref:reference:public-metrics-reference.adoc#redpanda_shadow_link_total_bytes_fetched[`redpanda_shadow_link_total_bytes_fetched`] - Monitor data transfer volume from source cluster -* xref:reference:public-metrics-reference.adoc#redpanda_shadow_link_total_bytes_written[`redpanda_shadow_link_total_bytes_written`] - Track data written to shadow cluster -* xref:reference:public-metrics-reference.adoc#redpanda_shadow_link_total_records_fetched[`redpanda_shadow_link_total_records_fetched`] - Monitor total records fetched from source cluster -* xref:reference:public-metrics-reference.adoc#redpanda_shadow_link_total_records_written[`redpanda_shadow_link_total_records_written`] - Track total messages written to shadow cluster - -For monitoring guidance and alert recommendations, see xref:manage:disaster-recovery/shadowing/monitor.adoc[]. - -== New commands - -Redpanda v25.3 introduces the following xref:reference:rpk/rpk-shadow/rpk-shadow.adoc[`rpk shadow`] commands for managing Redpanda shadow links: - -* xref:reference:rpk/rpk-shadow/rpk-shadow-config-generate.adoc[`rpk shadow config generate`] - Generate configuration files for shadow links -* xref:reference:rpk/rpk-shadow/rpk-shadow-create.adoc[`rpk shadow create`] - Create new shadow links -* xref:reference:rpk/rpk-shadow/rpk-shadow-update.adoc[`rpk shadow update`] - Update existing shadow link configurations -* xref:reference:rpk/rpk-shadow/rpk-shadow-list.adoc[`rpk shadow list`] - List all shadow links -* xref:reference:rpk/rpk-shadow/rpk-shadow-describe.adoc[`rpk shadow describe`] - View shadow link configuration details -* xref:reference:rpk/rpk-shadow/rpk-shadow-status.adoc[`rpk shadow status`] - Monitor shadow link replication status -* xref:reference:rpk/rpk-shadow/rpk-shadow-failover.adoc[`rpk shadow failover`] - Perform emergency failover operations -* xref:reference:rpk/rpk-shadow/rpk-shadow-delete.adoc[`rpk shadow delete`] - Delete shadow links - -In addition, the following commands have been added: - -* xref:reference:rpk/rpk-cluster/rpk-cluster-connections.adoc[`rpk cluster connections`] - Monitor cluster connections and client statistics. -* xref:reference:rpk/rpk-redpanda/rpk-redpanda-config-print.adoc[`rpk redpanda config print`] - Display node configuration. - -== New configuration properties - -Redpanda 25.3 introduces the following configuration properties: - -**Shadowing:** - -* xref:reference:properties/cluster-properties.adoc#enable_shadow_linking[`enable_shadow_linking`]: Enable shadow links (Enterprise license required) - -**Timestamp validation:** - -* xref:reference:properties/cluster-properties.adoc#log_message_timestamp_after_max_ms[`log_message_timestamp_after_max_ms`]: Maximum timestamp difference for future records -* xref:reference:properties/cluster-properties.adoc#log_message_timestamp_before_max_ms[`log_message_timestamp_before_max_ms`]: Maximum timestamp difference for past records -* xref:reference:properties/topic-properties.adoc#messagetimestampaftermaxms[`message.timestamp.after.max.ms`]: Topic-level timestamp validation (future) -* xref:reference:properties/topic-properties.adoc#messagetimestampbeforemaxms[`message.timestamp.before.max.ms`]: Topic-level timestamp validation (past) - -**Audit logging:** - -* xref:reference:properties/cluster-properties.adoc#audit_use_rpc[`audit_use_rpc`]: Use internal RPCs for audit logging - -**Object storage:** - -* xref:reference:properties/object-storage-properties.adoc#cloud_storage_client_lease_timeout_ms[`cloud_storage_client_lease_timeout_ms`]: Object storage connection timeout - -**Iceberg:** - -* xref:reference:properties/cluster-properties.adoc#iceberg_default_catalog_namespace[`iceberg_default_catalog_namespace`]: Default Iceberg catalog namespace for tables -* xref:reference:properties/cluster-properties.adoc#iceberg_dlq_table_suffix[`iceberg_dlq_table_suffix`]: Iceberg DLQ table name suffix -* xref:reference:properties/cluster-properties.adoc#iceberg_rest_catalog_gcp_user_project[`iceberg_rest_catalog_gcp_user_project`]: GCP project for Iceberg REST catalog billing -* xref:reference:properties/cluster-properties.adoc#iceberg_topic_name_dot_replacement[`iceberg_topic_name_dot_replacement`]: Dot replacement in Iceberg table names - -**TLS:** - -* xref:reference:properties/cluster-properties.adoc#tls_v1_2_cipher_suites[`tls_v1_2_cipher_suites`]: TLS 1.2 cipher suites for client connections -* xref:reference:properties/cluster-properties.adoc#tls_v1_3_cipher_suites[`tls_v1_3_cipher_suites`]: TLS 1.3 cipher suites for client connections - -**Tiered Storage:** - -* xref:reference:properties/cluster-properties.adoc#cloud_topics_epoch_service_epoch_increment_interval[`cloud_topics_epoch_service_epoch_increment_interval`]: Cluster epoch increment interval -* xref:reference:properties/cluster-properties.adoc#cloud_topics_epoch_service_local_epoch_cache_duration[`cloud_topics_epoch_service_local_epoch_cache_duration`]: Local epoch cache duration -* xref:reference:properties/cluster-properties.adoc#cloud_topics_short_term_gc_backoff_interval[`cloud_topics_short_term_gc_backoff_interval`]: Short-term garbage collection backoff interval -* xref:reference:properties/cluster-properties.adoc#cloud_topics_short_term_gc_interval[`cloud_topics_short_term_gc_interval`]: Short-term garbage collection interval -* xref:reference:properties/cluster-properties.adoc#cloud_topics_short_term_gc_minimum_object_age[`cloud_topics_short_term_gc_minimum_object_age`]: Minimum object age for garbage collection - -**Other configuration:** - -* xref:reference:properties/cluster-properties.adoc#controller_backend_reconciliation_concurrency[`controller_backend_reconciliation_concurrency`]: Maximum concurrent controller reconciliation operations -* xref:reference:properties/cluster-properties.adoc#fetch_max_read_concurrency[`fetch_max_read_concurrency`]: Maximum concurrent partition reads per fetch request -* xref:reference:properties/cluster-properties.adoc#kafka_max_message_size_upper_limit_bytes[`kafka_max_message_size_upper_limit_bytes`]: Maximum allowed `max.message.size` topic property value -* xref:reference:properties/cluster-properties.adoc#kafka_produce_batch_validation[`kafka_produce_batch_validation`]: Validation level for produced batches -* xref:reference:properties/cluster-properties.adoc#log_compaction_tx_batch_removal_enabled[`log_compaction_tx_batch_removal_enabled`]: Enable transactional batch removal during compaction -* xref:reference:properties/cluster-properties.adoc#sasl_mechanisms_overrides[`sasl_mechanisms_overrides`]: SASL authentication mechanisms per listener - -=== Changes to default values - -The following configuration properties have new default values in v25.3: - -* xref:reference:properties/cluster-properties.adoc#core_balancing_continuous[`core_balancing_continuous`]: Changed from `false` to `true` (Enterprise license required). -* xref:reference:properties/cluster-properties.adoc#partition_autobalancing_mode[`partition_autobalancing_mode`]: Changed from `node_add` to `continuous` (Enterprise license required). -* xref:reference:properties/cluster-properties.adoc#iceberg_throttle_backlog_size_ratio[`iceberg_throttle_backlog_size_ratio`]: Changed from `0.3` to `null`. - -[[behavior-changes]] -=== Behavior changes - -The following topic properties now support enhanced tristate behavior: - -* xref:reference:properties/topic-properties.adoc#segment-ms[`segment.ms`] -* xref:reference:properties/topic-properties.adoc#retention-bytes[`retention.bytes`] -* xref:reference:properties/topic-properties.adoc#retention-ms[`retention.ms`] -* xref:reference:properties/topic-properties.adoc#retention-local-target-bytes[`retention.local.target.bytes`] -* xref:reference:properties/topic-properties.adoc#retention-local-target-ms[`retention.local.target.ms`] -* xref:reference:properties/topic-properties.adoc#initial-retention-local-target-bytes[`initial.retention.local.target.bytes`] -* xref:reference:properties/topic-properties.adoc#initial-retention-local-target-ms[`initial.retention.local.target.ms`] -* xref:reference:properties/topic-properties.adoc#delete-retention-ms[`delete.retention.ms`] -* xref:reference:properties/topic-properties.adoc#min-cleanable-dirty-ratio[`min.cleanable.dirty.ratio`] - -Previously, these properties treated zero and negative values the same way. Now they support three distinct states: positive values set specific limits, zero provides immediate eligibility for cleanup/compaction, and negative values disable the feature entirely. Review your topic configurations if you currently use zero values for these properties. - -=== Deprecations - -The following configuration properties have been deprecated in v25.3 and will be removed in a future release: - -* `kafka_memory_batch_size_estimate_for_fetch`: No replacement. Remove from configuration. -* `log_compaction_disable_tx_batch_removal`: Use xref:reference:properties/cluster-properties.adoc#log_compaction_tx_batch_removal_enabled[`log_compaction_tx_batch_removal_enabled`] instead. Note the inverted logic: the new property enables the behavior when set to `true`. -* `log_message_timestamp_alert_after_ms`: Use xref:reference:properties/cluster-properties.adoc#log_message_timestamp_after_max_ms[`log_message_timestamp_after_max_ms`] instead. -* `log_message_timestamp_alert_before_ms`: Use xref:reference:properties/cluster-properties.adoc#log_message_timestamp_before_max_ms[`log_message_timestamp_before_max_ms`] instead. -* `raft_recovery_default_read_size`: No replacement. Remove from configuration. - -== Deprecated features - -Redpanda has deprecated support for specific TLSv1.2 and TLSv1.3 cipher suites and now uses more secure defaults. See xref:upgrade:deprecated/index.adoc[Deprecated Features] for the complete list. diff --git a/modules/reference/partials/properties/topic-properties.adoc b/modules/reference/partials/properties/topic-properties.adoc index 1463d30bfd..a40206670e 100644 --- a/modules/reference/partials/properties/topic-properties.adoc +++ b/modules/reference/partials/properties/topic-properties.adoc @@ -1270,6 +1270,11 @@ The preferred location (rack) for partition leaders of a topic. This property inherits the value from the config_ref:default_leaders_preference,true,properties/cluster-properties[] cluster configuration property. You may override the cluster-wide setting by specifying the value for individual topics. If the cluster configuration property config_ref:enable_rack_awareness,true,properties/cluster-properties[] is set to `false`, Leader Pinning is disabled across the cluster. +Accepted values: + +* `none`: Disable Leader Pinning for the topic. +* `racks:[,,...]`: Pin leaders to the specified racks with equal priority. Redpanda distributes partition leaders across brokers in the listed racks, with no preference ordering. +* `ordered_racks:[,,...]`: Pin leaders to the specified racks in priority order. Redpanda places leaders in the first listed rack when available, failing over to subsequent racks when higher-priority racks are unavailable. Requires Redpanda version 26.1 or later. [cols="1s,2a"] |=== @@ -1278,7 +1283,8 @@ If the cluster configuration property config_ref:enable_rack_awareness,true,prop | Type | `object` - +| Accepted Values +| `none`, `racks:[,,...]`, `ordered_racks:[,,...]` | Corresponding cluster property | xref:reference:cluster-properties.adoc#default_leaders_preference[default_leaders_preference]