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?
2. Can Solr 4.2 run with Solr 4.1 config files? This means all of conf/, not just the main XML files. 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. 4. Do we need to stop updates, wait for all nodes to sync, and not restart until the whole cluster is uploaded. 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. 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 >
