阅读完 chunk-migration-procedure 后，我还有几个问题。
- 目标分片是否在开始同步传输过程中 block 的更新之前完成 block 传输？
- 目标分片如何确定它已完全同步？如果在更新配置服务器上的元数据时 block 上发生一些更新怎么办？
最佳答案
以下信息在 MongoDB 3.2 中通常应该是正确的，但对于较旧(或较新)版本可能存在一些实现差异。
1. Does the destination shard finish transferring the chunk before start to synchronizing the update to the chunk that comes during the transfer?
是的，这就是 chunk migration procedure 中的步骤 4 和 5。 :
目标分片开始请求 block 中的文档并开始接收数据副本。
接收到 block 中的最终文档后，目标分片启动同步过程，以确保它具有迁移过程中发生的迁移文档的更改。
一个chunk表示特定分片内连续范围的分片键值，并且(在 MongoDB 3.2 中)不会为该范围内的文档赋予任何磁盘上的位置。迁移过程开始跟踪从源分片迁移的 block 中文档的所有更新，在目标分片上构建所需的索引，复制 block 范围中的初始文档，然后进入应用尚未完成的任何更新的循环。传播到目标分片。
2. How does the destination shard determine that it is fully synchronized?
在应用更新的周期中，迁移过程等待挂起的更新以达到源分片和目标分片接近(甚至完全)同步的状态。此时，迁移进入一个关键部分，其中对源分片上的 block 集合的更新和读取被阻止，任何最终数据更改都会被传输，并且存储在配置服务器上的分片集群元数据将被更新新的 block 所有权信息。
What if some updates on the chunk come while it is updating the metadata on the config server?
当迁移过程处于关键部分时，更新将被阻止。当迁移成功退出关键部分时，分片版本将增加，并且任何被阻止的请求都将返回 StaleConfigException。过时的配置异常提示 mongos 重新加载当前版本的分片集群元数据并将请求重新发送到正确的分片。
如果您想了解更多信息(并且愿意阅读 C++)，MongoDB 3.2 中的相关源路径是 src/mongodb/s/ .
关于mongodb - MongoDB block 迁移到底是如何工作的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36951967/