Amazon SOA-C02: Bancos de Dados e Cache — Guia de estudos

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Faz parte do AWS SysOps Administrator Associate SOA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Bancos de dados e cache são responsabilidades operacionais centrais para um administrador SysOps: eles fornecem armazenamento persistente, disponibilidade e leituras de baixa latência para as aplicações. Este domínio abrange a execução de bancos de dados relacionais gerenciados (RDS e Aurora), o escalonamento da capacidade de leitura/escrita, o comportamento de replicação e failover, e o uso do ElastiCache para reduzir a carga no banco de dados. A configuração adequada de backups, parameter groups, monitoramento e padrões de invalidação de cache previne a perda de dados e reduz incidentes operacionais.

Operações de RDS e Aurora, backups e Multi-AZ

O RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) e o Amazon Aurora (compatível com MySQL e PostgreSQL) são mecanismos relacionais gerenciados com semânticas operacionais diferentes. O Multi-AZ para RDS cria uma instância de standby síncrona em outra AZ — gerenciada pela AWS, com failover automatizado em minutos, sem promoção manual, e a instância de standby não é acessível para leituras. O Aurora separa os endpoints de escrita e de leitura: o de escrita é um endpoint de cluster apoiado por uma instância primária, e o Aurora usa armazenamento distribuído que se replica automaticamente entre AZs e normalmente consegue fazer o failover mais rápido que o RDS porque o armazenamento é compartilhado.

Configure backups e retenção usando:

Backups automatizados: habilite com um período de retenção (ex:

undefined

). Eles fornecem recuperação para um ponto no tempo (PITR) para qualquer segundo dentro da janela de retenção para os mecanismos suportados.

Snapshots manuais:

undefined

(ou

undefined

para o Aurora) para capturar um snapshot retido; os snapshots persistem até que você os exclua.

Restauração PITR:

undefined

para RDS, ou

undefined

e depois crie instâncias para o Aurora.

Critérios de decisão:

Use Multi-AZ para alta disponibilidade e failover automatizado quando a disponibilidade de escrita é crítica e leituras na instância de standby não são necessárias.
Use o Aurora (armazenamento em cluster) quando precisar de IOPS elevado, failover rápido e auto-scaling de armazenamento.
Use réplicas de leitura para escalar leituras e para recuperação de desastres entre regiões (elas são assíncronas e podem ser promovidas).

Exemplos de CLI operacional:

Habilitar Multi-AZ:

undefined

Criar snapshot automatizado:

undefined

Restaurar PITR:

undefined

Réplicas de leitura, failover e estratégias de replicação

Réplicas de leitura são cópias assíncronas (instâncias do RDS ou leitores do Aurora) usadas principalmente para escalar o tráfego de leitura e descarregar relatórios. Elas incorrem em atraso de replicação (monitore a métrica ReplicaLag) e não são adequadas para consistência forte. As réplicas de leitura podem ser promovidas a instâncias de banco de dados independentes para suportar a recuperação de desastres.

Estratégias e escolhas de replicação:

Síncrona (standby Multi-AZ do RDS) — garantia de zero desvio de dados, sem capacidade de leitura na instância de standby.
Réplicas de leitura assíncronas — escalam leituras, permitem cópias entre regiões, risco de lag de replicação e potencial perda de dados no failover.
Leitores do Aurora — fornecem endpoints de leitura em cluster, failover de baixa latência através do redirecionamento de endpoints e balanceamento automático do endpoint de leitura.

Padrões operacionais:

Criar réplica de leitura:

undefined

Promover réplica:

undefined

Monitorar: DatabaseConnections do CloudWatch, ReplicaLag, ReadIOPS, WriteIOPS e Performance Insights para decidir quando adicionar ou remover réplicas.

Critérios de decisão:

Se você precisa de HA para escritas, escolha Multi-AZ. Se precisa de throughput de leitura e descarregamento de análises, escolha réplicas de leitura ou leitores do Aurora.
Para DR entre regiões, crie réplicas de leitura na região de destino e considere a cópia automatizada de snapshots ou o DMS para migração.

Caching com ElastiCache e invalidação de cache

O ElastiCache oferece Redis e Memcached para reduzir a carga e a latência do banco de dados. Escolha Redis quando precisar de persistência, replicação, estruturas de dados e alta disponibilidade com Multi-AZ e failover automático. Escolha Memcached para caching horizontal simples, onde o sharding e o desempenho multithreaded são prioridades.

Configurações e padrões chave:

Criar cluster Redis com réplicas e Multi-AZ:

undefined

Use o modo cluster habilitado para Redis para escalar shards; o Memcached requer hashing do lado do cliente para sharding.
Políticas de evicção: volatile-lru, allkeys-lru, noeviction — ajuste com base na sua preferência por remover apenas chaves expiradas ou quaisquer chaves quando a memória estiver cheia.
Monitore CacheHits e CacheMisses para calcular a taxa de acerto do cache: taxa_de_acerto = CacheHits / (CacheHits + CacheMisses). Busque uma alta taxa de acerto para reduzir as leituras no banco de dados.

Estratégias de invalidação de cache:

Cache-aside: a aplicação verifica o cache primeiro; em caso de falha (miss), lê o banco de dados e preenche o cache; expire ou exclua explicitamente o cache nas operações de escrita.
Write-through/write-behind: as escritas no cache se propagam para o banco de dados; o write-behind agrupa as escritas no banco de dados em lotes (adiciona complexidade).
Time-to-live (TTL): defina TTLs conservadores para dados que podem ficar obsoletos; combine com versionamento de cache ou chaves de invalidação para alterações de esquema ou invalidação em massa.
Use o pub/sub do Redis ou eventos do Lambda para notificar as instâncias da aplicação para invalidação distribuída quando necessário.

