Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

Changelog del agente de automatización

Nota

Anuncio

El agente de supervisión y agente de copias de seguridad se ha fusionado en el agente de automatización, que ahora se conocerá como el MongoDB Agent. Más información sobre este cambio.


Lanzado con Ops Manager 4.0.17 el 06/02/2020

  • Redacta datos de configuración confidenciales en las entradas de registro del MongoDB Agent para mejorar la seguridad.

Publicado con Ops Manager 4.0.16 el 2019-11-07

  • Añade soporte para el/la businessCategory campo en validación extendida TLS certificados.

  • El agente de automatización ahora se compila usando Go 1.13.

Lanzado con Ops Manager 4.0.15 el 2019-09-05

  • Soluciona un error en el que el agente de MongoDB podía entrar en pánico y borrar archivos de su directorio de trabajo actual.

Lanzado con Ops Manager versión 4.0.14 el 31 de julio de 2019

  • Corrección: Restauración de las descargas realizadas por el agente de automatización ahora respeta el parámetro de Ops Manager sslTrustedMMSServerCertificate configurado.

Nota

sslTrustedMMSServerCertificate ha quedado obsoleta. Utiliza httpsCAFile en su lugar.

Publicado con Ops Manager 4.0.13 el 2019-07-04

Publicado con Ops Manager 4.0.12 el 2019-06-06

  • Solución: agente de automatización ahora cierra periódicamente todas las conexiones inactivas de HTTP.

  • Solución: Permitir que el agente de automatización se conecte a mongos a través de nombres de host "cortos" o "largos".

  • Solución: Corrige el fallo en la herramienta make-init-scripts.

  • Corrección: Reduzca el tiempo de espera HTTP Header por defecto en el agente de automatización de 15 minutos a 30 segundos. Esto garantiza fallos más rápidos en evento de cambios en la infraestructura del servicio Ops Manager, como cuando los balanceadores de carga mueven nodos fuera de un grupo.

  • Corrección: En la restauración de un clúster, remueve todos los metadatos de particionado de la colección config.system.sessions. Si no remueve los metadatos de particionado, MongoDB no podrá volver a crear esta colección después de que se complete la restauración.

Lanzado con Ops Manager 4.0.8 el 2019-02-07

  • Solución: Reduce la cantidad de memoria utilizada para generar planes para clústeres fragmentados grandes.

  • Solución: Rotación de entradas de registro cuando la rotación de registros de MongoDB está habilitada y el número máximo de entradas de registro sin comprimir está configurado en dos.

Lanzado con Ops Manager 4.0.7 el 2019-01-10

  • Agregue soporte para el net.ssl.certificateSelector opción de configuración.

  • Corrección: Permitir el cambio exitoso en el storageEngine para el binario autónomo: mongod con TLS/SSL habilitado.

  • Solucionado: El agente de automatización ya no intenta autenticarse en árbitros que están configurados para usar X.509 para clusterAuthMode.

Lanzado con Ops Manager 4.0.6 el 2018-12-10

Lanzado con Ops Manager 4.0.5 el 01-11-2018

  • Agregar soporte para el parámetro ssl.FIPSMode.

  • Corrección: Fuga de memoria al usar la funcionalidad de Grupos de servidores.

Lanzado con Ops Manager 4.0.4 el 12-10-2018

  • Corrección crítica: Las restauraciones de MongoDB 4.0 pueden fallar si las descargas de instantáneas para los nodos en el set de réplicas terminan en momentos significativamente diferentes.

  • Corrección: restaurar la capacidad de actualizar de authSchemaVersion 3 a 5 en un clúster shardizado.

Publicado con Ops Manager 4.0.3 el 2018-10-04

  • Solución: agente de automatización puede añadir nuevos usuarios de MongoDB incluso si la autenticación SCRAM-SHA-1 se habilitó para la implementación después de activar SCRAM-SHA-256.

Publicado con Ops Manager 4.0.2 el 2018-09-06

  • Los cambios en los campos que afectan al almacenamiento en un set de réplicas podrían provocar la pérdida de datos si se reinician los procesos inesperadamente.

  • El agente de automatización no pudo determinar correctamente el estado si la ID de proceso utilizada previamente por un proceso de MongoDB fue reclamada por un proceso diferente después de un reinicio inesperado del servidor.

  • Solución: Permitir que los miembros de CSRS se apaguen.

