Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

mongot Preguntas frecuentes sobre la implementación

Las siguientes preguntas y respuestas cubren la implementación de MongoDB Search y búsqueda vectorial con los controladores de MongoDB para el operador de Kubernetes. Para obtener una lista completa de las restricciones, consulte mongot Limitaciones de implementación. Para confirmar la compatibilidad de la versión antes de implementar, consulte Compatibilidad y requisitos de búsqueda y búsqueda vectorial.

No. 1.70.1 es la versión mínima de mongot para implementaciones autogestionadas. Las 0.x compilaciones anteriores son versiones preliminares que no recomendamos para uso en producción.

No. No puede actualizar una implementación de Public Preview (0.x) a una versión GA en su lugar. Para pasar a GA, realice una instalación nueva.

Haga una copia de seguridad de mongod, no de mongot. Los índices mongot son datos derivados que mongot reconstruye a partir de mongod, por lo que una copia de seguridad de mongod es suficiente para recuperarlos. Incluya el tiempo de reconstrucción del índice en sus objetivos de tiempo de recuperación, ya que la reconstrucción lleva tiempo. Para obtener más información, consulte Copia de seguridad y restauración.

La habilitación de TLS en una implementación que ya se está ejecutando provoca una interrupción del servicio breve y limitada porque mongot debe reiniciarse para leer los nuevos certificados. La rotación de un certificado en una implementación que ya utiliza TLS también requiere un reinicio de mongot, ya que mongot lee los certificados solo al inicio. Si implementa varias réplicas de mongot detrás del balanceador de carga, las query pueden continuar durante ese reinicio. Para obtener más información, consulta proteger la conexión de MongoDB a Search.

Depende del número de réplicas de mongot. Si implementa varias réplicas de mongot detrás del balanceador de carga y también ejecuta más de una réplica de Envoy, las queries seguirán ejecutándose mientras las implementaciones de mongot o Envoy se someten a reinicios en secuencia. Con una sola réplica, las queries ven una breve brecha hasta que el pod vuelve a estar listo.

Sí. Para usar su propio balanceador de carga, ejecute mongot en modo no administrado. El modo no administrado solo está disponible para implementación de clústeres únicos. Para obtener más información, consulte topología compatibles.

Sí. Cuando spec.clusters tiene más de una entrada, cada entrada debe establecer loadBalancer.managed. El operador de MongoDB Controllers para Kubernetes rechaza un recurso de clúster múltiple que utiliza un balanceador de carga no administrado o ningún balanceador de carga, porque mongod necesita un punto final estable y enrutable para llegar a la flota mongot en cada clúster. Para obtener más información, consulte Topología admitida.

No. El operador de MongoDB Controllers para Kubernetes no gestiona un mongod externo, por lo que no establece los valores mongotHost y searchIndexManagementHostAndPort setParameter en él. Debes configurar esos en tu mongod externo tú mismo para que las query lleguen a mongot. En una implementación de varios clústeres, señala cada mongod en el punto final mongot de su propio clúster.

mongot no proporciona cifrado en reposo a nivel de aplicación. Para cifrar los datos del índice mongot, cifre el volumen subyacente con un mecanismo de nivel de Kubernetes o de proveedor de nube. Para obtener más información, consulte Proteja la conexión de MongoDB a Search.

No. Una funcionalidad está disponible en mongot autogestionado solo después de que se envía en una versión binaria mongot. Para obtener más información, consulte mongot Limitaciones de implementación.