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

Sélectionnez une version de la documentation :

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

Les étapes décrites sur cette page partent du principe que le cluster de base de données Kubernetes source est créé sur Google Kubernetes Engine et que les disques de sauvegarde sont des disques persistants Compute Engine. Il suppose également que le serveur unique AlloyDB Omni cible est installé sur une machine virtuelle (VM) Compute Engine.

Si vous utilisez d'autres environnements, consultez 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 base de données source.
  2. Montez le disque de sauvegarde du cluster de base 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 sur lequel est stockée la sauvegarde de votre cluster de base de données source.
  • Un cluster de base 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 base de données source. Les PVC sont utilisés dans Kubernetes pour gérer le stockage persistant des applications.

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

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

     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 un 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 PV sous-jacent :

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

    Remplacez les éléments suivants :

    • PVC_NAME : nom du 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 un 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 soit un serveur AlloyDB Omni installé sur une machine virtuelle Compute Engine, montez 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 dans laquelle votre serveur cible est installé dans la machine virtuelle Compute Engine.

    • GCE_ZONE : zone dans laquelle se trouve 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 un montage de liaison personnalisé 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 montages de liaison dans Docker, consultez Montages 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 lors 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 base de données cible

Connectez-vous au serveur cible et exécutez les commandes pgBackRest pour vérifier que les sauvegardes du cluster de base 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 Restore.

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 les données sur le serveur cible

Une fois 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. Nous vous conseillons de renommer 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 seul serveur.

Étapes suivantes