Last checked and updated on 05 Jun 2026
What Is New in Apache Kafka 0.8
This release marks a major step forward for Kafka's production readiness, introducing the replication system that became a cornerstone of its reliability.
| Category | Key Changes |
|---|---|
| New Features | Data Replication, Preferred Replica Leader Election |
| API Changes | New Producer API, Asynchronous Producer |
| Tooling | Replica Verification Tool, JMX Metrics |
| Configuration | New Broker & Producer Settings |
How did Kafka 0.8 change data durability?
The headline feature is the built-in replication system. This allows you to specify a replication factor per-topic to automatically replicate partitions across multiple brokers.
In practice, this meant we could finally tolerate broker failures without losing data. The system uses a leader-follower model where producers write to the leader and followers replicate the data asynchronously.
You control the durability guarantee with the request.required.acks producer setting. Setting this to -1 ensures the producer blocks until a write is committed to all in-sync replicas.
What new producer options were available?
Kafka 0.8 introduced a new, simpler Producer API that supported both synchronous and asynchronous operation. This was a significant upgrade from the previous version.
The async producer was a game-changer for throughput. You could just fire off messages and provide a callback class to handle the server's response, eliminating the need to block on every single produce request.
Key configuration options included producer.type (set to async or sync) and batch.num.messages to control how many messages to send in one batch for the async producer.
What tools helped manage the new replication?
Two critical tools were added to manage the new replication landscape: the replica verification tool and support for preferred replica leader election.
The replica verification tool (kafka-replica-verification.sh) would scan all replicas for a topic and report any inconsistencies. This was essential for ensuring the health of your replicated data.
Preferred replica leader election allowed you to rebalance leadership across brokers. This prevented a situation where a single broker became the leader for most partitions after a failure, which could create a performance hotspot.
How was monitoring improved?
A comprehensive set of JMX metrics was exposed for the first time, giving deep insight into the inner workings of both brokers and producers.
You could now track everything from bytes-in/bytes-out and request rates to replication-specific stats like the number of under-replicated partitions. This visibility was non-negotiable for running a stable cluster.
These metrics allowed operators to set up proper alerting, for instance, to get notified immediately if the count of under-replicated partitions rose above zero, indicating a potential problem.
FAQ
What does the 'request.required.acks' setting actually do?
This producer configuration controls message durability. acks=1 waits for the leader to acknowledge. acks=-1 waits for all in-sync replicas to acknowledge, ensuring the message survives a leader failure. acks=0 fires and forgets for maximum speed but no guarantee.
Is the new 0.8 Producer API backwards compatible?
No, the new Producer API introduced in 0.8 is not compatible with the 0.7 producer API. You had to rewrite your producer applications to migrate to this version, but the effort was worth it for the new features.
What is an under-replicated partition?
It's a partition where one or more of its replicas are not in sync with the leader. This JMX metric became a critical health check. A count greater than zero means your cluster isn't fully redundant and could be at risk if another broker fails.
Why would I need to run preferred replica leader election?
After a broker failure and comeback, the leadership assignment can become unbalanced. This tool restores the preferred leader for each partition, which helps distribute the load evenly across all brokers in the cluster for better performance.
Can I mix 0.7 and 0.8 brokers in the same cluster?
No, the replication protocol and internal metadata changes made the two versions incompatible. A rolling upgrade from 0.7 to 0.8 was not supported. You had to bring the entire cluster down to upgrade it.