Recuperación de un punto en el tiempo

IBM Cloud® Databases for MySQL ofrece recuperación en un punto en el tiempo (PITR) para cualquier momento de los últimos 7 días. La implementación realiza copias de seguridad de forma continua e incremental, y permite reproducir transacciones para que una nueva implementación, restaurada a partir de una copia de seguridad, se sitúe en cualquier momento dentro de ese periodo de 7 días que necesites.

La pestaña «Copias de seguridad » de la interfaz de usuario de tu implementación recoge toda la información sobre PITR en la sección «Recuperación en un momento determinado ».

La información incluida es el momento más antiguo para una PITR. Para descubrir el punto de recuperación más antiguo a través de la CLI, utilice el mandato cdb mysql earliest-pitr-timestamp.

ibmcloud cdb mysql earliest-pitr-timestamp <deployment name or CRN>

Para descubrir el punto de recuperación más antiguo a través de la API, utilice el punto final /deployments/{id}/point_in_time_recovery_data para encontrar el momento de PITR más antiguo.

{
    "point_in_time_recovery_data": {
        "earliest_point_in_time_recovery_time": "2019-09-09T23:16:00Z"
    }
}

Recuperación

Las copias de seguridad se restauran en un nuevo despliegue. Después de que finalice el suministro del nuevo despliegue, los datos del archivo de copia de seguridad se restauran en el nuevo despliegue. Las copias de seguridad también se pueden restaurar entre cuentas, pero solo mediante la API y solo si el usuario que está ejecutando la restauración tiene acceso a las cuentas de origen y de destino.

De forma predeterminada, el nuevo despliegue se ajusta automáticamente al mismo disco y a la misma asignación de memoria que el despliegue de origen en el momento de realizar la copia de seguridad desde la que está restaurando. Especialmente en el caso de PITR, es posible que ese no sea el tamaño actual del despliegue. Si necesita ajustar los recursos asignados al nuevo despliegue, utilice los campos opcionales de la IU, la CLI o la API para cambiar el tamaño del nuevo despliegue. Asegúrese de asignar lo suficiente para los datos y la carga de trabajo, si el despliegue no recibe suficientes recursos, la restauración falla.

Mientras que el almacenamiento y la memoria se restauran igual que el despliegue de origen, las configuraciones específicas de la instancia no se establecen automáticamente para la nueva instancia. En este caso, puede ser necesario volver a ejecutar la configuración después de una restauración. Tenga en cuenta cualquier modificación de instancia antes de ejecutar la restauración (parámetros como shared_buffers, max_connections, deadlock_timeout, archive_timeout y otros) para garantizar el valor preciso de la instancia una vez finalizada la restauración.

Es fundamental que no elimines la implementación de origen mientras se está restaurando la copia de seguridad. Espera a que se haya configurado la nueva implementación y se haya restaurado la copia de seguridad antes de eliminar la implementación anterior. Al eliminar una implementación, también se eliminan sus copias de seguridad, por lo que no solo fallará la restauración, sino que es posible que tampoco puedas recuperar la copia de seguridad.

En la interfaz de usuario

Para iniciar una PITR, especifique la hora a la que desea volver a restaurar en la hora universal coordinada (UTC). Si quieres restaurar solo hasta el momento más reciente disponible, selecciona esa opción. Al pulsar Restaurar aparecen las opciones de la recuperación. Especifique un nombre, y seleccione la versión, la región y los recursos disponibles para el nuevo despliegue. Pulse Recuperar para iniciar el proceso.

Si utiliza Key Protect y tiene una clave, utilice la CLI para la recuperación. Se proporciona un mandato para su comodidad.

En la CLI

El controlador de recursos da soporte al suministro de despliegues de bases de datos, y el suministro y la restauración son responsabilidad de la CLI del controlador de recursos. Utilice el mandato resource service-instance-create.

Para PITR, utilice los parámetros point_in_time_recovery_time y point_in_time_recovery_deployment_id. El point_in_time_recovery_deployment_id es el ID del despliegue de origen y point_in_time_recovery_time es la indicación de fecha y hora en la hora universal coordinada a la que se desea restaurar. Si desea restaurar al punto en el tiempo más reciente disponible, utilice "point_in_time_recovery_time":" ".

ibmcloud resource service-instance-create <SERVICE_INSTANCE_NAME> <service-id> <region> -p '{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP"}'

Dispone de un mandato preformateado para una copia de seguridad o PITR específica en la vista detallada de la copia de seguridad.

Hay parámetros opcionales disponibles cuando se restaura a través de la CLI. Utilícelos si necesita personalizar los recursos o bien utilice una clave de Key Protect para el cifrado BYOK en el nuevo despliegue.

ibmcloud resource service-instance-create <SERVICE_INSTANCE_NAME> <service-id> standard <region> <--service-endpoints SERVICE_ENDPOINTS_TYPE> -p
'{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP","key_protect_key":"KEY_PROTECT_KEY_CRN", "members_disk_allocation_mb":"DESIRED_DISK_IN_MB", "members_memory_allocation_mb":"DESIRED_MEMORY_IN_MB", "members_cpu_allocation_count":"NUMBER_OF_CORES"}'

En la API

El controlador de recursos admite el aprovisionamiento de implementaciones de bases de datos; el aprovisionamiento y la restauración son responsabilidad de la API del controlador de recursos. Complete los pasos necesarios para utilizar la API del controlador de recursos antes de utilizarla para restaurar a partir de una copia de seguridad.

Cuando tenga toda la información, la solicitud de creación se publica (POST) en el punto final /resource_instances.

curl -X POST   
  https://resource-controller.cloud.ibm.com/v2/resource_instances   
  -H 'Authorization: Bearer <>'   
  -H 'Content-Type: application/json'     
    -d '{
    "name": "<SERVICE_INSTANCE_NAME>",
    "target": "<region>",
    "resource_group": "<your-resource-group>",
    "resource_plan_id": "<service-id>",
    "parameters":{
      "point_in_time_recovery_time":"<TIMESTAMP>",
      "point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>"
    }
  }'

Los parámetros name, target, resource_group y resource_plan_id son obligatorios. El valor target es la región en la que desea alojar el nuevo despliegue, que puede ser distinta de la región del despliegue de origen. Se admiten restauraciones entre regiones, excepto para una restauración de una copia de seguridad de eu-de a otra región.

Para PITR, utilice los parámetros point_in_time_recovery_time y point_in_time_recovery_deployment_id. point_in_time_recovery_deployment_id es el ID del despliegue de origen y point_in_time_recovery_time es la indicación de fecha y hora en UTC a la que desea restaurar. Si desea restaurar al punto en el tiempo más reciente disponible, utilice "point_in_time_recovery_time":" ".

Si tiene que ajustar recursos o utilizar una clave de Key Protect, añada los parámetros opcionales key_protect_key, members_disk_allocation_mb, members_memory_allocation_mb y/o members_cpu_allocation_count y sus valores en el cuerpo de la solicitud.

Verificación de PITR

Para verificar el tiempo de recuperación correcto, compruebe los registros de la base de datos. La comprobación de los registros de base de datos requiere que se configure la Integración de registro en el despliegue.

Cuando realiza una recuperación, los datos se restauran a partir de la copia de seguridad incremental más reciente. Las transacciones pendientes del registro WAL se utilizan para poner al día la base de datos hasta el momento en el que se ha realizado la recuperación. Una vez que la recuperación haya finalizado y se hayan ejecutado las transacciones, aparecerá un mensaje en los registros. Puedes comprobar si en tus registros aparece el siguiente mensaje.

LOG:  last completed transaction was at log time 2019-09-03 19:40:48.997696+00

Existen dos casos de ejemplo en los que la recuperación no aparece en los registros.

  1. El despliegue tiene una copia de seguridad completa reciente y no hay actividad después de que se haya realizado la copia de seguridad que sea necesario reproducir.
  2. Si ha especificado un momento para la recuperación que sea posterior a la hora actual o al punto de recuperación en un punto en el tiempo más reciente disponible.

En ambos casos, la recuperación sigue realizándose con éxito, pero no habrá una entrada en los registros para comprobar el momento exacto al que se ha restaurado la base de datos.