Hi guys (Shawn.Dwane & others) thanks for your support... My problem is tricky , I will try to summarize the constraints : - existing Solr with Zookeeper cluster , I cannot migrate Zk ensemble cluster separately because it is used by other applications (kafka ...) or I should change the current config to switch to the new version - running version 6.x JDK 8 on RH 6.2 (?), target config is OpenJDK11 on RH 8.x - 2 indexes and different shards (number depends from the target environmen/volumet) - we have 4 environments to migrate dev/staging (no important data here) and production + another (less important but customers facing) - production cluster , so because of the SLA the maximum down time is 4 hours and I am sure that it is not sufficient to reindex more than 1 billion of documents - for the moment I don't know the schema used but sure I will have access to the old version soon - SolarJ clients to be migrated too (customers would like not to upgrade these clients but it seems to be mandatory judging by the docs & your feedbacks)
On my todo list I already have written some points: - build the new cluster independently from the existing one - try to use the same Zk ensemble for both clusters ( there is no problem with recent Zk on JDK 11 with old Solr 6 running JDK 8 ?) - migrate the config files - migrate the JVM config : as mentionned by Dwane , of course we 'll try to get the best options offered by new JVM (ZGC or G1 , we 'll need some benchmarks to choose the best option) then reindexing full documents list... So the switch from one cluster to the other will be a network trick only routing traffic from one cluster to the other... Your expert advices strengthen my idea, but I fear to forgive an important step ..... You already helped me to paint an approximate procedure .... Thanks again for your support. On Sat, May 15, 2021 at 5:27 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 5/14/2021 3:12 PM, jerome moliere wrote: > > 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... > > If you have an index that has ever been touched by a 6.x version, you > can't use it in 8.x, even if you first upgrade it with a 7.x version. > It will fail. Reindexing is required. Jumping more than one major > version was iffy and not recommended before 6.x, now it is explicitly > enforced as not possible. The enforcement is done by Lucene. > > > Is it possible to have concurently 2 versions of SolR running in the same > > cluster? > > It would not be recommended at all to run two different major versions > in one cluster. I am assuming SolrCloud here, where the nodes are > always talking to each other. > > > 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... > > Build the new cluster separately from the old one. They could share the > same zookeeper ensemble by setting up the new cluster with a different > chroot. > > Create new config files for the indexes with the new version examples as > starting points. > > Build the indexes from scratch on the new cluster. > > Switch the URLs in your application to point to the new cluster. > > Thanks, > Shawn > -- J.MOLIERE - Mentor/J