Grupos de parâmetros de banco de dados, escalonamento e monitoramento

Os grupos de parâmetros (parameter groups) controlam configurações específicas do motor (engine) (ex: max_connections, innodb_buffer_pool_size). O RDS usa DB parameter groups para instâncias e DB cluster parameter groups para o Aurora. Alterações em alguns parâmetros exigem reinicialização (aplicar com reinicialização pendente, pending-reboot), enquanto outras são aplicadas imediatamente.

Padrões de gerenciamento:

Criar e modificar um parameter group:

undefined

; em seguida,

undefined

Escalonar a classe da instância:

undefined

(ou durante a janela de manutenção para evitar uma reinicialização).

Autoescalonamento de armazenamento: habilite para os tipos de motor (engine) suportados; o Aurora escalona o armazenamento automaticamente.

Sinais de monitoramento e escalonamento:

Use o CloudWatch (FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) e o Performance Insights para identificar SQLs lentos e as principais esperas (top waits).
Habilite o Enhanced Monitoring e defina a granularidade (ex: 1s para troubleshooting).
Use o RDS Proxy para gerenciar o pool de conexões e reduzir tempestades de conexões (connection storms) para aplicações serverless ou com alta concorrência.

Procedimentos de backup/restauração e considerações de migração

Backups e restaurações devem ser explícitos e testados. Backups automatizados fornecem recuperação para um ponto no tempo (PITR) dentro do período de retenção; snapshots manuais são mantidos até serem excluídos e podem ser copiados entre regiões e para diferentes chaves KMS. Seja explícito sobre a região e o timestamp ao restaurar.

Comandos comuns de restauração:

Restaurar para um ponto no tempo (RDS):

undefined

/ ou especifique

undefined

Restaurar snapshot (entre regiões): primeiro, copie o snapshot com

undefined

para a região de destino e, em seguida, restaure.

Considerações de migração:

AWS DMS para migrações com tempo de inatividade mínimo (heterogêneas/homogêneas). O DMS suporta replicação contínua; garanta as configurações corretas do motor de origem (binlog habilitado para MySQL).
Migração lógica (mysqldump, pg_dump) para exportações simples; restauração de snapshot físico para grandes conjuntos de dados.
Valide os conjuntos de caracteres (character sets), diferenças de parameter groups e chaves KMS para snapshots criptografados.

Armadilhas Comuns e Critérios de Decisão

Restaurar backups na região ou no tempo errado: sempre verifique

undefined

antes de restaurar; use o snapshot copiado para a região de destino e teste as restaurações em um ambiente de homologação (staging).

Assumir que réplicas de leitura (read replicas) fornecem alta disponibilidade: lembre-se de que as réplicas são assíncronas; use Multi-AZ ou Aurora para HA de escrita e replicação síncrona.
Ignorar a invalidação de cache: projete TTLs, chaves versionadas ou invalidação orientada a eventos; evite depender apenas de TTLs curtos para garantir a correção dos dados.
Não habilitar backups automatizados ou retenção corretamente: defina

undefined

0 e valide o PITR com restaurações de teste; garanta que as chaves KMS estejam disponíveis na região de destino para a cópia do snapshot.

Modificar parameter groups sem reiniciar: verifique o

undefined

; agende reinicializações nas janelas de manutenção para parâmetros que exigem reinicialização para evitar tempo de inatividade inesperado.

Escalonar sem gerenciamento de conexões: aumentar a classe da instância sem usar o RDS Proxy ou pool de conexões pode não resolver tempestades de conexões; implemente o pooling para gerenciar muitas conexões de curta duração.

Problema Prático: Cenário de Caso de Uso

A Acme Retail executa uma instância primária de MySQL no RDS com tráfego de leitura intenso e picos ocasionais de analytics; eles enfrentam atraso na replicação (replica lag) durante o ETL noturno e observam alta rotatividade de conexões (connection churn) causando picos de CPU.

Habilitar um grupo adicional de réplicas de leitura para analytics, isolado dos leitores da aplicação, e posicioná-lo em uma AZ ou região diferente para DR.
Configurar o monitoramento da réplica (métrica ReplicaLag) e adicionar lógica de autoescalonamento para adicionar leitores quando o atraso ou a ReadLatency excederem os limiares.
Implantar o RDS Proxy na frente da aplicação para multiplexar conexões e reduzir a rotatividade de conexões; ajuste o max_connections no parameter group apropriadamente.
Mover os jobs de analytics para usar a réplica de analytics e adotar o padrão de cache cache-aside via ElastiCache Redis com TTLs apropriados para reduzir consultas repetidas.
Testar procedimentos de failover e restauração: realize uma restauração PITR em uma instância de homologação (staging) e valide os passos de promoção da réplica.

Esta abordagem separa as cargas de trabalho de leitura, reduz a pressão de conexões na instância primária e usa cache para diminuir o volume de leitura do banco de dados. Ela segue as melhores práticas da AWS ao combinar escalonamento de leitura, pool de conexões e processos de backup/restauração testados para manter a disponibilidade e a resiliência operacional.

← Computação e Auto Scaling · Todos os domínios · Serverless e Integração de Aplicações →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →