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