Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-52727

Handle cloneCollectionAsCapped and convertToCapped during tenant migrations

    • Type: Icon: Task Task
    • Resolution: Won't Do
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Sharding

      cloneCollectionAsCapped creates a new capped collection and puts the data from an existing collection into it. It generates multiple oplog entries: first an oplog entry to create the new capped collection, then individual oplog entries to insert documents from the existing collection into the new capped collection.

      convertToCapped uses cloneCollectionAsCapped's machinery to create a new capped collection and put data from an existing collection into it, then rename the new capped collection over the existing collection. So, it also generates the same oplog entries as cloneCollectionAsCapped, plus an oplog entry for the rename.

      Currently, it's possible for a tenant migration to start blocking after cloneCollectionAsCapped or convertToCapped have written only some of their oplog entries. The operations will fail but leave the capped collection around as garbage on the donor, and the recipient will have the capped collection as garbage as well.

      I think it's also possible for this garbage to be created if a stepdown happens during cloneCollectionAsCapped or convertToCapped today.
       

            Assignee:
            backlog-server-sharding [DO NOT USE] Backlog - Sharding Team
            Reporter:
            jason.zhang@mongodb.com Jason Zhang (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: