Cloner un cluster de bases de données sur un serveur unique à l'aide d'une sauvegarde locale

Sélectionnez une version de la documentation :

Cette page vous explique comment cloner manuellement un cluster de bases de données sur un serveur unique à l'aide d'une sauvegarde locale.

Les étapes de cette page supposent que le cluster de bases de données Kubernetes source est créé sur Google Kubernetes Engine et que les disques de sauvegarde sont des disques persistants Compute Engine. Elles supposent également que le serveur unique AlloyDB Omni cible est installé sur une machine virtuelle (VM) Compute Engine.

Si vous utilisez d'autres environnements, reportez-vous à la documentation correspondante pour reproduire ces étapes dans votre environnement.

Le workflow suivant explique les étapes de clonage :

  1. Identifiez les informations sur le disque de sauvegarde, telles que le nom du volume persistant et le gestionnaire de disque persistant Compute Engine, pour le disque de sauvegarde du cluster de bases de données source.
  2. Installez le disque de sauvegarde du cluster de bases de données source sur le serveur cible.
  3. Utilisez les commandes pgBackRest pour vérifier que les sauvegardes sources sont accessibles.
  4. Utilisez les commandes pgBackRest pour restaurer la sauvegarde dans le cluster de bases de données cible.

Avant de commencer

  • Assurez-vous d'avoir accès au disque de sauvegarde dans lequel est stockée la sauvegarde de votre cluster de base de données source.
  • Un cluster de bases de données AlloyDB Omni cible à serveur unique est créé. Pour en savoir plus sur l'installation d'AlloyDB Omni sur Kubernetes, consultez Installer AlloyDB Omni.
  • Assurez-vous d'être connecté à la base de données en tant qu'utilisateur postgres.

Obtenir des informations sur le disque de sauvegarde source

Dans le cadre du processus de restauration, déterminez le nom de la demande de volume persistant (PVC) du disque de sauvegarde pour votre cluster de bases de données source. Les PVC sont utilisées dans Kubernetes pour gérer le stockage persistant des applications.

Les exemples de commandes suivants permettent de déterminer le nom du volume persistant sous-jacent et le gestionnaire de disque persistant Compute Engine à l'aide du nom de la PVC du disque de sauvegarde.

  1. Connectez-vous à votre cluster GKE dans lequel vous avez créé le cluster de bases de données AlloyDB Omni source :

     kubectl get pvc -n DB_CLUSTER_NAMESPACE | grep DB_CLUSTER_NAME | grep backupdisk

    Remplacez les éléments suivants :

    • DB_CLUSTER_NAMESPACE: espace de noms Kubernetes pour cette sauvegarde. Il doit correspondre à l'espace de noms du cluster de bases de données.

    • DB_CLUSTER_NAME: nom de ce cluster de bases de données, par exemple my-db-cluster.

    Voici l'exemple de réponse.

      backupdisk-al-fe8c-dbcluster-sample-0   Bound
  pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
  ```

  2. Utilisez le nom du disque de sauvegarde de l'étape précédente, par exemple backupdisk-al-fe8c-dbcluster-sample-0, pour trouver le nom du volume persistant sous-jacent :

      kubectl get pvc/PVC_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath={.spec.volumeName}

    Remplacez les éléments suivants :

    • PVC_NAME : nom de la PVC du disque de sauvegarde à partir de la réponse de l'étape précédente, par exemple backupdisk-al-fe8c-dbcluster-sample-0.

  3. Recherchez le gestionnaire de disque persistant Compute Engine sous-jacent :

      kubectl get pv/$PV_NAME -o json | jq -r .spec.csi.volumeHandle

    Remplacez les éléments suivants :

    • PV_NAME : nom du volume persistant du disque de sauvegarde à partir de la réponse de l'étape précédente.

    Voici l'exemple de réponse :

      projects/my-project/zones/us-central1-a/disks/pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

  4. Exportez le nom du disque de sauvegarde en tant que variable utilisée dans les sections suivantes :

      export BACKUP_DISK=pvc-89f91fba-6cd2-4bfa-84ed-cb5969b446c3

Installer le disque de sauvegarde sur le serveur cible

En supposant que le serveur cible est un serveur AlloyDB Omni installé sur une machine virtuelle Compute Engine, installez le disque de sauvegarde sur le serveur.

  1. Exécutez la commande gcloud compute instances attach-disk pour installer le disque :

      gcloud compute instances attach-disk GCE_INSTANCE_NAME \
  --disk ${BACKUP_DISK} \
  --zone=$GCE_ZONE

    Remplacez les éléments suivants :

    • GCE_INSTANCE_NAME : nom de l'instance sur laquelle votre serveur cible est installé dans la machine virtuelle Compute Engine.

    • GCE_ZONE : zone dans laquelle existe votre instance de machine virtuelle Compute Engine.

  2. Installez le disque de sauvegarde sur le serveur cible :

       lsblk
   mkdir -p /mnt/disks/backupdisk
   mount -o discard,defaults /dev/sdb /mnt/disks/backupdisk

  3. Ajoutez une installation de liaison personnalisée au fichier dataplane.conf AlloyDB Omni dans le répertoire /var/alloydb/config :

      PG_BIND_MOUNTS=/mnt/disks/backupdisk:/mnt/disks/backups:rshared

Pour en savoir plus sur les installations de liaison dans Docker, consultez Installations de liaison.

  1. Redémarrez le serveur cible :

Docker 

  docker restart CONTAINER_NAME

Remplacez CONTAINER_NAME par le nom d'un nouveau conteneur AlloyDB Omni, par exemple my-omni-1.

Podman 

  podman restart CONTAINER_NAME

Remplacez CONTAINER_NAME par le nom d'un nouveau conteneur AlloyDB Omni, par exemple my-omni-1.

Mettre à jour le fichier de configuration pgBackRest

Mettez à jour le fichier pgBackRest existant dans le répertoire du disque de sauvegarde avec le nouveau chemin d'accès au dépôt.

  1. Sur le serveur cible, accédez au répertoire /mnt/disks/backupdisk :

      cd /mnt/disks/backupdisk

  2. Mettez à jour le chemin d'accès pg1-path vers un répertoire temporaire dans le fichier pgbackrest.conf pour éviter d'écraser les données existantes. Le répertoire data-restored est créé automatiquement dans le cadre du processus de restauration :

      sudo sed -i 's|.*pg1-path.*|pg1-path=/mnt/disks/pgsql/data-restored|' pgbackrest.conf

  3. Mettez à jour le chemin d'accès repo1-path vers un répertoire temporaire dans le fichier pgbackrest.conf :

      sudo sed -i 's|.*repo1-path.*|repo1-path=/mnt/disks/backups/repo|' conf.d/repo1-local-backupplan.conf

Vérifier les sauvegardes sources dans le cluster de bases de données cible

Connectez-vous au serveur cible et exécutez les commandes pgBackRest pour vérifier que les sauvegardes du cluster de bases de données source sont accessibles sur le serveur cible :

Docker 

  sudo docker exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

Podman 

  sudo podman exec CONTAINER_NAME pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 info

Voici un exemple de réponse :

    stanza: db
    status: ok
    cipher: none
    db (current)
        wal archive min/max (15): 000000010000000000000002/00000001000000000000000D
        full backup: 20240213-231400F
            timestamp start/stop: 2024-02-13 23:14:00+00 / 2024-02-13 23:17:14+00
            wal start/stop: 000000010000000000000003 / 000000010000000000000003
            database size: 38.7MB, database backup size: 38.7MB
            repo1: backup set size: 4.6MB, backup size: 4.6MB
        incr backup: 20240213-231400F_20240214-000001I
            timestamp start/stop: 2024-02-14 00:00:01+00 / 2024-02-14 00:00:05+00
            wal start/stop: 00000001000000000000000D / 00000001000000000000000D
            database size: 38.7MB, database backup size: 488.3KB
            repo1: backup set size: 4.6MB, backup size: 84.2KB
            backup reference list: 20240213-231400F

Les codes temporels de la réponse sont utilisés pour restaurer la sauvegarde complète ou pour restaurer à partir d'un moment précis de la fenêtre de récupération.

Restaurer la sauvegarde sur le serveur cible

Une fois que vous avez identifié la sauvegarde ou le point dans le temps vers lequel vous souhaitez effectuer la restauration, exécutez les commandes pgBackRest sur votre serveur cible. Pour en savoir plus sur ces commandes, consultez Commande de restauration.

Voici quelques exemples de commandes de restauration pgBackRest :

  • Restaurer à partir d'une sauvegarde

    pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --set=20240213-231400F --type=immediate --target-action=promote --delta --link-all --log-level-console=info

  • Restaurer à un moment précis

    pgbackrest --config-path=/mnt/disks/backups --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info

Copier des données sur le serveur cible

Une fois l'exécution de la commande de restauration terminée, vous pouvez copier les données du répertoire temporaire data-restored vers le répertoire de données AlloyDB actuel.

  1. Sur le serveur cible, arrêtez le service de base de données :

    Docker 

    docker stop CONTAINER_NAME

    Podman 

    podman stop CONTAINER_NAME

  2. Par mesure de sécurité, renommez le répertoire de données actuel :

      mv ~/alloydb-data/data  ~/alloydb-data/data-old

  3. Renommez le répertoire temporaire data-restored en répertoire de données actuel :

      mv ~/alloydb-data/data-restored ~/alloydb-data/data

  4. Mettez à jour la valeur pg1-path dans le fichier postgresql.auto.conf pour charger les données restaurées :

        vim ~/alloydb-data/data/postgresql.auto.conf
    # Verify postgresql.auto.conf.
    # Do not edit this file manually!
    # It will be overwritten by the ALTER SYSTEM command.
    # Recovery settings generated by pgBackRest restore on 2024-03-13 20:47:11
    restore_command = 'pgbackrest --config-path=/mnt/disks/pgsql --pg1-path=/mnt/disks/pgsql/data --repo=1 --stanza=db archive-get %f "%p"'
    recovery_target = 'immediate'
    recovery_target_action = 'promote'
    recovery_target_timeline = 'current'

  5. Sur le serveur cible, démarrez le service de base de données :

    Docker 

    docker start CONTAINER_NAME

    Podman 

    podman start CONTAINER_NAME

Une fois le service de base de données démarré, vous pouvez vous connecter à l'instance principale et exécuter des requêtes pour vérifier que les données ont été restaurées à partir de la sauvegarde. Pour en savoir plus, consultez Se connecter à AlloyDB Omni sur un serveur unique.

Étape suivante