4.6.x to 4.7.x Migration Guide
This is a minor HiveMQ upgrade. HiveMQ 4.7 is a drop in replacement for HiveMQ 4.6.x.
You can learn more about all the new features HiveMQ 4.7 provides in our release blogpost
|HiveMQ 4.7 is prepackaged with all the HiveMQ Enterprise Extensions (disabled), the open-source MQTT CLI tool, and the load-testing tool HiveMQ Swarm (both located in the tools folder). If necessary, adapt your deployment pipeline to accommodate these changes.|
Upgrade a HiveMQ Cluster
Rolling upgrades are supported and it is possible to run HiveMQ version 4.6 and version 4.7 simultaneously in the same cluster. By default, the HiveMQ cluster enables all new cluster features when all nodes are upgraded to the new version. No manual intervention is required.
Please follow the instructions in our user guide to ensure a seamless and successful rolling upgrade.
For more information, see HiveMQ Clustering Documentation.
Upgrade a Single-node HiveMQ Instance
Create a backup of the entire HiveMQ 4.6.x installation folder from which you want to migrate
Install HiveMQ 4.7 as described in the HiveMQ Installation Guide
Migrate the contents of the configuration file from your old HiveMQ 4.6.x installation
To migrate your persistent data, copy everything from the
datafolder of your backup to the data folder of the new HiveMQ 4.7 installation. The first time you start HiveMQ 4.7, the file storage formats of the persistent data from your previous installation are automatically updated in the new persistent storage.
Configuration File Changes
You can upgrade from HiveMQ 4.6.x to HiveMQ 4.7 without making changes to your configuration file.
Persistent Data Migration
When you migrate, HiveMQ 4.7 automatically updates the file storage formats of all the data that you copied into your new data folder.
To migrate the persistent data, you must copy everything in the data folder of the previous HiveMQ 4.6.x installation to the data folder of your new HiveMQ 4.7 installation.
cp -r /opt/hivemq-4.6.3/data/* /opt/hivemq-4.7.0/data/
The first time you start HiveMQ 4.7, the file storage formats of the persistent data from your previous installation are automatically updated in the new persistent storage.
Default Authentication Behavior
Since version 4.3, HiveMQ only allows MQTT clients to connect if a security extension is present.
For testing purposes, HiveMQ includes a
Native SSL Default Communication Protocols
Due to security concerns, the OpenJDK Java platform no longer enables TLSv1 and TLSv1.1 by default. As a result, Java applications such as HiveMQ that use TLS to communicate now require TLS 1.2 or above to establish a connection.
To align with the OpenJDK Java platform, from HiveMQ 4.7 onwards, HiveMQ only enables the following TLS protocols by default for native SSL:
If you still need to support legacy TLS versions such as TLSv1 or TLSv1.1 for your Native SSL implementation, you must explicitly enable the versions in your
<?xml version="1.0"?> <hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ... <listeners> ... <tls-tcp-listener> <tls> ... <!-- Enable specific TLS versions manually --> <protocols> <protocol>TLSv1.1</protocol> </protocols> <native-ssl>true</native-ssl> ... </tls> </tls-tcp-listener> </listeners> ... </hivemq>
HiveMQ Kubernetes Operator
The most significant changes in this release include the following:
HiveMQ 4.7 (chart 0.9.0) requires a mandatory update of your CustomResourceDefinition. The update does not require downtime. To easily apply the new CRD, use
kubectl apply -f https://raw.githubusercontent.com/hivemq/helm-charts/master/charts/hivemq-operator/crds/hivemq-cluster.yaml.
HiveMQ 4.7 (chart 0.9.0) requires a 4.7.0 or newer image of HiveMQ and the HiveMQ Operator.
The HiveMQ Helm Chart now uses v1 CustomResourceDefinition by default. The v1 CRD requires Kubernetes 1.16 or higher. If you run a version of Kubernetes that is lower than 1.16, use
kubectl apply -f https://raw.githubusercontent.com/hivemq/helm-charts/master/manifests/legacy/v1beta1-hivemq-cluster.yamlto apply the CRD directly.
The HiveMQ Kubernetes Operator now supports the stable v1 API version of CustomResourceDefinition.
HiveMQ now runs with a more restricted pod and container security context by default. Additionally, security context configurations are now customizable.
For a complete list of changes, see the HiveMQ Helm Charts Changelog.