APRENDER. PRATICAR. EVOLUIR.Começar pelo requisito de cada leitura
Uma aplicação fictícia confirma subscrições de fundos e produz relatórios. A confirmação exige observar o commit; o relatório aceita até 30 segundos de atraso. Esses acessos não devem receber automaticamente o mesmo encaminhamento. Uma read replica PostgreSQL assíncrona pode escalar relatórios, mas uma leitura imediata pode ainda devolver o valor anterior. Define a semântica transacional da confirmação no primário e uma política para o relatório quando o atraso ultrapassa o limite. Disponibilidade da réplica não demonstra atualização suficiente para cada consumidor.
Identificar a topologia Multi-AZ
O termo Multi-AZ não descreve uma única topologia. Num RDS Multi-AZ DB instance deployment com um standby, esse standby não serve leituras da aplicação. Num Multi-AZ DB cluster existem dois standbys que podem servir leituras. Antes de recomendar um destino de relatórios, identifica o tipo, motor e disponibilidade regional. Acrescentar um alias DNS não altera a função de um standby. Na revisão de arquitetura, desenha quais componentes aceitam escrita, leitura e failover; evita usar apenas uma caixa chamada Multi-AZ.
Interpretar o reader endpoint Aurora
O reader endpoint Aurora distribui ligações, não cada SELECT dentro de uma sessão. Um cliente com uma ligação persistente pode concentrar mil consultas numa réplica enquanto outra está pouco ocupada. Analisa o pool e a duração das sessões antes de declarar falha de balanceamento. A distribuição por ligação também não garante igualdade de CPU, porque as consultas têm custos diferentes. Sem Aurora Replicas, o reader endpoint liga ao primário e pode permitir escrita; o nome do endpoint não substitui permissões SQL e o desenho de acesso.
Usar RDS Proxy para o problema certo
Um pico de funções com ligações curtas pode beneficiar da reutilização de ligações através de RDS Proxy. Isso não transforma o proxy numa cache de resultados nem resolve uma query que percorre milhões de linhas. Com poucas ligações e CPU dominada por uma consulta, examina o plano e os índices. Estado de sessão pode provocar pinning, limitando a reutilização; o comportamento depende do motor e da operação. Mede ligações, sessões presas, latência e carga da base de dados antes de atribuir capacidade adicional ao proxy.
Calcular um limite de concorrência explícito
Num modelo fictício, a base de dados admite 240 sessões, 40 estão reservadas e cada worker ocupa duas sem multiplexing. Sobram 200 sessões, pelo que cabem no máximo 100 workers por esse recurso. Não é uma promessa de throughput: CPU, locks, memória e latência podem impor um limite inferior. Se o estado de sessão impedir reutilização, não assumes que o proxy reduz a conta. Regista as premissas no plano de capacidade e mede a carga representativa antes da aprovação de produção.
Restaurar dados e recuperar o serviço
O point-in-time restore RDS cria uma nova instância; não reescreve automaticamente a instância antiga nem muda as ligações da aplicação. Depois de uma eliminação às 10:05, restaurar às 10:04 pode recuperar os dados perdidos, mas também deixa de fora operações legítimas posteriores. Preserva evidência, limita escritas concorrentes conforme o plano e reconcilia essas operações. Valida dados, permissões e resultados funcionais antes de controlar a mudança de ligações. O estado available é uma condição técnica, não a prova completa da recuperação do negócio.
240 sessões menos 40 de reserva, divididas por duas sessões por worker, dão 100 workers no modelo.
Armadilhas comuns
Confundir standby com réplica de leitura, balanceamento de ligações com queries ou instância restaurada com aplicação recuperada.
Tópicos relacionados: Disponibilidade e recuperação · Desempenho de bases de dados
Escolhe cada mecanismo pelo requisito que resolve e valida a aplicação após a mudança.
Referência: RDS Multi-AZ deployment types · SAA-C03