Actualización a una nueva versión principal

Gen 2

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 Estándar de MongoDB ).
  • Restauración a partir de una copia de seguridad (compatible con el plan Standard de MongoDB y el plan Enterprise de MongoDB ).

Actualizaciones de versión principal sin necesidad de reinicio

La actualización de versión principal in situ te permite actualizar tu implementación a la siguiente versión principal, lo que elimina la necesidad de restaurar una copia de seguridad en una nueva implementación. Este enfoque mantiene las mismas cadenas de conexión, sin necesidad de reconfigurar la implementación. No obstante, si la nueva versión principal requiere ajustes en la aplicación, estos deberán subsanarse.

Durante el periodo de actualización a una versión principal sin interrupción del servicio (incluida la realización de una copia de seguridad), el entorno de implementación se configura en modo «setUserWriteBlockMode», que solo permite operaciones de lectura, pero no de escritura, en el entorno de implementación, con el fin de garantizar una actualización segura. Tan pronto como se complete la actualización de la versión principal de la implementación, se writeBlockMode se elimina.

Hay dos opciones a la hora de realizar una actualización de versión principal sin desinstalar la versión anterior:

  • Actualización de la versión principal sin interrupción del servicio con copia de seguridad: esta opción crea una copia de seguridad antes de realizar la actualización propiamente dicha, lo que proporciona una capa adicional de seguridad.

  • Actualización de versión principal in situ sin copia de seguridad: esta opción lleva a cabo la actualización sin crear previamente una copia de seguridad. En caso de que la actualización in situ no se realice correctamente, tendrás que restaurar tu implementación a partir de la última copia de seguridad en una nueva implementación.

    No se recomienda realizar una actualización in situ sin copia de seguridad. Si la actualización falla en cualquier momento, podría producirse una pérdida de datos, ya que no habrá una copia de seguridad inmediata a partir de la cual restaurarlos.

Antes de empezar

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

  • Tu implementación debe estar en buen estado antes de realizar la actualización.
  • Tu instalación debe tener al menos 2 GB de espacio libre en disco.
  • Tu entorno de implementación no debe tener ningún usuario con privilegios para bypassWriteBlockingMode.
  • Solo puedes actualizar a la siguiente versión principal, en lugar de especificar la versión que prefieras.
  • Cada versión principal incluye algunas funciones que pueden no ser compatibles con versiones anteriores. Consulta las notas de la versión del proveedor de la base de datos para ver si hay algún cambio que pueda afectar a tus aplicaciones.
  • No se admite la reversión de una implementación a una versión anterior.
  • La actualización de versión principal in situ no se puede cancelar una vez iniciada.
  • En el caso de MongoDB Enterprise Edition, debe haber al menos una copia de seguridad disponible antes de realizar la actualización.

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. Comprueba que tu aplicación de prueba pueda conectarse correctamente al entorno de pruebas y que funcione según lo previsto. Realizar todas las pruebas de rendimiento y operativas necesarias en el entorno de prueba.

  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. Toma nota de cuánto tiempo tarda en completarse la actualización, para que puedas utilizar la configuración de caducidad de la actualización y así limitar las actualizaciones a tu 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 implementación» de la página «Resumen», haz clic en el botón «Actualizar versión principal» y sigue los pasos indicados.

    Una vez iniciado el proceso de actualización in situ, no se puede detener ni revertir. Por lo tanto, en el improbable caso de que se produjera un error, la implementación de tu base de datos podría quedar irrecuperable. Por lo tanto, crea una copia de seguridad que luego puedas utilizar para restaurar una nueva implementación. Si seleccionas «Actualización de versión principal in situ con copia de seguridad», la copia de seguridad que se cree se podrá utilizar para restaurar el sistema en una nueva implementación.

La opción « expiration for starting upgrade » te permite configurar un periodo de «tiempo de espera» dentro del cual debe iniciarse la tarea de actualización antes de que se cancele automáticamente. Además, prueba la actualización previamente en el entorno de pruebas para asegurarte de que se complete dentro del plazo deseado. Si, por ejemplo, quieres completar la actualización en el plazo de una hora, y has probado la actualización y sabes que tarda 30 minutos, entonces tu tarea de actualización debe iniciarse en los 30 minutos siguientes a que confirmes que deseas actualizar. Por lo tanto, configura el tiempo de caducidad en 30 minutos, de modo que, si no se inicia en ese plazo, no se salga del intervalo establecido.

Actualización a través de la API

Utiliza el siguiente comando para actualizar sin desinstalar la versión anterior:

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"}'

La opción « expiration for starting upgrade » te permite configurar un periodo de «tiempo de espera» dentro del cual debe iniciarse la tarea de actualización antes de que se cancele automáticamente. Además, prueba la actualización previamente en el entorno de pruebas para asegurarte de que se complete dentro del plazo deseado. Si, por ejemplo, quieres completar la actualización en el plazo de una hora, y has probado la actualización y sabes que tarda 30 minutos, entonces tu tarea de actualización debe iniciarse en los 30 minutos siguientes a que confirmes que deseas actualizar. Por lo tanto, configura la fecha de caducidad en una marca de tiempo de 30 minutos a partir de ahora, de modo que, si no se inicia dentro de ese plazo, no se salga del intervalo establecido. El plazo de caducidad debe estar comprendido entre 5 minutos (por defecto) y 24 horas a partir de ahora. Para obtener más información, consulta la API de « 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 implementación:

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

Para ejecutar comando «upgrade» con los parámetros necesarios:

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

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

ibmcloud cdb deployment-version-upgrade --help

La opción « expiration for starting upgrade » te permite configurar un periodo de «tiempo de espera» dentro del cual debe iniciarse la tarea de actualización antes de que se cancele automáticamente. Además, prueba la actualización previamente en el entorno de pruebas para asegurarte de que se complete dentro del plazo deseado. Si, por ejemplo, quieres completar la actualización en el plazo de una hora, y has probado la actualización y sabes que tarda 30 minutos, entonces tu tarea de actualización debe iniciarse en los 30 minutos siguientes a que confirmes que deseas actualizar. Por lo tanto, configura el tiempo de caducidad en 30 minutos, de modo que, si no se inicia en ese plazo, no se salga del intervalo establecido. El plazo de caducidad debe estar comprendido entre 5 minutos (por defecto) y 24 horas a partir de ahora. Hay dos formas de configurar la fecha de caducidad mediante 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, solo tienes que añadir o modificar el valor de « version » en tu configuración. También hay un indicador booleano opcional, version_upgrade_skip_backup``, que puedes activar para omitir la copia de seguridad.

No se recomienda saltarse una copia de seguridad. No realizar una copia de seguridad antes de actualizar a una nueva versión es peligroso y puede provocar la pérdida de datos si la actualización falla en cualquier momento, ya que no habrá ninguna copia de seguridad inmediata a partir de la cual restaurar los datos.

La base de datos pasará a modo «SOLO LECTURA» durante la actualización. Se recomienda encarecidamente realizar pruebas antes de actualizar.

La actualización puede requerir más tiempo del establecido en el tiempo de espera predeterminado. Se puede establecer un valor de tiempo de espera más largo utilizando el atributo «timeouts».

Terraform utiliza tiempos de espera en lugar de marcas de tiempo de caducidad. Por lo tanto, aumenta el tiempo de espera, ya que el valor de actualización del tiempo de espera se utiliza como fecha de caducidad. Por ejemplo, si estableces un tiempo de espera de 20 minutos, el plazo de 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á. Ten en cuenta que el plazo máximo de caducidad es de 24 horas, por lo que, aunque configures un tiempo de espera de 36 horas, la actualización caducará si no se ha iniciado en las primeras 24 horas.

Si se está llevando a cabo una actualización, ten en cuenta que algunas tareas pueden quedar en cola y no se ejecutarán hasta que finalice 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 operaciones 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 permiso para bypassWriteBlockingMode. Si se identifica a un usuario de este tipo, la tarea pasa a un estado de fallo. Cualquier nuevo intento fracasará y solo eliminando a un usuario con dicho privilegio se podrá llevar a cabo la actualización de versión principal in situ.

Revisiones médicas

Si una instancia de servicio tiene pocos recursos, la tarea falla porque, en estas circunstancias, no se puede garantizar una actualización segura. El consumo de recursos se puede evaluar utilizando la herramienta integración de la supervisión. Si no todos los componentes de la base de datos están disponibles para la actualización, la tarea de actualización falla. Esto puede deberse a trabajos de mantenimiento. Las tareas que hayan fallado debido a que no superaron las comprobaciones de estado se pueden volver a intentar más tarde. Si la tarea sigue fallando, abre un ticket de asistencia en 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 ciclo de vida (EOL), actualícela a la siguiente versión principal disponible restaurando una copia de seguridad en una nueva instancia de la base de datos.

Prepárate para seguir utilizando la versión más reciente y, posteriormente, migrar a ella antes de la fecha de fin de vida útil. Para obtener más información, consulta la Política de control de versiones.

No se admite la reversión a versiones anteriores.

Actualiza a la última versión de « MongoDB », disponible en Databases for MongoDB. Encuentra la última versión en la página del catálogo, mediante el comando del complemento de la CLI de « Cloud Databases » ibmcloud cdb deployables-show o a través del punto final de la API de « Cloud Databases » /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 presenta 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

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

Actualización en la IU

En el caso de 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.

Puedes actualizar a una nueva versión restaurando una copia de seguridad desde la página «Copias de seguridad y restauración» de tu implementación en la consola de IBM Cloud. Haz 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ás modificar algunas opciones para la nueva implementació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

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

  1. Configura tu backup_id. Para obtener más información, consulte backup_id.
  2. Establece « version » en el atributo «version». Para obtener más información, consulte version.

El código tiene el siguiente aspecto:

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

Para obtener más información, consulta el Registro de Terraform de Cloud Databases.