Récupération à un point de cohérence

IBM Cloud® Databases for MySQL offre la récupération à un point de cohérence (PITR) pour n'importe quel moment au cours des 7 derniers jours. Le déploiement fait l'objet d'une sauvegarde incrémentielle en continu et permet de rejouer les transactions afin de rétablir un nouveau déploiement à partir d'une sauvegarde, à n'importe quel moment au cours de cette période de 7 jours, selon vos besoins.

L'onglet « Sauvegardes » de l'interface utilisateur de votre déploiement regroupe toutes vos informations PITR sous « Restauration à un instant donné ».

Les informations incluses correspondent au moment le plus ancien pour une récupération à un point de cohérence. Pour découvrir le point de récupération le plus ancien via l'interface de ligne de commande, utilisez la commande cdb mysql earliest-pitr-timestamp.

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

Pour découvrir le point de récupération le plus ancien via l'API, utilisez le noeud final /deployments/{id}/point_in_time_recovery_data afin de trouver le moment de récupération à un point de cohérence le plus ancien.

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

Récupération

Les sauvegardes sont restaurées dans un nouveau déploiement. Une fois que le nouveau déploiement a terminé la mise à disposition, vos données du fichier de sauvegarde sont restaurées dans le nouveau déploiement. Les sauvegardes sont également restaurables sur les comptes, mais uniquement à l'aide de l'API et uniquement si l'utilisateur qui exécute la restauration a accès aux comptes source et de destination.

Par défaut, le nouveau déploiement est automatiquement dimensionné avec la même allocation de disque et de mémoire que le déploiement source au moment de la sauvegarde à partir de laquelle vous effectuez la restauration. En particulier dans le cas d'une récupération à un point de cohérence, il peut ne pas s'agir de la taille en cours de votre déploiement. Si vous devez ajuster les ressources allouées au nouveau déploiement, utilisez les zones facultatives de l'interface utilisateur, de l'interface de ligne de commande ou de l'API pour redimensionner le nouveau déploiement. Veillez à procéder à une allocation suffisante en fonction de vos données et de votre charge de travail. Si le déploiement ne dispose pas des ressources suffisantes, la restauration échoue.

Alors que le stockage et la mémoire sont restaurés au même niveau que le déploiement source, les configurations d'instance spécifiques ne sont pas automatiquement définies pour la nouvelle instance. Dans ce cas, il peut être nécessaire de réexécuter la configuration après une restauration. Notez toutes les modifications d'instance avant d'exécuter la restauration (paramètres tels que shared_buffers, max_connections, deadlock_timeout, archive_timeout, etc.) pour avoir l'assurance que l'instance sera définie de manière exacte une fois la restauration terminée.

Il est essentiel de ne pas supprimer le déploiement source pendant la restauration de la sauvegarde. Attendez que le nouveau déploiement soit mis en place et que la sauvegarde soit restaurée avant de supprimer l'ancien déploiement. La suppression d'un déploiement entraîne également la suppression de ses sauvegardes; par conséquent, non seulement la restauration échouera, mais vous risquez également de ne plus pouvoir récupérer la sauvegarde.

Dans l'interface utilisateur

Pour lancer un PITR, entrez l'heure à laquelle vous souhaitez procéder à la restauration en temps universel coordonné. Si vous souhaitez effectuer une restauration uniquement à la date la plus récente disponible, sélectionnez cette option. Lorsque vous cliquez sur Restaurer, les options de récupération s'affichent. Entrez un nom, sélectionnez la version, la région et les ressources allouées pour le nouveau déploiement. Cliquez sur Récupérer pour lancer le processus.

Si vous utilisez Key Protect et disposez d'une clé, utilisez l'interface de ligne de commande pour la reprise. Une commande est fournie pour vous faciliter la tâche.

Dans l'interface de ligne de commande

Le contrôleur de ressources prend en charge la mise à disposition des déploiements de base de données, et la mise à disposition et la restauration sont la responsabilité de l'interface de ligne de commande du contrôleur de ressources. Utilisez la commande resource service-instance-create.

Pour la récupération à un point de cohérence, utilisez les paramètres point_in_time_recovery_time et point_in_time_recovery_deployment_id. point_in_time_recovery_deployment_id est l'ID du déploiement source et point_in_time_recovery_time est l'horodatage en temps universel coordonné à restaurer. Si vous souhaitez effectuer la restauration au point de cohérence disponible le plus récent, utilisez "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"}'

Une commande préformatée pour une sauvegarde ou une récupération à un point de cohérence spécifique est disponible dans la vue détaillée de la sauvegarde.

Des paramètres facultatifs sont disponibles lors de la restauration via l'interface de ligne de commande. Utilisez-les si vous devez personnaliser les ressources ou utilisez une clé Key Protect pour le chiffrement BYOK sur le nouveau déploiement.

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

Dans l'API

Le contrôleur de ressources prend en charge la mise en place des déploiements de bases de données; la mise en place et la restauration relèvent de la responsabilité de l'API du contrôleur de ressources. Effectuez les étapes nécessaires pour utiliser l'API du contrôleur de ressources avant de l'utiliser pour effectuer une restauration à partir d'une sauvegarde.

Une fois que vous possédez toutes les informations, la demande POST est envoyée au noeud 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>"
    }
  }'

Les paramètres name, target, resource_group et resource_plan_id sont tous obligatoires. target est la région où vous souhaitez situer le nouveau déploiement, qui peut être une région différente du déploiement source. Les restaurations interrégionales ne sont pas prises en charge, sauf dans le cas de la restauration d'une sauvegarde eu-de vers une autre région.

Pour la récupération à un point de cohérence, utilisez les paramètres point_in_time_recovery_time et point_in_time_recovery_deployment_id. Le paramètre point_in_time_recovery_deployment_id est l'ID du déploiement source et le paramètre point_in_time_recovery_time est l'horodatage au format UTC vers lequel vous souhaitez effectuer la restauration. Si vous souhaitez effectuer la restauration au point de cohérence disponible le plus récent, utilisez "point_in_time_recovery_time":" ".

Si vous devez ajuster des ressources ou utiliser une clé Key Protect, ajoutez les paramètres facultatifs key_protect_key, members_disk_allocation_mb, members_memory_allocation_mb et/ou members_cpu_allocation_count, ainsi que leurs valeurs au corps de la demande.

Vérification de la récupération à un point de cohérence

Pour vérifier l'heure de récupération correcte, consultez les journaux de la base de données. L'examen des journaux de base de données nécessite que l'intégration de la consignation soit configurée sur votre déploiement.

Lorsque vous effectuez une récupération, vos données sont restaurées à partir de la sauvegarde incrémentielle la plus récente. Toutes les transactions en attente issues du journal WAL sont utilisées pour mettre votre base de données à jour jusqu'au moment où vous avez effectué la restauration. Une fois récupération terminée et les transactions exécutées, un message est consigné dans les journaux. Vous pouvez vérifier que vos fichiers journaux contiennent le message suivant.

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

Il existe deux scénarios dans lesquels la récupération n'apparaît pas dans les journaux :

  1. Il existe une sauvegarde intégrale récente de votre déploiement et aucune activité après la sauvegarde ne doit être réexécutée.
  2. Vous avez entré une heure de récupération postérieure à l'heure en cours ou antérieure à la dernière récupération à un point de cohérence disponible.

Dans les deux cas, la récupération aboutit toujours généralement, mais aucune entrée n'est générée dans les journaux et vous ne pouvez pas vérifier le moment exact auquel la base de données a été restaurée.