Upgrading Control Center

Important

  • By default, the upgrade process will preserve the last 15 minutes of historical data. There are two properties that allow you to control how much history will be preserved: confluent.metrics.topic.skip.backlog.minutes for broker metrics and confluent.monitoring.interceptor.topic.skip.backlog.minutes for stream monitoring. Preserving history for longer will slow down restore time of Control Center after the upgrade, while preserving less history will speed the process up.
  • Every version of Control Center (even minor upgrades) will re-create a new set of topics, since topic names contain the full version number. It is a good idea to remove the old ones to avoid confusion.
  • For Confluent Platform version compatibility, see the compatibility matrix.

Upgrading to 6.2.2 or later

If you are upgrading your deployments to Confluent Control Center 6.2.2 or newer from an earlier version of Confluent Platform, you must also upgrade Schema Registry to the same version (6.2.2 or newer). Starting with Confluent Platform 6.2.2, Schema Registry provides a new endpoint for Confluent Control Center to filter visible Schema Registry clusters to support Control Center interaction with an RBAC enabled Schema Registry, and Control Center is upgraded to call this endpoint. Control Center versions 6.2.2 and newer are not compatible with pre-6.2.2 versions of Schema Registry. Therefore, if you upgrade Control Center from pre-6.2.2, you must also upgrade Schema Registry. (You can run an older version of Control Center with a newer Schema Registry, but you will not get the benefit of the improved interaction of Control Center with RBAC enabled registries.)

More details are provided under Upgrade Schema Registry, and in the Confluent Platform Component Changelogs for Version 6.2.2 under DGS-2570 for Schema Registry and DGS-2570 for Control Center.

Upgrading from 6.0.1 or 6.0.2 to 6.1.0 or later

In most cases, we recommend you upgrade Confluent Control Center last among the Confluent Platform components. However, if you are upgrading from 6.0.1 or 6.0.2 to 6.1.0 or later, you should upgrade Confluent Control Center first, and then upgrade your Kafka brokers to avoid Confluent Control Center instability. If you have already upgraded your Kafka brokers and Confluent Control Center crashes, upgrade Confluent Control Center and the situation should resolve itself.

Upgrading to version 6.0.1

Version 6.0.1 of Confluent Platform includes the option to enable the Cluster Registry for Control Center, which creates a more user-friendly RBAC role binding experience and enables centralized audit logging.

Note

For details on all new feature flags for cluster registry in Control Center, see the section on Cluster Registry Settings.

Upgrading from 6.0.0 to 6.0.1

  1. Export your cluster information from the command store and then import it into cluster registry using the migration scripts described below.

  2. Configure Control Center to talk to MDS and RBAC.

  3. Add the following property to the control-center.properties file:

    confluent.metadata.cluster.registry.enable=true

Upgrading from 5.5.x to 6.0.1

To upgrade existing Control Center components from versions 5.5.x and prior to 6.0.x, you need to transition your existing cluster data from command store to cluster registry. You can do this easily using import and export scripts.

  1. Export your cluster information from the command store and then import it into cluster registry using the migration scripts described below.

  2. Configure Control Center to talk to MDS and RBAC.

  3. Add the following property to the control-center.properties file:

    confluent.metadata.cluster.registry.enable=true

Migrating cluster data with import and export scripts

Important

Only MDS broker super.user or MDS broker SystemAdmin roles can successfully execute the migration scripts.

Export Script

To export cluster information from the command store into a .json file:

  1. Confirm that your Kafka broker is up and running.

  2. Run the export command script:

    ./control-center-export --cluster controlCenterPropertiesFilePath --outfile outputfilePath
    controlCenterPropertiesFilePath

    The path to the Control Center properties file.

    outputfilePath

    The path for the .json file where you want save your output.

Import Script

