Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of solr@elyograg.org designates
 166.70.79.219 as permitted sender)
Message-ID: <5154D1C9.3000800@elyograg.org>
Date: Thu, 28 Mar 2013 17:27:05 -0600
From: Shawn Heisey <solr@elyograg.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: solr-user@lucene.apache.org
Subject: Re: Solr Cloud update process
References: <5628888F-AFA2-4927-8A25-B9C442774CCD@wunderwood.org>
 <515340D4.9080504@elyograg.org>
 <5C76C6D4-D431-4523-AEF2-BBFAEB074EDC@wunderwood.org>
In-Reply-To: <5C76C6D4-D431-4523-AEF2-BBFAEB074EDC@wunderwood.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 3/28/2013 3:01 PM, Walter Underwood 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?
>
> 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.

Solr 4.2 will work just fine with config files from 4.1.

I have a SolrCloud that was running a 4.1 snapshot.  I upgraded it to 
4.2.1 built from source with no problem.  The exact steps that I did were:

1) Replace solr.war.
2) Replace lucene-analyzers-icu-4.1-SNAPSHOT.jar with 
lucene-analyzers-icu-4.2.1-SNAPSHOT.jar
3) Upgrade all of my jetty jars from 8.1.7 to 8.1.9.
4) Repeat the steps above on the other server.
5) Use zkcli.sh to 'upconfig' a replacement config set with only one 
change - luceneMatchVersion went from LUCENE_40 to LUCENE_42.
6) Restart both Solr instances.

Upgrading jetty is something applicable to only my install, and was not 
a necessary step.  The jetty version currently included in Solr as of 
4.1 is 8.1.8 - see SOLR-4155.

The upconfig command on zkcli.sh will add/replace the config set with 
the one that you specify.  It will go into /configs in your zookeeper 
ensemble.  If you specify a chroot on your zkhost parameter, then it 
will go into /path/to/chroot/configs instead.  Most of the time a chroot 
will only have one element, so /chroot/configs would the most likely 
location.

I actually would like more detail on upconfig myself - what if you 
delete files from the config directory on disk?  Will they be deleted 
from zookeeper?  I use a solrconfig that has xinclude statements, and 
occasionally those files do get deleted or renamed.

Thanks,
Shawn