Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-38733

cbbackupmgr handle complete snapshots where the final seqno != snapshot end

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Critical
    • 6.6.0
    • 6.6.0
    • tools
    • Triaged
    • Unknown

    Description

      Before talking about this issue, let's quickly discuss the current behavior of DCP (and metadata purge) with regards to the snapshot end seqno. As of 6.5 (non-dp) when sent the snapshot (start: 0, end: 15) we will always receive a mutation with the sequence number is 15. This assertion remains true even for the metadata purge edge case; lets say we have the mutation history:

      1 - Document key-1 inserted
      2 - Document key-2 inserted
      3 - Document key-3 inserted
      4 - Document key-2 deleted (tombstone created)
      5 - Document key-3 deleted (tombstone created)

      If we were to stream this vBucket we would get the snapshot marker (start: 0, end: 5) and we would get all the items listed above. Now lets say that we force a metadata purge. We would still get the same snapshot marker, however, we would only get items for the sequence numbers [1, 5]. This is because the final tombstone is maintained when a metadata purge runs.

      When we introduce collections (and most importantly stream filters) into the mix, the above assertion becomes invalid; lets say we have the mutation history:

      1 - Document key-1 inserted
      2 - Collection 'collection-1' created

      Now, if we were to stream this vBucket with the stream filter [0x0, 0x8] we would get the snapshot marker (start: 0, end: 2) however if we were to stream this data, we would actually only see a single mutation for sequence number 1; the stream event mutation for the collection creation is omitted (since we must know it exists, because we asked for it in the stream filter). Practically, this means that we now have an assumption that is no longer correct; in backup, we will see that the last persisted seqno (1) is less that the snapshot end (2) so we try to use the failoverlogs and snapshot info from the current backup (as if we were doing a resume). This leads to us getting a rollback because the current backups failoverlogs are empty (they haven't been created yet).

      cbbackupmgr must now work without the assumption that the last persisted sequence number == snapshot end.

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              james.lee James Lee
              james.lee James Lee
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty