On 10/29/2010 4:33 PM, Shawn Heisey wrote:
The recommended method of safely upgrading Solr that I've read about
is to upgrade slave servers, keeping your production application
pointed either at another set of slave servers or your master
servers. Then you test it with a dev copy of your application, and
once you're sure it's working, you can switch production traffic over
to the upgraded set. If it falls over, you just switch back to the
old version. Once you're sure it's TRULY working, you upgrade
everything else. To convert fully to the new index format, you have
the option of reindexing or optimizing your existing indexes.
I like this method, and this is the way I want to do it, except that
the new javabin format makes it impossible. I need a viable way to
replicate indexes from a set of 1.4.1 master servers to 3.1-dev
slaves. Delving into the source and tackling the problem myself is
something I would truly love to do, but I lack the necessary skills.
Since I don't have the java skills required to solve the underlying
problem, I have come up with a solution in the realm that I do
understand - my build scripts. I will update the scripts so that they
can safely work on the slave machines as well as the masters. They are
currently hard-coded to work on the masters. By turning replication off
and running the scripts against both server sets, I'll be able to do all
my testing.
IMHO this incompatibility with replication is a bug that needs to be
fixed before the official release, which is why I filed SOLR-2204. I
have found a way around it, but the workaround might not be a viable
option for everyone.
Thanks,
Shawn
