Cette page explique comment cloner un cluster de base de données dans Kubernetes à l'aide d'une sauvegarde Cloud Storage d'un cluster de base de données AlloyDB Omni.
Le workflow suivant explique les étapes utilisées pour cloner:
- Créez et appliquez le fichier manifeste
DBClustersur le cluster de base de données cible avec le paramètrelivenessProbedésactivé. - Créez et configurez le fichier
pgbackrest.confpour accéder à la sauvegarde Cloud Storage. - Utilisez les commandes
pgBackRestpour vérifier que vous pouvez accéder aux sauvegardes sources. - Utilisez les commandes
pgBackRestpour restaurer la sauvegarde dans le cluster de base 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
BackupPlanpour 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 la section Créer un cluster de base 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 base de données en désactivant temporairement le paramètre livenessProbe pendant le processus de restauration.
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: standardRemplacez 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 utilisateurpostgrespar défaut, encodé en tant que chaîne base64 (par exemple,Q2hhbmdlTWUxMjM=pourChangeMe123).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 avez définicpusur2plus tôt dans ce fichier manifeste, nous vous recommandons de définirmemorysur16Gi.DISK_SIZE: taille de disque par instance de base de données (par exemple,10Gi).
Appliquez le fichier manifeste:
kubectl apply -f DBCLUSTER_FILENAMERemplacez les éléments suivants :
- DBCLUSTER_FILENAME: nom du fichier manifeste
DBClustercréé à l'étape précédente.
- DBCLUSTER_FILENAME: nom du fichier manifeste
Utilisez la commande kubectl describe pour vérifier que la ressource de cluster de base de données est à l'état READY.
Configurer le fichier pgBackRest
Configurez le fichier pgBackRest pour permettre au cluster de base de données cible d'accéder au bucket Cloud Storage où se trouvent les sauvegardes sources.
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=<var>DB_CLUSTER_NAME</var>, 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:
kubectl exec -ti DATABASE_POD_NAME -- /bin/bashRemplacez 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 postgresCréez un fichier de configuration
pgBackRestpour 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=/etc/ssl/certs/ca-certificates.crt repo1-retention-full=9999999 repo1-gcs-key-type=autoRemplacez les éléments suivants :
GCS_SOURCE_BACKUP_BUCKET_NAME: nom du bucket Cloud Storage que vous avez créé lorsque vous avez créé le fichier manifeste de ressourcesBackupPlanpour le cluster de base de données source. Il ne s'agit pas de l'URL complète du bucket. N'ajoutez pasgs://au nom du bucket.GCS_SOURCE_BACKUP_BUCKET_PATH: chemin d'accès du 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-typeest défini surautopour utiliser le compte de service de l'instance. Pour en savoir plus sur les autres options, consultez la section Option de type de clé de dépôt GCS.
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.
pgbackrest --config-path=/backup --stanza=db --repo=1 infoVoici 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=infoRestaurer à 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 postgresUne 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.