Lanzado con Ops Manager 4.0.1 el 2018-08-02

  • Solución crítica: Configure TasksMax=infinity y TasksAccounting=false en los scripts systemd del Agente de automatización.

  • Solución: Manejo del agente de automatización de las compilaciones empresariales para Amazon Linux 2.

Lanzado junto con Ops Manager 4.0.0 el 2018-06-27.

  • Se añadió soporte para MongoDB 4.0.

  • Se añadió soporte para SCRAM-SHA-256

  • Soporte de plataforma añadido para:

    • zLinux en RHEL 6

    • Debian 9

    • Amazon Linux 2

Importante

MongoDB 4.0 Community Edition requiere libcurl. Instalá libcurl antes de utilizar Ops Manager para instalar MongoDB 4.0 Community.


Publicado con Ops Manager 3.6.10 el 2019-01-10

  • Corrección: Permitir el apagado de los miembros del conjunto de réplicas CSRS.

Lanzado con Ops Manager 3.6.9 el 01-11-2018

  • Arreglo crítico: Si los procesos se reiniciaban inesperadamente, los cambios en los campos que afectan al almacenamiento en un set de réplicas podían provocar la pérdida de datos.

  • Corrección: Fuga de memoria al usar la funcionalidad de Grupos de servidores.

Lanzado con Ops Manager 3.6.8 el 2018-08-02

  • Solución crítica: Configure TasksMax=infinity y TasksAccounting=false en los scripts systemd del Agente de automatización.

  • Se finaliza el soporte para SLES 11 y Ubuntu 12.04.

  • Soporte del Agente de Automatización para BI Connector 2.5.

  • Índices de texto compuestos a través de la automatización.

  • Solución: Cuando se recopilan registros, ignore los errores de los archivos que hayan desaparecido.

  • Sustituir la prueba de Evergreen Ubuntu 12 por Ubuntu 14.

  • Actualizar la versión del BI Connector probada a 2.5.0.

Lanzado con Ops Manager 3.6.6 el 2018-05-03

  • Corrección: los agente de automatización no deben intentar rotar la entrada de registro de BI Connector para los BI Connectors en otros servidores.

Lanzado con Ops Manager 3.6.5 el 2018-04-05

  • Corregir: Desactivar el hilo de monitor TTL de MongoDB al aplicar los oplogs durante la restauración a un punto específico del tiempo.

  • Al realizar tareas de mantenimiento en un nodo de partición de MongoDB 3.2 para el redimensionamiento del oplog, inicia el nodo con --recoverShardingState en falso.

  • Cuando el agente de automatización realiza un cambio de tamaño en un clúster fragmentado de MongoDB 3.2, desactiva la recuperación de particionado mientras el nodo se inicia como un autónomo.

Publicado con Ops Manager 3.6.4 el 01/03/2018

  • Los cambios realizados en cualquier opción que afecte el almacenamiento en MongoDB darán como resultado automático una sincronización inicial gradual del set de réplicas.

    Para conjuntos de set de réplicas de un solo nodo y autónomos, se realizará una mongodump / mongorestore. Estas opciones incluyen security.enableEncryption, storage.smallfiles, storage.directoryPerDb y wiredTiger.directoryForIndexes. (El parámetro storage.engine siempre ha tenido este tratamiento.)

  • Corrección: el agente de automatización ahora cambia correctamente el tamaño del oplog en los clústeres de MongoDB que utilizan X-509 para la autenticación del clúster.

Nota

AVISO DE LANZAMIENTO

Ops Manager 3.6.4 soluciona un problema en el que establecer un valor para un campo setParameter usando Automatización puede no haber resultado en un reinicio adecuado del clúster de MongoDB. Como consecuencia de esta corrección, los clústeres en los que un campo setParameter esté específicamente configurado en el valor predeterminado para el setParameter pueden experimentar un reinicio en secuencia al actualizar a Ops Manager 3.6.4.

Al configurar un campo setParameter en MongoDB a través de la automatización, siempre realice un reinicio progresivo.

Publicado con Ops Manager 3.6.3 el 2018-02-01

  • Solución: la determinación del Estado Objetivo por parte del agente de automatización era incorrecta para implementaciones multi-servidor que utilizan el parámetro ldap.bind.queryPassword. Esto ya está resuelto y los cambios continuos procederán correctamente en estas implementaciones.

  • Corrección: Rotación de registros del BI Connector por el agente de automatización para zonas horarias con desfases positivos de GMT.

