With the recent release of Solr 8.0 you may be wondering if it is worth migrating to the new version and how to do it. Is it possible to upgrade your cluster without major downtime? Is it possible to upgrade to new version using rolling restarts? We will try to answer that question in this blog post.
Which version to migrate from
The first thing that we should mention are the changes to LIR and recovery algorithm introduced with Solr 7.3. Because of those changes it is impossible to use rolling restarted when migrating from version that is older then 7.3. In such cases you need a full cluster restart.
We should also remember that Apache Lucene library version 8.0 and thus Solr 8.0 is not able to read data created with Solr 5.x. Because of this you will have to go through each major version up to 8.x and rewrite your data on each or just created new cluster and re-idnex your data.
Migrating from Solr 7.3 and newer
If you will be migrating from Solr 7.3 or newer you can upgrade your cluster to 8.0.0 without the need of full cluster rrestart and just by using rolling restarts. This is how the procedure should look like:
- Prepare the cluster for upgrade, create data backup, Zookeeper data backup and so on.
- Turn off one Solr instance.
- Update the turned off instance to 8.0.
- Add -Dsolr.http1=true parameter to SOLR_OPTS property in solr.in.sh configuration file.
- Launch the updated Solr instance.
- Wait for the cluster to stabilize (there may be a need of data replication, so it may take a while).
- Start the upgrade of the next Solr instance, so begin with point 2).
After being done with all the instances we need to do one more round of node by node restarts. This time we need to do the following for each instance belonging to our cluster:
- Turn off a single Solr instance.
- Remove the -Dsolr.http1 parameter from the SOLR_OPTS property in the solr.in.sh configuration file.
- Start the modified Solr instance.
- Wait for the cluster to stabilize.
- Repeat from point 1) for the next instance.
Additional restarts round – but why?
You may be asking yourself why we do the additional, second round of restarts once we have all the nodes upgraded to version 8. The problem lies in the foundation of the changes that were introduced to the newest version of Solr. With Solr 8.0.0 the internal communication between the nodes is done using the HTTP/2 protocol. The usage of that protocol and the changes done to introduce it resulted in more robustness and higher efficiency of the inter-node communication. However the downside is that the changes are not compatible with the earlier Solr versions. That’s why, when we have 7.x and 8.0 Solr version in the cluster we need to be sure that they are compatible with each other. Once all the nodes are running the newest version of Solr we can finally turn off forcing the backwards compatibility and fully use the latest and greatest features introduced in Solr 8.0. This is why we first add the -Dsolr.http1=true parameter and then remove it.
Should I be afraid of the upgrade
Each migration comes with a degree of risk and possible complications. Because of that it is crucial to plan and prepare. We shouldn’t do the upgrade during peak hours or during the period of time where we expect a higher load on the cluster. We should think if it is possible to minimize or completely turn off indexing during the upgrade time – it will minimize the time needed for the instance restart. It is also crucial to be able to roll back if something goes wrong, though it is not always possible, especially if you have a large amount of data. You should think about it all and prepare. Good luck with your upgrades