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

Reply via email to