Actualización a una nueva versión principal

Databases for MongoDB ofrece dos vías de actualización diferentes:

  • Actualización in situ a una nueva versión principal (actualmente compatible con el Plan MongoDB Estándar y el Plan MongoDB Empresarial).
  • Restauración desde una copia de seguridad (compatible con el Plan MongoDB Estándar y el Plan MongoDB Empresarial).

Actualizaciones de versiones importantes in situ

La actualización in situ de versiones principales le permite actualizar su implantación a la siguiente versión principal, eliminando la necesidad de restaurar una copia de seguridad en una nueva implantación. Este enfoque mantiene las mismas cadenas de conexión, sin necesidad de reconfigurar el despliegue. Sin embargo, si la nueva versión principal requiere ajustes en la aplicación, habrá que abordarlos.

Durante la ventana de actualización de versión principal in situ (incluida una copia de seguridad), la implantación se establece en setUserWriteBlockMode, que sólo permite operaciones de lectura pero no de escritura en la implantación para garantizar una actualización segura. Tan pronto como se complete la actualización de la versión principal de la implementación, se writeBlockMode eliminará el.

Existen dos opciones a la hora de realizar una actualización de versión principal in situ:

  • Actualización de versión mayor in situ con copia de seguridad: esta ruta crea una copia de seguridad antes de realizar la actualización real, lo que proporciona una capa adicional de seguridad (la única opción para el Plan MongoDB Enterprise).

  • Actualización in situ de la versión principal sin copia de seguridad: Esta opción procede a la actualización sin crear previamente una copia de seguridad. En caso de que la actualización in situ no tenga éxito, deberá restaurar la implantación a partir de la última copia de seguridad en una nueva implantación.

    No se recomienda la actualización in situ sin copia de seguridad. Puede provocar la pérdida de datos si la actualización falla en cualquier fase, ya que no habrá una copia de seguridad inmediata desde la que restaurar.

    [La recuperación a un momento determinado](/docs/databases-for-mongodb?topic=databases-for-mongodb-pitr) y [la restauración fuera de línea mediante recuperación a un momento determinado(PITR)](/docs/databases-for-mongodb?topic=databases-for-mongodb-pitr#pitr-offline-restore) no estarán disponibles temporalmente para una versión hasta que se haya completado una instantánea de dicha versión y se haya realizado correctamente su copia de seguridad. Esta instantánea no aparece en tu lista de copias de seguridad.

Antes de empezar

Tenga en cuenta los siguientes aspectos antes de iniciar el procedimiento de actualización.

  • Su implantación debe estar en buen estado antes de proceder a la actualización.
  • Su instalación debe tener al menos 2 GB de espacio libre en disco.
  • Su despliegue no debe tener ningún usuario con privilegios para bypassWriteBlockingMode.
  • Sólo puede actualizar a la siguiente versión principal, en lugar de especificar la versión de su elección.
  • Cada versión principal contiene algunas características que pueden no ser compatibles con versiones anteriores. Consulte las notas de la versión del proveedor de la base de datos para ver los cambios que pueden afectar a sus aplicaciones.
  • No es posible degradar una implantación a una versión anterior.
  • Una vez iniciada, la actualización de la versión principal no puede cancelarse.
  • En el caso de MongoDB Enterprise Edition, debe haber al menos una copia de seguridad disponible antes de realizar la actualización.
  • En el caso de MongoDB Enterprise Edition, la restauración y actualización mediante PITR con un punto en el tiempo de la versión anterior, tras una actualización in situ a una versión principal superior, debe realizarse en dos pasos distintos.

Actualización en la IU

  1. Crea un nuevo « Databases for MongoDB » para probar el proceso de actualización.
    Crea la implementación restaurando una copia de seguridad de tu implementación actual con la misma versión.

  2. Dirige tu aplicación de prueba hacia el entorno de prueba.
    Actualiza tu aplicación de staging para que apunte a la implementación de prueba. Confirme que su aplicación de prueba puede conectarse correctamente a la implantación de ensayo y que la aplicación funciona como se espera. Realice las pruebas de rendimiento y funcionamiento necesarias del entorno de ensayo.

  3. Actualiza la versión principal de tu entorno de pruebas haciendo clic en el botón « Actualizar versión principal » de la página «Resumen ».
    Esto pondrá tu base de datos en modo «SOLO LECTURA» mientras se completa el proceso de actualización. Tenga en cuenta el tiempo que tarda en completarse la actualización para que pueda utilizar la configuración de caducidad de actualización para contener las actualizaciones dentro de su ventana de mantenimiento.

  4. Comprueba que tu aplicación de prueba funcione con la nueva versión de la base de datos.
    Si tu aplicación funciona, este paso confirma que es seguro actualizar tu base de datos de producción.

  5. Actualiza la implementación de tu base de datos de producción a la nueva versión.
    Una vez que hayas comprobado que tu aplicación funciona correctamente con la nueva versión de la base de datos, puedes volver a la consola de administración e iniciar el proceso de actualización de tu entorno de producción. En la sección Detalles de la implantación de la página Descripción general, haga clic en el botón Actualizar versión principal y siga los pasos.

    Una vez que se inicia el proceso de actualización in situ, no se puede detener ni revertir. Así, en el improbable caso de que se produzca un error, la implantación de su base de datos podría resultar irrecuperable. Por lo tanto, cree una copia de seguridad que luego pueda utilizar para restaurar en una nueva implantación. Si selecciona "Actualización de versión principal in situ con copia de seguridad", la copia de seguridad que se crea puede utilizarse para restaurar en una nueva implantación.

expiration for starting upgrade le permite configurar un periodo de "tiempo de espera" dentro del cual debe iniciarse el trabajo de actualización antes de que se cancele automáticamente. Además, pruebe la actualización por adelantado para asegurarse de que se completa en el plazo deseado. Si, por ejemplo, quieres completar la actualización en 1 hora, y has probado la actualización y sabes que tarda 30 minutos, entonces tu trabajo de actualización debe comenzar en los 30 minutos siguientes a que confirmes que quieres actualizar. Por lo tanto, establece la caducidad en 30 minutos, de modo que si no se inicia en ese tiempo, no sobrepase tu ventana.

Actualización a través de la API

Utilice el siguiente comando para actualizar in situ:

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/version -H 'Authorization: Bearer <>' -H 'Content-Type: application/json' -d '{"version": "7.0"}'

expiration for starting upgrade le permite configurar un periodo de "tiempo de espera" dentro del cual debe iniciarse el trabajo de actualización antes de que se cancele automáticamente. Además, pruebe la actualización por adelantado para asegurarse de que se completa en el plazo deseado. Si, por ejemplo, quieres completar la actualización en 1 hora, y has probado la actualización y sabes que tarda 30 minutos, entonces tu trabajo de actualización debe comenzar en los 30 minutos siguientes a que confirmes que quieres actualizar. Por lo tanto, establezca la caducidad a una marca de tiempo de 30 minutos a partir de ahora, de modo que si no se inicia dentro de ese tiempo, no sobrepasará su ventana. La caducidad debe estar comprendida entre 5 minutos (por defecto) y 24 horas a partir de ahora. Para más información, consulte la API Cloud Databases.

Actualización a través de la CLI

Disponible en la versión del complemento CDB >= 0.20.0

Para ver la lista de transiciones de actualización y restauración permitidas para la implantación:

ibmcloud cdb deployment-capability-show <NAME|CRN> versions

Para actualizar el comando con los parámetros requeridos:

ibmcloud cdb deployment-version-upgrade <NAME|CRN> <TARGET_VERSION>

Para ver todos los detalles de los parámetros del comando:

ibmcloud cdb deployment-version-upgrade --help

expiration for starting upgrade le permite configurar un periodo de "tiempo de espera" dentro del cual debe iniciarse el trabajo de actualización antes de que se cancele automáticamente. Además, pruebe la actualización por adelantado para asegurarse de que se completa en el plazo deseado. Si, por ejemplo, quieres completar la actualización en 1 hora, y has probado la actualización y sabes que tarda 30 minutos, entonces tu trabajo de actualización debe comenzar en los 30 minutos siguientes a que confirmes que quieres actualizar. Por lo tanto, establece la caducidad en 30 minutos, de modo que si no se inicia en ese tiempo, no sobrepase tu ventana. La caducidad debe estar comprendida entre 5 minutos (por defecto) y 24 horas a partir de ahora. Hay dos formas de establecer la caducidad utilizando la CLI --expire-in o --expire-at. Para obtener más información, consulta la ayuda del comando.

Actualización mediante Terraform

Disponible en la versión del proveedor de Terraform >= 1.79.2

Para actualizar, sólo tiene que añadir o cambiar el valor version en su configuración. También hay un indicador bool opcional, version_upgrade_skip_backup, que puede establecer para omitir la copia de seguridad.

No se recomienda omitir una copia de seguridad. Omitir una copia de seguridad antes de actualizar una versión es peligroso y puede provocar la pérdida de datos si la actualización falla en cualquier fase, ya que no habrá una copia de seguridad inmediata desde la que restaurar.

La base de datos se pondrá en modo SOLO LECTURA durante la actualización. Se recomienda encarecidamente probar antes de actualizar.

La actualización puede requerir más tiempo que el tiempo de espera predeterminado. Se puede establecer un valor de tiempo de espera más largo utilizando el atributo timeouts.

Terraform tiene timeouts en lugar de timestamps de expiración. Por lo tanto, aumente su tiempo de espera, ya que su valor de actualización de tiempo de espera se utiliza como la expiración. Por ejemplo, si establece un tiempo de espera de 20 minutos, la caducidad se fijará en 20 minutos y si la actualización no se inicia en ese plazo, caducará y la actualización no se iniciará. Tenga en cuenta que la caducidad máxima es de 24 horas, por lo que aunque establezca una caducidad de 36 horas, la actualización caducará si no se ha iniciado en las primeras 24 horas.

Si hay una actualización en curso, tenga en cuenta que algunas tareas pueden estar en cola y no procederán hasta que se complete la actualización de la versión.

Resolución de problemas

Usuario con bypassWriteBlockingMode

Para garantizar una actualización segura, ningún usuario debe poder realizar una acción de escritura durante la copia de seguridad o la actualización. Antes de que la base de datos entre en writeBlockMode, se comprueba si algún usuario tiene privilegios para bypassWriteBlockingMode. Si se identifica a dicho usuario, la tarea entra en estado fallido. Cualquier reintento fallará y sólo la eliminación de un usuario con dicho privilegio permite ejecutar la actualización de versión principal in situ.

Chequeos médicos

Si una instancia de servicio tiene pocos recursos, la tarea falla porque no se puede garantizar una actualización segura en estas circunstancias. El consumo de recursos puede evaluarse mediante la integración de la supervisión. Si no todos los componentes de la base de datos están disponibles para ser actualizados, la tarea de actualización falla.

Para MongoDB Enterprise Edition, el soporte de PITR requiere que existan instantáneas actuales sin lagunas, y no se realizarán instantáneas durante la actualización. Si no se puede garantizar PITR, la actualización in situ fallará.

Esto puede suceder debido al mantenimiento o al uso de la base de datos. Las tareas que fallaron debido a comprobaciones de estado fallidas pueden reintentarse más tarde. Si la tarea sigue fallando, abre un ticket de soporte con IBM Cloud support.

Restauración de la copia de seguridad

Antes de que una versión principal de una base de datos llegue al final de su vida útil (EOL), actualice a la siguiente versión principal disponible restaurando a partir de una copia de seguridad en una nueva instancia de base de datos.

Prepare la ejecución y, a continuación, migre a la última versión antes de la fecha EOL. Para obtener más información, consulte Política de versiones.

No se da soporte a la retrotracción de versiones.

Actualiza a la última versión de « MongoDB », disponible en Databases for MongoDB. Busque la versión más reciente en la página de catálogo, en el mandato de plugin de CLI Cloud Databases ibmcloud cdb deployables-show, o en el punto final Cloud Databases API /deployables.

La actualización se lleva a cabo restaurando una copia de seguridad de tus datos en una nueva implementación. La restauración a partir de una copia de seguridad tiene varias ventajas:

  • La base de datos original se mantiene en ejecución y el trabajo de producción no se tiene que interrumpir.
  • Puede probar la base de datos nueva fuera de producción y actuar ante cualquier incompatibilidad de alguna aplicación.
  • Se puede volver a ejecutar todo el proceso en cualquier momento.
  • Una restauración nueva reduce la probabilidad de que los artefactos innecesarios de la versión anterior de la base de datos se pasen a la nueva base de datos.

Vías de acceso de actualización

Principales vías de actualización de versiones
Versión actual Vía de acceso de actualización principal
MongoDB 7 MongoDB 8

Actualización en la IU

Para los nuevos modelos de alojamiento (computación aislada y computación compartida), la actualización a una nueva versión principal está disponible a través de la CLI y la API.

Puede actualizar a una nueva versión restaurando una copia de seguridad desde la página Copias de seguridad y restauración de su despliegue en la consola IBM Cloud. Haga clic en Restaurar copia de seguridad en una copia de seguridad para abrir una página en una nueva pestaña en la que podrá cambiar algunas opciones para la nueva implantación. Una de ellas es la versión de la base de datos, que se rellena automáticamente con las versiones disponibles a las que puede actualizar. Selecciona una versión y haz clic en « Restaurar copia de seguridad » para iniciar el proceso de aprovisionamiento y restauración.

Actualización a través de la CLI

Cuando actualice y restaure desde la copia de seguridad mediante la CLI de IBM Cloud, utilice el mandato de suministro desde el controlador de recursos.

ibmcloud resource service-instance-create <INSTANCE_NAME> <SERVICE_ID> <SERVICE_PLAN_ID> <REGION>

Los parámetros instance_name, service_id, service_plan_id y region son todos obligatorios. También debe indicar -p con los parámetros de versión y de ID de copia de seguridad en un objeto JSON. El nuevo despliegue se dimensiona automáticamente con el mismo disco y memoria que el despliegue de origen en el momento de la copia de seguridad.

ibmcloud resource service-instance-create example-upgrade databases-for-mongodb standard us-south \
-p \ '{
  "backup_id": "crn:v1:bluemix:public:databases-for-mongodb:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
  "version":"7.0"
}'

