Aiven for Kafka versions 1.x, 2.0, 2.1, 2.2 reach EOL on February 1st 2021. For a vast majority of our users, this means that their services will be upgraded automatically upon EOL to the latest supported version of Kafka on Aiven, which at this time is v2.6.

Before you begin

Please read through the notable changes in various versions of Apache Kafka: 1.1.0, 1.1.1, 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0, 2.5.0, 2.6.0. This will help you gain an understanding of what to expect with this upgrade.

Many of these changes may be not relevant to you or concern the client side (Kafka clients, Kafka Streams). Do note that it's not necessary to upgrade the client libraries immediately with the server-side upgrade (see a note on client protocol compatibility below).

We would like to emphasize on some of the changes:

  • KIP-225 changed the metric records.lag to use tags for topic and partition. The original version with the name format {topic}-{partition}.records-lag was deprecated in version 1.0.0 and removed in version 2.0.0.
  • In version 2.0.0, the default offset retention time was increased from 1 day to 7 days.
  • In version 2.0.0, the default value of ssl.endpoint.identification.algorithm was changed to https, which performs hostname verification. Set it to an empty string ("") to restore the previous behavior.
  • In version 2.0.0, API version tag was added to the metric,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower|...}. This metric became,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower|...},version={0|1|2|3|...}.
  • In version 2.2.0, the default consumer group id has been changed from the empty string ("") to null. Old clients that rely on the empty string group id will now have to explicitly provide it as part of their consumer configuration. For more information see KIP-289.

Upgrading to v2.6 from Aiven Console

Go to the Overview page of the affected service, click on "Upgrade Available" button as annotated in the screenshot below and follow the instructions.

During the upgrade process, your cluster will be running mixed versions. For example, you may have one broker on 1.1 and two brokers on 2.6.

Please note that Kafka has a "bidirectional" client protocol compatibility policy. In other words, new clients can talk to old servers, and old clients can talk to new servers. This allows you to upgrade either clients or servers without experiencing any downtime.

Did this answer your question?