From 93f2057031f814027255bbb222af6e9540952e14 Mon Sep 17 00:00:00 2001 From: Paulo Borges Date: Mon, 9 Dec 2024 19:04:50 -0300 Subject: [PATCH] DOC-833 rename topic-partition to topic partition (#905) --- modules/get-started/pages/architecture.adoc | 6 +++--- .../manage/pages/cluster-maintenance/cluster-balancing.adoc | 2 +- .../pages/rpk/rpk-cluster/rpk-cluster-partitions-move.adoc | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/modules/get-started/pages/architecture.adoc b/modules/get-started/pages/architecture.adoc index 1f437d3fb..5703d215b 100644 --- a/modules/get-started/pages/architecture.adoc +++ b/modules/get-started/pages/architecture.adoc @@ -25,13 +25,13 @@ endif::[] == Partitions -To scale topics, Redpanda shards them into one or more partitions that are distributed across the nodes in a cluster. This allows for concurrent writing and reading from multiple nodes. When producers write to a topic, they route events to one of the topic's partitions. Events with the same key (like a stock ticker) are always routed to the same partition, and Redpanda guarantees the order of events at the partition level. Consumers read events from a partition in the order that they were written. If a key is not specified, then events are sent to all topic-partitions in a round-robin fashion. +To scale topics, Redpanda shards them into one or more partitions that are distributed across the nodes in a cluster. This allows for concurrent writing and reading from multiple nodes. When producers write to a topic, they route events to one of the topic's partitions. Events with the same key (like a stock ticker) are always routed to the same partition, and Redpanda guarantees the order of events at the partition level. Consumers read events from a partition in the order that they were written. If a key is not specified, then events are sent to all topic partitions in a round-robin fashion. == Raft consensus algorithm -Redpanda provides strong guarantees for data safety and fault tolerance. Events written to a topic-partition are appended to a log file on disk. They can be replicated to other nodes in the cluster and appended to their copies of the log file on disk to prevent data loss in the event of failure. The https://raft.github.io/[Raft consensus algorithm^] is used for data replication. +Redpanda provides strong guarantees for data safety and fault tolerance. Events written to a topic partition are appended to a log file on disk. They can be replicated to other nodes in the cluster and appended to their copies of the log file on disk to prevent data loss in the event of failure. The https://raft.github.io/[Raft consensus algorithm^] is used for data replication. -Every topic-partition forms a Raft group consisting of a single elected leader and zero or more followers (as specified by the topic's replication factor). A Raft group can tolerate ƒ failures given 2ƒ+1 nodes. For example, in a cluster with five nodes and a topic with a replication factor of five, the topic remains fully operational if two nodes fail. +Every topic partition forms a Raft group consisting of a single elected leader and zero or more followers (as specified by the topic's replication factor). A Raft group can tolerate ƒ failures given 2ƒ+1 nodes. For example, in a cluster with five nodes and a topic with a replication factor of five, the topic remains fully operational if two nodes fail. Raft is a majority vote algorithm. For a leader to acknowledge that an event has been committed to a partition, a majority of its replicas must have written that event to their copy of the log. When a majority (quorum) of responses have been received, the leader can make the event available to consumers and acknowledge receipt of the event when `acks=all (-1)`. xref:develop:produce-data/configure-producers.adoc#producer-acknowledgement-settings[Producer acknowledgement settings] define how producers and leaders communicate their status while transferring data. diff --git a/modules/manage/pages/cluster-maintenance/cluster-balancing.adoc b/modules/manage/pages/cluster-maintenance/cluster-balancing.adoc index 3d632f1b8..59e1cd402 100644 --- a/modules/manage/pages/cluster-maintenance/cluster-balancing.adoc +++ b/modules/manage/pages/cluster-maintenance/cluster-balancing.adoc @@ -42,7 +42,7 @@ include::develop:partial$balance-existing-topic-redistribution.adoc[] == Partition leadership balancing -Every Redpanda topic-partition forms a Raft group with a single elected leader. This leader manages all writes for the partition. Raft uses a heartbeat mechanism to maintain leadership authority and to initiate leader elections. The partition leader regularly sends heartbeats (xref:reference:tunable-properties.adoc#raft_heartbeat_interval_ms[`raft_heartbeat_interval_ms`]) to its followers. If a follower does not receive a heartbeat within a timeout (xref:reference:tunable-properties.adoc#raft_heartbeat_timeout_ms[`raft_heartbeat_timeout_ms`]), it triggers a new leader election. For more information, see xref:get-started:architecture.adoc#raft-consensus-algorithm[Raft consensus algorithm] and xref:get-started:architecture.adoc#partition-leadership-elections[partition leadership elections]. +Every Redpanda topic partition forms a Raft group with a single elected leader. This leader manages all writes for the partition. Raft uses a heartbeat mechanism to maintain leadership authority and to initiate leader elections. The partition leader regularly sends heartbeats (xref:reference:tunable-properties.adoc#raft_heartbeat_interval_ms[`raft_heartbeat_interval_ms`]) to its followers. If a follower does not receive a heartbeat within a timeout (xref:reference:tunable-properties.adoc#raft_heartbeat_timeout_ms[`raft_heartbeat_timeout_ms`]), it triggers a new leader election. For more information, see xref:get-started:architecture.adoc#raft-consensus-algorithm[Raft consensus algorithm] and xref:get-started:architecture.adoc#partition-leadership-elections[partition leadership elections]. By default, Redpanda enables topic-aware leadership balancing with the xref:reference:cluster-properties.adoc#enable_leader_balancer[`enable_leader_balancer`] property. Automatic partition leadership balancing improves cluster performance by transferring partition leadership from one broker to other replicas. This transfer changes where data is written to first, but leadership transfer does not involve any data transfer. diff --git a/modules/reference/pages/rpk/rpk-cluster/rpk-cluster-partitions-move.adoc b/modules/reference/pages/rpk/rpk-cluster/rpk-cluster-partitions-move.adoc index 64a502de1..dfac03fa5 100644 --- a/modules/reference/pages/rpk/rpk-cluster/rpk-cluster-partitions-move.adoc +++ b/modules/reference/pages/rpk/rpk-cluster/rpk-cluster-partitions-move.adoc @@ -53,7 +53,7 @@ rpk cluster partitions move [flags] |-h, --help |- |Help for move. -|-p, --partition |stringArray |Topic-partitions to move and new replica locations (repeatable). +|-p, --partition |stringArray |Topic partitions to move and new replica locations (repeatable). |--config |string |Redpanda or `rpk` config file; default search paths are `/var/lib/redpanda/.config/rpk/rpk.yaml`, `$PWD/redpanda.yaml`, and `/etc/redpanda/redpanda.yaml`.