Lanzado con Ops Manager 3.6.2 el 2018-01-11

  • Permitir que el usuario especifique las flags del BI Connector sampleRefreshIntervalSecs y sampleSize

  • Solución: relajar la validación cuando se especifique krb5ConfigLocation parameter. Esto ya no implica que krb5Principal y krb5Keytab sean requeridos.

  • Corrección: la configuración de rotación de registro del BI Connector ahora respeta las marcas de tiempo de los host UTC.

  • Solución: Mejora la lógica que controla cuándo el agente de copias de seguridad utiliza el primario como fuente de sincronización.

Lanzado con Ops Manager 3.6.1 el 2017-12-19

  • Solución: Prevenir la condición de competencia cuando la versión de MongoDB y la compatibilidad de características entre versiones se actualizan al mismo tiempo.

  • Gestione las reglas de Firewall de Windows para el BI Connector.

Lanzado con Ops Manager 3.6.0 el 2017-12-05

  • Soporte para MongoDB 3.6.

  • Compatibilidad con campos avanzados de configuración de sets de réplicas.

  • Soporte para el nuevo modelo de clave API de agente.


Lanzado con Ops Manager 3.4.14 el 03-05-2018

Publicado con Ops Manager 3.4.13 el 2018-04-05

  • Solución: La determinación del estado de objetivo del Agente de automatización era incorrecta para implementaciones de varios servidores que usaban el parámetro ldap.bind.queryPassword. parámetro. Esto ya está resuelto y los cambios progresivos avanzarán correctamente en estas implementaciones.

Publicado con Ops Manager 3.4.12 por Ops Manager 3.4.12 en 2018-02-01

  • Mejoras en el registro

Lanzado con Ops Manager 3.4.10 el 2017-11-02

Lanzado con Ops Manager 3.4.9 el 05-10-2017

  • Solucionar el fallo para recolectar estadísticas de hardware relacionadas con el disco en algunas configuraciones de hardware.

  • Cuando la automatización crea un Windows temporal para realizar operaciones de mantenimiento en un mongod, remueva el servicio cuando se complete el mantenimiento.

Lanzado con Ops Manager 3.4.7 en 2017-08-03

  • Optimización para reducir la cantidad de verificaciones para comprobar si un proceso está en funcionamiento.

  • Mejorar la detección de estado durante las conversiones a sets de réplicas de servidores de configuración.

Publicado con Ops Manager 3.4.6 el 2017-07-06

  • Solución: Durante la conversión de CSRS, utiliza archivos de registro con nombres diferentes para los servidores de configuración temporales.

  • Solución: Durante la conversión de CSRS, solo apague un nodo cuando esté en estado secundario.

  • Solución: El código de análisis del archivo de configuración en Windows no analizaba todas las opciones posibles.

Lanzado con Ops Manager 3.4.5 el 18/05/2017

  • Cuando se realiza una restauración automatizada a un clúster particionado con diferentes nombres de particiones, actualizar el documento de identidad de la partición.

  • Cuando realices una restauración automatizada, asegúrate de que los metadatos de la partición siempre se actualicen en el orden correcto.

  • Cuando se realiza una restauración automatizada, siempre se debe restaurar a la versión de protocolo por defecto.

  • Solución: Empaquetamiento de RHEL7 para que el agente de automatización se inicie al arrancar el servidor.

  • Reduzca la frecuencia con la que el agente de automatización verifica los archivos de registro gestionados para reducir la sobrecarga de la CPU.

  • Ignorar los errores de get_mempolicy y asumir que NUMA no está habilitado.

Lanzado con Ops Manager 3.4.4 el 2017-03-30

  • Soluciona el problema del apagado de los procesos mongod durante una restauración automatizada en Windows.

  • Corrección de problemas al utilizar la automatización en implementaciones de múltiples servidores que emplean SSL y archivos de claves PEM cifrados.

  • Optimización para el mantenimiento del estado objetivo de clústeres fragmentados. Los agentes de automatización ejecutarán muchos menos comandos en el estado estable.

Lanzado con Ops Manager 3.4.3 el 17-02-2017

  • Corregir el error en la eliminación de fragmentos para clústeres particionados en MongoDB 3.4.

  • Creado con Go 1.7.

  • Compatibilidad con MacOS Sierra.

