Recupera pedidos PostgreSQL desde un snapshot de RDS

Introducción

Un cambio accidental puede dejar una aplicación funcionando con registros de negocio ausentes. Crearás un snapshot manual de RDS, realizarás una eliminación controlada y recuperarás el pedido restaurando una instancia nueva y cambiando el endpoint de la aplicación.

Completa primero los laboratorios anteriores de base de datos y SQL. Este entorno independiente proporciona un primario con tres pedidos y una aplicación conectada. Eliminarás las dos instancias de práctica y el snapshot después de demostrar la recuperación.

Relación con certificaciones

Este laboratorio ofrece práctica introductoria para los siguientes temas de examen.

Cloud Practitioner (CLF-C02) · Tarea 3.4: Comprender bases relacionales administradas y sus opciones de recuperación.
Solutions Architect – Associate (SAA-C03) · Tarea 2.2: Practicar copias de seguridad y recuperación de una base de aplicación.

Captura un snapshot manual de la base

En este paso guardarás los datos actuales antes de modificarlos.

Un snapshot de base de datos es una copia de recuperación de una instancia RDS. Se crea explícitamente y permanece como recurso independiente hasta eliminarlo. Este laboratorio usa uno manual; no configura retención automática ni recuperación a un momento dado.

Carga la configuración de conexión e inspecciona los datos de la aplicación:

cd /home/labex/project
source database.env

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

Debes obtener los pedidos 101, 102 y 103. El 101 pertenece a Maya y su importe es 49.90.

Captura la base de datos:

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}'

Debes obtener un snapshot manual de orders-db con estado available. AWS View debe mostrarlo junto al primario. Espera a que termine antes del siguiente cambio.

Observa una pérdida de datos controlada

En este paso eliminarás exactamente un pedido de ejemplo y observarás el resultado en la aplicación.

La siguiente eliminación es intencionada para este ejercicio. WHERE la limita al pedido 101:

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

Lee las filas restantes:

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

Debes obtener solo los pedidos 102 y 103. Solicita la lista de la aplicación:

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

La aplicación sigue conectando y respondiendo, pero falta el pedido de Maya. Una conexión correcta no demuestra que los datos de negocio estén completos. El snapshot anterior a la eliminación contiene la copia necesaria para recuperarlos.

Restaura una instancia nueva y cambia la aplicación

En este paso recuperarás el snapshot en una instancia nueva y demostrarás que la aplicación lee los datos restaurados.

Restaurar crea un endpoint nuevo; la línea discontinua compara el origen sin revertir

Diagrama conceptual: Restaurar crea un endpoint nuevo; la línea discontinua compara el origen sin revertir.

Restaurar un snapshot crea una instancia RDS nueva. No revierte la existente en el mismo sitio. Usa otro identificador y selecciona explícitamente el grupo de subredes y el grupo de seguridad preparados:

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

Consulta el motor nuevo mediante su entrada de conexión preparada:

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

Debes obtener los tres pedidos originales. Comprueba el origen por separado:

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

Debe seguir conteniendo solo 102 y 103. Ahora tienes dos instancias independientes: el origen modificado y una base recuperada.

Obtén el endpoint recuperado y actualiza ambos campos de host de la aplicación:

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

Prueba la aplicación:

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

Debes obtener otra vez 101, 102 y 103. AWS View debe listar ambas instancias y mostrar los datos recuperados. La recuperación termina cuando la aplicación usa el endpoint restaurado y los registros esperados están disponibles, no solo cuando se crea una instancia.

El snapshot contiene datos capturados antes de la eliminación. Los cambios posteriores a la copia no aparecen automáticamente en la instancia restaurada. El momento de la copia y las decisiones de cambio de aplicación importan al planificar la recuperación. La aplicación lee los pedidos recuperados de la instancia PostgreSQL restaurada de forma independiente.

Elimina ambas instancias y el snapshot manual

En este paso eliminarás todos los recursos de recuperación utilizados.

Elimina la instancia recuperada y la instancia original de práctica:

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

El snapshot manual es independiente de las instancias y también debe eliminarse:

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

Inspecciona ambos inventarios:

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

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

Debes obtener [] en ambos. AWS View no debe mostrar bases ni snapshots manuales. Conserva la aplicación y la red preparadas.

Resumen

Capturaste un snapshot manual, observaste una eliminación controlada y restauraste los datos guardados en una instancia nueva. Cambiar el endpoint recuperó el pedido ausente sin modificar el origen. Después eliminaste ambas instancias y el snapshot independiente.

El siguiente laboratorio separa lecturas y escrituras de la aplicación mediante una réplica de lectura PostgreSQL.

Restaura pedidos desde un snapshot de RDS