Distributed Local Writes for Insert Only Workloads仅插入工作负载的分布式本地写入

Shard Key分片键

The collection uses the { datacenter : 1, userid : 1 } compound index as the shard key.该集合使用{ datacenter : 1, userid : 1 }复合索引作为分片键。

The datacenter field in each document allows for creating a tag range on each distinct datacenter value. 每个文档中的datacenter字段允许在每个不同的数据中心值上创建标记范围。Without the datacenter field, it would not be possible to associate a document with a specific datacenter.如果没有datacenter字段，就不可能将文档与特定的数据中心相关联。

The userid field provides a high cardinality and low frequency component to the shard key relative to datacenter.userid字段为相对于数据中心的分片键提供了一个高基数和低频率的组件。

See Choosing a Shard Key for more general instructions on selecting a shard key.有关选择分片键的更多一般说明，请参阅选择分片键。

Architecture建筑学

The deployment consists of two datacenters, alfa and bravo. 该部署包括两个数据中心，alfa和bravo。There are two shards, shard0000 and shard0001. Each shard is a replica set with three members. 有两个分片，shard0000和shard0001。每个分片都是一个有三个成员的副本集。shard0000 has two members on alfa and one priority 0 member on bravo. shard0001 has two members on bravo and one priority 0 member on alfa.shard0000在alfa有两名成员，在bravo有一名优先级为0的成员。shard0001在bravo有两名成员，在alfa有一名优先级为0的成员。

Tags标签

This application requires one tag per datacenter. Each shard has one tag assigned to it based on the datacenter containing the majority of its replica set members. There are two tag ranges, one for each datacenter.此应用程序要求每个数据中心有一个标签。每个分片都有一个根据包含其大多数副本集成员的数据中心分配给它的标签。有两个标记范围，每个数据中心一个。

alfa Datacenter数据中心

Tag shards with a majority of members on this datacenter as alfa.将此数据中心上大多数成员的分片标记为alfa。

Create a tag range with:使用以下内容创建标记范围：

• a lower bound of { "datacenter" : "alfa", "userid" : MinKey },{ "datacenter" : "alfa", "userid" : MinKey }的下限，
• an upper bound of { "datacenter" : "alfa", "userid" : MaxKey }, and{ "datacenter" : "alfa", "userid" : MaxKey }的上限，以及
• the tag 标签alfa

bravo Datacenter数据中心

Tag shards with a majority of members on this datacenter as bravo.将此数据中心上大多数成员的分片标记为bravo。

Create a tag range with:使用以下内容创建标记范围：

• a lower bound of { "datacenter" : "bravo", "userid" : MinKey },
• an upper bound of { "datacenter" : "bravo", "userid" : MaxKey }, and
• the tag bravo

Based on the configured tags and tag ranges, mongos routes documents with datacenter : alfa to the alfa datacenter, and documents with datacenter : bravo to the bravo datacenter.根据配置的标记和标记范围，mongos将具有datacenter : alfa的文档路由到alfa数据中心，将具有datacenter : bravo的文档路由至bravo数据中心。

Write Operations写入操作

If an inserted or updated document matches a configured tag range, it can only be written to a shard with the related tag.如果插入或更新的文档与配置的标记范围匹配，则只能将其写入具有相关标记的分片。

MongoDB can write documents that do not match a configured tag range to any shard in the cluster.MongoDB可以将与配置的标记范围不匹配的文档写入集群中的任何分片。

Balancer平衡器

The balancer migrates the tagged chunks to the appropriate shard. 平衡器将标记的块迁移到适当的分片。Until the migration, shards may contain chunks that violate configured tag ranges and tags. Once balancing completes, shards should only contain chunks whose ranges do not violate its assigned tags and tag ranges.在迁移之前，分片可能包含违反配置的标记范围和标记的块。一旦平衡完成，分片应该只包含其范围不违反其分配的标签和标签范围的块。

Adding or removing tags or tag ranges can result in chunk migrations. Depending on the size of your data set and the number of chunks a tag range affects, these migrations may impact cluster performance. 添加或删除标签或标签范围可能会导致块迁移。根据数据集的大小和标记范围影响的块数，这些迁移可能会影响集群性能。Consider running your balancer during specific scheduled windows. 考虑在特定的计划窗口期间运行平衡器。See Schedule the Balancing Window for a tutorial on how to set a scheduling window.有关如何设置计划窗口的教程，请参阅计划平衡窗口。

