movePrimary

在此页面上

兼容性
Considerations
更多信息

movePrimary

In a 分片集群, movePrimary reassigns the 主分片 which holds all un-sharded collections in the database. movePrimary first changes the primary shard in the cluster metadata, and then migrates all un-sharded collections to the specified 分片. Use the command with the following form:

db.adminCommand( { movePrimary: <databaseName>, to: <newPrimaryShard> } )

For example, the following command moves the primary shard from test to shard0001:

db.adminCommand( { movePrimary : "test", to : "shard0001" } )

When the command returns, the database's primary shard location has switched to the specified shard. To fully decommission a shard, use the removeShard command.

movePrimary is an administrative command that is only available for mongos instances.

警告

After starting movePrimary, do not perform any read or write operations against any unsharded collection in that database until the command completes. Read or write operations issued against those collections during the migration can result in unexpected behavior, including potential failure of the migration operation or loss of data.

兼容性

此命令可用于以下环境中托管的部署：

MongoDB Atlas：用于云中 MongoDB 部署的完全托管服务

重要

无服务器实例不支持此命令。有关更多信息，请参阅不支持的命令。

MongoDB Enterprise：基于订阅、自我管理的 MongoDB 版本
MongoDB Community：源代码可用、免费使用且可自行管理的 MongoDB 版本

Considerations

mongos uses "majority" write concern for movePrimary。

Issue `movePrimary` During A Maintenance Window

movePrimary may require a significant time to complete depending on the size of the database and factors such as network health or machine resources. During migration, attempts to write or perform any DDL operations to the unsharded collections on the database being moved fail with the error: "movePrimary is in progress".

Consider scheduling a maintenance window during which applications stop all reads and writes to the cluster. Issuing movePrimary during planned downtime mitigates the risk of encountering undefined behavior due to interleaving reads or writes to the unsharded collections in the database.

Namespace Conflicts Prevent Migration

movePrimary fails if the destination shard contains a conflicting collection namespace. For example:

An administrator issues movePrimary to change the primary shard for the hr database.
A user or application issues a write operation against an unsharded collection in hr while movePrimary is moving that collection. The write operation creates the collection in the original primary shard.
An administrator later issues movePrimary to restore the original primary shard for the hr database.
movePrimary fails due to the conflicting namespace left behind from the interleaving write operation.

Destination Shard Must Rebuild Indexes

As part of the movePrimary operation, the destination shard must rebuild indexes on the migrated collections after becoming the primary shard. This may require a significant amount of time depending on the number of indexes per collection and the amount of data to index.

See 已填充集合上的索引构建 for more information on the index build process.

Moving Collections that have Change Streams

Starting in MongoDB 8.0, movePrimary doesn't invalidate collections that have change streams. The change streams can continue to read events from collections after the collections are moved to a new shard.

In earlier MongoDB versions, movePrimary invalidates collection change streams and the change streams cannot read events from the collections.

In all MongoDB versions, movePrimary updates the UUID for moved unsharded collections.