Mecanismos e classes de instância do RDS

O Amazon RDS é compatível com seis mecanismos de banco de dados: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server e Amazon Aurora. Cada mecanismo é uma versão totalmente gerenciada do banco de dados de código aberto ou comercial que você já conhece. A AWS cuida da aplicação de correções, dos backups e do failover, para que você possa se concentrar na lógica da sua aplicação.

A escolha do mecanismo adequado depende dos requisitos atuais da sua aplicação, dos custos de licenciamento e dos recursos oferecidos por cada mecanismo. O Aurora é a opção nativa da nuvem da AWS, desenvolvida para oferecer desempenho e disponibilidade.

O MySQL é o banco de dados relacional de código aberto mais popular do mundo e é uma escolha natural para aplicações web e CMSs. O PostgreSQL oferece conformidade avançada com SQL, suporte robusto a JSONB e um poderoso ecossistema de extensões, sendo popular para cargas de trabalho analíticas e geoespaciais.

Ambos os mecanismos no RDS são compatíveis com backups automatizados, implantações Multi-AZ e réplicas de leitura. As réplicas de leitura do PostgreSQL podem abranger várias regiões, enquanto o MySQL é compatível com até 15 réplicas entre regiões com o Aurora MySQL.

O MariaDB é uma bifurcação do MySQL desenvolvida pela comunidade, totalmente compatível no nível do protocolo de comunicação com clientes MySQL. Ele oferece mecanismos de armazenamento adicionais, melhor desempenho em algumas cargas de trabalho e um modelo de desenvolvimento aberto, sem recursos proprietários.

No RDS, o MariaDB é um substituto direto do MySQL caso você queira evitar o licenciamento do MySQL pela Oracle ou prefira a bifurcação mantida pela comunidade. Ele oferece suporte aos mesmos recursos de backup automatizado, Multi-AZ e réplicas de leitura do MySQL.

O Oracle Database no RDS oferece suporte aos modelos License Included (LI) e Bring Your Own License (BYOL). O LI inclui a licença Oracle SE2 na tarifa por hora, enquanto o BYOL permite usar sua licença existente da Enterprise Edition para recursos como particionamento e Advanced Security.

O Microsoft SQL Server no RDS oferece, de forma semelhante, edições LI (Express, Web, Standard, Enterprise) e BYOL. Ambos os mecanismos são compatíveis com Multi-AZ usando espelhamento síncrono, mas não oferecem suporte a réplicas de leitura da mesma forma que os mecanismos de código aberto.

O Amazon Aurora é um banco de dados relacional nativo da nuvem, compatível com MySQL e PostgreSQL. O Aurora oferece até 5 vezes a taxa de transferência do MySQL e 3 vezes a taxa de transferência do PostgreSQL no mesmo hardware, usando uma camada de armazenamento distribuído que replica os dados automaticamente em seis cópias distribuídas por três zonas de disponibilidade.

O armazenamento do Aurora cresce automaticamente em incrementos de 10 GB, até 128 TiB, eliminando a necessidade de provisionamento manual. A separação entre computação e armazenamento também permite que o Aurora Serverless aumente ou reduza a capacidade automaticamente.

As classes de instância do RDS seguem a mesma convenção de nomenclatura do EC2, mas têm o prefixo db. em vez de apenas a letra da família. As principais famílias são:

• db.t — Desempenho expansível, econômico para desenvolvimento/testes (por exemplo, db.t3.micro, db.t4g.small)
• db.m — Uso geral, com CPU/memória equilibradas (por exemplo, db.m6g.large)
• db.r — Otimizada para memória, destinada a caches grandes e tabelas em memória (por exemplo, db.r6g.xlarge)
• db.x — Memória extrema para Oracle e SQL Server com cargas de trabalho SAP

Escolha db.t para desenvolvimento, db.m para produção típica e db.r para bancos de dados com grandes conjuntos de trabalho.

