redpanda-data · Deflaimun · Dec 9, 2024 · Dec 9, 2024
@@ -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.
 

@@ -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.
 

@@ -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`.