[
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-4661:
---------------------------
Description:
the ReplicationHandler (and the replication admin UI screen) report the index
version & gen for the master based on what commit point is currently open for
searching -- but this is not necessarily the most recent commit point available
for replication.
Thus, it can appear that a slave has "gotten ahead" of the master, if there are
"empty commits" (because of reader reopening shotcuts) or commits using
openSearcher=false.
We need to add additional data to help make it clear there is no actual problem
in this sitation.
Summary of original bug report..
{panel}
Index and Gen number on Slave is higher than master.
If you apply commit on master with no pending docs then the commit time stamp
and gen is incremented. When Slaves polls master for replication it see the
index version difference and starts replicating but all files are skipped.
On Admin UI (on Slaves) the version number displayed for master is old where as
for slave is the latest which is higher than master.
Below is the response from master (/replication?command=details) where i see
two different Version an Gen numbers. This creates confusion of having version
out of sync, though its not.
...
{panel}
was:
Index and Gen number on Slave is higher than master.
If you apply commit on master with no pending docs then the commit time stamp
and gen is incremented. When Slaves polls master for replication it see the
index version difference and starts replicating but all files are skipped.
On Admin UI (on Slaves) the version number displayed for master is old where as
for slave is the latest which is higher than master.
Below is the response from master (/replication?command=details) where i see
two different Version an Gen numbers. This creates confusion of having version
out of sync, though its not.
<response>
<lst name="responseHeader">
<int name="status">0</int>
<int name="QTime">1</int>
</lst>
<lst name="details">
<str name="indexSize">1.52 GB</str>
<str name="indexPath">/storage/solrdata/index/</str>
<arr name="commits">
<lst>
<long name="indexVersion">{color:red}1364835609803{color}</long>
<long name="generation">{color:red}34{color}</long>
<arr name="filelist">...</arr>
</lst>
</arr>
<str name="isMaster">true</str>
<str name="isSlave">false</str>
<long name="indexVersion">{color:red}1364778010902{color}</long>
<long name="generation">{color:red}31{color}</long>
<lst name="master">
<str name="confFiles">schema.xml</str>
<arr name="replicateAfter">
<str>commit</str>
<str>startup</str>
</arr>
<str name="replicationEnabled">true</str>
<long name="replicatableGeneration">34</long>
</lst>
</lst>
<str name="WARNING">
This response format is experimental. It is likely to change in the future.
</str>
</response>
Summary: Index Version & Gen look out of sync in replication UI when
master searcher uses older commit then what is replicatable (was: Index
Version & Gen Number out of sync on Admin UI)
update summary & description based on investigation
> Index Version & Gen look out of sync in replication UI when master searcher
> uses older commit then what is replicatable
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4661
> URL: https://issues.apache.org/jira/browse/SOLR-4661
> Project: Solr
> Issue Type: Bug
> Components: replication (java), web gui
> Affects Versions: 4.2
> Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
> Reporter: Aditya
> Labels: gui, replication, web
> Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg, SOLR-4661.patch
>
>
> the ReplicationHandler (and the replication admin UI screen) report the index
> version & gen for the master based on what commit point is currently open for
> searching -- but this is not necessarily the most recent commit point
> available for replication.
> Thus, it can appear that a slave has "gotten ahead" of the master, if there
> are "empty commits" (because of reader reopening shotcuts) or commits using
> openSearcher=false.
> We need to add additional data to help make it clear there is no actual
> problem in this sitation.
> Summary of original bug report..
> {panel}
> Index and Gen number on Slave is higher than master.
> If you apply commit on master with no pending docs then the commit time stamp
> and gen is incremented. When Slaves polls master for replication it see the
> index version difference and starts replicating but all files are skipped.
> On Admin UI (on Slaves) the version number displayed for master is old where
> as for slave is the latest which is higher than master.
> Below is the response from master (/replication?command=details) where i see
> two different Version an Gen numbers. This creates confusion of having
> version out of sync, though its not.
> ...
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
