[
https://issues.apache.org/jira/browse/SOLR-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906497#action_12906497
]
Peter Sturge commented on SOLR-2100:
------------------------------------
I'm not really familiar with the reservation code for replication, but will it
still save the commit point for replication even if another commit (or many
commits) come along during replication?
By default, it would probably be rare, as the data to be replicated is only a
delta and would likely not take too long to complete.
This was the problem with backups - it's a full file copy of everything, which
typically takes minutes on large indexes - longer if writing to a remote
volume.
As the replication timing is configurable, you could have a scenario where the
amount of data to be replicated is very significant, and is generally remote,
so could take some time to complete. Would the reserveration mechanism still
hold the commit point if 1,2, 5 or 10 commits came along during the replication
process?
ReplicationHandler.postCommit() calls saveCommitPoint()/releaseCommitPoint(),
so as things stand this would preserve the commit point even if a separate
reserveration didn't, and there's no price to pay for holding the indexVersion
in this way.
Not sure what the standard policy is for marking issues Resolved/Closed, so
I'll leave this up to you. But do let me know if you'd like me to perform any
additional testing.
> Fix for saving commit points during java-based backups
> ------------------------------------------------------
>
> Key: SOLR-2100
> URL: https://issues.apache.org/jira/browse/SOLR-2100
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Affects Versions: 1.4, 1.4.1
> Reporter: Peter Sturge
> Priority: Minor
> Fix For: 1.4.2
>
> Attachments: SOLR-2100.PATCH
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> This patch fixes the saving of commit points during backup operations.
> This fixes the perviously commited (for 1.4) SOLR-1475 patch.
> 1. In IndexDeletionPolicyWrapper.java, commit points are not saved to the
> 'savedCommits' map.
> 2. Also, the testing of the presence of a commit point uses the contains()
> method instead of containsKey().
> The result of this means that backups for anything but toy indexes fail,
> because the commit points are deleted (after 10s) before the full backup is
> completed.
> This patch addresses these 2 issues.
> Tested with 1.4.1 release trunk, but should also work fine with 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
