Before cloning the catalog data, the movePrimary operation blocks writes to ensure the consistency of the cloning information. To do that, a dedicated synchronization mechanism is exposed by the Database Sharding State.

Unlike the critical section, this mechanism ensures that any writes would fail with the MovePrimaryInProgress error instead of waiting for a refresh of the database metadata (handling a StaleConfig error). Since the critical section is already entered by the movePrimary operation, the refresh will take a long time (mainly depending on the actual duration of the cloning of the catalog data).

Once the Online movePrimary project (PM-3025) will be completed, the actual time frame in which writes are blocked will be drastically reduced, and the movePrimary implementation could adopt the critical section as a mechanism to block writes.