1. Controlled Shutdown Tool
What does the tool do?
In 0.8, each partition can have multiple replicas. These replicas are distributed across different brokers for better availability. At any given instance of time, only one of these replicas will serve reads and writes. In other words, one replica acts as the leader. When a broker needs to be shutdown (A broker can be shutdown for doing a new release, changing config etc), it would be useful to still serve the requests for the partitions on this broker using the other in-sync replicas. This is what the Controlled shutdown tool helps you to achieve. It transfers the leadership of the partitions from the broker (to be shutdown) to the other available replicas(in the in-sync set) on the remaining brokers. A summary of the steps that the tool does is shown below -
1. Finds the jmx port of the broker where the controller resides.
2. Issues a shutdown command to the controller using the port specifying the broker to be shutdown.
3. The controller finds the list of partitions the broker is currently leading.
4. For each of the partitions, the controller finds another broker that is in the "in-sync" replica set and makes it the leader for the partition.
5. For a given partition, if the controller cannot find any other replica that is in the 'in-sync" set, it fails the shutdown.
6. The shutdown tool waits for the response of the controller. If it finds that the shutdown was not successful, it retries (this is configurable) and eventually succeeds or fails based on the controller response.
Note that the shutdown tool only moves the leadership of the partitions to the other available brokers. It does not terminate the broker. This needs to be done manually after running the tool.
How to use the tool?
bin/kafka-run-class.sh kafka.admin.ShutdownBroker --zookeeper localhost:12913/kafka --broker #brokerId# --num.retries 3 --retry.interval.ms 60
The tool takes in a list of zookeeper hosts (including the namespace if any) and the broker id that needs to be shutdown. Both these arguments are mandatory. The tool also allows to specify an optional number of retries and the interval between those retries. If the shutdown attempt by the controller fails, the tool retries after the specified interval.
FAQ
How does the tool work when ack = 0?
When the leadership for a partition is changed, the clients (producer and consumer) gets an error when they try to produce or consume from the old leader when they wait for a response. The client then refreshes the partition metadata from zookeeper and gets the new leader for the partition and retries. This does not work for the producer client when ack = 0. This is because the producer does not wait for a response and hence does not know about the leadership change. The client would end up loosing messages till the shutdown broker is brought back up.
What happens when there are no other replicas in the "in-sync" set for a partition?
When a partition does not have any other replicas that are in the "in-sync" set, the tool fails to shutdown the broker. This is to ensure that we do not have an unclean leader election (choosing a replica that is outside the "in-sync" set) and thereby causing data loss.
2. Preferred Replica Leader Election Tool
What does the tool do?
With replication, each partition can have multiple replicas.