Ensure your new cluster has a unique zookeeper chroot.
> On May 15, 2021, at 3:10 PM, jerome moliere <jer...@javaxpert.com> wrote: > > 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