Lanzado con Ops Manager 3.4.2 el 19/01/2017

  • Solución: Es posible instalar el agente en Windows si el firewall de Windows estaba deshabilitado.

  • Corrección: Se puede usar MONGODB-CR para la autenticación del agente cuando se utiliza LDAP para la autenticación del usuario.

  • Solución: Problema en el que el agente dejaría de enviar el estado después de que MongoDB alcance su límite de conexiones.

Lanzada con Ops Manager 3.4.1 el 2016-12-27

  • Corrección: Puede instalar MongoDB en Power Linux cuando utilice Ops Manager en "modo local".

Publicado con OpsManager 3.4.0 el 2016-11-29

  • Agrega soporte para la automatización de las implementaciones de MongoDB 3.4.

  • Agrega soporte para la gestión de agentes de supervisión/copias de seguridad en sistemas Linux basados en PowerPC, exclusivo para implementaciones de MongoDB 3.4 o posteriores.

  • Desarrollada con Go 1.6.

  • Agrega soporte para la recopilación de métricas de hardware.

  • Cuando importes un proceso que use una contraseña para el archivo PEMKeyFile, ya no requerirá que el usuario vuelva a ingresar la contraseña del PEMKeyFile.

  • Solución: Puede actualizarse de MongoDB 2.4 a 2.6 mientras se permanece en authSchemaVersion 1.

  • No crea reglas de firewall de Windows para procesos que se inician en puertos temporales donde no se requiere acceso externo.

  • Utiliza la gestión systemd en RHEL7 y Ubuntu 16.04.


Lanzado con Ops Manager 2.0.7 en 2016-11-03

  • Los archivos de datos y entradas de registro de MongoDB tendrán un umask de 027. Requiere la instalación de un nuevo paquete.

Lanzado con Ops Manager 2.0.6 el 18/08/2016

  • Mejorar el registro de eventos en caso de fallos de autenticación.

  • Solución: se puede establecer clusterAuthMode en clústeres particionados.

Lanzado con Ops Manager 2.0.5 el 2016-07-14

  • Optimización sustancial en la recopilación de estados.

  • Tiempo de espera configurable para las conexiones a los procesos de MongoDB.

  • Arreglo: Problema al verificar el éxito al crear índices de texto en creación de índices continuas.

Lanzado con Ops Manager 2.0.4 el 20-05-2016

  • El agente ya no descarga datos de restauración para árbitros.

  • Corrección: Algunos casos en los que la conversión de CSRS podría quedar bloqueada.

  • Corrección: El agente puede reiniciar un servidor de configuración si todos los servidores de configuración están caídos.

  • Solución: validando las versiones de MongoDB cuando un clúster estaba en sistemas operativos mixtos.

Lanzado con Ops Manager 2.0.3 el 24-03-2016

  • Solución: Se puede importar el árbitro utilizando un archivo clave diferente al de la configuración existente.

  • Permitir especificar un puerto temporal para usar durante una actualización de CRSR.

Lanzado con Ops Manager 2.0.2 el 2016-03-01

Lanzado con Ops Manager 2.0.1 el 21-01-2016

  • Mejoras en la estabilidad y el rendimiento para las restauraciones a través de la automatización.

  • Se agregó una optimización para priorizar las acciones de reconfiguración del conjunto de réplicas sobre la creación de índices.

  • Mecanismo de creación de índices mejorado: la creación de índices ya no se realiza de manera progresiva para sets de réplicas de 2 nodos, sino que se realiza en segundo plano.

  • Se añadió una optimización para no comparar opciones de índice no compatibles al determinar si un índice ya existe o no.

  • Correction: Puede importar implementaciones existentes que incluyan árbitros ejecutándose con autenticación.

  • Solución: Conversión del motor de almacenamiento continua para conjuntos de réplicas para garantizar que siempre haya una supermayoría activa.

  • Solución: puede crear roles personalizados en clústeres segmentados que ejecuten MongoDB 3.2 con conjuntos de réplicas como servidores de configuración.

