> Info you might already know: TLOG (and PULL) replicas do not index, > unless a TLOG replica is the leader, in which case it behaves exactly > like NRT. A PULL replica can never become leader. > > When you have TLOG or PULL replicas, Solr is only going to do indexing > on the shard leaders. When a commit finishes, it should be done on all > cores that participate in indexing. > > Replication of the completed index segments to TLOG and PULL replicas > will happen AFTER the commit is done, not concurrently. I don't think > there's a reliable way of asking Solr to tell you when all replications > are complete.
Thanks Shawn, it's good to have this all spelled out. Validates what we're seeing. > Does your "query only the leaders" code check clusterstate in ZK to > figure out which replicas are leader? Leaders can change in response to > problems. Yeah, exactly. Working implementation is to check `/collections/<name>/state.json` in ZK to determine the leaders, and put a watch on that node to react if the cluster state changes. I see what you're saying about determining if the replications are complete. However, querying the leaders post-commit is good enough for our particular use case, so we'll opt to keep the indexing speed as high as possible and not wait on the replication before proceeding to the next group of data. Thanks for all your help! Kyle On Tue, 7 Sept 2021 at 17:13, Shawn Heisey <apa...@elyograg.org> wrote: > On 9/7/2021 3:08 PM, Shawn Heisey wrote: > > I don't think there's a reliable way of asking Solr to tell you when > > all replications are complete. > > > You could use the replication handler (/solr/corename/replication) to > gather this info and compare info from the leader index with info from > the follower index(es). For this to be reliable, you would need to > check clusterstate in ZK so you're absolutely sure which cores are > leaders. I do not know off the top of my head what parameters need to > be sent to the replication handler to gather that info. > > Thanks, > Shawn > >
