Solr Master High Availability

[KARHU Toni <To...@ext.oami.europa.eu>]

Hi, im looking into High availability SOLR master configurations. Does anybody have a good solution to this the things im looking into are:

*       Using SOLR replication to keep a second backup master.
*       Indexing in a separate machine(s), problem being here that the index will be different from the other machine needing a full replication to all slaves in case of failure to first master.
*       Having the whole setup replicated to another machine which is then used as a master machine if primary master fails?

Any more ideas/experiences?

Toni

**********************************************************************************************
IMPORTANT: This message is intended exclusively for information purposes. It cannot be considered as an 
official OHIM communication concerning procedures laid down in the Community Trade Mark Regulations 
and Designs Regulations. It is therefore not legally binding on the OHIM for the purpose of those procedures.
The information contained in this message and attachments is intended solely for the attention and use of the 
named addressee and may be confidential. If you are not the intended recipient, you are reminded that the 
information remains the property of the sender. You must not use, disclose, distribute, copy, print or rely on this 
e-mail. If you have received this message in error, please contact the sender immediately and irrevocably 
delete or destroy this message and any copies.

**********************************************************************************************

Re: Solr Master High Availability

[Erick Erickson <er...@gmail.com>]

Look at the repeater setup on the replication page, and instead of
"repeater", think "backup master". But you don't really need to even
do this. You can simply provision yourself an extra slave. Now, if you
master goes south, you can reconfigure any slave as the new master by
just putting the configuration file you used for the master on it and
pointing the remaining slaves at the new master. Provision another
slave and point it at the new master and you're right back where you
started.

But you have one other worry. What if your master goes south in such a
way that the index in unusable? Solr/Lucene have a lot of safeguards
built in to prevent this, but....

You can consider setting up the replicator mentioned above with a
deletion policy that keeps, say, 1 or 2 copies of the old index
around. Then only replicating, say, every day. That way, you have a
couple of days to notice the problem and a viable index to use again.

Under any circumstances, you need to create a mechanism whereby you
can re-index from a known good point. At the very least, if your
master goes down you may have uncommitted documents. Even if you have
all your documents committed, you still have to worry about the
polling interval to your backup master. So you should be ready to
re-index from the last known good point. But assuming you have a
<uniqueKey> defined, there's no problem with re-indexing documents
already in the index, the old copy will just be replaced.

Best
Erick

On Thu, Nov 17, 2011 at 7:30 AM, KARHU Toni
<To...@ext.oami.europa.eu> wrote:
> Hi, im looking into High availability SOLR master configurations. Does anybody have a good solution to this the things im looking into are:
>
> *       Using SOLR replication to keep a second backup master.
> *       Indexing in a separate machine(s), problem being here that the index will be different from the other machine needing a full replication to all slaves in case of failure to first master.
> *       Having the whole setup replicated to another machine which is then used as a master machine if primary master fails?
>
> Any more ideas/experiences?
>
> Toni
>
> **********************************************************************************************
> IMPORTANT: This message is intended exclusively for information purposes. It cannot be considered as an
> official OHIM communication concerning procedures laid down in the Community Trade Mark Regulations
> and Designs Regulations. It is therefore not legally binding on the OHIM for the purpose of those procedures.
> The information contained in this message and attachments is intended solely for the attention and use of the
> named addressee and may be confidential. If you are not the intended recipient, you are reminded that the
> information remains the property of the sender. You must not use, disclose, distribute, copy, print or rely on this
> e-mail. If you have received this message in error, please contact the sender immediately and irrevocably
> delete or destroy this message and any copies.
>
> **********************************************************************************************