Application Behavior应用行为

By default, the application writes to the nearest datacenter. If the local datacenter is down, or if writes to that datacenter are not acknowledged within a set time period, the application switches to the other available datacenter by changing the value of the datacenter field before attempting to write the document to the database.默认情况下，应用程序会写入最近的数据中心。如果本地数据中心已关闭，或者在设定的时间段内未确认对该数据中心的写入，则应用程序会在尝试将文档写入数据库之前，通过更改datacenter字段的值切换到其他可用的数据中心。

The application supports write timeouts. The application uses Write Concern to set a timeout for each write operation.应用程序支持写入超时。应用程序使用写入关注为每个写入操作设置timeout。

If the application encounters a write or timeout error, it modifies the datacenter field in each document and performs the write. This routes the document to the other datacenter. 如果应用程序遇到写入或超时错误，它会修改每个文档中的datacenter字段并执行写入。这会将文档路由到其他数据中心。If both datacenters are down, then writes cannot succeed. See Resolve Write Failure.如果两个数据中心都停机，则写入无法成功。请参阅解决写入失败。

The application periodically checks connectivity to any data centers marked as "down". If connectivity is restored, the application can continue performing normal write operations.该应用程序会定期检查与标记为“关闭”的任何数据中心的连接。如果连接恢复，应用程序可以继续执行正常的写入操作。

Given the switching logic, as well as any load balancers or similar mechanisms in place to handle client traffic between datacenters, the application cannot predict which of the two datacenters a given document was written to. 考虑到交换逻辑，以及任何负载均衡器或类似的机制来处理数据中心之间的客户端流量，应用程序无法预测给定文档被写入两个数据中心中的哪一个。To ensure that no documents are missed as a part of read operations, the application must perform broadcast queries by not including the datacenter field as a part of any query.为了确保在读取操作中不会遗漏任何文档，应用程序必须通过不将datacenter字段作为任何查询的一部分来执行广播查询。

The application performs reads using a read preference of nearest to reduce latency.应用程序使用读取首选项nearest执行读取，以减少延迟。

It is possible for a write operation to succeed despite a reported timeout error. The application responds to the error by attempting to re-write the document to the other datacenter - this can result in a document being duplicated across both datacenters. 尽管报告了超时错误，但写入操作仍有可能成功。应用程序通过尝试将文档重写到其他数据中心来响应错误，这可能会导致文档在两个数据中心之间重复。The application resolves duplicates as a part of the read logic.应用程序在读取逻辑中解析重复项。

Switching Logic切换逻辑

The application has logic to switch datacenters if one or more writes fail, or if writes are not acknowledged within a set time period. 如果一个或多个写入失败，或者在设定的时间段内未确认写入，应用程序有逻辑切换数据中心。The application modifies the datacenter field based on the target datacenter's tag to direct the document towards that datacenter.应用程序根据目标数据中心的标记修改datacenter字段，以将文档定向到该数据中心。

For example, an application attempting to write to the alfa datacenter might follow this general procedure:例如，试图写入alfa数据中心的应用程序可能会遵循以下一般过程：

1. Attempt to write document, specifying datacenter : alfa.尝试写入文档，指定datacenter : alfa。
2. On write timeout or error, log alfa as momentarily down.在写入超时或错误时，将alfa记录为暂时关闭。
3. Attempt to write same document, modifying datacenter : bravo.尝试编写相同的文档，修改datacenter : bravo。
4. On write timeout or error, log bravo as momentarily down.在写入超时或错误时，将bravo记录为暂时关闭。
5. If both alfa and bravo are down, log and report errors.如果alfa和bravo都宕机，记录并报告错误。

See Resolve Write Failure.请参阅解决写入失败。

Configure Shard Tags配置分片标签

You must be connected to a mongos associated with the target sharded cluster in order to proceed. You cannot create tags by connecting directly to a shard replica set member.您必须连接到与目标分片集群关联的mongos才能继续。您不能通过直接连接到分片副本集成员来创建标签。

sh.addShardTag("shard0000", "alfa")

