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

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

Les étapes de cette page supposent 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 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 base 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 permettent de déterminer le nom du PV sous-jacent et le gestionnaire de disques persistants 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 de cette sauvegarde. Il doit correspondre à l'espace de noms du cluster de base 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 de 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 PV 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

Monter 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, 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 où 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 d'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 des 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 à partir d'un moment donné de la fenêtre de récupération.

Restaurer la sauvegarde sur le serveur cible

Une fois que vous avez identifié la sauvegarde ou un point dans le temps auquel vous souhaitez restaurer, exécutez des commandes pgBackRest sur votre serveur cible. Pour en savoir plus sur ces commandes, consultez la section 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 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 dans 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 recommandons 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 sont restaurées à partir de la sauvegarde. Pour en savoir plus, consultez Se connecter à AlloyDB Omni sur un seul serveur.

Étape suivante