Well, other than testing he heck out of the 3.4 before putting it into
production, the answer is "how long will it take you to install new
software and replicate?"
Note, I'm not saying that I know of any instabilities in 3.4, just that
thoroughly testing a major upgrade is *always* called for. 3.4 is better
tested than 1.4 ever was in terms of unit tests....
Here's a suggested cut-over path, assuming you have a window
in which you can handle your full search load on one slave.
1> create a full index on 3.4. You'll be better off re-creating the entire
index by 3.4. This can be on your separate server.
2> take your master out of service/disable replication and move
the index over to it and verify it's operational.
3> take one slave out of service, install 3.4 and point it at your master.
4> Once replication is complete, put this slave back in service and
take the other slave out of service.
5> install 3.4 on the slave, replicate, and put it back in service.
Really, you should be able to predict this pretty reliably by trying it on
a spare machine to work the kinks out.
Best
Erick
On Fri, Sep 30, 2011 at 5:54 AM, Pranav Prakash <pra...@gmail.com> wrote:
> Hi List,
>
> We have our production search infrastructure as - 1 indexing master, 2
> serving identical twin slaves. They are all Solr 1.4 beasts. Apart from this
> we have 1 beast on Solr 3.4, which we have benchmarked against our
> production setup (against performance and relevancy) and would like to
> upgrade our production setup. Something like this has not happened before in
> our organization. I'd like to know opinions from the community about what
> are ways in which this migration can be performed? Will there be any
> downtimes, if so for how many hours? What are some of the common issues that
> might come along?
>
> *Pranav Prakash*
>
> "temet nosce"
>
> Twitter <http://twitter.com/pranavprakash> | Blog <http://blog.myblive.com> |
> Google <http://www.google.com/profiles/pranny>
>