sh.addShardTag("shard0001", "bravo")

sh.addTagRange( 
  "<database>.<collection>",
  { "datacenter" : "alfa", "userid" : MinKey },
  { "datacenter" : "alfa", "userid" : MaxKey }, 
  "alfa"
)

sh.addTagRange( 
  "<database>.<collection>",
  { "datacenter" : "bravo", "userid" : MinKey },
  { "datacenter" : "bravo", "userid" : MaxKey }, 
  "bravo"
)

Resolve Write Failure解决写入失败

When the application's default datacenter is down or inaccessible, the application changes the datacenter field to the other datacenter.当应用程序的默认数据中心关闭或无法访问时，应用程序会将datacenter字段更改为其他数据中心。

For example, the application attempts to write the following document to the alfa datacenter by default:例如，默认情况下，应用程序会尝试将以下文档写入alfa数据中心：

{
   "_id" : ObjectId("56f08c447fe58b2e96f595fa"),
   "message_id" : 329620,
   "datacenter" : "alfa",
   "userid" : 123,
   ...
}

If the application receives an error on attempted write, or if the write acknowledgment takes too long, the application logs the datacenter as unavailable and alters the datacenter field to point to the bravo datacenter.如果应用程序在尝试写入时收到错误，或者写入确认时间过长，则应用程序会将数据中心记录为不可用，并更改datacenter字段以指向bravo数据中心。

{
   "_id" : ObjectId("56f08c457fe58b2e96f595fb"),
   "message_id" : 329620,
   "datacenter" : "bravo",
   "userid" : 123,
   ...
}

The application periodically checks the alfa datacenter for connectivity. If the datacenter is reachable again, the application can resume normal writes.应用程序会定期检查alfa数据中心的连接情况。如果数据中心再次可访问，则应用程序可以恢复正常写入。

Resolve Duplicate Documents on Reads读取时解决重复文档

The application's switching logic allows for potential document duplication. When performing reads, the application resolves any duplicate documents on the application layer.应用程序的切换逻辑允许潜在的文档复制。执行读取时，应用程序会解析应用程序层上的任何重复文档。

The following query searches for documents where the userid is 123. Note that while userid is part of the shard key, the query does not include the datacenter field, and therefore does not perform a targeted read operation.以下查询搜索userid为123的文档。请注意，虽然userid是分片键的一部分，但查询不包括datacenter字段，因此不会执行定向读取操作。

db.collection.find( { "userid" : 123 } )

The results show that the document with message_id of 329620 has been inserted into MongoDB twice, probably as a result of a delayed write acknowledgment.结果显示，message_id为329620的文档已被插入MongoDB两次，可能是由于延迟的写入确认。

{
  "_id" : ObjectId("56f08c447fe58b2e96f595fa"),
  "message_id" : 329620
  "datacenter" : "alfa",
  "userid" : 123,
  data : {...}
}
{
  "_id" : ObjectId("56f08c457fe58b2e96f595fb"),
  "message_id" : 329620
  "datacenter" : "bravo",
  "userid" : 123,
  ...
}

The application can either ignore the duplicates, taking one of the two documents, or it can attempt to trim the duplicates until only a single document remains.应用程序可以忽略重复项，取两个文档中的一个，也可以尝试修剪重复项，直到只剩下一个文档。

One method for trimming duplicates is to use the ObjectId.getTimestamp() method to extract the timestamp from the _id field. 修剪重复项的一种方法是使用ObjectId.getTimestamp()方法从_id字段中提取时间戳。The application can then keep either the first document inserted, or the last document inserted. This assumes the _id field uses the MongoDB ObjectId().然后，应用程序可以保留插入的第一个文档或插入的最后一个文档。这假设_id字段使用MongoDB ObjectId()。

For example, using getTimestamp() on the document with ObjectId("56f08c447fe58b2e96f595fa") returns:例如，对具有ObjectId("56f08c447fe58b2e96f595fa")的文档使用getTimestamp()返回：

ISODate("2016-03-22T00:05:24Z")

Using getTimestamp() on the document with ObjectId("56f08c457fe58b2e96f595fb") returns:对具有ObjectId("56f08c457fe58b2e96f595fb")的文档使用getTimestamp()返回：

ISODate("2016-03-22T00:05:25Z")