Actualización a través de la API

Al igual que en el caso del aprovisionamiento a través de la API, debes seguir los pasos necesarios para utilizar la API del controlador de recursos antes de poder utilizarla para actualizar a partir de una copia de seguridad. A continuación, envíe una solicitud POST a la API. Los parámetros name, target, resource_group y resource_plan_id son obligatorios. Indica también la versión y el ID de la copia de seguridad. El nuevo despliegue tiene la misma asignación de memoria y de disco que el despliegue de origen en el momento de la copia de seguridad.

curl -X POST   https://resource-controller.cloud.ibm.com/v2/resource_instances   -H 'Authorization: Bearer <>'   -H 'Content-Type: application/json'     -d '{
    "name": "my-instance",
    "target": "us-south",
    "resource_group": "5g9f447903254bb58972a2f3f5a4c711",
    "resource_plan_id": "databases-for-mongodb-standard",
    "backup_id": "crn:v1:bluemix:public:databases-for-mongodb:us-south:a/54e8ffe85dcedf470db5b5ee6ac4a8d8:1b8f53db-fc2d-4e24-8470-f82b15c71717:backup:06392e97-df90-46d8-98e8-cb67e9e0a8e6",
    "version":"7.0"
  }'

Actualización mediante Terraform

Utilice Terraform para restaurar una copia de seguridad de una versión anterior a una nueva versión.

  1. Configure su backup_id. Para obtener más información, consulte backup_id.
  2. Establezca su version en el atributo de versión. Para obtener más información, consulte version.

El código es el siguiente:

resource "ibm_database" "<your-instance>" {
  name                                 = "<your_database_name>"
  service                              = "<service>"
  plan                                 = "<plan>"
  location                             = "<region>"
  version                              = "<version>"
  backup_id                            = "<backup_id>"
}

Para más información, consulte el registro de Terraform en Cloud Databases. Como alternativa, puede utilizar Terraform IBM Modules(TIM) para crear una nueva instancia de base de datos a partir de una instancia de copia de seguridad. Para obtener más información, consulte Ejemplo de restauración a partir de una copia de seguridad.