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