Récupérer des commandes PostgreSQL depuis un instantané RDS

Introduction

Une modification accidentelle peut laisser une application fonctionner avec des enregistrements métier manquants. Vous créerez un instantané manuel RDS, effectuerez une suppression contrôlée et récupérerez la commande en restaurant une nouvelle instance et en changeant l’endpoint de l’application.

Terminez d’abord les laboratoires précédents sur les bases et SQL. Cet environnement indépendant fournit un primaire avec trois commandes et une application connectée. Vous supprimerez les deux instances d’exercice et l’instantané après avoir prouvé la récupération.

Lien avec les certifications

Ce laboratoire propose une pratique introductive des sujets d’examen suivants.

Cloud Practitioner (CLF-C02) · Tâche 3.4 : Comprendre les bases relationnelles gérées et leurs options de récupération.
Solutions Architect – Associate (SAA-C03) · Tâche 2.2 : Pratiquer la sauvegarde et la récupération d’une base applicative.

Capturer un instantané manuel de la base

Dans cette étape, vous sauvegarderez les données actuelles avant de les modifier.

Un instantané de base de données est une copie de récupération d’une instance RDS. Un instantané manuel est créé explicitement et reste une ressource séparée jusqu’à sa suppression. Ce laboratoire en utilise un seul ; il ne configure ni rétention automatique ni restauration à un instant donné.

Chargez les paramètres de connexion et inspectez les données de l’application :

cd /home/labex/project
source database.env

curl \
  --silent \
  --show-error \
  --fail \
  http://127.0.0.1:8080/application/orders | jq

Vous devez obtenir les commandes 101, 102 et 103. La commande 101 appartient à Maya et vaut 49.90.

Capturez la base :

aws rds \
  create-db-snapshot \
  --db-instance-identifier orders-db \
  --db-snapshot-identifier orders-before-delete \
  --query 'DBSnapshot.{Snapshot:DBSnapshotIdentifier,Source:DBInstanceIdentifier,Status:Status}'

aws rds \
  wait db-snapshot-available \
  --db-snapshot-identifier orders-before-delete

aws rds \
  describe-db-snapshots \
  --db-snapshot-identifier orders-before-delete \
  --query 'DBSnapshots[].{Snapshot:DBSnapshotIdentifier,Type:SnapshotType,Source:DBInstanceIdentifier,Status:Status}'

Vous devez obtenir un instantané manuel de orders-db avec le statut available. AWS View doit le montrer à côté du primaire. Attendez sa fin avant la prochaine modification.

Observer une perte de données contrôlée

Dans cette étape, vous supprimerez exactement une commande d’exemple et observerez les données de l’application.

La suppression suivante est intentionnelle pour cet exercice. WHERE la limite à la commande 101 :

psql \
  "service=orders-db" \
  --set=ON_ERROR_STOP=1 \
  --command 'DELETE FROM orders WHERE order_id = 101;'

Lisez les lignes restantes :

psql \
  "service=orders-db" \
  --command 'SELECT order_id, customer, total FROM orders ORDER BY order_id;'

Vous devez obtenir seulement 102 et 103. Demandez la liste de l’application :

curl \
  --silent \
  --show-error \
  --fail \
  http://127.0.0.1:8080/application/orders | jq

L’application se connecte et répond toujours, mais la commande de Maya manque. Une connexion saine ne prouve pas que les données métier sont complètes. L’instantané précédent contient la copie de récupération nécessaire.

Restaurer une nouvelle instance et basculer l’application

Dans cette étape, vous récupérerez l’instantané dans une nouvelle instance et prouverez que l’application lit ses données restaurées.

La restauration crée un nouveau point de terminaison ; le pointillé compare la source non restaurée

Schéma conceptuel: La restauration crée un nouveau point de terminaison ; le pointillé compare la source non restaurée.

La restauration d’un instantané crée une nouvelle instance RDS. Elle ne rembobine pas l’instance existante sur place. Utilisez un identifiant distinct et sélectionnez explicitement les groupes de sous-réseaux et de sécurité préparés :

