Shawn,
Indeed, we're probably already in catastrophe territory in this case. A
complete replace does indeed seem like the best option in that case.
Client is just the default solr client, `
org.apache.solr:solr-solrj:`
Mikhail,
Sounds possible, but I wonder about the cases where I would need a
Hello, Koen.
What about switching "query" alias to restored collection, and then nuking
the old one?
On Fri, Oct 4, 2019 at 10:52 PM Koen De Groote
wrote:
> Greetings.
>
> Solr 7.6, cloud.
>
> From what I've researched, backup and restore is pretty straightforward.
> BACKUP and RESTORE are colle
On 10/4/2019 1:41 PM, Koen De Groote wrote:
From what I've researched, backup and restore is pretty straightforward.
BACKUP and RESTORE are collection commands and the backup is to be put on a
shared filesystem.
So far so good.
I'm a bit concerned about the RESTORE action. A RESTORE command wi
Now, I use this. But I still want a snapshot index too.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Backup-strategy-for-SolrCloud-tp4009291p4138359.html
Sent from the Solr - User mailing list archive at Nabble.com.
: The ReplicationHandler still works when you use SolrCloud, right? can't you
: just replicate from one (or N, depending on the number of shards) of the
: nodes in the cluster? That way you could keep a Solr instance that's only
: used to replicate the indexes, and you could have it somewhere else
The ReplicationHandler still works when you use SolrCloud, right? can't you
just replicate from one (or N, depending on the number of shards) of the
nodes in the cluster? That way you could keep a Solr instance that's only
used to replicate the indexes, and you could have it somewhere else (other
d
I also think that's a good question and currently without a "use this"
answer :-)
I think it shouldn't be hard to write a Solr service querying ZK and
replicate both conf and indexes (via SnapPuller or ZK itself) so that such
a node is responsible to back up the whole cluster in a secure storage
(N
What sorts of failures are you thinking of? Power loss? Index
corruption? Server overload?
Could you keep somewhat remote replicas of each shard, but not behind
your load balancer?
Then, should all your customer facing nodes go down, those replicas
would be elected leaders. When you bring the cus
ene.apache.org
> Subject: RE: Backup strategy for SolrCloud
>
> I'm thinking about catastrophic failure and recovery. If, for some reason,
> the cluster should go down or become unusable and I simply want to bring it
> back up as quickly as possible, what's the best way to ac
I'm thinking about catastrophic failure and recovery. If, for some reason,
the cluster should go down or become unusable and I simply want to bring it
back up as quickly as possible, what's the best way to accomplish that?
Maybe I'm thinking about this incorrectly? Is this not a concern?
--
He explained why in the message. Because it is faster to bring up a new host
from a snapshot.
I presume that he doesn't need the full cluster running all the time.
wunder
On Sep 20, 2012, at 2:19 PM, Markus Jelsma wrote:
> Hi,
>
> Why do you want to back up? With enough machines and a decent
Hi,
Why do you want to back up? With enough machines and a decent replication
factor (3 or higher) there is usually little need to back it up. If you have
the space it's better to launch a second cluster in another DC.
You can also choose to increase the number of maxCommitsToKeep but it'll tak
12 matches
Mail list logo
