Upgrade the Operating System¶
When you upgrade the operating system (OS) of the hosts running Confluent Platform components, it is crucial to follow a structured approach to
minimize downtime and ensure cluster stability. This process is similar to a standard Confluent Platform upgrade but does not require
configuration changes like modifying the inter.broker.protocol.version.
Note
Confluent does not provide support for issues encountered during the operating system upgrade itself. We recommend that you reach out to your OS provider for any OS-specific issues.
Upgrade order¶
To minimize the impact of the OS upgrade, follow this recommended order:
Clients and Other Components: Start by upgrading the OS of machines running Kafka clients, ksqlDB, Kafka Connect, and other components. These components are backed by the Kafka cluster, so any issues encountered here will have a limited impact. This approach allows you to troubleshoot client-side issues without affecting the core Kafka cluster.
Kafka Brokers: After you successfully upgrade the OS on the client and component machines, proceed to upgrade the OS on the Kafka brokers, one by one. Upgrading the brokers last is the best practice because if something goes wrong, it could impact all downstream services.
Pre-upgrade checks¶
Before you shut down any Confluent Platform service or the OS itself, perform the following checks to ensure the cluster can tolerate a broker being down:
Minimum In-Sync Replicas (min.isr): Check the min.insync.replicas configuration for your topics. Ensure that the value is set to a number that allows for one broker to be down without affecting topic availability. For example, if you have a replication factor of 3, a min.insync.replicas of 2 will allow one broker to go down. You can check this setting using the following command:
kafka-configs --bootstrap-server <broker-host>:<port> --describe --entity-type topics --entity-name <topic-name>
Post-upgrade checks¶
After you upgrade the OS on a broker and restart the Confluent Platform services, perform these checks to verify that the broker has successfully rejoined the cluster and is functioning correctly:
Describe Topics: Use the kafka-topics --describe command to check the status of your topics.
kafka-topics --bootstrap-server <broker-host>:<port> --describe
Verify the following:
- Under-Replicated Partitions (URPs): Ensure there are no under-replicated partitions.
kafka-topics --bootstrap-server <broker-host>:<port> --describe --under-replicated-partitions
- In-Sync Replicas (ISR): Confirm that the broker you just upgraded is in the ISR list for the partitions it hosts.
kafka-topics --bootstrap-server <broker-host>:<port> --describe --under-min-isr-partitions