Cloner un cluster de base de données dans Kubernetes à l'aide d'une sauvegarde locale

Sélectionnez une version de la documentation :

Ce document explique comment cloner un cluster de bases de données dans Kubernetes à l'aide d'une sauvegarde locale d'un cluster de bases de données AlloyDB Omni.

Ce document repose sur les hypothèses suivantes :

  • Vos clusters de bases de données source et cible sont créés sur Google Kubernetes Engine, et les disques de sauvegarde sont des disques persistants Compute Engine.
  • Les disques persistants Compute Engine utilisés comme disque de sauvegarde dans la base de données ne sont pas utilisés par d'autres clusters de bases de données.

Pour cloner un cluster de bases de données, procédez comme suit :

  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. Assurez-vous d'avoir activé la fonctionnalité de sauvegarde pour le cluster de bases de données source et d'avoir au moins une sauvegarde réussie. Si ces conditions ne sont pas remplies, suivez les instructions de la section Activer et planifier les sauvegardes.
  2. Créez une ressource PersistentVolume pour utiliser un disque de sauvegarde existant sur le cluster de base de données cible afin d'accéder au disque de sauvegarde du cluster de base de données source.
  3. Créez et appliquez le fichier manifeste de ressources DBCluster sur le cluster de bases de données cible avec le paramètre livenessProbe désactivé et les informations sur le disque de sauvegarde ajoutées.
  4. Utilisez les commandes pgBackRest pour vérifier que les sauvegardes sources sont accessibles.
  5. 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.
  • Le disque de sauvegarde du cluster de base de données source doit pouvoir être monté sur le cluster de base de données cible. Pour en savoir plus, consultez Volumes persistants. Si le backend de stockage sous-jacent n'est pas compatible avec l'accès ReadOnlyMany (ROX), assurez-vous que le disque de sauvegarde n'est utilisé par aucun pod du cluster source.
  • Étant donné que le disque de sauvegarde source est monté sur le cluster de base de données cible, le fichier pgBackRest.conf est réutilisé tel quel.
  • 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 à localiser le nom du PV sous-jacent et le gestionnaire de disque persistant Compute Engine. Dans l'exemple, tous les disques de sauvegarde sont des disques persistants Compute Engine, accessibles sur les VM Compute Engine à l'aide de l'identifiant du gestionnaire de disque.

  1. Connectez-vous à votre cluster de bases de données cible pour trouver le nom de la PVC :

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

    Remplacez les éléments suivants :

    • DB_CLUSTER_NAMESPACE : espace de noms Kubernetes pour ce plan de 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.

        backuprepodisk-my-db-cluster-br-0   Bound
    pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h

  2. Utilisez le nom du PVC du disque de sauvegarde de l'étape précédente (par exemple, backuprepodisk-my-db-cluster-br-0) pour trouver le nom du PV sous-jacent et le gestionnaire de disque persistant Compute Engine :

      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 backuprepodisk-my-db-cluster-br-0.

  3. Exportez les configurations en fonction du nom du PV en tant que variables à utiliser dans les sections suivantes :

      export BACKUP_DISK_SIZE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.capacity.storage}")
  export FS_TYPE=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.fsType}")
  export VOLUME_HANDLER=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.csi.volumeHandle}")
  export STORAGE_CLASS=$(kubectl get pv/PV_NAME -o jsonpath="{.spec.storageClassName}")

    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. Par exemple, "backupDiskVolume".

Créer une ressource de volume persistant

À l'aide du nom du gestionnaire de disque, créez une ressource PersistentVolume.

  1. Dans le cluster Kubernetes cible, créez le fichier manifeste PersistentVolume :

        apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: PV_NAME
    spec:
      storageClassName: "${STORAGE_CLASS}"
      capacity:
        storage: "${BACKUP_DISK_SIZE}"
      accessModes:
        - ReadWriteOnce
      csi:
        driver: pd.csi.storage.gke.io
        volumeHandle: "${VOLUME_HANDLER}"
        fsType: "${FS_TYPE}"

    Remplacez les éléments suivants :

    • PV_NAME : nom de la ressource PersistentVolume qui sera créée.

  2. Appliquez le fichier manifeste :

      kubectl apply -f PV_FILENAME

    Remplacez les éléments suivants :

    • PV_FILENAME : nom du fichier manifeste PersistentVolume créé à l'étape précédente.

Créer un cluster de base de données cible

