liveBook · Manning

Replica

As explained in Apache Kafka in Action

A Kafka replica is a copy of a partition maintained on a broker for fault tolerance and high availability.

A Kafka replica is a copy of a partition on a broker. Replicas keep a topic available when a broker fails: another running broker can take over rather than waiting for a backup to be restored. Backups remain a separate responsibility; Kafka does not provide cold-replication backups. section 4.2.3 section 1.3

Set the replication factor per topic. A factor of three requires at least three brokers and gives each partition three replicas. One is the leader; followers continuously copy new messages from it. Producers and consumers normally communicate with the leader, not the followers. section 4.2.3

Create and inspect a replicated topic

On a three-broker cluster, run `kafka-topics.sh --create --topic products.prices.replication --partitions 3 --replication-factor 3 --bootstrap-server localhost:9092`. Then run `kafka-topics.sh --describe --topic products.prices.replication --bootstrap-server localhost:9092` to inspect each partition’s leader, replicas, and in-sync replicas (ISR). Asking those three brokers for a replication factor of four fails. section 4.2.3

$ kafka-topics.sh \
    --describe \
    --topic products.prices.replication \
    --bootstrap-server localhost:9092
Topic: products.prices.replication PartitionCount: 3 ReplicationFactor: 3
Configs:    #1
Topic: products.prices.replication Partition: 0 Leader: 2 Replicas: 2,1,3
Isr: 2,1,3 Elr:   #2
Topic: products.prices.replication Partition: 1 Leader: 3 Replicas: 3,2,1
Isr: 3,2,1 Elr:
Topic: products.prices.replication Partition: 2 Leader: 1 Replicas: 1,3,2
Isr: 1,3,2 Elr:

The description shows three replicas for each partition, with leadership spread across brokers 2, 3, and 1. section 4.2.3

If a leader’s broker fails, the cluster controller triggers an election to promote a replica. Clients can request updated metadata and reconnect to the new leader; fetching may pause briefly during the election. section 7.4

Producer acknowledgments determine when a write is confirmed:

  • `acks=all` (or `acks=-1`) waits until all in-sync replicas have received the message—not necessarily every configured replica. section 5.1.1
  • `acks=1` confirms when the leader receives the message. It reduces acknowledgment latency, but an immediate leader failure before followers receive the message can lose it. section 5.1.1
  • `acks=0` waits for no acknowledgment. It can improve performance but does not guarantee successful persistence. section 5.1.1

How Apache Kafka in Action covers it

How deep it goes
Explains topic-level replication factors, leader–follower behavior, inspection, failover, and acknowledgment trade-offs without detailing replica-election internals.
Examples
Creates and describes a three-partition, three-replica product-prices topic, then contrasts `acks=all`, `acks=1`, and `acks=0`.
What it assumes
Builds on topics, partitions, and brokers while introducing replication through the familiar problem of restoring backups after failures.
What you can do after
Operate/configure it by setting a feasible replication factor, inspecting replica assignments, and choosing producer acknowledgments with their reliability trade-offs in mind.
How it connects
Connects replicas to partitions, brokers, leaders, followers, in-sync replicas, producer acknowledgments, and client metadata.
Cover of Apache Kafka in Action
liveBookmanning.com
Read Apache Kafka in Action on liveBook Get the book at manning.com

Also explained in

Compare how 12 books explain replica →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Apache Kafka in Action. The section links point to the parts of the book it draws on.