Estado agora
HADR_SYNC_COMMIT)Nos nós, Em disco (hardened) corresponde a last_hardened_lsn e Redo aplicado a last_redone_lsn em sys.dm_hadr_database_replica_states. Simplificação: cada transação avança o LSN em 1, e os tempos da animação estão fora de escala (na vida real o round-trip entre AZs custa poucos milissegundos).
Linha do tempo
Standby Multi-AZ (commit síncrono)
O primary grava o log localmente e envia o bloco de log ao standby em outra AZ. A sessão fica em HADR_SYNC_COMMIT até o standby gravar o log em disco (hardened) e devolver o ACK. Só então o COMMIT retorna à aplicação.
Resultado: toda transação confirmada já existe em duas AZs. No failover, o RDS promove o standby e move o DNS do endpoint, com RPO zero para o que foi confirmado.
Custo: cada commit paga a latência de rede até a outra AZ. No RDS, o standby não aceita conexões; ele existe para o failover.
Read replica (commit assíncrono)
O primary confirma o COMMIT sem esperar a read replica. O log é enviado depois e reaplicado (redo) lá, então as leituras enxergam os dados com algum atraso, medido no CloudWatch pela métrica ReplicaLag.
Ela é ótima para tirar relatórios e BI do primary, mas não protege contra perda: se fosse promovida no momento de uma falha, as transações ainda não recebidas ficariam para trás mesmo já confirmadas ao cliente.
Apps de leitura: e se a read replica cair?
O RDS não redireciona o endpoint da read replica para o primary. Diferente do failover do Multi-AZ, aqui não existe chaveamento automático do lado do banco: o endpoint da réplica simplesmente para de responder até ela voltar. Quem decide para onde ir é a aplicação.
App com fallback automático para o primary (tem as duas connection strings e tenta o endpoint de escrita quando a réplica falha):
⚠️ Alinhe com o time de DBA para que o login da aplicação fique sempre ativo também no primary. Se ele estiver desabilitado, o fallback falha na hora com Login failed … The account is disabled (erro 18470), justamente quando a réplica já está fora.
Lembre que, durante o fallback, as consultas passam a disputar CPU, memória e I/O com o OLTP. Relatórios pesados devem ser evitados ou adiados nesse período.
App sem chaveamento automático (só conhece o endpoint da réplica):
Fica sem consultas até a réplica voltar. Se não der para esperar, o caminho é: abrir solicitação ao time de DBA para habilitar o login no primary, trocar a connection string para o endpoint de escrita e, depois que a réplica voltar, reverter as duas coisas.
Para o time de DBA: enquanto a réplica está desconectada, o primary pode reter o log que ela ainda não recebeu (log_reuse_wait_desc = AVAILABILITY_REPLICA), o que faz o log crescer. Na simulação, isso aparece como "log retido no primary".
Detalhes que costumam gerar dúvida
Síncrono garante log gravado em disco (hardened), não redo aplicado. O ACK sai quando o log está gravado em disco no standby; o redo roda depois. Em um secundário legível on-premises isso aparece como leitura levemente atrasada mesmo em modo síncrono.
Se o standby cair, o primary não trava. O AG marca a réplica como desconectada e os commits voltam a ser confirmados sem esperar, abrindo uma janela sem proteção até a ressincronização. A simulação mostra isso logo após o failover, enquanto o antigo primary ainda não voltou.
O nome do endpoint não muda no failover. A aplicação sempre conecta em meu-db.xxxxx.us-east-1.rds.amazonaws.com; o RDS só atualiza para onde esse nome resolve. Os nomes rds-sql-a e rds-sql-b do diagrama representam os hosts internos, que no RDS você nem enxerga. Vale garantir que a aplicação não guarde o DNS em cache por muito tempo (ex.: cache de DNS da JVM), senão ela continua tentando o IP antigo depois do failover.
A aplicação precisa tratar o erro de conexão. Commits em voo no momento da falha não são confirmados ao cliente; o correto é reconectar pelo mesmo endpoint e repetir a transação.