A seleção de uma classe de instância do RDS exige analisar a utilização de CPU, o consumo de memória, as necessidades de IOPS e a largura de banda da rede da sua carga de trabalho. O AWS Compute Optimizer e a ferramenta RDS Performance Insights ajudam a identificar se a sua instância atual está superdimensionada ou subdimensionada.

Um padrão comum é começar com uma db.t3 para criar protótipos, migrar para db.m6g quando a carga se tornar estável e passar para db.r6g quando as consultas se beneficiarem de um pool de buffers maior. Instâncias baseadas em Graviton2 (db.m6g, db.r6g) normalmente oferecem uma relação preço-desempenho até 35% melhor que as equivalentes x86.

O RDS oferece três tipos de armazenamento que correspondem a volumes EBS nos bastidores:

• gp2 / gp3 — SSD de uso geral; o gp3 permite provisionar IOPS e taxa de transferência de forma independente, sem pagar por mais armazenamento
• io1 / io2 — SSD com IOPS provisionadas para bancos de dados OLTP sensíveis à latência que exigem respostas consistentes abaixo de um milissegundo
• st1 — HDD otimizado para taxa de transferência, disponível somente para mecanismos específicos e cargas de trabalho de teste

Para a maioria das implantações de produção do RDS, o gp3 é a opção padrão recomendada, pois oferece 3.000 IOPS sem custo adicional e pode ser dimensionado independentemente do tamanho do armazenamento.

O RDS oferece duas dimensões de dimensionamento. O dimensionamento vertical (alteração da classe da instância) exige uma breve janela de indisponibilidade, a menos que o Multi-AZ esteja habilitado — com o Multi-AZ, o failover permite uma indisponibilidade quase nula durante o redimensionamento. Você pode agendar a modificação para a próxima janela de manutenção ou aplicá-la imediatamente.

O dimensionamento horizontal é somente para leitura: você adiciona réplicas de leitura para distribuir as consultas SELECT, afastando-as da instância primária. As réplicas de leitura usam replicação assíncrona, portanto existe um pequeno atraso de replicação que sua aplicação precisa tolerar.

Ao escolher entre o Aurora e o MySQL/PostgreSQL da comunidade, considere estas compensações:

• Aurora: maior taxa de transferência, replicação automática em 6 cópias, failover rápido (~30 s), nenhuma gestão manual do armazenamento, custo por hora mais alto
• MySQL/PostgreSQL: custo menor, ecossistema mais amplo de extensões da comunidade, opção BYOL, ferramentas operacionais conhecidas

Em cenários de prova, o Aurora é preferível quando a questão enfatiza alta disponibilidade, crescimento automático do armazenamento ou desempenho próximo ao de bancos de dados comerciais pelo preço de uma solução de código aberto. Os mecanismos da comunidade são melhores quando a prioridade é a minimização de custos ou a paridade de recursos com ambientes locais.

O RDS separa as atualizações de versões secundárias (por exemplo, MySQL 8.0.32 → 8.0.36) das atualizações de versões principais (por exemplo, MySQL 5.7 → 8.0). As atualizações secundárias podem ser configuradas para aplicação automática durante a janela de manutenção, habilitando --auto-minor-version-upgrade. As atualizações principais são manuais e podem exigir testes de compatibilidade da aplicação.

Sempre teste primeiro as atualizações de versões principais em um ambiente de preparação. Você pode criar um snapshot do banco de dados antes da atualização para reverter caso surjam problemas. Os clusters Aurora são compatíveis com atualizações de versões principais no local, com interrupção mínima.

Nesta lição, você aprendeu que: o RDS é compatível com seis mecanismos (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora), as classes de instância correspondem aos perfis das cargas de trabalho (db.t para desenvolvimento/testes, db.m para uso geral, db.r para uso intensivo de memória) e o Aurora oferece maior taxa de transferência e dimensionamento automático do armazenamento em comparação com os mecanismos da comunidade. A seguir, vamos explorar as implantações Multi-AZ e os backups automatizados para alta disponibilidade.