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 > > 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. > > 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. > 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 > > > > > > >
