Re: Replicas for same shard not in sync

I didn’t leave it out, I was asking what it was. I’ve been reading around some more this morning though, and here’s what I’ve come up with, feel free to correct. Continuing my scenario: If you did NOT specify min_rf 5. leader sets leader_initiated_recovery in ZK for the replica with the failur

Re: Replicas for same shard not in sync

You left out step 5... leader responds with fail for the update to the client. At this point, the client is in charge of retrying the docs. Retrying will update all the docs that were successfully indexed in the failed packet, but that's not unusual. There's no real rollback semantics that I know

Re: Replicas for same shard not in sync

At the risk of thread hijacking, this is an area where I don’t know I fully understand, so I want to make sure. I understand the case where a node is marked “down” in the clusterstate, but what if it’s down for less than the ZK heartbeat? That’s not unreasonable, I’ve seen some recommendations

Re: Replicas for same shard not in sync

Ted: Yes, deleting and re-adding the replica will be fine. Having commits happen from the client when you _also_ have autocommits that frequently (10 seconds and 1 second are pretty aggressive BTW) is usually not recommended or necessary. David: bq: if one or more replicas are down, updates pres

Re: Replicas for same shard not in sync

Erick, So that my understanding is correct, let me ask, if one or more replicas are down, updates presented to the leader still succeed, right? If so, tedsolr is correct that the Solr client app needs to re-issue updates, if it wants stronger guarantees on replica consistency than what Solr pr

Re: Replicas for same shard not in sync

Erick, I was referring to the Achieved Replication Factor section of the Solr reference guide Maybe I'm misreading it. If an update succeeds on the leader but fails on the replica, it's a success for the cli

Re: Replicas for same shard not in sync

bq: I also read that it's up to the client to keep track of updates in case commits don't happen on all the replicas. This is not true. Or if it is it's a bug. The update cycle is this: 1> updates get to the leader 2> updates are sent to all followers and indexed on the leader as well 3> each rep

Re: Replicas for same shard not in sync

I've done a bit of reading - found some other posts with similar questions. So I gather "Optimizing" a collection is rarely a good idea. It does not need to be condensed to a single segment. I also read that it's up to the client to keep track of updates in case commits don't happen on all the repl

Re: Replicas for same shard not in sync

Hi, An extra tip, on top of everything that Erick said: Add an extra field to all documents, that contains the date the document was indexed. That way, you can always compare the solr documents on different machines, and quickly see what "version" exists on each machine. And you don't have to

Re: Replicas for same shard not in sync

Slow down a bit ;)... First, just to cover the bases, you have done a commit, right? The index generation on the UI screen is a bit misleading as replicas in SolrCloud don't necessarily have the same generation, that's normal. The "master/slave" bits are cruft from the older non-cloud days. So I'