aws rds \
  restore-db-instance-from-db-snapshot \
  --db-instance-identifier orders-restored \
  --db-snapshot-identifier orders-before-delete \
  --db-instance-class db.t3.micro \
  --db-subnet-group-name orders-subnets \
  --vpc-security-group-ids "$DB_SECURITY_GROUP_ID" \
  --no-publicly-accessible \
  --query 'DBInstance.{Identifier:DBInstanceIdentifier,Status:DBInstanceStatus,Endpoint:Endpoint}'

aws rds \
  wait db-instance-available \
  --db-instance-identifier orders-restored

Interrogez le nouveau moteur avec son entrée de connexion préparée :

psql \
  "service=orders-restored" \
  --command 'SELECT order_id, customer, total FROM orders ORDER BY order_id;'

Vous devez obtenir les trois commandes initiales. Vérifiez la source indépendamment :

psql \
  "service=orders-db" \
  --command 'SELECT order_id, customer, total FROM orders ORDER BY order_id;'

Elle doit toujours contenir seulement 102 et 103. Vous avez maintenant deux instances indépendantes : la source modifiée et la base récupérée.

Obtenez l’endpoint restauré et mettez à jour les deux champs de serveur de l’application :

RESTORED_ENDPOINT=$(aws rds \
  describe-db-instances \
  --db-instance-identifier orders-restored \
  --query 'DBInstances[0].Endpoint.Address' \
  --output text)

jq \
  --arg host "$RESTORED_ENDPOINT" \
  '.read_host = $host | .write_host = $host' \
  app-config.json > app-config.new
mv app-config.new app-config.json

Testez l’application :

curl \
  --silent \
  --show-error \
  --fail \
  http://127.0.0.1:8080/application/orders | jq

Vous devez retrouver 101, 102 et 103. AWS View doit lister les deux instances et afficher les commandes récupérées. La récupération est terminée lorsque l’application utilise l’endpoint restauré et retrouve les enregistrements attendus, pas seulement lorsqu’une instance est créée.

L’instantané contient les données capturées avant la suppression. Les modifications postérieures à la sauvegarde n’apparaissent pas automatiquement dans l’instance restaurée. Le moment de sauvegarde et les décisions de bascule comptent dans la planification de la récupération. L’application lit les commandes récupérées depuis l’instance PostgreSQL restaurée indépendamment.

Supprimer les deux instances et l’instantané manuel

Dans cette étape, vous supprimerez chaque ressource de récupération utilisée.

Supprimez l’instance restaurée et l’instance initiale d’exercice :

aws rds \
  delete-db-instance \
  --db-instance-identifier orders-restored \
  --skip-final-snapshot \
  --query 'DBInstance.DBInstanceIdentifier'

aws rds \
  delete-db-instance \
  --db-instance-identifier orders-db \
  --skip-final-snapshot \
  --query 'DBInstance.DBInstanceIdentifier'

aws rds \
  wait db-instance-deleted \
  --db-instance-identifier orders-restored

aws rds \
  wait db-instance-deleted \
  --db-instance-identifier orders-db

L’instantané manuel est séparé des instances et doit aussi être supprimé :

aws rds \
  delete-db-snapshot \
  --db-snapshot-identifier orders-before-delete \
  --query 'DBSnapshot.DBSnapshotIdentifier'

Inspectez les deux inventaires :

aws rds \
  describe-db-instances \
  --query 'DBInstances[].DBInstanceIdentifier'

aws rds \
  describe-db-snapshots \
  --snapshot-type manual \
  --query 'DBSnapshots[].DBSnapshotIdentifier'

Vous devez obtenir [] pour les deux. AWS View ne doit montrer ni base ni instantané manuel. Conservez l’application et le réseau préparés.

Résumé

Vous avez capturé un instantané manuel, observé une suppression contrôlée et restauré les données dans une nouvelle instance. Changer l’endpoint de l’application a récupéré la commande manquante sans changer la source. Vous avez ensuite supprimé les deux instances et l’instantané séparé.

Le prochain laboratoire sépare lectures et écritures de l’application grâce à un réplica de lecture PostgreSQL.

Restaurer des commandes depuis un instantané RDS