APRENDER. PRATICAR. EVOLUIR.Identificar a topologia antes de prometer disponibilidade
Começa por registar motor, versão, região e modo de deployment. Numa instância RDS Multi-AZ com um standby, esse standby serve o failover e não recebe consultas de reporting. Num cluster RDS Multi-AZ, um writer e dois readers ocupam três zonas da mesma região; os readers podem servir consultas. A confirmação semissíncrona não significa que ambos já aplicaram todos os eventos. Por isso, o ensaio tem de incluir lag e carga nos readers. Uma read replica tradicional usa replicação assíncrona e permite aliviar leituras, mas não demonstra leitura imediata após uma escrita. No exemplo fictício, o relatório tolera noventa segundos de atraso; a confirmação de uma ordem não tolera ausência da escrita acabada de aceitar. Trata estas duas operações como requisitos distintos e mede cada uma no percurso de leitura proposto.
Seguir o papel do endpoint e renovar ligações
O endpoint writer de um cluster acompanha o writer atual; o endpoint de instância identifica uma instância concreta. Usar o segundo por conveniência pode deixar a aplicação ligada ao antigo writer após uma mudança de papel. O reader endpoint distribui pedidos de ligação, não cada query de uma sessão persistente. Mede a distribuição real dos pools antes de concluir que dois readers dividem igualmente o trabalho. Em failover de uma instância Multi-AZ, o DNS é atualizado e as ligações existentes precisam de ser restabelecidas. Confirma a cache DNS da JVM e a política de renovação do pool, sem fixar IPs. Num ensaio de WebSphere, compara resolução numa ligação nova com o endereço usado pelas sessões antigas. Um teste de rede numa shell não demonstra o comportamento da JVM que executa a aplicação.
Usar o proxy com uma fronteira de transação explícita
RDS Proxy pode reutilizar ligações ao terminar transações e reduzir trabalho de estabelecimento de sessões. O benefício depende do tráfego efetivamente passar pelo endpoint do proxy. Sessões com estado que impede reutilização podem ficar pinned; examina a métrica de ligações pinned e os motivos antes de aumentar indiscriminadamente pools. Não removas estado necessário à correção funcional apenas para melhorar uma métrica. Durante failover, ligações com transações ou instruções em curso podem ser canceladas. Um proxy não decide se deves repetir uma ordem de negócio cujo resultado é desconhecido. O runbook deve distinguir leitura repetível, transação explicitamente abortada e confirmação perdida após envio de COMMIT. No último caso, consulta uma identidade durável ou reconcilia antes de criar outro efeito. Mantém evidência do erro e dos resultados de aplicação, não só do estado do proxy.
Medir recuperação e reconstruir proteção
Define o início e o fim da medição com o negócio. No exercício, o serviço deixa de responder às 02:10:00, a base aceita novas ligações às 02:11:20 e o fluxo funcional passa às 02:14:50. São oitenta segundos para a base e 290 segundos para o serviço; um objetivo de quatro minutos falhou por cinquenta segundos. Estes valores são inventados para o exercício e não são compromissos AWS. Numa promoção planeada de read replica, suspende escritas de forma controlada e demonstra aplicação das alterações antes da promoção. Depois da promoção, a instância é independente: não assumas que a replicação anterior continua ou que regressar ao endpoint antigo desfaz novas escritas. O plano inclui proteção da nova origem, autoridade de escrita, verificação dos consumidores e aceitação APS. Tempos típicos da documentação ajudam a preparar ensaios, não substituem resultados medidos.
service_stop = 2 * 3600 + 10 * 60
database_ready = 2 * 3600 + 11 * 60 + 20
service_ready = 2 * 3600 + 14 * 60 + 50
database_seconds = database_ready - service_stop # 80
service_seconds = service_ready - service_stop # 290
objective_seconds = 4 * 60
overrun_seconds = service_seconds - objective_seconds # 50No ensaio fictício, Dynatrace mostra erros JDBC após a base mudar de zona. Uma nova ligação resolve o writer correto, mas o pool WebSphere conserva sessões inválidas. A equipa recolhe eventos RDS, resolução da JVM e resultados do fluxo antes de ajustar e repetir o ensaio.
Armadilhas comuns
Confundir os dois modos Multi-AZ; tratar reader endpoint como balanceamento por query; prometer que o proxy repete transações; medir apenas o tempo da base.
Tópicos relacionados: Restauro histórico e prova de recuperação
A recuperação exige topologia adequada, reconexão correta, tratamento de resultados incertos e prova do fluxo funcional.
Referência: RDS Multi-AZ DB instance deployments · SAP-C02