Récupération ponctuelle (PITR)

IBM Cloud® Databases for MongoDB Enterprise Edition offre un PITR utilisant tout horodatage supérieur au point de récupération disponible le plus ancien. Pour reconnaître le point de récupération le plus ancien via l'API, utilisez le noeud final d'horodatage de récupération au point de cohérence.

Pour les nouveaux modèles d'hébergement, PITR est actuellement disponible via l'interface de ligne de commande, l'API et Terraform.

Lors de la restauration à un point spécifique au cours des 7 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. Si votre restauration échoue pour cette raison, effectuez la restauration au dernier point disponible ou choisissez une date et une heure antérieures pour la restauration à un point spécifique au cours des 7 derniers jours.

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

Dans cette phase, le noeud final d'horodatage de point de reprise renvoie toujours heure actuelle- environ une semaine.

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.

La nouvelle répartition est automatiquement dimensionnée en fonction de la même allocation de disque et de mémoire que la répartition source au moment de la sauvegarde à partir de laquelle vous effectuez la restauration. En particulier avec le PITR, il se peut que la taille actuelle de votre déploiement ne corresponde pas à ce critère. 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. Si le déploiement ne dispose pas de suffisamment de ressources, la restauration échoue. Par conséquent, allouez suffisamment de ressources pour vos données et votre charge de travail.

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 apportées à l'instance avant d'exécuter la restauration (paramètres tels que shared_buffers, max_connections, deadlock_timeout, archive_timeout) afin de garantir des paramètres exacts pour l'instance une fois la restauration terminée.

Ne supprimez pas 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. Par conséquent, non seulement la restauration échoue, mais vous risquez de ne pas être en mesure de récupérer la sauvegarde.

Récupération via l'interface utilisateur

Une fois la première sauvegarde de votre déploiement terminée, l'option de récupération à un point de cohérence s'affiche dans l'interface utilisateur. Pour lancer un PITR, entrez l'heure à laquelle vous souhaitez procéder à la restauration en temps universel coordonné.

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.

Pour rétablir l'heure 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 que vous disposez d'une clé, vous devez utiliser l'interface CLI pour la récupérer, et une commande est fournie à cet effet.

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

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

Les paramètres disponibles sont les suivants :

instance_name (Obligatoire): Le nom lisible par l'homme de la nouvelle instance à déployer, par exemple, new-mongo.
service_id (obligatoire): Dans ce contexte, il s'agit de databases-for-mongodb.
service_plan_name (obligatoire): standard ou enterprise.
region (obligatoire): La IBM Cloud® région où la nouvelle base de données sera déployée, par exemple, eu-gb.
point_in_time_recovery_deployment_id (Obligatoire): L'identifiant du déploiement source (également connu sous le nom de CRN).
point_in_time_recovery_time: Le moment auquel la sauvegarde est restaurée, au format %Y-%m-%dT%H:%M:%SZ, Par exemple,2024-05-10T08:15:00Z. Laissez ce champ vide pour obtenir le dernier point restaurable.
version: La version de la base de données, par exemple "6.0 ". Laissez ce champ vide pour utiliser la dernière version préférée.
key_protect_key: ID (CRN) du Key Protect ressource utilisée. Ce champ est facultatif pour le cryptage BYOK (Bring Your Own Key).
members_host_flavor: taille de l'hôte d'instance que vous souhaitez déployer. Si elle n'est pas fournie, la nouvelle instance sera créée avec la même RAM et le même processeur que l'instance source. Voir ce tableau pour les valeurs disponibles.

Example

ibmcloud resource service-instance-create big-mongo-restore databases-for-mongodb enterprise eu-gb -p '{"point_in_time_recovery_deployment_id":"crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::", "members_host_flavor":"b3c.4x16.encrypted", "point_in_time_recovery_time":"", "version":""}'

Récupération à l'aide de 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 disposez de toutes les informations, la demande de création est un POST vers le /resource_instances endpoint.

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 champs suivants sont tous obligatoires :

name: Le nom lisible par l'homme de la nouvelle instance à déployer, par exemple new-mongo.
resource_group: L'ID du groupe de ressources, par exemple 5c49eabc12fgt65
resource_plan_id: Dans ce contexte, c'est databases-for-mongodb-enterprise
target: Le IBM Cloud région où la nouvelle base de données sera déployée, par exemple eu-gb. Les restaurations interrégionales sont prises en charge, à l'exception de la restauration d'une sauvegarde eu-de dans une autre région.

De plus, un parameters L'objet peut être fourni avec les champs suivants :

point_in_time_recovery_deployment_id : ID du déploiement source (également appelé CRN).
point_in_time_recovery_time: Le moment auquel la sauvegarde est restaurée, au format %Y-%m-%dT%H:%M:%SZ, Par exemple,2024-05-10T08:15:00Z. Laissez ce champ vide pour obtenir le dernier point restaurable.
version: La version de la base de données, par exemple "6.0 ". Laissez ce champ vide pour utiliser la dernière version préférée.
key_protect_key: ID (CRN) du Key Protect ressource utilisée. Ce champ est facultatif pour le cryptage BYOK (Bring Your Own Key).
members_host_flavor: taille de l'hôte d'instance que vous souhaitez déployer. Si elle n'est pas fournie, la nouvelle instance sera créée avec la même RAM et le même processeur que l'instance source. Voir le tableau pour les valeurs disponibles.

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.

Restauration d'une sauvegarde avec Terraform

