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

Prevent concurrent merges

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 5.2.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Fully Compatible
    • v5.1
    • Server Serverless 2021-10-18, Server Serverless 2021-10-25, Server Serverless 2021-11-01, Server Serverless 2021-11-15, Server Serverless 2021-11-29, Server Serverless 2021-12-13

      The multitenant migrations process begins when Cloud calls donorStartMigration on the donor primary with a tenantId. The donor calls recipientSyncData on the recipient primary with the tenantId. On both sides, we have ugly code for preventing concurrent migrations with the same tenantId. In SERVER-60752 we added an API to make such conflict-detection cleaner.

      This ticket will need at least 3 commits:

      1. Using the new API introduced in SERVER-60752, clean up the conflict detection code in the recipientSyncData command. The change we made in the donorStartMigration command in SERVER-60752 is a good example to start from.
      2. The donorStartMigration command already uses the new API to ban multiple migrations with the same tenantId. (Well, once SERVER-60752 is committed.) We're adding a new concept of the migration "protocol", which can be "multitenant migrations" (old protocol, the default) or "shard merge" (the new one). Add a new rule: if any active migration has protocol "shard merge" it must be the only migration - other migrations are banned regardless of their protocol or tenantId. So if there's any existing migration then a new "shard merge" is banned. If there's an existing "shard merge", any new migration is banned.
      3. Same change as #2, but for recipientSyncData.

            Assignee:
            christopher.caplinger@mongodb.com Christopher Caplinger
            Reporter:
            jesse@mongodb.com A. Jesse Jiryu Davis
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: