On 7/6/23 14:00, Oakley, Craig (NIH/NLM/NCBI) [C] wrote:
We are having problems transitioning Leader/Follower replication to Solr9.2.1
In Solr8.5 and below, what was then called Master/Slave replication had the
annoying problem that, even though we specified httpBasicAuthUser and
httpBasicAuthPassword, it would always attempt to connect first without a
password before retrying with a password. This made solr.log noisy with lots of
unnecessary login failures: but at least it worked.
In general, this is how basic auth via http works. The client first
attempts the request without any credentials, and receives a 401 response.
At this point, a browser would see the 401 response and display a popup
asking for username/password.
Then on future requests to that server in the current session, the
browser sends the supplied credentials on every request to that server.
If you are supplying credentials in the replication config, it should
NOT follow that pattern ... the credentials should be always used.
Now when we are preparing to upgrade to Solr9.2.1, we are having issues with
the following:
2023-07-06 15:46:53.315 INFO (indexFetcher-39-thread-1) [ ]
o.a.s.h.IndexFetcher Last replication failed, so I'll force replication
2023-07-06 15:46:53.320 WARN (indexFetcher-39-thread-1) [ ]
o.a.s.h.IndexFetcher Leader at:
http://[REDACTED]/solr/sequence2_shard1_replica_n1 is not available.
The info above is valid for Solr running in standalone mode. But those
core names indicate that you are running in SolrCloud mode.
In cloud mode, Solr handles all replication. Don't attempt to actually
configure the replication handler in cloud mode ... Solr will handle it
all for you, and will even automatically take care of authenticating the
requests. You don't need to configure the replication handler at all.
If you are using the replication handler as a "back door" to copy
indexes to a separate Solr install, a better option is to use the
backup/restore functionality in the Collections API.
Thanks,
Shawn
