mongosync 行为

集群独立性

mongosync 在源集群和目标集群之间同步集合数据。mongosync 不同步用户或角色。因此，你可以在每个集群上创建具有不同访问权限的用户。

配置文件

可以在 YAML 配置文件中设立mongosync的选项。 使用--config选项。 示例：

$ mongosync --config /etc/mongosync.conf

有关可用设置的信息，请参阅配置。

分片集群

Mongosync 支持分片的集群之间的复制。mongosync 将单个分片从源集群并行复制到目标集群。但是，mongosync 不会保留源集群的分片配置。

db.adminCommand(
  { 
    setAllowMigrations: “<db>.<collection>”,
    allowMigrations: false
  }
)

多个集群

要将源集群同步到多个目标集群，请为每个目标集群使用一个 mongosync 实例。有关更多信息，请参阅多集群限制。

固定大小集合

从 1.3.0 开始，Mongosync 支持固定大小集合，但有一些限制。

从 1.20.0 开始，启动 mongosync 时必须传递 --enableCappedCollectionHandling 标志，启用在迁移期间创建新的固定大小集合。

• convertToCapped is not supported. If you run convertToCapped, mongosync exits with an error.

• cloneCollectionAsCapped 不受支持。

同步期间，源集群上的固定大小集合可正常工作。

同步期间，目标集群上的固定大小集合会出现临时更改：

• 文档数量没有上限。

• 最大集合大小为 1PB。

mongosync 在提交期间恢复最大文档数量和最大文档大小的原始值。

写入阻塞

mongosync 根据迁移配置在内部管理源集群和目标集群上的写入阻塞：

mongosync 调用/提交后阻止源写入。除非迁移因托管错误而失败，否则源写入将保持阻塞状态。如果 mongosync 在提交期间意外终止，您可以通过运行以下命令来手动解除对源集群的写入阻止：

db.adminCommand(
   {
      setUserWriteBlockMode: 1,
      global: false
   }
)

For more information, see setUserWriteBlockMode.

mongosync 在调用/start后阻止目标写入。目标写入保持阻塞状态，直到 /progress 响应中的 canWrite 为 true。

读关注和写关注

By default, mongosync sets the read concern level to "majority" for reads on the source cluster. For writes on the destination cluster, mongosync sets the write concern level to "majority" with j: true.

有关读关注和写关注配置和行为的更多信息，请参阅读关注和写关注。

读取偏好

mongosync requires the primary read preference when connecting to the source and destination clusters. For more information, see Read Preference Options.

传统索引处理

mongosync 将传统索引值（如 0 或空字符串）重写为目标上的 1。 mongosync 还会删除目标上的任何无效索引选项。

对集合特征的临时更改

mongosync 在同步期间临时更改以下集合特征。 原始值会在提交进程中恢复。

滚动索引构建

mongosync does not support rolling index builds during migration. To avoid building indexes in a rolling fashion during migration, use one of the following methods to ensure that your destination indexes match your source indexes:

• 迁移前在源上构建索引。

• Build the index on the source during migration with a default index build.

• 迁移后在目标上构建索引。

mongosync Metadata

mongosync 在迁移期间将其元数据存储在一个或多个数据库中。元数据数据库可以命名为以下任何名称：

• __mdb_internal_mongosync

• 任何以 __mdb_internal_mongosync_verifier

成功迁移后，应删除所有元数据数据库。删除元数据后，无法反向迁移。

一致性(Consistency)

mongosync supports eventual consistency on the destination cluster. Read consistency is not guaranteed on the destination cluster until commit. Before committing, the source and destination clusters may differ at a given point in time. To learn more, see Mid-sync Considerations.

当mongosync进行同步时， mongosync可能会在将写入从源中继到目标时对写入进行重新排序或组合。 对于给定文档，源和目标之间的写入总数可能不同。

事务可能不会自动出现在目标集群上。 可重试写入可能无法在目标集群上重试。

剖析

如果在源数据库上启用了分析， MongoDB会创建一个名为 <db>.system.profile 的特殊集合。同步完成后，Mongosync 不会从目标中删除 <db>.system.profile集合，即使稍后删除源数据库也是如此。<db>.system.profile集合不会改变目标上用户数据的准确性。

视图

如果将带视图的数据库拖放到源上，则目标可能会在该数据库中显示空system.views集合。空system.views集合不会改变目标上用户数据的准确性。

系统集合

Mongosync 不会将系统集合复制到目标集群。

If you issue a dropDatabase command on the source cluster, this change is not directly applied on the destination cluster. Instead, Mongosync drops user collections and views in the database on the destination cluster, but it does not drop system collections on that database.

例如，在目标集群上：

• The drop operation does not affect a user-created system.js collection.

• If you enable profiling, the system.profile collection remains.

• If you create views on the source cluster and then drop the database, replicating the drop removes the views, but leaves an empty system.views collection.

在这些情况下，复制 dropDatabase 时会删除数据库中所有用户创建的集合，但会将其系统集合留在目标集群上。

UUID

mongosync creates collections with new UUIDs on the destination cluster. There is no relationship between UUIDs on the source cluster and the destination cluster. If applications contain hard-coded UUIDs (which MongoDB does not recommend), you may need to update those applications before they work properly with the migrated cluster.

排序

mongosync 以未定义的顺序在目标集群上插入文档，这不会保留源集群的自然排序顺序。如果应用程序依赖于文档顺序，但没有定义的排序方法，则您可能需要更新这些应用程序以指定预期的排序顺序，才能使应用程序与迁移的集群正常工作。

MongoDB Atlas内部数据库

MongoDB Atlas和其他云服务将基本数据存储在集群内的专用内部数据库中。这些数据库以 __mdb_internal1开头。从.18 开始，mongosync 忽略所有以__mdb_internal 开头的数据库。

索引构建优化

恢复力

mongosync 具有弹性，能够处理非致命错误。包含“错误”或“故障”字样的日志并不表明 mongosync 正在发生故障或损坏数据。例如，如果发生网络错误，mongosync 日志可能会包含“错误”字样，但 mongosync 仍能完成同步。如果同步未完成，mongosync 会写入一个致命错误日志条目。

数据定义语言 (DDL) 操作

Using DDL operations (operations that act on collections or databases such as db.createCollection() and db.dropDatabase()) during sync increase the risk of migration failure and may negatively impact mongosync performance. For best performance, refrain from performing DDL operations on the source cluster while the sync is in progress.

有关 DDL 操作的更多信息，请参阅待处理 DDL 操作和事务。

网络延迟

迁移组件之间的网络延迟或较长的物理距离可能会对同步速度产生负面影响。

mongosync 和目标分片之间的延迟

对于源集群上的每个操作，mongosync 都会两次往返目标服务器。 延迟越大，同步越慢。

目标分片之间的延迟

mongosync 在目标集群上的ACID 事务中运行操作并分批更新自己的元数据。 这可能会导致跨分片事务，如果分片相距较远，则成本可能更高。

源集群或目标集群上任何副本集的节点之间的延迟

mongosync uses "majority" writes and "majority" reads, which require acknowledgement from multiple nodes in a replica set, including shard-backing replica sets. If the majority of these nodes aren't in the same region, there will be negative performance implications.

错误和崩溃

如果 mongosync 在同步过程中遇到错误或变得不可用，您也可以从停止的地方恢复 mongosync 操作。 mongosync 二进制文件是无状态的，用于存储目标集群重启所需的元数据。

要继续同步，请在 mongosync 再次可用后重新启动它，并使用与中断的同步相同的参数。 重新启动 mongosync 后，进程会从停止处恢复。

集群可用性

如果源集群或目标集群发生意外崩溃，您可以恢复迁移，而无需从头开始重新启动。集群重新在线后，使用原始迁移中的相同连接字符串参数重新启动 mongosync binary。mongosync 从目标集群读取其存储状态，并自动恢复同步。

要验证同步已经恢复，请调用 /progress 终结点并确认 state 返回 RUNNING。

暂停同步

如果mongosync 处于 PAUSED 状态，则mongosync 不支持以下操作：

• 升级源集群或目标集群的MongoDB版本

• 启用然后禁用负载均衡器

您可以在 mongosync 处于 PAUSED 状态时对其升级。