DIH should run fine from any node. It sends update requests as any other client,
and those are routed to the leader, wherever it is. It could be problematic if
node 2
gets overloaded by both doing DIH work, Overseer work and perhaps shard leader
work, and an overloaded node gets into all kind of p
Hi,
About the number of Zookeeper elements in an ensemble, you can find this
good information in this page. It applies to Solr.
https://www.cloudkarafka.com/blog/2018-07-04-cloudkarafka-how-many-zookeepers-in-a-cluster.html
- 1 Node: no fault tolerance, no maintenance possibilities
- 3 Node
Hello,
Thanks for your reply.
Yes, the CDCR buffer is disable when we check it.
We finally found that the increase of tlog files was due to the version of
Zookeeper used. We re-installed Zookeeper in the same version as the one
embedded by Solr, and this fixed the problem of non-deleted tlogs.
The Lucene PMC is pleased to announce the release of Apache Solr 8.6.1.
Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search, dynamic clustering, database
integrat
Reported in SOLR-14515 (private) and fixed in SOLR-14561 (public), released
in Solr version 8.6.0.
The Replication handler (
https://lucene.apache.org/solr/guide/8_6/index-replication.html#http-api-commands-for-the-replicationhandler)
allows commands backup, restore and deleteBackup. Each of these
Hello,
One of our Solr 6.6.2 DR cluster (target CDCR) which even doesn't have any
live search load seems to be taking 60 ms many times for the ping /
health check calls. Anyone has seen this before/suggestion what could be
wrong. The collection has 8 shards/3 replicas and 64GB memory and index
