Cette page présente la documentation de la version 15.7.0 d'AlloyDB Omni.
Accédez à Versions de la documentation AlloyDB Omni pour choisir une autre version.

Cette page a été traduite par l'API Cloud Translation.

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

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

Ce document repose sur les hypothèses suivantes:

Vos clusters de base 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 base de données, procédez comme suit:

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 base de données source et d'avoir effectué au moins une sauvegarde. Si ces conditions ne sont pas remplies, suivez les instructions de la section Activer et planifier des sauvegardes.
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.
Créez et appliquez le fichier manifeste de ressources DBCluster sur le cluster de base de données cible avec le paramètre livenessProbe désactivé et les informations sur le disque de sauvegarde ajoutées.
Utilisez les commandes pgBackRest pour vérifier que les sauvegardes sources sont accessibles.
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.
Le disque de sauvegarde du cluster de base de données source doit pouvoir être installé sur le cluster de base de données cible. Pour en savoir plus, consultez la section 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 installé 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 permettent de localiser le nom du PV sous-jacent et le gestionnaire de disques persistants Compute Engine. Dans l'exemple, tous les disques de sauvegarde sont des disques persistants Compute Engine, auxquels vous pouvez accéder sur les VM Compute Engine à l'aide de l'identifiant du gestionnaire de disque.

Connectez-vous à votre cluster de base 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 de ce plan de 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.
```
    backuprepodisk-my-db-cluster-br-0   Bound
    pvc-36d8f05d-ef1a-4750-ac01-9bb330c15b3a   10Gi       RWO            standard-rwo   5d21h
```
Utilisez le nom du PVC de 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).

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

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.

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 base de données en désactivant temporairement le paramètre livenessProbe. Une fois la restauration terminée, reconfigurez le paramètre livenessProbe.

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: "15.7.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é en tant que 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 Go 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 de disque par instance de base de données (par exemple, 10Gi).

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.

Utilisez la commande kubectl describe pour vérifier que la ressource de cluster de base 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.

Dans votre cluster de base de données cible, recherchez les détails du pod de 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.
Connectez-vous au pod de base de données:
```
  kubectl exec -ti DATABASE_POD_NAME  -- /bin/bash
```
Remplacez les éléments suivants :
- DATABASE_POD_NAME : nom du pod de cluster de base de données de l'étape précédente.
Arrêtez le pod avant de mettre à jour le fichier de configuration pgBackRest:
```
  supervisorctl.par stop postgres
```

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

Vérifiez les sauvegardes sources dans le pod du cluster de base 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 à partir d'un moment donné de la fenêtre de récupération.

Restaurer la sauvegarde dans le cluster de base de données cible

Après avoir identifié la sauvegarde ou le point d'inflexion auquel vous souhaitez restaurer, exécutez des commandes pgBackRest dans votre cluster de base de données 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=/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 terminée, vous pouvez démarrer le processus postgres.

supervisorctl.par start postgres

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

Configurer le cluster de base de données

Après avoir cloné un cluster de base de données, configurez les spécifications de votre cluster de base de données. 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"}}}}'

Étape suivante

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