APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Uma cópia redundante não resolve todos os modos de falha. Na modalidade RDS Multi-AZ DB instance com um standby síncrono, esse standby suporta disponibilidade e não serve consultas de leitura. Não generalizes esse comportamento para todas as modalidades de cluster. Um point-in-time restore cria uma nova instância e exige rever ligação, parâmetros, grupos e acesso. No S3, uma regra live cobre o fluxo aplicável após a sua criação; objetos anteriores precisam de uma estratégia de backfill, como Batch Replication. O plano deve explicar o que será recuperado, de que ponto e como o resultado será reconciliado antes de regressar aos consumidores.
Aplicação guiada
No Auto Scaling, confirma quais verificações alimentam a substituição. Um resultado unhealthy no load balancer não ativa automaticamente a integração ELB no grupo. A inicialização também importa: o grace period evita certas substituições prematuras, mas não suspende as verificações do load balancer nem protege uma instância que deixa de estar running. Mede separadamente perda potencial de dados e duração até ao serviço utilizável. Os objetivos pertencem ao serviço definido, não apenas ao estado available de uma base. Num projeto de infraestrutura, inclui teste funcional, encaminhamento dos clientes, dono de aceitação e evidência de reconciliação no plano de ensaio.
Interrupção às02:00, dados até01:52 e serviço às02:38: oito minutos de perda potencial e38 de recuperação. Com RPO10 e RTO30, só o primeiro objetivo foi cumprido.
Armadilhas comuns
Tratar standby como read replica; contar só o restauro técnico; assumir que live replication copia todo o histórico.
Tópicos relacionados: Sinais, alarmes e diagnóstico operacional · Mudanças, drift e automação controlada · Autorização, chaves e consumidores de segredos
A recuperação termina quando o serviço definido está utilizável e os dados estão aceites.
Referência: RDS point-in-time restore · SOA-C02 archived guide v2.3; retired2025-09-29