Change Streams Production Recommendations更改流生产建议

Replica Sets复制集

For replica sets with arbiter members, change streams may remain idle if enough data-bearing members are unavailable such that operations cannot be majority committed.对于具有仲裁器成员的副本集，如果有足够的数据承载成员不可用，以致无法大多数提交操作，则更改流可能会保持空闲。

For example, consider a 3-member replica set with two data-bearing nodes and an arbiter. 例如，考虑一个具有两个数据承载节点和一个仲裁器的三成员副本集。If the secondary goes down, such as due to failure or an upgrade, writes cannot be majority committed. 如果辅助服务器宕机，例如由于故障或升级，则无法多数提交写入操作。The change stream remains open, but does not send any notifications.更改流保持打开状态，但不发送任何通知。

In this scenario, the application can catch up to all operations that occurred during the downtime so long as the last operation the application received is still in the oplog of the replica set.在这种情况下，只要应用程序接收的最后一个操作仍在副本集的oplog中，应用程序就可以赶上停机期间发生的所有操作。

If significant downtime is estimated, such as for an upgrade or a significant disaster, consider increasing the size of the oplog such that operations are retained for a duration of time greater than the estimated downtime. 如果估计有重大停机时间，例如升级或重大灾难，请考虑增加oplog的大小，以便操作的保留时间大于估计的停机时间。Use rs.printReplicationInfo() to retrieve information on the oplog status, including the size of the oplog and the time range of operations.使用rs.printReplicationInfo()检索有关oplog状态的信息，包括oplog的大小和操作的时间范围。

Sharded Clusters分片群集

Change streams provide a total ordering of changes across shards by utilizing a global logical clock. 更改流通过利用全局逻辑时钟提供跨分片的更改的总体顺序。MongoDB guarantees the order of changes are preserved and change stream notifications can be safely interpreted in the order received. MongoDB保证更改的顺序得到保留，并且可以按照收到的顺序安全地解释更改流通知。For example, a change stream cursor opened against a 3-shard sharded cluster returns change notifications respecting the total order of those changes across all three shards.例如，针对3分片集群打开的变更流游标将返回关于所有三个分片中这些变更的总顺序的变更通知。

To guarantee total ordering of changes, for each change notification the mongos checks with each shard to see if the shard has seen more recent changes. 为了保证更改的总顺序，对于每个更改通知，mongos会检查每个分片，看看分片是否有最近的更改。Sharded clusters with one or more shards that have little or no activity for the collection, or are "cold", can negatively affect the response time of the change stream as the mongos must still check with those cold shards to guarantee total ordering of changes. 带有一个或多个分片的分片群集，这些分片对集合几乎没有活动，或者是“冷”的，可能会对更改流的响应时间产生负面影响，因为mongos仍然必须检查这些冷分片，以确保更改的总体顺序。This effect may be more apparent with geographically distributed shards, or workloads where the majority of operations occur on a subset of shards in the cluster.对于地理位置分散的分片，或大多数操作发生在集群中分片子集上的工作负载，这种影响可能更为明显。

If a sharded collection has high levels of activity, the mongos may not be able to keep up with the changes across all of the shards. 如果一个分片集合具有较高的活动级别，则mongos可能无法跟上所有分片的变化。Consider utilizing notification filters for these types of collections. 考虑对这些类型的集合使用通知筛选器。For example, passing a $match pipeline configured to filter only insert operations.例如，传递配置为仅筛选插入操作的$match管道。

For sharded collections, update operations with multi : true may cause any change streams opened against that collection to send notifications for orphaned documents.对于分片集合，使用multi : true进行更新操作可能会导致针对该集合打开的任何更改流发送孤立文档的通知。

From the moment an unsharded collection is sharded until the time the change stream catches up to the first chunk migration, the documentKey in the change stream notification document only includes the _id of the document, not the full shard key.从对未分片的集合进行分片的那一刻起，直到更改流赶上第一次块迁移，更改流通知文档中的documentKey只包含文档的_id，而不包含完整的分片键。

Indexes and Performance索引和性能

Change streams cannot use indexes. MongoDB does not support creating indexes on the oplog collection. 更改流不能使用索引。MongoDB不支持在oplog集合上创建索引。Therefore, avoid opening a high number of specifically-targeted change streams as these can impact server performance.因此，请避免打开大量特定目标的更改流，因为这些更改流可能会影响服务器性能。