From f8fa2c5a832986640238743453d5cce1dc83defe Mon Sep 17 00:00:00 2001 From: Kat Batuigas Date: Tue, 31 Mar 2026 12:52:35 -0700 Subject: [PATCH 1/8] Follow up SME feedback --- modules/manage/pages/iceberg/about-iceberg-topics.adoc | 2 +- modules/manage/pages/iceberg/iceberg-topics-aws-glue.adoc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/manage/pages/iceberg/about-iceberg-topics.adoc b/modules/manage/pages/iceberg/about-iceberg-topics.adoc index 4f74450f63..c9cbcb9b1f 100644 --- a/modules/manage/pages/iceberg/about-iceberg-topics.adoc +++ b/modules/manage/pages/iceberg/about-iceberg-topics.adoc @@ -122,7 +122,7 @@ The link:/api/doc/cloud-controlplane/operation/operation-clusterservice_updatecl endif::[] ifndef::env-cloud[] + -When multiple clusters write to the same catalog, each cluster must use a distinct namespace to avoid table name collisions. This is especially critical for REST catalog providers that offer a single global catalog per account (such as AWS Glue), where there is no other isolation mechanism. By default, Redpanda creates Iceberg tables in a namespace called `redpanda`. To use a unique namespace for your cluster's REST catalog integration, set config_ref:iceberg_default_catalog_namespace,true,properties/cluster-properties[`iceberg_default_catalog_namespace`] at the same time. This property cannot be changed after you enable Iceberg topics on the cluster. +When multiple clusters write to the same catalog, each cluster must use a distinct namespace to avoid table name collisions. This is especially critical for REST catalog providers that offer a single global catalog per account (such as AWS Glue), where there is no other isolation mechanism. By default, Redpanda creates Iceberg tables in a namespace called `redpanda`. To use a unique namespace for your cluster's REST catalog integration, also set config_ref:iceberg_default_catalog_namespace,true,properties/cluster-properties[`iceberg_default_catalog_namespace`] when you set `iceberg_enabled`. This property cannot be changed after you enable Iceberg topics on the cluster. + [,bash] ---- diff --git a/modules/manage/pages/iceberg/iceberg-topics-aws-glue.adoc b/modules/manage/pages/iceberg/iceberg-topics-aws-glue.adoc index a530eeec06..bbc730f0ba 100644 --- a/modules/manage/pages/iceberg/iceberg-topics-aws-glue.adoc +++ b/modules/manage/pages/iceberg/iceberg-topics-aws-glue.adoc @@ -130,7 +130,7 @@ To configure your Redpanda cluster to enable Iceberg on a topic and integrate wi . Edit your cluster configuration to set the `iceberg_enabled` property to `true`, and set the catalog integration properties listed in the example below. ifndef::env-cloud[] + -By default, Redpanda creates Iceberg tables in a namespace called `redpanda`. Because AWS Glue provides a single catalog per account, each Redpanda cluster that writes to the same Glue catalog must use a distinct namespace to avoid table name collisions. To set a unique namespace, set config_ref:iceberg_default_catalog_namespace,true,properties/cluster-properties[`iceberg_default_catalog_namespace`] at the same time. This property cannot be changed after Iceberg is enabled. +By default, Redpanda creates Iceberg tables in a namespace called `redpanda`. Because AWS Glue provides a single catalog per account, each Redpanda cluster that writes to the same Glue catalog must use a distinct namespace to avoid table name collisions. To set a unique namespace, also set config_ref:iceberg_default_catalog_namespace,true,properties/cluster-properties[`iceberg_default_catalog_namespace`] when you set `iceberg_enabled`. This property cannot be changed after Iceberg is enabled. + Run `rpk cluster config edit` to update these properties: + From cbb3f65174e753fe37b032115fb1267554e4a0e2 Mon Sep 17 00:00:00 2001 From: Kat Batuigas Date: Tue, 31 Mar 2026 12:53:09 -0700 Subject: [PATCH 2/8] Add Cloud Topics doc link --- modules/develop/pages/produce-data/leader-pinning.adoc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/modules/develop/pages/produce-data/leader-pinning.adoc b/modules/develop/pages/produce-data/leader-pinning.adoc index 74cb3a0da8..8f496f3221 100644 --- a/modules/develop/pages/produce-data/leader-pinning.adoc +++ b/modules/develop/pages/produce-data/leader-pinning.adoc @@ -178,8 +178,7 @@ If a higher-priority rack recovers and the topic's replication factor ensures th == Suggested reading -// TODO: Add link to Cloud Topics -// * For latency-tolerant, high-throughput workloads where cross-AZ networking charges are a major cost driver, also consider xref:develop:manage-topics/cloud-topics.adoc[Cloud Topics] +* For latency-tolerant, high-throughput workloads where cross-AZ networking charges are a major cost driver, also consider xref:develop:manage-topics/cloud-topics.adoc[Cloud Topics] * xref:develop:consume-data/follower-fetching.adoc[] // end::single-source[] \ No newline at end of file From cde3845dc4b474dc9cfca0ddd78853683f146cf1 Mon Sep 17 00:00:00 2001 From: Kat Batuigas Date: Tue, 31 Mar 2026 12:53:24 -0700 Subject: [PATCH 3/8] Specify license expiry behavior for GBAC --- modules/get-started/pages/licensing/overview.adoc | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/modules/get-started/pages/licensing/overview.adoc b/modules/get-started/pages/licensing/overview.adoc index 93d0a73edc..dd9ea32c68 100644 --- a/modules/get-started/pages/licensing/overview.adoc +++ b/modules/get-started/pages/licensing/overview.adoc @@ -128,6 +128,10 @@ Continuous Intra-Broker Partition Balancing is enabled by default for all new cl | Enables compliance with FIPS security standards for cryptography. | No change. +| xref:manage:security/authorization/gbac.adoc[Group-Based Access Control (GBAC)] +| Manages permissions using OIDC group memberships for ACLs and role assignments. +| ACLs and role assignments that use `Group:` principals cannot be created. Existing group permissions continue to be evaluated and can be deleted. + | xref:manage:iceberg/topic-iceberg-integration.adoc[Iceberg Topics] | Enables Iceberg integration for Redpanda topics. | Topics cannot be created or modified with the `redpanda.iceberg.mode` property. From fa34f6d5dd15b7867308d151efb02f5876be1805 Mon Sep 17 00:00:00 2001 From: Kat Batuigas Date: Tue, 31 Mar 2026 13:07:10 -0700 Subject: [PATCH 4/8] Conditionalize Cloud topics link for Cloud docs --- modules/develop/pages/produce-data/leader-pinning.adoc | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/modules/develop/pages/produce-data/leader-pinning.adoc b/modules/develop/pages/produce-data/leader-pinning.adoc index 8f496f3221..323d177f96 100644 --- a/modules/develop/pages/produce-data/leader-pinning.adoc +++ b/modules/develop/pages/produce-data/leader-pinning.adoc @@ -178,7 +178,14 @@ If a higher-priority rack recovers and the topic's replication factor ensures th == Suggested reading +ifndef::env-cloud[] * For latency-tolerant, high-throughput workloads where cross-AZ networking charges are a major cost driver, also consider xref:develop:manage-topics/cloud-topics.adoc[Cloud Topics] +endif::[] +ifdef::env-cloud[] +* For latency-tolerant, high-throughput workloads where cross-AZ networking charges are a major cost driver, also consider xref:develop:topics/cloud-topics.adoc[Cloud Topics] +endif::[] + + * xref:develop:consume-data/follower-fetching.adoc[] // end::single-source[] \ No newline at end of file From a6290762c9f594185806310f892d092ab4565f1d Mon Sep 17 00:00:00 2001 From: Kat Batuigas Date: Tue, 31 Mar 2026 13:10:21 -0700 Subject: [PATCH 5/8] Delete old version of Manage Topics doc --- modules/develop/pages/config-topics.adoc | 279 ----------------------- 1 file changed, 279 deletions(-) delete mode 100644 modules/develop/pages/config-topics.adoc diff --git a/modules/develop/pages/config-topics.adoc b/modules/develop/pages/config-topics.adoc deleted file mode 100644 index a2e7117030..0000000000 --- a/modules/develop/pages/config-topics.adoc +++ /dev/null @@ -1,279 +0,0 @@ -= Manage Topics -:page-categories: Clients, Development -:description: Learn how to create topics, update topic configurations, and delete topics or records. -// tag::single-source[] - -include::develop:partial$topic-defaults.adoc[] - -== Create a topic - -Creating a topic can be as simple as specifying a name for your topic on the command line. For example, to create a topic named `xyz`, run: - -[,bash] ----- -rpk topic create xyz ----- - -ifndef::env-cloud[] -This command creates a topic named `xyz` with one partition and one replica, because these are the default values set in the cluster configuration file. Replicas are copies of partitions that are distributed across different brokers, so if one broker goes down, other brokers still have a copy of the data. - -endif::[] - -ifdef::env-cloud[] -This command creates a topic named `xyz` with one partition and three replicas, because these are the default values set in the cluster configuration file. Replicas are copies of partitions that are distributed across different brokers, so if one broker goes down, other brokers still have a copy of the data. - -Redpanda Cloud supports 40,000 topics per cluster. - -endif::[] - -=== Choose the number of partitions - -A partition acts as a log file where topic data is written. Dividing topics into partitions allows producers to write messages in parallel and consumers to read messages in parallel. The higher the number of partitions, the greater the throughput. - -TIP: As a general rule, select a number of partitions that corresponds to the maximum number of consumers in any consumer group that will consume the data. - -For example, suppose you plan to create a consumer group with 10 consumers. To create topic `xyz` with 10 partitions, run: - -[,bash] ----- -rpk topic create xyz -p 10 ----- - -ifndef::env-cloud[] -=== Choose the replication factor - -The default replication factor in the cluster configuration is set to 1. By choosing a replication factor greater than 1, you ensure that each partition has a copy of its data on at least one other broker. One replica acts as the leader, and the other replicas are followers. - -To specify a replication factor of 3 for topic `xyz`, run: - -[,bash] ----- -rpk topic create xyz -r 3 ----- - -NOTE: The replication factor must be an odd number. Redpanda Data recommends a replication factor of 3 for most use cases. Administrators may set a minimum required replication factor for any new topic in the cluster through the cluster-level xref:reference:cluster-properties.adoc#minimum_topic_replications[`minimum_topic_replications`] property. - -TIP: If you enable xref:manage:tiered-storage.adoc[Tiered Storage] on a topic, you can then use xref:manage:topic-recovery.adoc[topic recovery] to restore data for a deleted topic. - -endif::[] - -== Update topic configurations - -After you create a topic, you can update the topic property settings for all new data written to it. For example, you can add partitions or change the cleanup policy. - -=== Add partitions - -You can assign a certain number of partitions when you create a topic, and add partitions later. For example, suppose you add brokers to your cluster, and you want to take advantage of the additional processing power. To increase the number of partitions for existing topics, run: - -[,bash] ----- -rpk topic add-partitions [TOPICS...] --num [#] ----- - -Note that `--num <#>` is the number of partitions to _add_, not the total number of partitions. - -include::develop:partial$balance-existing-topic-redistribution.adoc[] - -ifndef::env-cloud[] -=== Change the replication factor - -Suppose you create a topic with the default replication factor of 1 (which is specified in the cluster properties configuration file). Now you want to change the replication factor to 3, so you can have two backups of topic data in case a broker goes down. To set the replication factor to 3, run: - -[,bash] ----- -rpk topic alter-config [TOPICS...] --set replication.factor=3 ----- - -NOTE: The replication factor can't exceed the number of Redpanda brokers. If you try to set a replication factor greater than the number of brokers, the request is rejected. - -endif::[] - -=== Change the cleanup policy - -The cleanup policy determines how to clean up the partition log files when they reach a certain size: - -* `delete` deletes data based on age or log size. Topics retain all records until then. -* `compact` compacts the data by only keeping the latest values for each KEY. -* `compact,delete` combines both methods. - -Unlike compacted topics, which keep only the most recent message for a given key, topics configured with a `delete` cleanup policy provide a running history of all changes for those topics. - -[NOTE] -==== -include::shared:partial$tristate-behavior-change-25-3.adoc[] -==== - -include::develop:partial$topic-properties-warning.adoc[] - -For example, to change a topic's policy to `compact`, run: - -[,bash] ----- -rpk topic alter-config [TOPICS…] —-set cleanup.policy=compact ----- - -ifndef::env-cloud[] -For details on compaction in Redpanda, see xref:manage:cluster-maintenance/compaction-settings.adoc[Compaction settings]. - -endif::[] - -=== Configure write caching - -Write caching is a relaxed mode of xref:develop:produce-data/configure-producers.adoc#acksall[`acks=all`] that provides better performance at the expense of durability. It acknowledges a message as soon as it is received and acknowledged on a majority of brokers, without waiting for it to be written to disk. This provides lower latency while still ensuring that a majority of brokers acknowledge the write. - -Write caching applies to user topics. It does not apply to transactions or consumer offsets: data written in the context of a transaction and consumer offset commits is always written to disk and fsynced before being acknowledged to the client. - -ifndef::env-cloud[] -NOTE: For clusters in xref:reference:rpk/rpk-redpanda/rpk-redpanda-mode.adoc#development-mode[development mode], write caching is enabled by default. For clusters in production mode, it is disabled by default. - -endif::[] - -Only enable write caching on workloads that can tolerate some data loss in the case of multiple, simultaneous broker failures. Leaving write caching disabled safeguards your data against complete data center or availability zone failures. - -ifndef::env-cloud[] - -==== Configure at cluster level - -To enable write caching by default in all user topics, set the cluster-level property xref:reference:cluster-properties.adoc#write_caching_default[`write_caching_default`]: - -`rpk cluster config set write_caching_default=true` - -With `write_caching_default` set to true at the cluster level, Redpanda fsyncs to disk according to xref:reference:cluster-properties.adoc#raft_replica_max_pending_flush_bytes[`raft_replica_max_pending_flush_bytes`] and xref:reference:cluster-properties.adoc#raft_replica_max_flush_delay_ms[`raft_replica_max_flush_delay_ms`], whichever is reached first. - -endif::[] - -==== Configure at topic level - -To override the cluster-level setting at the topic level, set the topic-level property `write.caching`: - -`rpk topic alter-config my_topic --set write.caching=true` - -With `write.caching` enabled at the topic level, Redpanda fsyncs to disk according to `flush.ms` and `flush.bytes`, whichever is reached first. - -=== Remove a configuration setting - -You can remove a configuration that overrides the default setting, and the setting will use the default value again. For example, suppose you altered the cleanup policy to use `compact` instead of the default, `delete`. Now you want to return the policy setting to the default. To remove the configuration setting `cleanup.policy=compact`, run `rpk topic alter-config` with the `--delete` flag: - -[,bash] ----- -rpk topic alter-config [TOPICS...] --delete cleanup.policy ----- - -== List topic configuration settings - -To display all the configuration settings for a topic, run: - -[,bash] ----- -rpk topic describe -c ----- - -The `-c` flag limits the command output to just the topic configurations. This command is useful for checking the default configuration settings before you make any changes and for verifying changes after you make them. - -The following command output displays after running `rpk topic describe test-topic`, where `test-topic` was created with default settings: - -ifndef::env-cloud[] -[,bash] ----- -rpk topic describe test_topic -SUMMARY -======= -NAME test_topic -PARTITIONS 1 -REPLICAS 1 - -CONFIGS -======= -KEY VALUE SOURCE -cleanup.policy delete DYNAMIC_TOPIC_CONFIG -compression.type producer DEFAULT_CONFIG -max.message.bytes 1048576 DEFAULT_CONFIG -message.timestamp.type CreateTime DEFAULT_CONFIG -redpanda.datapolicy function_name: script_name: DEFAULT_CONFIG -redpanda.remote.delete true DEFAULT_CONFIG -redpanda.remote.read false DEFAULT_CONFIG -redpanda.remote.write false DEFAULT_CONFIG -retention.bytes -1 DEFAULT_CONFIG -retention.local.target.bytes -1 DEFAULT_CONFIG -retention.local.target.ms 86400000 DEFAULT_CONFIG -retention.ms 604800000 DEFAULT_CONFIG -segment.bytes 1073741824 DEFAULT_CONFIG ----- - -Suppose you add two partitions, and increase the number of replicas to 3. The new command output confirms the changes in the `SUMMARY` section: - -[.no-copy] ----- -SUMMARY -======= -NAME test_topic -PARTITIONS 3 -REPLICAS 3 ----- - -endif::[] - -ifdef::env-cloud[] -[,bash] ----- -rpk topic describe test_topic -SUMMARY -======= -NAME test_topic -PARTITIONS 1 -REPLICAS 3 - -CONFIGS -======= -KEY VALUE SOURCE -cleanup.policy delete DYNAMIC_TOPIC_CONFIG -compression.type producer DEFAULT_CONFIG -max.message.bytes 20971520 DEFAULT_CONFIG -message.timestamp.type CreateTime DEFAULT_CONFIG -redpanda.datapolicy function_name: script_name: DEFAULT_CONFIG -redpanda.remote.delete true DEFAULT_CONFIG -redpanda.remote.read false DEFAULT_CONFIG -redpanda.remote.write false DEFAULT_CONFIG -retention.bytes -1 DEFAULT_CONFIG -retention.local.target.bytes -1 DEFAULT_CONFIG -retention.local.target.ms 86400000 DEFAULT_CONFIG -retention.ms 604800000 DEFAULT_CONFIG -segment.bytes 1073741824 DEFAULT_CONFIG ----- - -endif::[] - -== Delete a topic - -To delete a topic, run: - -[,bash] ----- -rpk topic delete ----- - -When a topic is deleted, its underlying data is deleted, too. - -To delete multiple topics at a time, provide a space-separated list. For example, to delete two topics named `topic1` and `topic2`, run: - -[,bash] ----- -rpk topic delete topic1 topic2 ----- - -You can also use the `-r` flag to specify one or more regular expressions; then, any topic names that match the pattern you specify are deleted. For example, to delete topics with names that start with "`f`" and end with "`r`", run: - -[,bash] ----- -rpk topic delete -r '^f.*' '.*r$' ----- - -Note that the first regular expression must start with the `^` symbol, and the last expression must end with the `$` symbol. This requirement helps prevent accidental deletions. - -include::develop:partial$delete-topic-records.adoc[] - -== Next steps - -xref:develop:produce-data/configure-producers.adoc[] - -// end::single-source[] From 69c41cfd8f94ad2f9443ffb877d669784cae7426 Mon Sep 17 00:00:00 2001 From: Kat Batuigas Date: Tue, 31 Mar 2026 16:13:38 -0700 Subject: [PATCH 6/8] Fix redirect/xref for config-topics --- .../pages/redpanda/kubernetes/k-production-readiness.adoc | 2 +- modules/develop/pages/manage-topics/config-topics.adoc | 1 + modules/manage/pages/disaster-recovery/shadowing/overview.adoc | 2 +- modules/reference/partials/properties/cluster-properties.adoc | 2 +- modules/reference/partials/properties/topic-properties.adoc | 2 +- 5 files changed, 5 insertions(+), 4 deletions(-) diff --git a/modules/deploy/pages/redpanda/kubernetes/k-production-readiness.adoc b/modules/deploy/pages/redpanda/kubernetes/k-production-readiness.adoc index 01ae3cd02a..8ea242a90d 100644 --- a/modules/deploy/pages/redpanda/kubernetes/k-production-readiness.adoc +++ b/modules/deploy/pages/redpanda/kubernetes/k-production-readiness.adoc @@ -529,7 +529,7 @@ Ensure storage classes provide adequate IOPS and throughput for your workload by * Use NVMe-based storage classes for production deployments * Specify a minimum 16,000 IOPS (Input/Output Operations Per Second) * Consider provisioned IOPS where available to meet or exceed the minimum -* Enable xref:develop:config-topics.adoc#configure-write-caching[write caching] to help Redpanda perform better in environments with disks that don't meet the recommended IOPS +* Enable xref:develop:manage-topics/config-topics.adoc#configure-write-caching[write caching] to help Redpanda perform better in environments with disks that don't meet the recommended IOPS * NFS (Network File System) is not supported * Test storage performance under load diff --git a/modules/develop/pages/manage-topics/config-topics.adoc b/modules/develop/pages/manage-topics/config-topics.adoc index 09d5c0b191..36f412a8a3 100644 --- a/modules/develop/pages/manage-topics/config-topics.adoc +++ b/modules/develop/pages/manage-topics/config-topics.adoc @@ -1,5 +1,6 @@ = Manage Topics :page-categories: Clients, Development +:page-aliases: develop:config-topics.adoc :description: Learn how to create topics, update topic configurations, and delete topics or records. tag::single-source[] diff --git a/modules/manage/pages/disaster-recovery/shadowing/overview.adoc b/modules/manage/pages/disaster-recovery/shadowing/overview.adoc index 54f1d4c6b3..66f6178920 100644 --- a/modules/manage/pages/disaster-recovery/shadowing/overview.adoc +++ b/modules/manage/pages/disaster-recovery/shadowing/overview.adoc @@ -171,7 +171,7 @@ The filtering system you configure determines the precise scope of replication a To ensure reliable disaster recovery with Shadowing: ifndef::env-cloud[] -* **Avoid write caching on source topics**: Do not shadow source topics that have xref:develop:config-topics.adoc#configure-write-caching[write caching] enabled. Write caching can result in data loss on the source cluster during broker resets, causing cluster divergence if shadow links replicate data before it's lost on the source. +* **Avoid write caching on source topics**: Do not shadow source topics that have xref:develop:manage-topics/config-topics.adoc#configure-write-caching[write caching] enabled. Write caching can result in data loss on the source cluster during broker resets, causing cluster divergence if shadow links replicate data before it's lost on the source. endif::[] * **Do not modify shadow topic properties**: Avoid modifying synced topic properties on shadow topics, as these properties automatically revert to source topic values. diff --git a/modules/reference/partials/properties/cluster-properties.adoc b/modules/reference/partials/properties/cluster-properties.adoc index a3ca43602a..cff7165699 100644 --- a/modules/reference/partials/properties/cluster-properties.adoc +++ b/modules/reference/partials/properties/cluster-properties.adoc @@ -19829,7 +19829,7 @@ endif::[] | * xref:reference:properties/topic-properties.adoc#writecaching[`write.caching`] -* xref:develop:config-topics.adoc#configure-write-caching[Write caching] +* xref:develop:manage-topics/config-topics.adoc#configure-write-caching[Write caching] |=== diff --git a/modules/reference/partials/properties/topic-properties.adoc b/modules/reference/partials/properties/topic-properties.adoc index 2f599a9cb3..30202e4a8c 100644 --- a/modules/reference/partials/properties/topic-properties.adoc +++ b/modules/reference/partials/properties/topic-properties.adoc @@ -2184,7 +2184,7 @@ endif::[] | Related topics | -* xref:develop:config-topics.adoc#configure-write-caching[Write caching] +* xref:develop:manage-topics/config-topics.adoc#configure-write-caching[Write caching] * xref:manage:tiered-storage.adoc[Tiered Storage] From 6afdd5c85a1fc8c04891748eaf6aa01afcf9dcf4 Mon Sep 17 00:00:00 2001 From: Kat Batuigas Date: Tue, 31 Mar 2026 16:16:11 -0700 Subject: [PATCH 7/8] Update GBAC behavior per PM feedback --- modules/get-started/pages/licensing/overview.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/get-started/pages/licensing/overview.adoc b/modules/get-started/pages/licensing/overview.adoc index dd9ea32c68..8c50d327dc 100644 --- a/modules/get-started/pages/licensing/overview.adoc +++ b/modules/get-started/pages/licensing/overview.adoc @@ -130,7 +130,7 @@ Continuous Intra-Broker Partition Balancing is enabled by default for all new cl | xref:manage:security/authorization/gbac.adoc[Group-Based Access Control (GBAC)] | Manages permissions using OIDC group memberships for ACLs and role assignments. -| ACLs and role assignments that use `Group:` principals cannot be created. Existing group permissions continue to be evaluated and can be deleted. +| ACLs with `Group:` principals cannot be created. Existing group ACLs continue to be evaluated and can be deleted. | xref:manage:iceberg/topic-iceberg-integration.adoc[Iceberg Topics] | Enables Iceberg integration for Redpanda topics. From b79a7067b7172d592d70b8a0e306c9edd2906a5b Mon Sep 17 00:00:00 2001 From: Kat Batuigas Date: Wed, 1 Apr 2026 11:51:54 -0700 Subject: [PATCH 8/8] Update config-topic xrefs --- docs-data/property-overrides.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs-data/property-overrides.json b/docs-data/property-overrides.json index a13c840587..7b11ea65a4 100644 --- a/docs-data/property-overrides.json +++ b/docs-data/property-overrides.json @@ -2245,7 +2245,7 @@ "write.caching": { "description": "The write caching mode to apply to a topic.\n\nWhen `write.caching` is set, it overrides the cluster property xref:cluster-properties.adoc#write_caching_default[`write_caching_default`]. Write caching acknowledges a message as soon as it is received and acknowledged on a majority of brokers, without waiting for it to be written to disk. With `acks=all`, this provides lower latency while still ensuring that a majority of brokers acknowledge the write. Fsyncs follow <> and <>, whichever is reached first.", "related_topics": [ - "xref:develop:config-topics.adoc#configure-write-caching[Write caching]", + "xref:develop:manage-topics/config-topics.adoc#configure-write-caching[Write caching]", "xref:manage:tiered-storage.adoc[Tiered Storage]", "xref:reference:properties/cluster-properties.adoc#write_caching_default[`write_caching_default`]", "xref:cluster-properties.adoc#write_caching_default[`write_caching_default`]" @@ -2255,7 +2255,7 @@ "write_caching_default": { "related_topics": [ "xref:reference:properties/topic-properties.adoc#writecaching[`write.caching`]", - "xref:develop:config-topics.adoc#configure-write-caching[Write caching]" + "xref:develop:manage-topics/config-topics.adoc#configure-write-caching[Write caching]" ], "config_scope": "cluster", "description": "The default write caching mode to apply to user topics. Write caching acknowledges a message as soon as it is received and acknowledged on a majority of brokers, without waiting for it to be written to disk. With `acks=all`, this provides lower latency while still ensuring that a majority of brokers acknowledge the write. \n\nFsyncs follow <> and <>, whichever is reached first.\n\nThe `write_caching_default` cluster property can be overridden with the xref:reference:properties/topic-properties.adoc#writecaching[`write.caching`] topic property."