Recupere pedidos PostgreSQL de um snapshot do RDS

Introdução

Uma alteração acidental pode deixar uma aplicação funcionando sem registros de negócio. Você criará um snapshot manual do RDS, fará uma exclusão controlada e recuperará o pedido restaurando uma nova instância e alterando o endpoint da aplicação.

Conclua primeiro os laboratórios anteriores de banco e SQL. Este ambiente independente fornece um primário com três pedidos de exemplo e uma aplicação conectada. Você removerá as duas instâncias de exercício e o snapshot após comprovar a recuperação.

Relação com certificações

Este laboratório oferece prática introdutória para os seguintes tópicos de exames.

Cloud Practitioner (CLF-C02) · Tarefa 3.4: Entender bancos relacionais gerenciados e opções de recuperação.
Solutions Architect – Associate (SAA-C03) · Tarefa 2.2: Praticar backup e recuperação de um banco de aplicação.

Capture um snapshot manual do banco

Nesta etapa, você salvará os dados atuais antes de alterá-los.

Um snapshot de banco é uma cópia de recuperação de uma instância RDS. Um snapshot manual é criado explicitamente e permanece como recurso separado até sua exclusão. Este laboratório usa um manual; não configura retenção automática nem recuperação para um ponto no tempo.

Carregue as configurações de conexão e inspecione os dados da aplicação:

cd /home/labex/project
source database.env

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

Espere encontrar os pedidos 101, 102 e 103. O 101 pertence a Maya e tem total 49.90.

Capture o banco:

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

Espere encontrar um snapshot manual de orders-db com status available. O AWS View deve mostrá-lo junto ao primário. Aguarde sua conclusão antes da próxima alteração.

Observe uma perda de dados controlada

Nesta etapa, você removerá exatamente um pedido de exemplo e observará os dados resultantes na aplicação.

A exclusão a seguir é intencional neste exercício. WHERE limita seu alcance ao pedido 101:

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

Leia as linhas restantes:

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

Espere encontrar apenas 102 e 103. Solicite a lista da aplicação:

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

A aplicação ainda conecta e responde, mas o pedido de Maya desapareceu. Uma conexão saudável não comprova que os dados de negócio estejam completos. O snapshot anterior à exclusão contém a cópia necessária para recuperação.

Restaure uma nova instância e altere a aplicação

Nesta etapa, você recuperará o snapshot em uma nova instância e comprovará que a aplicação lê os dados restaurados.

A restauração cria um novo endpoint; a linha tracejada compara a origem sem reversão

Diagrama conceitual: A restauração cria um novo endpoint; a linha tracejada compara a origem sem reversão.

Restaurar um snapshot cria uma nova instância RDS. Não reverte a instância existente no mesmo lugar. Use outro identificador e selecione explicitamente os grupos de sub-redes e segurança 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

Consulte o novo mecanismo usando a entrada de conexão preparada:

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

Espere encontrar os três pedidos originais. Verifique a origem de forma independente:

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

Ela deve continuar contendo apenas 102 e 103. Agora há duas instâncias independentes: a origem alterada e um banco recuperado.

Obtenha o endpoint recuperado e atualize os dois campos de host da aplicação:

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

Teste a aplicação:

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

Espere encontrar novamente 101, 102 e 103. O AWS View deve listar ambas as instâncias e mostrar os pedidos recuperados. A recuperação termina quando a aplicação usa o endpoint restaurado e os registros esperados estão disponíveis, não apenas quando uma instância é criada.

O snapshot contém dados capturados antes da exclusão. Alterações após o backup não aparecem automaticamente na instância restaurada. O momento do backup e as decisões de troca da aplicação importam no planejamento de recuperação. A aplicação lê os pedidos recuperados da instância PostgreSQL restaurada de forma independente.

Remova ambas as instâncias e o snapshot manual

Nesta etapa, você removerá todos os recursos de recuperação usados.

Exclua a instância recuperada e a instância original de exercício:

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

O snapshot manual é separado das instâncias e também deve ser excluído:

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

Inspecione ambos os inventários:

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

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

Espere encontrar [] em ambos. O AWS View não deve mostrar bancos nem snapshots manuais. Preserve a aplicação e a rede preparadas.

Resumo

Você capturou um snapshot manual, observou uma exclusão controlada e restaurou os dados em uma nova instância. Alterar o endpoint da aplicação recuperou o pedido ausente sem mudar a origem. Depois, excluiu ambas as instâncias e o snapshot separado.

O próximo laboratório separa leituras e gravações da aplicação usando uma réplica de leitura PostgreSQL.

Restaure pedidos de um snapshot do RDS