n
> version 2. What you are proposing above will not work.
>
> Hopefully you have two complete sets of servers, for redundancy. It would
> be a good idea to upgrade one server set, then upgrade the other.
> SOLR-2204 is in the works to make it possible to have these versions work
> togethe
y you have two complete sets of servers, for redundancy. It would
be a good idea to upgrade one server set, then upgrade the other.
SOLR-2204 is in the works to make it possible to have these versions work
together. I don't think it's been committed yet.
Thanks,
Shawn
>
>
>
On 12/23/2011 5:41 AM, Bhavnik Gajjar wrote:
• Consider this case.
http://myserver:8080/solr/mainindex/select/?q=solr&start=0&rows=10&shards=myserver:8080/solr/index1,myserver:8080/solr/mainindex,remoteserver:8080/solr/remotedata.
In this example, consider that 'myserver' has been upgraded with S
One migration strategy is to fall back to XML parser from the javabin parser,
upgrade Solrj jars to 3.4, turn off replication, upgrade master, upgrade each
of the slaves while turning on replication. Once all slaves have been
upgraded/replication turned on - switch back to javabin parser.
Best
Have you looked at CHANGES.txt in ? It has upgrade
instructions for every release. Note that in general, newer Solr will *read*
an older index (one major revision back. i.e. 3.x should read 1.x, but 4.x
will not read 1.x. Note also that there was no 2.x solr).
The cautions in the upgrade notes are
