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

IBM Cloud® Databases for PostgreSQL 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 effectue des sauvegardes incrémentielles continues et peut réexécuter des transactions afin d'amener un nouveau déploiement restauré à partir d'une sauvegarde à n'importe quel point dans cette fenêtre de 7 jours selon vos besoins.

L'onglet Sauvegardes et restaurations de l'interface utilisateur de votre déploiement conserve toutes vos informations PITR sous la rubrique Récupération ponctuelle.

Dans PostgreSQL versions 13 et ultérieures, lors de la restauration à un point spécifique au cours des sept derniers jours, avec une heure de restauration après la dernière transaction, votre restauration échoue avec le message recovery ended before configured recovery target is reached. Avant PostgreSQL v13, lors de la restauration à un point spécifique au cours des sept derniers jours, avec une heure de restauration après la dernière transaction, le point de restauration le plus récent est utilisé. Si votre restauration échoue pour cette raison, Restore to last available point ou choisissez une date / heure antérieure pour Restore to a specific point in the last 7 days.

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 postgresql earliest-pitr-timestamp.

ibmcloud cdb postgresql earliest-pitr-timestamp <INSTANCE_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. Cela concerne particulièrement PITR qui risque de ne pas être de la même taille que la taille actuelle 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 important de ne pas supprimer le déploiement source pendant la restauration de la sauvegarde. Vous devez attendre que le nouveau déploiement soit mis à disposition et que la sauvegarde soit restaurée avant de supprimer l'ancien déploiement. La suppression d'un déploiement supprime également ses sauvegardes, de sorte que non seulement la restauration échoue, mais il se peut que vous ne puissiez pas non plus récupérer la sauvegarde.

Reprise 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 la restauration au point de cohérence disponible le plus récent, sélectionnez cette option. En cliquant sur le bouton Restaurer, la nouvelle interface utilisateur de provisionnement s'affiche dans un onglet avec les options de restauration. Saisissez les détails du service, allouez des ressources et définissez la version de la base de données, le cryptage et le point de terminaison pour votre nouveau déploiement. Cliquez sur Récupération ponctuelle pour lancer le processus.

Si vous utilisez la Key Protect et que vous disposez d'une clé, vous devez utiliser l'interface de communication pour la récupération, et une commande est fournie à cet effet.

Reprise 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. Pour restaurer le dernier point de cohérence disponible, utilisez "point_in_time_recovery_time":" ".

ibmcloud resource service-instance-create <databases-for-postgresql> <INSTANCE_NAME> <REGION> -p '{"point_in_time_recovery_deployment_id":"DEPLOYMENT_ID", "point_in_time_recovery_time":"TIMESTAMP", "version":" "}'

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.

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

ibmcloud resource service-instance-create <databases-for-postgresql> <INSTANCE_NAME> 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", "version":" "}'

Reprise dans l'API

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'API du contrôleur de ressources. Vous devez effectuer les étapes nécessaires à l'utilisation de l'API du contrôleur de ressources avant de pouvoir 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": "<INSTANCE_NAME_OR_CRN>",
    "target": "<REGION>",
    "resource_group": "<RESOURCE_GROUP>",
    "resource_plan_id": "<SERVICE_ID>"
    "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 inter-régions sont prises en charge, à l'exception de la restauration d'une sauvegarde eu-de dans une autre région.

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 du journal WAL sont utilisées pour la restauration de votre base de données jusqu'au moment de la récupération. 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 journaux contiennent le message à l'aide de la commande suivante :

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 :

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.
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.