Lanzado con Ops Manager 2.0.0 el 2015-12-08

  • Se añadió soporte para MongoDB 3.2.0 clústeres con servidores de configuración como sets de réplicas.

  • Se agregó soporte para restauraciones automatizadas a través del Agente de Automatización.

  • Se añadió soporte para la creación de índices rolling.

  • Se añadió compatibilidad para configurar el almacenamiento cifrado WiredTiger para MongoDB 3.2.

  • Se añadió compatibilidad para la conversión progresiva a la autenticación de nodos X-509.

  • Gestión mejorada de clústeres fragmentados con miembros que se ejecutan en ambos sistemas operativos, basados en Linux y en Windows.

  • Se agregó la optimización al iniciar un nuevo Agente de supervisión o agente de copias de seguridad para garantizar que el proceso esté en ejecución antes de alcanzar el estado objetivo.

  • Corrección: glibc problema de compatibilidad en RHEL5 y RHEL6.

  • Corrección: los fallos en las actualizaciones automáticas del agente de automatización podrían causar un aumento en las llamadas de configuración desde el agente de automatización.

Lanzado con Ops Manager 1.8.2 el 20/10/2015

  • Corrección: El agente no reconoce las estaciones de trabajo RHEL como RHEL.

Lanzada con Ops Manager 1.8.1 el 2015-08-17

  • Fijar: puede gestionar un despliegue existente con un usuario que tenga privilegios de "root".

  • Corrección: Las conversiones del motor de almacenamiento no se quedan atascadas si el set de réplicas contiene un árbitro.

  • Solución: Se pueden actualizar las credenciales después de un intento fallido de gestionar una implementación existente.

Publicado con Ops Manager 1.8 el 2015-06-23

  • Se añadió soporte para gestionar implementaciones habilitadas para SSL.

  • Se añadió soporte para la gestión de implementaciones utilizando autenticación mediante Kerberos, LDAP y certificados de cliente x.509.

  • Se añadió soporte para importar un mongos existente con un archivo de configuración.

  • Soporte agregado para importar una implementación existente que contiene árbitros autenticados en los cuales el hostname no se resuelve localmente en la interface de loopback.

  • Se añadió la capacidad de actualizar el authSchemaVersion cuando la autenticación no está activada.

  • Se agregó la posibilidad de cambiar el motor de almacenamiento para sets de réplicas con más de un nodo de datos.

  • Se habilitaron conversiones de motor de almacenamiento para conjuntos de réplicas de un solo nodo y autónomos.

  • Se añadió un registro más detallado de cuándo MongoDB, el agente de supervisión o el agente de copias de seguridad rotan sus registros.

  • Se añadió soporte para versiones específicas de distribución de MongoDB Community Edition.

  • Se añadió una validación previa para garantizar que los procesos de MongoDB se ejecuten bajo el mismo usuario que el Agente de Automatización.

  • Se agregó la funcionalidad para borrar los binarios de MongoDB en disco que no están siendo utilizados por un proceso gestionado.

  • Se agregó una optimización en la que Ops Manager asume el éxito al iniciar un proceso bifurcado de MongoDB, en lugar de esperar a EOF.

  • Algoritmo mejorado para equilibrar los procesos de mongod entre núcleos.

  • Al borrar directorios, los enlaces simbólicos ya no se borran.

  • Solución: Puede importar credenciales para MONGODB-CR usuarios desde SCRAM-SHA-1 implementaciones. Consulte: MMS-2612 para obtener más detalles.

  • Solución: Puede derivar el puerto por defecto para los servidores de configuración que se inician con la opción --configsvr pero sin especificar un puerto. Ver: MMS-2489.

  • Solución: se pueden configurar tamaños de oplog superiores a 1TB.

  • Solución: El agente de automatización no interfiere con las etiquetas del set de réplicas creadas manualmente.

  • Se aseguró de que el Agente de automatización falle de manera controlada cuando no exista un usuario esperado durante una importación inicial.

Lanzado con Ops Manager 1.6.3 el 2015-06-23

  • Soporte agregado para importar una implementación existente que contiene árbitros autenticados en los cuales el hostname no se resuelve localmente en la interface de loopback.

  • Solución: Lógica utilizada para realizar un reinicio en secuencia.

  • Corrección: al derivar el puerto por defecto para los servidores de configuración iniciados con la opción --configsvr, pero sin especificar ningún puerto. Ver MMS-2489.

Publicado el 28-04-2015

  • Solución: Puede actualizar usuarios creados en MongoDB 2.4.

  • Solución: Ya no se realiza la reparación del servidor de configuración si el tercer servidor de configuración está fuera de sincronización.

Publicado el 26-03-2015

  • Arreglo: un caso poco común que impedía que el agente de automatización pudiera activar la autenticación con éxito.

Publicado el 02-03-2015

Lanzamiento inicial.

Volver

MongoDB Agent

En esta página