更改流生产建议
在本页面
如果您删除或重命名集合或数据库，并为其打开了更改流，则更改流游标在操作日志中前进到该点时将关闭。使用fullDocument : updateLookup选项更改流游标可能会为查询文档返回null。
尝试针对删除的集合恢复更改流将导致错误。在上一次捕获更改流和收集丢弃事件之间的收集上发生的任何数据更改都将丢失。
变更流响应文档必须遵守 16MB BSON 文档限制。根据打开变更流的集合中文档的大小，如果生成的通知文档超过 16MB 限制，则通知可能会失败。例如，对配置为返回完整更新的文档的变更流的更新操作，或对等于或低于限制的文档进行插入/替换操作。
Replica Sets
对于具有arbiter个成员的副本集，如果没有足够的数据承载成员，则更改流可能会保持空闲状态，从而使操作不能被多数提交。
例如，考虑一个具有两个数据承载节点和一个仲裁器的 3 成员副本集。如果辅助节点发生故障(例如由于故障或升级)，则写入操作不能占多数。更改流保持打开状态，但不发送任何通知。
在这种情况下，只要应用程序收到的最后一个操作仍在副本集的操作日志中，则该应用程序可以赶上停机期间发生的所有操作。
如果估算出重大停机时间，例如升级或重大灾难，请考虑增加操作日志的大小，以使操作保留的时间长于估算停机时间。使用rs.printReplicationInfo()检索有关 oplog 状态的信息，包括 oplog 的大小和操作的时间范围。
Sharded Clusters
变更流通过利用全局逻辑时钟提供了整个分片上变更的总体排序。 MongoDB 确保更改的 Sequences 得以保留，并且更改流通知可以按接收到的 Sequences 安全地解释。例如，针对 3 个分片集群打开的更改流游标会返回更改通知，该通知遵循所有三个分片中这些更改的总 Sequences。
为了保证变更的总体排序，对于每个变更通知，mongos会与每个分片进行核对，以查看该分片是否查看了最近的变更。带有一个或多个分片的分片集群对集合几乎没有或没有任何活动，或者是“冷”的分片集群，可能会对更改流的响应时间产生负面影响，因为mongos仍必须检查这些冷分片以确保更改的总体 Sequences。对于地理上分布的分片或工作负载，其中大多数操作都发生在集群中的子集的子集上，这种影响可能会更加明显。
如果分片集合的活动水平很高，则mongos可能无法跟上所有分片的更改。考虑将通知过滤器用于这些类型的集合。例如，传递被配置为仅过滤insert个操作的$match管道。
对于分片集合，使用多：真进行更新操作可能会导致针对该集合打开的任何更改流都发送orphaned documents的通知。
