A Major SearchStax Managed Search service Solr upgrade means going from Solr 7.x to Solr 8.x or from Solr 8.x to Solr 9.x. These are non-trivial upgrades because they involve changes to Solr schema, potentially breaking changes to search or indexing functionality, and potentially shifts in hardware utilization for similar traffic and usage patterns.
Customers are encouraged to follow the Self-Managed Upgrade path to allow for proper testing and validation. For a major version upgrade, the backup/restore path is not available.
Below are areas to consider when planning for an upgrade:
Upgrade Tasks to Consider
| Task | Why it’s important |
|---|---|
| Test and refine data models | Solr schema typically changes between Major Versions which can force an unexpected need to rebuild Solr data. |
| Address Solr API deprecations or replacements. Review Solr upgrade notes. | Prevents accidental loss of functionality and elevated error rates. |
| Rebuild outdated Lucene data formats | If an in-place upgrade was done previously, Solr may reject the indexed data if it’s in a Lucene format older than n-1. This could force unplanned downtime for index rebuilds. |
| Performance test and upsize RAM accordingly | JVM, which is part of the deployment’s RAM, utilization changes across Major and even Minor Versions and can require an unplanned deployment hardware upgrade for equivalent traffic patterns. |
| Perform Disaster Recovery drills | This is a customer responsibility. This is a great opportunity to test DR before switching live traffic to the new version deployment. |
Best Practice for a Self-Managed Upgrade
To upgrade from one major Solr release to a different one, the best practice is as follows:
- Your current deployment is deployment A.
- Create a new deployment using the desired version of Solr, deployment B.
- Configure B. Note that there will probably be significant changes to the Solr schema if this is a major-Solr-version upgrade.
- Load your data into deployment B.
- Validate the behavior of deployment B.
- Switch over from A to B.
- Delete deployment A.
You will be billed for the number of days that each deployment was active during the month. Running two deployments side-by-side during the transition period results in a small increase in your monthly bill.
For a list of currently supported versions of Solr, refer to Solr Versions Supported by SearchStax Managed Search.