My apologies. We're running 2 different sets of SOLR instances, the version
with the replication problems is 6.2.0 and NOT 4.8.0.
After reading your questions, I double checked the config and we're set to
autoCommit after a LOOOOONG time.
<autoCommit>
<maxTime>36000000</maxTime>
<openSearcher>true</openSearcher>
</autoCommit>
Also using softCommit as well:
<autoSoftCommit>
<maxTime>60000</maxTime>
</autoSoftCommit>
After looking at our other servers, I changed the autoCommit maxTime down to
180000 to match. Hoping this might be our issue ;-) I'll report back in a
bit though!
Thanks for the reminder about commits. We may have forgotten to change these
values when these new servers got setup.
Scott
-----Original Message-----
From: Andrea Gazzarini [mailto:gxs...@gmail.com]
Sent: Friday, March 10, 2017 3:12 AM
To: solr-user@lucene.apache.org
Subject: Re: SOLR 4.8.0 Master/Slave Replication Issues
Hi Scott,
that could depend on a lot of things. Some questions:
* What is your commit policy? Explicit / auto / soft / hard ...
* "Other days things are off by a small amount between master and
slave"...what do you mean exactly? What is the behaviour you see in
terms of index versions between nodes?
* Any error / message in the log file?
Honestly I never used Solr 4.8.0 (this specific version) but I have a lot of
customers with other 4.x (mostly 4.10.4) master / slave configuration and they
don't have such problems.
Best,
Andrea
On 09/03/17 22:26, Pouliot, Scott wrote:
> So we've been having oddball replication issues between master and slave (Not
> SOLRCloud) for a few weeks now. Some days...everything lines up just fine.
> Other days things are off by a small amount between master and slave.
>
> Here is the config on the MASTER server replication config:
>
> <!-- ReplicationHandler -->
> <requestHandler name="/replication" class="solr.ReplicationHandler" >
> <lst name="master">
> <!--Replicate on 'startup' and 'commit'. 'optimize' is also a valid
> value for replicateAfter. -->
> <str name="replicateAfter">startup</str>
> <str name="replicateAfter">commit</str>
>
> <!--The default value of reservation is 10 secs.See the documentation
> below . Normally , you should not need to specify this -->
> <str name="commitReserveDuration">00:00:10</str>
> </lst>
> <!-- keep only 1 backup. Using this parameter precludes using the
> "numberToKeep" request parameter. (Solr3.6 / Solr4.0)-->
> <!-- (For this to work in conjunction with "backupAfter" with Solr
> 3.6.0, see bug fix https://issues.apache.org/jira/browse/SOLR-3361 )-->
> <str name="maxNumberOfBackups">1</str>
> </requestHandler>
>
> Here is the SLAVE server replication config:
>
> <requestHandler name="/replication" class="solr.ReplicationHandler" >
> <lst name="slave">
>
> <!--fully qualified url to the master core. It is possible to pass on
> this as a request param for the fetchindex command-->
> <str
> name="masterUrl">http://server01:8080/solr/${solr.core.name}</str>
>
> <!--Interval in which the slave should poll master .Format is HH:mm:ss
> . If this is absent slave does not poll automatically.
> But a fetchindex can be triggered from the admin or the http API -->
> <str name="pollInterval">00:01:00</str>
> </lst>
> </requestHandler>
>
> It seems very sporadic at best. Sometimes I can manually click "Replicate
> Now" from the replication page in the SOLR UI and it will work, sometimes it
> does nothing. Sometimes I can go to the master server, and if the "Optimize"
> button is available and I click it....it will replicate as soon as the
> Optimization is done.
>
> Is this a bug in SOLR? Could we possibly have some settings out of whack
> here? I've been digging around online for a bit and not finding much info
> here.
>
> This is on an older version of SOLR though, so wondering if maybe it used to
> be a bug?
>
> Thanks!
>
> Scott