To read the cluster information from the provided .json file and register the clusters with cluster registry:

  1. Confirm that MDS is up and running.

  2. Run the import command script. You can specify the MDS credentials and URL in a properties file, or specify the MDS URL as a command line argument, and be prompted for the username and password:

    cluster-information-migration-script [-i import] [-u url] [-p mds-properties-file] -f clusters-file
    mds-properties-file

    A properties file that contains the the MDS URL, username, and password. This file should have contents similar to the following:

    username=<mds-username>
password=<mds-password>
url=<http://mds-url:8090>
    url

    URL for the MDS server. If URL is passed, you will be prompted for the username and password.

    clusters-file

    The .json file for importing and exporting cluster information.

Upgrading from version 3.1.x and later

  1. Upgrade Apache Kafka® brokers to your target Confluent Platform release. Follow instructions in Confluent Platform Upgrade Guide.

  2. Upgrade the monitoring interceptors in all Kafka clients to your target Confluent Platform version (this is optional if you are using Confluent Platform interceptors 3.1 version and later).

  3. Stop the Control Center process.

  4. Make a backup of your current version configuration file. For example, copy and rename as control-center-3.1.properties.

    sudo cp /etc/confluent-control-center/control-center.properties /etc/confluent-control-center/control-center-3.1.properties

  5. Upgrade Control Center packages to your target version.

  6. Edit the Control Center properties file. Configuration property names may have changed between versions.

    • If you are running against a secured cluster you need to update your security configs. Properties named confluent.controlcenter.streams.{producer,consumer}.{sasl,ssl}.* are now confluent.controlcenter.streams.{sasl,ssl}.*
    • You can control the amount of historical stream monitoring data Control Center will process after the upgrade (which can take some time), by setting confluent.metrics.topic.skip.backlog.minutes for broker metrics and confluent.monitoring.interceptor.topic.skip.backlog.minutes for stream monitoring. They default to 15 minutes. Setting them to shorter period will allow Control Center to catch up and show current data faster, at the expense of not processing old data.

  7. Start Control Center. For more information about starting Confluent Platform, see On-Premises Deployments.

    <path-to-confluent>/bin/control-center-start <path-to-confluent>/etc/confluent-control-center/control-center.properties

  8. If you have authentication and authorization configured, you must run control-center-set-acls to give Control Center permission to create topics. For more information, see Configuring Control Center to work with Kafka ACLs.

Upgrading from version 3.0.x

  1. Upgrade Kafka brokers to Confluent Platform 3.1

  2. Upgrade the monitoring interceptors in all Kafka clients to Confluent Platform 3.1

  3. Stop the Control Center process

  4. Copy the 3.0.x configuration file

    sudo cp /etc/confluent-control-center/control-center.properties /etc/confluent-control-center/control-center-3.0.properties

  5. Upgrade Control Center packages to Confluent Platform 3.1

  6. Reset the application (deleting internal state)

    # Use the same properties file you used to launch |c3-short|
# From 3.0.1
/usr/bin/control-center-3_0_1-reset /etc/confluent-control-center/control-center-3.0.properties
# From 3.0.0
/usr/bin/control-center-3_0_0-reset /etc/confluent-control-center/control-center-3.0.properties

  7. Edit the Control Center properties file. Some configuration property names have changed

    • If you had set the confluent.controlcenter.name parameter, we suggest changing the value to reflect the new version (e.g. _confluent-controlcenter-3-1-0). This isn’t strictly necessary but a good precaution in case any step of the reset failed.
    • You can control the amount of historical stream monitoring data Control Center will process after the upgrade (which can take some time), by setting confluent.metrics.topic.skip.backlog.minutes for broker metrics and confluent.monitoring.interceptor.topic.skip.backlog.minutes for stream monitoring. They default to 15 minutes. Setting them to shorter period will allow Control Center to catch up and show current data faster, at the expense of not processing old data.

  8. Start Control Center

    /usr/bin/control-center-start /etc/confluent-control-center/control-center.properties