On 3/16/2024 11:52, mtn search wrote:
While following up on a request to verify replication within our Solr farm,
I discovered a state that is puzzling. For a number of Solr 6 cores I see
the master and the core replicating to the master having the same doc
count, indexVersion number, and LastUp
Follow on question -
While following up on a request to verify replication within our Solr farm,
I discovered a state that is puzzling. For a number of Solr 6 cores I see
the master and the core replicating to the master having the same doc
count, indexVersion number, and LastUpdatedDate values,
Thanks Shawn! That is helpful information.
Matt
On Fri, Mar 8, 2024 at 2:26 AM Shawn Heisey
wrote:
> On 3/7/24 16:22, mtn search wrote:
> > Realized my question was not very clear. It pertains to when we bring
> the
> > primary cores back up, after X number of days, how does Solr determine to
On 3/7/24 16:22, mtn search wrote:
Realized my question was not very clear. It pertains to when we bring the
primary cores back up, after X number of days, how does Solr determine to
do an standard replication of updates or a full replication of the set of
index files.
There is no "tipping poi
Realized my question was not very clear. It pertains to when we bring the
primary cores back up, after X number of days, how does Solr determine to
do an standard replication of updates or a full replication of the set of
index files.
On Thu, Mar 7, 2024 at 4:12 PM mtn search wrote:
> Hello,
>
Hello,
While building/deploying a new SolrCloud based solution our team is still
maintaining a Solr 6 M/S large deployment, and I have a replication
question.
We are in a situation where we likely need to take down our set of primary
slave cores. My understanding is that there is a point where S
Thanks again Dave, helpful information! Yes, we have one slave as primary
- serving queries, and the other for failover... We are in a slow process
of moving to SolrCloud Solr 8/9, but still a lot of work is given to
maintaining our Solr 6 deployment. So learning more about this type of
replica
I’ve seen this happen where the slaves behave differently from each other or
get the version of the index out of whack, usually it happened if the latency
of one slave vs another to the master isn’t the same. But again, that’s why you
should have at least double the size on your slaves for the i
Thanks Dave! Yes, we ran into this issue yesterday and do need to review
the disk space we have available (as well as the large size of our cores).
Also, there was some interesting context for this event. We have 2 slaves
on separate servers replicating from the master. One slave replicated fine
Only an optimize or a large fragment merge would cause a large file deposits
there. That’s why “slaves” should always have double the index size available
as solr will decide on its own when to merge or optimize on the master so the
slaves need to be ready for double the size, and the master nee
As I go back through
https://solr.apache.org/guide/6_6/index-replication.html, the picture is
filling in a little more. My guess the tmp dir referenced, is the
index. dir.
Very interested in cases that might generate a full replication. To my
knowledge no optimize commands has been issued agains
Hello, I am learning more about replication as I maintain a large Solr 6
set of Solr servers configured for Master/Slave.
I noticed during some replication activities in addition to the original
index dir under the core name on the file system is a dir named "index"
with a timestamp. index.. Fi
12 matches
Mail list logo