Avant de procéder à la restauration, assurez-vous que votre point_in_time_recovery_time n'a pas plus d'une semaine. Si l'horodatage est antérieur à 7 jours, jusqu'à la seconde, la validation échoue.

Utilisez la source de données ibm_database_point_in_time_recovery pour restaurer votre instance de base de données avec point_in_time_recovery.

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.

Votre script Terraform ressemble à ceci.

terraform {
  required_providers {
     ibm = {
       version = "1.44.3"
       source  = "IBM-Cloud/ibm"
    }
  }
}

variable "ibmcloud_api_key" {
  description = "<Enter your IBM Cloud API Key>"
}

provider "ibm" {
  region = "us-south"
  ibmcloud_api_key = var.ibmcloud_api_key
}

data "ibm_resource_group" "default_group" {
  is_default = true
}

resource "ibm_database" "mongodb_enterprise" {
  resource_group_id = data.ibm_resource_group.default_group.id
  name              = "testing-mongodb-pitr"
  service           = "databases-for-mongodb"
  plan              = "enterprise"
  location          = "us-south"

  point_in_time_recovery_deployment_id = "<crn>"
  point_in_time_recovery_time = "2022-09-14T14:47:45Z"

}

Ce qui précède restaurera vers une nouvelle base de données avec la même taille d'hôte et la même taille de disque que la source. Si vous souhaitez modifier la taille de l'hôte ou la taille du disque de votre déploiement, reportez-vous au Documentation Terraform pour le bon formatage.

Restauration hors ligne avec récupération au point de départ (PITR)

IBM Cloud® Databases for MongoDB Enterprise Edition requiert deux processus pour lancer une restauration. Tout d'abord, une image instantanée de Ops Manager AppDBest prise. Cette image instantanée sert ensuite de sauvegarde PITR, qui peut être utilisée pour restaurer votre base de données.

Dans certaines reprise après sinistreCapacité d'un service ou d'une charge de travail à se remettre d'incidents rares, majeurs et de défaillances à grande échelle, tels que l'interruption d'un service. Il peut s'agir d'un désastre physique qui affecte une région entière, de la corruption d'une base de données ou de la perte d'un service contribuant à une charge de travail. L'impact dépasse la capacité de la conception de la haute disponibilité à le gérer. Dans certains cas, le processus PITR peut échouer. Dans ces cas Databases for MongoDB Enterprise Edition La restauration hors ligne de récupération ponctuelle (PITR) peut être utilisée pour restaurer le dernier instantané disponible. L'option de restauration hors ligne garantit la disponibilité des données et la résilience du système dans le cas où la méthode d'image instantanée ne fonctionne pas comme prévu.

Restauration ponctuelle (PITR) hors ligne par l'intermédiaire de l'interface utilisateur

Lancez une restauration hors ligne via le tableau de bord IBM Cloud comme vous le feriez pour un PITR standard. Choisissez la troisième option de reprise à un point de cohérence.

Restauration ponctuelle (PITR) hors ligne par l'intermédiaire de la CLI

Lancez une restauration hors ligne via l'interface de ligne de commande IBM Cloud à l'aide d'une commande telle que:

ibmcloud resource service-instance-create big-mongo-restore databases-for-mongodb enterprise eu-gb -p '{"point_in_time_recovery_deployment_id":"crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::", "members_host_flavor":"b3c.4x16.encrypted", "point_in_time_recovery_time":"", "version":"", "offline_restore": true}'

Indiquez les paramètres suivants :

point_in_time_recovery_deployment_id-Il s'agit du CRN source.
point_in_time_recovery_time- Ne rien indiquer, "".
offline_restore- Fixer cette valeur à true.

La sortie de la commande se présente comme suit :

Creating service instance <INSTANCE_NAME> in resource group Default of account <ACCOUNT> as <USER>...
OK
Service instance <INSTANCE_NAME> was created.

Name:                <INSTANCE_NAME>
ID:                  crn:v1:bluemix:public:databases-for-mongodb:eu-gb:a/f19c0f5eff94b69ae419xyz2345ra7a0ed:3c647ad1-b9a8-2233-a47e-668d8b83e79f::
GUID:                3c647ad1-b9a8-2233-a47e-668d8b83e79f
Location:            <LOCATION>
State:               provisioning
Type:                service_instance
Sub Type:            Public
Service Endpoints:   public
Allow Cleanup:       false
Locked:              false
Created at:          2023-08-03T09:36:37Z
Updated at:          2023-08-03T09:36:41Z
Last Operation:
                     Status    create in progress
                     Message   Started create instance operation

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.

Restauration ponctuelle (PITR) hors ligne par l'intermédiaire de 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. 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 disposez de toutes les informations, la demande de création est un POST du /resource_instances qui se présente comme suit:

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-ID>",
    "resource_plan_id": "<SERVICE-ID>",
    "parameters": {
      "point_in_time_recovery_time":"<TIMESTAMP>",
      "point_in_time_recovery_deployment_id":"<DEPLOYMENT_ID>",
      "offline_restore": true
    }
  }'

Indiquez les paramètres suivants :

point_in_time_recovery_deployment_id-Il s'agit du CRN source.
point_in_time_recovery_time- Ne rien indiquer, "".
offline_restore- Fixer cette valeur à true.

L'horodatage de reprise à un point de cohérence doit être formaté comme suit: %Y-%m-%dT%H:%M:%SZ.