Comments hidden inline below. Overall - we need to focus on upgrades at some point, but there is little that should stop the old distrib update process from working (multi node clusters pre solrcloud).
Hoever, we should have tests and stuff. If only the days were twice as long. On Mar 28, 2013, at 5:27 PM, Timothy Potter <thelabd...@gmail.com> wrote: > Hi Walter, > > I just did our upgrade from a nightly build of 4.1 (a few weeks before the > release) and 4.2 - thankfully it went off with 0 downtime and no issues ;-) > > First and foremost, I had a staging environment that I upgraded first so I > already had a good feeling that things would be fine. Hopefully you have a > sandbox environment where you can mess around with the upgrade first. > > On Thu, Mar 28, 2013 at 3:01 PM, Walter Underwood > <wun...@wunderwood.org>wrote: > >> There are lots of small issues, though. >> >> 1. Is Solr tested with a mix of current and previous versions? It is safe >> to run a cluster that is a mix of 4.1 and 4.2, even for a little bit? >> >> > I did a rolling upgrade and no issues. So I dropped a node, waited until > that was noticed by Zk (almost instant). This left me with a new leader > still on 4.1 and then I brought up a replica on 4.2. Then I took down the > leader on 4.1 (so Solr failed over to my 4.2 node) and brought it up to 4.2 > > > >> 2. Can Solr 4.2 run with Solr 4.1 config files? This means all of conf/, >> not just the main XML files. >> > > Afaik yes - I didn't change any configuration between 4.1 and 4.2 other > than some newSearcher warming queries and cache settings That's generally been how things work - old config works with new versions. Occasionally, things might get deprecated. That's why there is the version thing in solrconfig.xml. > > >> >> 3. We don't want a cluster with config files that are ahead of the >> software version, so I think we need: >> >> * Update all the war files and restart each Solr process. >> * Upload the new config files >> * Reload each collection on each Solr process >> >> But this requires that Solr 4.2 be able to start with Solr 4.1 config >> files. >> > > This is what I did too. > > >> >> 4. Do we need to stop updates, wait for all nodes to sync, and not restart >> until the whole cluster is uploaded. >> > > Can't help you on this one as I was not accepting updates during the > upgrade. This should generally work fine. > > >> >> 5. I'd like a bit more detail about exactly what upconfig is supposed to >> do, because I spent a lot of time with it doing things that did not result >> in a working Solr cluster. For example, for files in the directory >> argument, where exactly do they end up in the Zookeeper space? Currently, >> I've been doing updates with bootstrap, because it was the only thing I >> could get to work. >> >> > So when you do upconfig, you pass the collection name, so the files get put > under: /configs/COLLECTION_NAME > You can test this by doing the upconfig and then going into the admin > console: Cloud > Tree > /configs and verifying your updates are correct. The main different between using bootstrap and upconfig is that upconfig does not link a collection to a config set. You must have a link from a collection to a config set. The following rules apply for this: 1. If there is only one config set, when you start a new collection without an explicit link, it will link to it. 2. If a collection does not have an explicit link, but shares the name of a config set, it will link to it. 3. You can set an explicit link. Also, you can link before creating the collection - it will sit in zk waiting for the collection to find it. - Mark > > > > >> wunder >> >> On Mar 27, 2013, at 11:56 AM, Shawn Heisey wrote: >> >>> On 3/27/2013 12:34 PM, Walter Underwood wrote: >>>> What do people do for updating, say from 4.1 to 4.2.1, on a live >> cluster? >>>> >>>> I need to help our release engineering team create the Jenkins scripts >> for deployment. >>> >>> Aside from replacing the .war file and restarting your container, there >> hopefully won't be anything additional required. >>> >>> The subject says SolrCloud, so your config(s) should be in zookeeper. It >> would generally be a good idea to update luceneMatchVersion to LUCENE_42 in >> the config(s), unless you happen to know that you're relying on behavior >> from the old version that changed in the new version. >>> >>> I also make a point of deleting the old extracted version of the .war >> before restarting, just to be sure there won't be any problems. In theory >> a servlet container should be able to handle this without intervention, but >> I don't like taking the chance. >>> >>> Thanks, >>> Shawn >>> >> >> >> >> >>
