Si elimina o renombra una colección o base de datos con flujos de cambios abiertos, los cursores de flujo de cambios se cerrarán al avanzar a ese punto en el registro de operaciones. Los cursores de flujo de cambios con fullDocument :
updateLookup La opción puede devolver null para el documento buscado.
Los documentos de respuesta de flujo de cambio deben cumplir con el límite de 16 MB para documentos BSON. Dependiendo del tamaño de los documentos en la colección donde abres un flujo de cambios, las notificaciones pueden fallar si el documento de notificación resultante excede el límite de 16 MB. Por ejemplo, actualiza las operaciones en flujos de cambios configurados para devolver el documento actualizado completo, o inserta o reemplaza operaciones con un documento que esté en el límite o justo por debajo.
Importante
A partir de la versión 6.0.9, puedes utilizar el
$changeStreamSplitLargeEvent Etapa de agregación para dividir los eventos en fragmentos más pequeños.
Sets de réplicas
Para los set de réplicas con nodos árbitros, los flujos de cambios pueden quedarse inactivos si no hay suficientes miembros con datos disponibles para que las operaciones se confirmen por mayoría.
Por ejemplo, considera un set de réplicas de 3 nodos con dos nodos que contienen datos y un árbitro. Si el secundario deja de funcionar, por ejemplo debido a un fallo o a una actualización, las operaciones de guardado no pueden ser confirmadas por la mayoría. El flujo de cambios permanece abierto, pero no envía ninguna notificación.
En este caso, la aplicación puede ponerse al día con todas las operaciones que ocurrieron durante el tiempo de inactividad, siempre que la última operación que la aplicación recibió todavía esté en el oplog del set de réplicas.
Si se estima un tiempo de inactividad significativo, como para actualizar o debido a un desastre importante, considera aumentar el tamaño del oplog de modo que las operaciones se conserven durante un tiempo mayor que el tiempo de inactividad estimado. Utiliza rs.printReplicationInfo() para recuperar información sobre el estado del oplog, incluidos el tamaño del oplog y el rango de tiempo de las operaciones.
Clústeres fragmentados
Los flujos de cambios proporcionan un orden total de los cambios en las particiones mediante la utilización de un reloj lógico global. MongoDB garantiza que se conserve el orden de los cambios y que las notificaciones del flujo de cambios se puedan interpretar de forma segura en el orden recibido. Por ejemplo, un cursor de flujo de cambios abierto contra un clúster de 3 particiones devuelve notificaciones de cambios respetando el orden total de esos cambios en las tres particiones.
Para garantizar el orden total de cambios, para cada notificaciones de cambios, mongos comprueba con cada partición para ver si la partición ha experimentado cambios más recientes. Los clústeres particionados con una o más particiones que tienen poca o ninguna actividad para la colección (o que están “fríos”) pueden afectar negativamente el tiempo de respuesta del flujo de cambios, ya que mongos aún debe verificar esas particiones frías para garantizar el orden total de los cambios. Este efecto puede ser más evidente con particiones distribuidas geográficamente, o cargas de trabajo donde la mayoría de las operaciones ocurren en un subconjunto de particiones dentro del clúster. Para minimizar la latencia de las particiones en frío, puedes especificar un valor de periodicNoopIntervalSecs más bajo.
Si una colección particionada tiene altos niveles de actividad, el mongos puede no ser capaz de mantenerse al día con los cambios en todas las particiones. Considera utilizar filtros de notificaciones para estos tipos de colecciones. Por ejemplo, pasar una pipeline $match configurada para filtrar solo insert operaciones.
Índices y rendimiento
Los flujos de cambios no pueden usar índices. MongoDB no admite la creación de índices en la colección oplog. Por lo tanto, evita abrir un gran número de flujos de cambio específicamente dirigidos, ya que pueden tener un impacto en el rendimiento del servidor.
Optimización del flujo de cambios
A partir de MongoDB 5.1, los flujos de cambios están optimizados, proporcionando una utilización de recursos más eficiente y una ejecución más rápida de algunas etapas de la canalización de agregación.
Change Streams y documentos huérfanos
A partir de MongoDB 5.3, durante la migración de rango, los eventos de flujo de cambios no se generan para las actualizaciones de documentos huérfanos.