Solr
  1. Solr
  2. SOLR-2100

Fix for saving commit points during java-based backups

    Details

      Description

      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.

      1. SOLR-2100.PATCH
        0.8 kB
        Peter Sturge

        Activity

        Hide
        Yonik Seeley added a comment -

        Thanks for the patch Peter! Such a small patch... but I've been trying to puzzle out all of the possible ramifications (and going back to puzzle through some of the replication code).

        saveCommitPoint() (which obviously did nothing before this) is called in the postCommit (and postOptimize) events.
        This doesn't even seem necessary for replication, since SolrDeletionPolicy always saves the last commit point and the last optimized point (if configured to do so, or if replicate on optimize is configured). Once replication has started, a reservation scheme is used rather than saving a commit point forever.

        Also, if one configures replication onCommit and onOptimize, then the event callback code has some bugs: both refer to indexCommitPoint, and close the previous one. So if we did rely on saveCommitPoint, a commit after an optimize would release the optimized commit point.

        Show
        Yonik Seeley added a comment - Thanks for the patch Peter! Such a small patch... but I've been trying to puzzle out all of the possible ramifications (and going back to puzzle through some of the replication code). saveCommitPoint() (which obviously did nothing before this) is called in the postCommit (and postOptimize) events. This doesn't even seem necessary for replication, since SolrDeletionPolicy always saves the last commit point and the last optimized point (if configured to do so, or if replicate on optimize is configured). Once replication has started, a reservation scheme is used rather than saving a commit point forever. Also, if one configures replication onCommit and onOptimize, then the event callback code has some bugs: both refer to indexCommitPoint, and close the previous one. So if we did rely on saveCommitPoint, a commit after an optimize would release the optimized commit point.
        Hide
        Peter Sturge added a comment -

        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.

        Show
        Peter Sturge added a comment - 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.
        Hide
        Yonik Seeley added a comment -

        but will it still save the commit point for replication even if another commit (or many commits) come along during replication?

        Yes.... that's what the reservation system is for. When someone asks us for the current index version, we reserve that version for some amount of time and return that. When the client is retrieving a file, they also specify what index version it is for so we can periodically renew the reservation during streaming back.

        If we didn't use a reservation system, a client could ask for the index version, die, and then we would save it forever.

        Show
        Yonik Seeley added a comment - but will it still save the commit point for replication even if another commit (or many commits) come along during replication? Yes.... that's what the reservation system is for. When someone asks us for the current index version, we reserve that version for some amount of time and return that. When the client is retrieving a file, they also specify what index version it is for so we can periodically renew the reservation during streaming back. If we didn't use a reservation system, a client could ask for the index version, die, and then we would save it forever.
        Hide
        Yonik Seeley added a comment -

        OK, I've fixed this in 4.x, 3.x, and 1.4.x

        Show
        Yonik Seeley added a comment - OK, I've fixed this in 4.x, 3.x, and 1.4.x
        Hide
        Grant Ingersoll added a comment -

        Bulk close for 3.1.0 release

        Show
        Grant Ingersoll added a comment - Bulk close for 3.1.0 release

          People

          • Assignee:
            Unassigned
            Reporter:
            Peter Sturge
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development