Créez un cluster de bases de données en désactivant temporairement le paramètre livenessProbe. Une fois la restauration terminée, reconfigurez le paramètre livenessProbe.

  1. Créez le fichier manifeste DBCluster :

      apiVersion: v1
  kind: Secret
  metadata:
    name: db-pw-DB_CLUSTER_NAME
  type: Opaque
  data:
    DB_CLUSTER_NAME: "ENCODED_PASSWORD"
  ---
  apiVersion: alloydbomni.dbadmin.goog/v1
  kind: DBCluster
  metadata:
    name: DB_CLUSTER_NAME
  spec:
    databaseVersion: "16.8.0"
    primarySpec:
      availabilityOptions:
        livenessProbe: "Disabled"
      adminUser:
        passwordRef:
          name: db-pw-DB_CLUSTER_NAME
      resources:
        cpu: CPU_COUNT
        memory: MEMORY_SIZE
        disks:
        - name: DataDisk
          size: DATA_DISK_SIZE
        - name: BackupDisk
          size: ${BACKUP_DISK_SIZE}
          storageClass: ${STORAGE_CLASS}
          volumeName: PV_NAME

    Remplacez les éléments suivants :

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

    • ENCODED_PASSWORD : mot de passe de connexion à la base de données pour le rôle utilisateur postgres par défaut, encodé sous forme de chaîne base64 (par exemple, Q2hhbmdlTWUxMjM= pour ChangeMe123).

    • CPU_COUNT : nombre de processeurs disponibles pour chaque instance de base de données de ce cluster de bases de données.

    • MEMORY_SIZE : quantité de mémoire par instance de base de données de ce cluster de bases de données. Nous vous recommandons de définir cette valeur sur 8 gigaoctets par processeur. Par exemple, si vous définissez CPU_COUNT sur 2, nous vous recommandons de définir memory sur 16Gi.

    • DATA_DISK_SIZE : taille du disque par instance de base de données, par exemple 10Gi.

  2. Appliquez le fichier manifeste :

      kubectl apply -f DBCLUSTER_FILENAME

    Remplacez les éléments suivants :

    • DBCLUSTER_FILENAME : nom du fichier manifeste DBCluster créé à l'étape précédente.

Exécutez la commande kubectl describe pour vérifier que la ressource du cluster de bases de données est à l'état READY.

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

Exécutez des commandes pgBackRest pour vérifier que les sauvegardes du cluster de base de données source sont accessibles sur le cluster de base de données cible.

  1. Dans votre cluster de base de données cible, recherchez les détails du pod du cluster de base de données :

      kubectl get pod -l "alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME, alloydbomni.internal.dbadmin.goog/task-type=database"

    La réponse inclut le nom du pod de base de données du cluster.

  2. Connectez-vous au pod de la base de données :

      kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash

    Remplacez les éléments suivants :

    • DATABASE_POD_NAME : nom du pod du cluster de base de données de l'étape précédente.

  3. Arrêtez le pod avant de mettre à jour le fichier de configuration pgBackRest :

      supervisorctl.par stop postgres

  4. Mettez à jour le fichier de configuration pgBackRest :

      cp /backup/pgbackrest.conf /backup/pgbackrest.conf.bak
  rm /backup/pgbackrest.conf
  cat << EOF > /backup/pgbackrest.conf
  [db]
  pg1-path=/mnt/disks/pgsql/data
  pg1-socket-path=/tmp
  pg1-user=pgbackrest
  [global]
  log-path=/backup/logs
  log-level-file=info
  EOF

  5. Vérifiez les sauvegardes sources dans le pod du cluster de bases de données :

    pgbackrest --config-path=/backup --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 dans le cluster de base de données cible

Une fois que vous avez identifié la sauvegarde ou le point dans le temps à partir duquel vous souhaitez effectuer la restauration, exécutez les commandes pgBackRest dans votre cluster de base de données 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=/backup --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=/backup --stanza=db --repo=1 restore --target="2024-01-22 11:27:22" --type=time --target-action=promote --delta --link-all --log-level-console=info

Redémarrer le pod

Une fois la commande de restauration exécutée, vous pouvez démarrer le processus postgres.

supervisorctl.par start postgres

Une fois le processus postgres 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 exécuté sur Kubernetes.

Configurer le cluster de bases de données

Après avoir cloné un cluster de bases de données, configurez ses spécifications. Veillez à activer le paramètre livenessProbe à l'aide de la commande suivante :

    kubectl patch dbcluster DBCLUSTER_FILENAME --type merge -p '{"spec":{"primarySpec":{"availabilityOptions":{"livenessProbe":"Enabled"}}}}'

Étapes suivantes