We decided to go with the latest (it seems to have a lot more bug /performance fixes). The issue i mentioned was a red herring. I was able to successfully upgrade
On Tue, Mar 11, 2014 at 2:09 PM, Chris W <chris1980....@gmail.com> wrote: > Moving 4 versions ahead may need much additional tests from my side to > ensure our cluster performance is good and within our SLA. Moving to 4.4 > (just 1 month after 4.3.1 was released) gives me the most important bug > fix for reloading collections (which does not work now and have to do a > rolling restart) > > I am also ok upgrading to 4.5 but do not want to go too far without more > testing > > Either way i think i will hit the issue mentioned above > > > > On Tue, Mar 11, 2014 at 12:22 PM, Erick Erickson > <erickerick...@gmail.com>wrote: > >> First I have to ask why you're going to 4.4 rather than 4.7. I >> understand vetting requirements, but I thought I'd ask.... No use >> going through this twice if you can avoid it. >> >> On Tue, Mar 11, 2014 at 12:49 PM, Chris W <chris1980....@gmail.com> >> wrote: >> > I am running solrcloud version 4.3.0 with a 10 m1.xlarge nodes and >> using >> > zk to manage the state/data for collections and configs.I want to >> upgrade >> > to version 4.4.0. >> > >> > >> > When i deploy a 4.4 version of solrcloud in my test environment, none of >> > the collections/configs (created using the 4.3 version of solr) that >> exist >> > in zk show up in the core admin. I should also mention that, all of my >> > collection configs for solrconfig.xml have >> > >> > <luceneMatchVersion>LUCENE_43</luceneMatchVersion>. >> > >> > Should i change the lucene version to match lucene_44 (match solr >> > version?) to get it working again? >> > >> > What is the best way to upgrade to a newer version of solrcloud without >> > deleting and recreating all configs and collections? >> > >> > Kindly advise >> > -- >> > Best >> > -- >> > C >> > > > > -- > Best > -- > C > -- Best -- C
