If we had a backup node with all the data on, we'd exclude this node
when doing a release. Then if the release goes well it would start
building a brand new backup node (and the old one would becomes
obsolete and eventually deleted).
If the release does not go well (say the index data gets corrupted)
we'd discard the bad index nodes (and therefor all the corrupt data)
use the backup node from the previous release to re-populate the index
via regular replication.
However, if as you say we can't specify where shards get allocated
then we'll need to come up with a different solution. I thought it
might be possible because it must be possible to specify rules about
having a copy of the data in different data centers... or have a made
another incorrect assumption there?
On Jan 23, 6:02 pm, Berkay Mollamustafaoglu mber...@gmail.com wrote:
Afaik it is not possible to control where a replica goes. You can control
which nodes an index should go using shard allocation via tags, which you
may be able to create a config that may work.
More importantly, I don't think this would be a good way to have a hot
backup. Everything that happens to primary would also happen to replicas,
so if something goes wrong, it would go wrong with the replicas as well.
mberkay on yahoo, google and skype
On Mon, Jan 23, 2012 at 12:06 PM, snowmonkey npomf...@gmail.com wrote:
We have a cluster with 3 nodes (with 1 replica and 5 shards) and we'd
like to create a 4th node which will have a complete copy of all the
data. Is this possible? And if so how do we best achieve it? We only
want the complete copy on the new 4th node (not all nodes).
So perhaps having 2 replicas, but where I can specify the location of
one of the replicas?
FYI - the purpose of this is to create a 'hot backup' of the data
which we can use, should a release go bad and we need to roll-back.