Hey Jerome, Are you using Solr Cloud? If so you'll require a reindex as you hint at below (Solr committers recommend reindexing through major version jumps anyway). From memory you need to be on at least a 7.x version of Solr to be able to upgrade to 8.x and the newer 8.x releases (from about 8.5 from memory) also use a newer zookeeper version so you may have some incompatibilities which will prevent you from adding new nodes to the existing cluster with your 6.x nodes (or using another znode in the existing environment). If possible can you add your new 8.x nodes using another (newer) zookeeper instance alongside your existing infrastructure and then switch your users over to the new environment when the reindexing process is complete? Your new "temporary" group of machines would then become your primaries and your old 6.x versions would become redundant. If you have your clients access Solr via a proxy/load balancer (which is recommended best practice), and your clients access your collections via a collection alias then the switch over can appear seamless via an API call to the collections API to reroute your users to the new Solr 8.x environment.
i.e. DELETEALIAS over old Solr 6.x instance, ADDALIAS of same name to new 8.x instance (millisecond response times) With the upgrade there's been a jump in Java versions from 8.x to 11.x and a change in the default garbage collection algorithm from CMS to G1. A separate dedicated 8.x environment would enable you to test these changes in isolation and prevent any production surprises as I've occasionally seen comments on this forum from users indicating differences in resource consumption on their hosts when this jump has been made. If you're using some of the Trie... fileds in your schema they've also become deprecated in more recent versions of Solr and some of the default settings (docValues) have changed so you'll want to confirm your schema is compatible with 8.x Solr. Solr has a good list of upgrade notes with every release so it'd be worth making your way through that list as well as there's more than I can explicitly call out and I don't know what features of Solr you're using (facets, nested docs ...etc.) https://solr.apache.org/guide/8_8/solr-upgrade-notes.html Solr Upgrade Notes | Apache Solr Reference Guide 8.8.2<https://solr.apache.org/guide/8_8/solr-upgrade-notes.html> Removing base_url from Stored State. If you’re able to upgrade SolrJ to 8.8.x for all of your client applications, then you can set -Dsolr.storeBaseUrl=false to better align the stored state in Zookeeper with future versions of Solr; as of Solr 9.x, the base_url will no longer be persisted in stored state. However, if you are not able to upgrade SolrJ to 8.8.x for all client applications ... solr.apache.org Every Solr environment is different so it's recommended you run tests under your own environmental conditions to confirm the behaviour is as you expect it to be. This is how I've typically managed upgrades in the past and if you're not using Solr Cloud disregard my advice that's where all of my Solr experience resides. Cheers, Dwane ________________________________ From: jerome moliere <jer...@javaxpert.com> Sent: Saturday, 15 May 2021 7:12 AM To: users@solr.apache.org <users@solr.apache.org> Subject: Migrating huge files volume Hi all, I would like to know the best practices to migrate a mission critical Solr cluster from version 6.x to 8.x without any service shutdown. Is the double upgrade required (mandatory) ? We can introduce another temporary group of machines ro join the cluster, then we may stop the existing nodes one by one once upgrade done... In this case we have different indexes and 2 replicas per shard... Is it possible to have concurently 2 versions of SolR running in the same cluster? Of course a full reindexing seems to be required , there is no problem we have enough time ( upgrade procedure is not required to be finished in a short time). I would like to have a summary of options available , pros & cons for each one and if possible a few tips & tricks to avoid some pitfalls... If you have good pointers to share and any feedback from production upgrades they will be welcome... Thanks for your help . Kind regards