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

Sélectionnez une version de la documentation :

Cette page vous explique comment cloner un cluster de bases de données dans Kubernetes à l'aide d'une sauvegarde Cloud Storage d'un cluster de bases de données AlloyDB Omni.

Le workflow suivant explique les étapes à suivre pour cloner :

  1. Créez et appliquez le fichier manifeste DBCluster sur le cluster de base de données cible avec le paramètre livenessProbe désactivé.
  2. Créez et configurez le fichier pgbackrest.conf pour accéder à la sauvegarde Cloud Storage.
  3. Utilisez les commandes pgBackRest pour vérifier que vous pouvez accéder aux sauvegardes sources.
  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 chemin d'accès complet du bucket Cloud Storage dans lequel est stockée la sauvegarde de votre cluster de base de données source. Il s'agit du même chemin d'accès que celui que vous avez utilisé lorsque vous avez créé la ressource BackupPlan pour votre cluster de base de données source.
  • Créez un cluster de base de données AlloyDB Omni cible. Pour en savoir plus sur l'installation d'AlloyDB Omni sur Kubernetes, consultez Créer un cluster de bases de données.
  • Assurez-vous d'être connecté à la base de données en tant qu'utilisateur postgres.

Créer un cluster de base de données dans 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 pendant la restauration.

  1. Créez le fichier manifeste de ressources 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:
  primarySpec:
    availabilityOptions:
      livenessProbe: "Disabled"
    adminUser:
      passwordRef:
        name: db-pw-DB_CLUSTER_NAME
    resources:
      cpu: CPU_COUNT
      memory: MEMORY_SIZE
      disks:
      - name: DataDisk
        size: DISK_SIZE
        storageClass: standard

    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 avez défini cpu sur 2 plus haut dans ce fichier manifeste, nous vous recommandons de définir memory sur 16Gi.

    • 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 de cluster de bases de données est à l'état READY.

Configurer le fichier pgBackRest

Configurez le fichier pgBackRest pour permettre au cluster de bases de données cibles d'accéder au bucket Cloud Storage où résident les sauvegardes sources.

  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 :

      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. Créez un fichier de configuration pgBackRest pour accéder aux sauvegardes stockées dans Cloud Storage :

      cat << EOF > /backup/pgbackrest.conf
  [db]
  pg1-path=/mnt/disks/pgsql/data
  pg1-socket-path=/tmp
  pg1-user=pgbackrest
  [global]
  log-path=/obs/pgbackrest
  log-level-file=info
  repo1-type=gcs
  repo1-gcs-bucket=GCS_SOURCE_BACKUP_BUCKET_NAME
  repo1-path=GCS_SOURCE_BACKUP_BUCKET_PATH
  repo1-storage-ca-file=/scripts/ca-certificates.crt
  repo1-retention-full=9999999
  repo1-gcs-key-type=auto

    Remplacez les éléments suivants :

    • GCS_SOURCE_BACKUP_BUCKET_NAME : nom du bucket Cloud Storage que vous avez créé lors de la création du fichier manifeste de ressources BackupPlan pour le cluster de base de données source. Il ne s'agit pas de l'URL complète du bucket. Ne faites pas précéder le nom du bucket de gs://.
    • GCS_SOURCE_BACKUP_BUCKET_PATH : chemin d'accès au répertoire dans lequel l'opérateur AlloyDB Omni écrit les sauvegardes, dans le bucket Cloud Storage du cluster de base de données source. Le chemin d'accès doit être absolu et commencer par /.

    repo1-gcs-key-type est défini sur auto pour utiliser le compte de service de l'instance. Pour en savoir plus sur les autres options, consultez Option de type de clé de dépôt Cloud Storage.

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

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

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 bases 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.

Étapes suivantes