Bancos gerenciados na nuvem (RDS/Aurora/Cloud SQL/Atlas/Azure SQL)
Sintoma
Objetivo: conhecer as principais diferenças entre bancos gerenciados na nuvem e instalações autogerenciadas; entender como funcionam na nuvem backup, parâmetros, failover, monitoramento, upgrades e conectividade.
1. Mudança de mentalidade: você acessa um serviço, não um servidor
Em bancos gerenciados você NÃO tem acesso de shell ao SO, ao sistema de arquivos nem ao processo do banco; não pode entrar por SSH, editar arquivos de configuração à mão nem virar superusuário. Você tem apenas a API/console de gerenciamento do provedor e uma conexão SQL normal. AWS RDS/Aurora: o gerenciamento é no nível do recurso (instância/cluster), o servidor fica oculto. GCP Cloud SQL: apenas API da instância, sem SO. MongoDB Atlas: cluster totalmente gerenciado, sem acesso ao mongod. Azure SQL Database: PaaS, nem o servidor nem o SO são visíveis por baixo (a Managed Instance dá um pouco mais de controle). Por isso a maioria dos reflexos do mundo autogerenciado, como 'olhar o arquivo', 'matar o processo' ou 'rodar uma ferramenta do SO', não se aplica.
2. Backup: snapshots automáticos + recuperação point-in-time (PITR)
Você não agenda backups; o provedor os faz automaticamente. A recuperação geralmente é 'restaurar para um ponto específico no tempo' (PITR) ou criar uma nova instância a partir de um snapshot; a instância existente não é sobrescrita. AWS RDS/Aurora: backups automáticos + janela de retenção; um restore PITR com precisão de segundos abre como nova instância/cluster; snapshots manuais também são possíveis. GCP Cloud SQL: backups automáticos + PITR via binary logs; o restore vai para uma nova instância. MongoDB Atlas: cloud backup contínuo + PITR (M10+); restore a partir de snapshots. Azure SQL: backups automáticos nativos, retenção de 1-35 dias, PITR para qualquer ponto e restore de bancos excluídos. Regra comum: verifique a configuração de backup (janela, período de retenção) e faça testes de restore regulares.
3. Parâmetros: parameter groups / flags, não um arquivo de configuração
Em vez de editar postgresql.conf ou my.cnf à mão, você usa a abstração de parâmetros do provedor; alguns parâmetros são bloqueados e alguns exigem restart (estáticos). AWS RDS/Aurora: definidos via DB parameter group (e cluster parameter group); parâmetros dinâmicos se aplicam na hora, os estáticos no reboot. GCP Cloud SQL: as 'database flags' são definidas pelo console/gcloud. MongoDB Atlas: 'Additional Settings' limitadas + tamanho do oplog etc.; a maioria dos parâmetros internos é gerenciada. Azure SQL: a maioria das configurações de nível de servidor é gerenciada; o comportamento muda via SCOPED CONFIGURATION e a escolha do service tier. Antes de aplicar, verifique se o parâmetro é dinâmico ou estático.
4. Alta disponibilidade / failover: Multi-AZ e réplicas gerenciados
Você não monta o failover; marca uma opção e deixa com o provedor. O standby e o failover automático são gerenciados, e as conexões são redirecionadas ao novo primário por um endpoint estável. AWS RDS: Multi-AZ (standby síncrono, failover automático); Aurora: storage com várias cópias + failover automático, o cluster endpoint aponta para o writer. GCP Cloud SQL: configuração de HA (regional, standby em uma zona secundária) com um clique; réplicas de leitura são adicionadas à parte. MongoDB Atlas: replica set nativo, implantação multirregião/multicloud disponível, failover automático. Azure SQL: HA nativa (réplicas locais no Business Critical), opção zone-redundant e active geo-replication / failover groups entre regiões. A aplicação deve sempre se conectar ao endpoint, nunca a um IP fixo.
5. Monitoramento: o serviço de métricas e logs do provedor
Como você não pode rodar ferramentas do SO (top, iostat), monitora pela plataforma de métricas do provedor; métricas de CPU, número de conexões, IOPS, lag de replicação e armazenamento ficam lá. AWS: métricas do CloudWatch + Enhanced Monitoring + Performance Insights (análise por consulta). GCP Cloud SQL: Cloud Monitoring (antigo Stackdriver) + Query Insights. MongoDB Atlas: métricas/gráficos nativos do Atlas + Performance Advisor + painel em tempo real. Azure SQL: Azure Monitor + SQL Analytics + Query Performance Insight. Sempre configure alarmes de limite (uso de armazenamento, CPU, limite de conexões, atraso de réplica).
6. Upgrades de versão e manutenção: pelo console, em uma janela de manutenção
Em vez de atualizar binários à mão, você escolhe uma versão de destino; patches de versão minor são em geral automáticos, enquanto upgrades de versão principal são planejados e geralmente envolvem downtime/um failover de HA. AWS RDS/Aurora: seleção da versão do engine + opção de upgrade minor automático + upgrades principais de baixo risco com Blue/Green Deployments. GCP Cloud SQL: janela de manutenção + upgrade de versão principal self-service. MongoDB Atlas: upgrade de versão com um clique, downtime quase zero de forma rolling. Azure SQL: recebe patches automaticamente da plataforma (a noção de versão é em grande parte abstraída); o comportamento é controlado pelo compatibility level. Sempre teste primeiro em uma cópia de teste/staging e agende a janela de manutenção fora do horário comercial.
7. Conectividade e segurança: endpoint + IAM/TLS
As conexões sempre passam pelo endpoint DNS fornecido pelo provedor e são criptografadas (TLS); o acesso de rede e a identidade podem ser ligados ao sistema de identidade da nuvem. AWS RDS/Aurora: endpoint de instância/cluster + Security Group para a rede + autenticação IAM de banco opcional + TLS (certificado rds-ca). GCP Cloud SQL: IP público + Authorized Networks ou IP privado/VPC, Cloud SQL Auth Proxy, autenticação IAM de banco, TLS. MongoDB Atlas: connection string SRV (mongodb+srv://), IP access list + private endpoint/peering, SCRAM ou IAM/X.509, TLS obrigatório. Azure SQL: endpoint FQDN do servidor + firewall/Private Link + autenticação Microsoft Entra ID (antigo Azure AD) + TLS obrigatório. Regra: use o endpoint, não um IP fixo, na connection string, imponha TLS e conecte com uma identidade IAM da nuvem sempre que possível.