Práticas recomendadas do Amazon RDS

Conheça as práticas recomendadas para trabalhar com o Amazon RDS. Conforme são identificadas novas práticas recomendadas, manteremos esta seção atualizada.

nota

Para reconhecer as recomendações comuns do Amazon RDS, consulte Visualizar e responder às recomendações do Amazon RDS.

Diretrizes operacionais básicas do Amazon RDS

As diretrizes operacionais básicas a seguir devem ser seguidas por todos ao trabalhar com o Amazon RDS. Observe que o Acordo de Nível de Serviço do Amazon RDS exige que você siga essas diretrizes:

• Use métricas para monitorar sua memória, CPU, atraso de réplica e uso de armazenamento. É possível configurar o Amazon CloudWatch para notificar você quando os padrões de uso mudam ou quando a implantação se aproxima dos limites de capacidade. Isso permite manter a disponibilidade e o desempenho do sistema.

• Escale sua instância de banco de dados quando estiver se aproximando dos limites de capacidade de armazenamento. É preciso ter algum buffer de armazenamento e memória para acomodar aumentos imprevistos na demanda de seus aplicativos.

• Habilite backups automáticos e configure a janela de backup para ocorrer durante a baixa diária em IOPS de gravação. É quando um backup causa menos interrupções ao uso do banco de dados.

• Se a workload do banco de dados exigir mais E/S do que você provisionou, a recuperação após um failover ou a falha no banco de dados será lenta. Para aumentar a capacidade de E/S de uma instância de banco de dados, realize uma ou todas as ações a seguir:

  • Migre para uma classe de instância de banco de dados diferente, com alta capacidade de E/S.

  • Converta o armazenamento magnético de uso geral ou armazenamento de IOPS provisionadas, dependendo de quanto é necessário aumentar. Para obter informações sobre os tipos de armazenamento disponíveis, consulte Tipos de armazenamento do Amazon RDS.

    Se você converter para o armazenamento de IOPS provisionadas, certifique-se usar também uma classe de instância de banco de dados otimizada para IOPS provisionadas. Para obter informações sobre IOPS provisionadas, consulte Armazenamento SSD de IOPS provisionadas.

  • Se você já estiver usando armazenamento de IOPS provisionadas, forneça a capacidade de transferência adicional.

• Se o seu aplicativo cliente estiver armazenando em cache os dados do Serviço de Nome de Domínio (DNS) de suas instâncias de banco de dados, defina um valor de tempo de vida (TTL) de menos de 30 segundos. O endereço IP subjacente de uma instância de banco de dados pode ser alterado após um failover. Dessa forma, armazenar os dados do DNS em cache por um longo período pode ocasionar falhas de conexão. Sua aplicação pode tentar se conectar a um endereço IP que não está mais em serviço.

• Teste o failover da instância de banco de dados para entender quanto tempo o processo leva para seu caso de uso específico. Além disso, teste o failover para garantir que a aplicação que acessa sua instância de banco de dados possa se conectar automaticamente à nova instância de banco de dados após o failover.

Recomendações de RAM para a instância de banco de dados

Uma das práticas recomendadas de performance do Amazon RDS é alocar RAM suficiente para que seu conjunto de trabalho resida quase que completamente na memória. O conjunto de trabalho é composto de dados e índices que são usados frequentemente em sua instância. Quanto mais você usar a instância de banco de dados, mais o conjunto de trabalho crescerá.

Para saber se o seu conjunto de trabalho está quase todo na memória, verifique a métrica ReadIOPS (usando o Amazon CloudWatch) enquanto a instância de banco de dados estiver sob carga. O valor de ReadIOPS deve ser pequeno e estável. Em alguns casos, aumentar a escala verticalmente da classe de instância de banco de dados para uma classe com mais RAM ocasiona uma queda dramática no ReadIOPS. Nesses casos, seu conjunto de trabalho não estava totalmente na memória. Continue a escalar até que a ReadIOPS não caia mais drasticamente após uma operação de escalabilidade, ou a ReadIOPS será reduzida a uma quantidade muito pequena. Para obter informações sobre como monitorar as métricas da instância de banco de dados, consulte Visualizar métricas no console do Amazon RDS.

Uso do monitoramento avançado para identificar problemas do sistema operacional

Quando o monitoramento avançado está habilitado, o Amazon RDS fornece métricas em tempo real para o sistema operacional (SO) no qual a instância de banco de dados é executada. É possível visualizar as métricas para sua instância de banco de dados usando o console. Além disso, é possível consumir o resultado do JSON de monitoramento avançado do Amazon CloudWatch Logs em um sistema de monitoramento de sua escolha. Para obter mais informações sobre o monitoramento avançado, consulte Monitorar métricas do SO com o monitoramento avançado.

Uso de métricas para identificar problemas de performance

Para identificar problemas de performance causados por recursos insuficientes e outros gargalos comuns, você pode monitorar as métricas disponíveis para a instância de banco de dados do Amazon RDS.

Visualização de métricas de performance

Você deve monitorar as métricas de performance regularmente para ver os valores médio, máximo e mínimo de uma série de intervalos de tempo. Fazendo isso, você pode identificar quando a performance está degradado. Você também pode definir alarmes do Amazon CloudWatch para limites métricos específicos para que você seja alertado se eles forem atingidos.

Para solucionar problemas de performance, é importante entender a performance de linha de base do sistema. Ao configurar uma instância de banco de dados e executá-la com uma workload típica, capture os valores médio, máximo e mínimo de todas as métricas de performance. Faça isso em vários intervalos diferentes (por exemplo, uma hora, 24 horas, uma semana, duas semanas). Isso poder dar a você uma ideia do que é normal. Isso ajuda a obter comparações para as horas de operação de pico e fora de pico. Você pode usar essas informações para identificar quando a performance está ficando abaixo dos níveis padrão.

Se você usar clusters de banco de dados multi-AZ, monitore a diferença de tempo entre a transação mais recente na instância de banco de dados do gravador e a transação aplicada mais recente em uma instância de banco de dados do leitor. Essa diferença é chamada de atraso de réplica. Para ter mais informações, consulte Atraso de réplica e clusters de banco de dados multi-AZ.

É possível visualizar as métricas combinadas do Insights de Performance e do CloudWatch no painel do Insights de Performance e monitorar a instância de banco de dados. Para usar essa visualização de monitoramento, o Insights de Performance deve estar ativado para a instância de banco de dados. Para obter mais informações sobre essa visualização de monitoramento, consulte Visualizar métricas combinadas no console do Amazon RDS.

Você pode criar um relatório de análise de performance para um período específico e visualizar os insights identificados e as recomendações para resolver os problemas. Consulte mais informações em Criar um relatório de análise de performance.

Para visualizar as métricas de performance

1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

2. No painel de navegação, escolha Databases (Bancos de dados) e uma instância de banco de dados.

3. Escolha Monitoring.

   O painel fornece as métricas de performance. Por padrão, as métricas mostram as informações das últimas três horas.

4. Use os botões numerados no canto superior direito da página por meio das métricas adicionais ou ajuste as configurações para ver mais métricas.

5. Escolha uma métrica de performance para ajustar o período para ver os dados além do dia atual. Você pode alterar os valores de Statistic (Estatística), Time Range (Intervalo de tempo) e Period (Período) para ajustar as informações exibidas. Por exemplo, talvez você queira ver os valores de pico de uma métrica para cada dia das últimas duas semanas. Em caso afirmativo, defina Statistic (Estatística) como Maximum (Máximo), Time Range (Intervalo de Tempo) como Last 2 Weeks (Últimas duas semanas) e Period (Período) como Day (Dia).

Você também pode visualizar métricas de performance usando a CLI ou a API. Para obter mais informações, consulte Visualizar métricas no console do Amazon RDS.

Para definir um alarme do CloudWatch

1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

2. No painel de navegação, escolha Databases (Bancos de dados) e uma instância de banco de dados.

3. Escolha Logs & events (Logs e eventos).

4. Na seção CloudWatch alarms (Alarmes do CloudWatch), escolha Create alarm (Criar alarme).

   

5. Em Send notifications (Enviar notificações), escolha Yes (Sim), e em Send notifications to (Enviar notificações para), escolha New email or SMS topic (Novo tópico de email ou SMS).

6. Em Topic name (Nome do tópico), digite um nome para a notificação e em With these recipients (Com esses destinatários), digite uma lista separada por vírgulas de endereços de e-mail e números de telefone.

7. Em Metric (Métrica), escolha a estatística e a métrica de alarme a serem definidas.

8. Em Threshold (Limite), especifique se a métrica deve ser maior que, menor que ou igual ao limite e especifique o valor do limite.

9. Em Evaluation period (Período de avaliação), selecione o período de avaliação do alarme. Em consecutive period(s) of (períodos consecutivos de), selecione o período durante o qual o limite deve ter sido atingido para acionar o alarme.

10. Em Name of alarm (Nome de alarme), digite um nome para o alarme.

11. Escolha Create Alarm.

O alarme aparece na seção CloudWatch alarms (Alarmes do CloudWatch).

Avaliação de métricas de performance

Uma instância de banco de dados apresenta várias categorias de métricas diferentes, e determinar valores aceitáveis depende de cada métrica.

CPU

• Utilização da CPU – porcentagem da capacidade de processamento computacional utilizada.

Memória

• Memória disponível: a quantidade de RAM disponível na instância de banco de dados, em bytes. A linha vermelha nas métricas da guia Monitoring (Monitoramento) é marcada em 75% para CPU, memória e métricas de armazenamento. Se o consumo de memória da instância cruzar essa linha com frequência, isso indica que é necessário verificar sua workload ou atualizar sua instância.

• Uso de troca: quanto espaço de troca é usado pela instância do banco de dados, em bytes.

Espaço em disco

• Espaço de armazenamento gratuito – quanto espaço de disco não está sendo usado atualmente pela instância de banco de dados, em megabytes.

Operações de entrada/saída

• IOPS de leitura, IOPS de gravação – o número médio de operações de leitura ou gravação de disco por segundo.

• Latência de leitura, Latência de gravação – o tempo médio de uma operação de leitura ou gravação em milissegundos.

• Taxa de transferência de leitura, Taxa de transferência de gravação – o número médio de megabytes lido ou gravado no disco por segundo.

• Profundidade da fila – o número de operações de E/S que aguardam pela gravação ou leitura no disco.

Tráfego de rede

• Taxa de transferência de recepção de rede, Taxa de transferência de transmissão de rede – a taxa de tráfego de rede entre a instância de banco de dados em bytes por segundo.

Conexões de banco de dados

• Conexões de banco de dados – o número de sessões do cliente que estão conectadas à instância do banco de dados.

Para obter descrições individuais mais detalhadas das métricas de performance disponíveis, consulte Monitorar métricas do Amazon RDS com o Amazon CloudWatch.

De um modo geral, os valores aceitáveis para as métricas de performance dependem do aspecto da linha de base e do que o aplicativo está fazendo. Investigue variações consistentes ou tendenciais de sua linha de base. Conselhos sobre tipos específicos de métricas a seguir:

• Alto consumo de CPU ou RAM: valores altos para o consumo de CPU ou RAM podem ser adequados. Por exemplo, eles poderão ficar assim se estiverem de acordo com seus objetivos em relação à aplicação (como throughput ou simultaneidade) e estiverem de acordo com sua expectativa.

• Consumo de espaço em disco: inspecione o consumo de espaço em disco caso o espaço usado seja consistentemente igual ou superior a 85% do espaço total no disco. Veja se é possível excluir dados da instância ou arquivar dados em um sistema diferente para liberar mais espaço.

• Tráfego de rede – em relação ao tráfego de rede, fale com o administrador do sistema para entender qual taxa de transferência é esperada para sua rede de domínio e conexão com a Internet. Inspecione o tráfego de rede caso a taxa de transferência seja consistentemente menor do que a esperada.

• Conexões do banco de dados – considere restringir as conexões do banco de dados caso perceba um alto número de conexões de usuários em conjunto com uma diminuição na performance da instância e no tempo de resposta. O melhor número de conexões de usuários para sua instância de banco de dados vai variar conforme a classe da instância e a complexidade das operações sendo executadas. Para determinar o número de conexões de banco de dados, associe sua instância de banco de dados a um grupo de parâmetros. Nesse grupo, defina o parâmetro User Connections (Conexões de usuário) como diferente de 0 (ilimitado). Você pode usar um parameter group existente ou criar um novo. Para obter mais informações, consulte Trabalhar com grupos de parâmetros.

• Métricas de IOPS – os valores esperados para as métricas de IOPS dependem da especificação do disco e da configuração do servidor, por isso, use sua linha de base para saber os valores típicos. Inspecione caso os valores sejam consistentemente diferentes da sua linha de base. Para obter o melhor performance de IOPS, confira se o seu conjunto de trabalho típico se adequa à memória para minimizar as operações de leitura e gravação.

Para problemas com métricas de performance, a primeira etapa para melhorar a performance é ajustar as consultas mais usadas e mais caras. Ajuste-os para ver se isso diminui a pressão sobre os recursos do sistema. Para ter mais informações, consulte Ajuste das consultas.

Se suas consultas forem ajustadas e o problema persistir, considere atualizar a Classes de instância de banco de dados do Amazon RDS. Você pode atualizá-la para uma que tenha mais do recurso (CPU, RAM, espaço em disco, largura de banda de rede, capacidade de E/S) que está relacionado ao problema.

Ajuste das consultas

Uma das melhores maneiras de melhorar a performance da instância de banco de dados é ajustar as consultas mais utilizadas e que requerem mais recursos. Aqui, você os ajusta para ficar mais barato executá-los. Para obter informações sobre como aprimorar consultas, use os seguintes recursos:

• MySQL – Consulte Otimizar instruções SELECT na documentação do MySQL. Para obter recursos adicionais de ajuste da consulta, consulte MySQL performance tuning and optimization resources (Recursos de otimização e ajuste de performance do MySQL).

• Oracle: consulte Database SQL Tuning Guide (Guia de ajuste do banco de dados SQL) na documentação do Oracle Database.

• SQL Server – Consulte Analyzing a query (Analisar uma consulta) na documentação da Microsoft. Você também pode usar as visualizações de gerenciamento de dados (DMVs) execution- e index-, relacionadas à E/S descritas na documentação System Dynamic Management Views (Visualizações de gerenciamento dinâmico de sistemas) para solucionar problemas de consulta do SQL Server.

  Um aspecto comum do ajuste de consulta é a criação de índices efetivos. Para obter melhorias do índice potencial para sua instância de banco de dados, consulte Database Engine Tuning Advisor (Orientador de Otimização do Mecanismo de Banco de dados) na documentação da Microsoft. Para obter informações sobre como usar o Orientador de Otimização em RDS for SQL Server, consulte Análise da workload do banco de dados em uma instância de banco de dados do Amazon RDS para SQL Server com o Orientador de Otimização do Mecanismo de Banco de Dados.

• PostgreSQL – Consulte Using EXPLAIN na documentação do PostgreSQL para saber como analisar um plano de consulta. Você pode usar essas informações para modificar uma consulta ou tabelas subjacentes para melhorar a performance da consulta.

  Para obter informações sobre como especificar as junções na consulta visando a melhor performance, consulte Controlling the planner with explicit JOIN clauses (Controlar o planejador com cláusulas JOIN explícitas).

• MariaDB – Consulte Otimizações de consulta na documentação do MariaDB.

Práticas recomendadas para trabalhar com o MySQL

Ambos os tamanhos de tabela e o número de tabelas em um banco de dados MySQL podem afetar a performance.

Tamanho da tabela

Normalmente, as restrições do sistema operacional em tamanhos de arquivo determinam o tamanho máximo efetivo da tabela para bancos de dados MySQL. Assim, os limites geralmente não são determinados por restrições internas do MySQL.

Em uma instância de banco de dados MySQL, evite que as tabelas em seu banco de dados se tornem muito grandes. Embora o limite geral de armazenamento seja de 64 TiB, os limites de armazenamento provisionados restringem o tamanho máximo de um arquivo de tabela do MySQL a 16 TiB. Divida suas tabelas grandes para que os tamanhos de arquivo estejam bem abaixo do limite de 16 TiB. Esta abordagem também pode melhorar a performance e o tempo de recuperação. Para obter mais informações, consulte Limites de tamanho de arquivo do MySQL no Amazon RDS.

Tabelas muito grandes (maiores que 100 GB de tamanho) podem afetar negativamente a performance de leituras e gravações (incluindo instruções DML e especialmente instruções DDL). Os índices em tabelas grandes podem melhorar significativamente a performance de seleção, mas também podem degradar a performance das instruções DML. As instruções DDL, como ALTER TABLE, podem ser significativamente mais lentas para as grandes tabelas porque essas operações podem reconstruir completamente uma tabela em alguns casos. Essas instruções DDL podem bloquear as tabelas durante a operação.

A quantidade de memória exigida pelo MySQL para leituras e gravações depende das tabelas envolvidas nas operações. É uma melhor prática ter pelo menos RAM suficiente para manter os índices de tabelas usadas ativamente. Para encontrar as dez maiores tabelas e índices em um banco de dados, use a seguinte consulta:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Número de tabelas

Seu sistema de arquivos subjacente pode ter um limite no número de arquivos que representam tabelas. No entanto, o MySQL não tem limite para o número de tabelas. No entanto, o número total de tabelas no mecanismo de armazenamento MySQL InnoDB pode contribuir para a degradação da performance, independentemente do tamanho dessas tabelas. Para limitar o impacto do sistema operacional, você pode dividir as tabelas em vários bancos de dados na mesma instância de banco de dados MySQL. Isso pode limitar o número de arquivos em um diretório, mas não resolverá o problema geral.

Quando há degradação de performance devido a um grande número de tabelas (mais de 10 mil), ela é causada pelo MySQL trabalhando com arquivos de armazenamento, incluindo a abertura e o fechamento deles. Para resolver esse problema, você pode aumentar o tamanho dos parâmetros table_open_cache e table_definition_cache. No entanto, aumentar os valores desses parâmetros pode aumentar significativamente a quantidade de memória que o MySQL usa, e pode até usar toda a memória disponível. Para obter mais informações, consulte How MySQL opens and closes tables na documentação do MySQL.

Além disso, muitas tabelas podem afetar significativamente o tempo de inicialização do MySQL. Tanto um desligamento limpo como uma reinicialização e uma recuperação de falha podem ser afetados, especialmente em versões anteriores ao MySQL 8.0.

Recomendamos ter menos de dez mil tabelas no total em todos os bancos de dados em uma instância de banco de dados. Para um caso de uso com um grande número de tabelas em um banco de dados MySQL, consulte Um milhão de tabelas no MySQL 8.0.

Mecanismo de armazenamento

Os recursos de recuperação a um ponto anterior no tempo restauração de snapshot do Amazon RDS para MySQL exigem um mecanismo de armazenamento de recuperação de falhas. Esses recursos só são compatíveis com o mecanismo de armazenamento InnoDB. Embora o MySQL suporte vários mecanismos de armazenamento com recursos variados, nem todos eles são otimizados para durabilidade de dados e recuperação de falha. Por exemplo, o mecanismo de armazenamento MyISAM não é compatível com a recuperação de falha confiável e pode impedir que uma recuperação a um ponto anterior no tempo ou uma restauração de snapshot funcionem da forma pretendida. Isso pode resultar em dados perdidos ou corrompidos quando o MySQL for reiniciado após uma falha.

O InnoDB é o mecanismo de armazenamento recomendado e compatível com instâncias de banco de dados MySQL no Amazon RDS. As instâncias do InnoDB também podem ser migradas para o Aurora, enquanto as instâncias do MyISAM não podem ser migradas. No entanto, o MyISAM funciona melhor do que o InnoDB se você precisar de uma capacidade de pesquisa intensa de texto completo. Se você ainda optar por usar o MyISAM com o Amazon RDS, seguir as etapas descritas em Backups automáticos com mecanismos de armazenamento MySQL sem suporte pode ser útil em certos cenários para a funcionalidade de restauração de snapshot.

Se você quiser converter tabelas do MyISAM existentes em tabelas do InnoDB, pode usar o processo descrito na documentação do MySQL. O MyISAM e a InnoDB têm pontos fortes e fracos diferentes. Portanto, é necessário que você avalie totalmente o impacto que essas alterações terão em seus aplicativos antes de fazê-las.

Além disso, o Federated Storage Engine atualmente não é compatível com o Amazon RDS for MySQL.

Práticas recomendadas para trabalhar com o MariaDB

Tanto os tamanhos de tabelas quanto o número de tabelas em um banco de dados MariaDB podem afetar a performance.

Tamanho da tabela

Normalmente, as restrições do sistema operacional em tamanhos de arquivo determinam o tamanho máximo efetivo da tabela para bancos de dados MariaDB. Assim, os limites geralmente não são determinados por restrições internas do MariaDB.

Em uma instância de banco de dados MariaDB, evite que as tabelas em seu banco de dados se tornem muito grandes. Embora o limite geral de armazenamento seja de 64 TiB, os limites de armazenamento provisionados restringem o tamanho máximo de um arquivo de tabela do MariaDB a 16 TiB. Divida suas tabelas grandes para que os tamanhos de arquivo estejam bem abaixo do limite de 16 TiB. Esta abordagem também pode melhorar a performance e o tempo de recuperação.

Tabelas muito grandes (maiores que 100 GB de tamanho) podem afetar negativamente a performance de leituras e gravações (incluindo instruções DML e especialmente instruções DDL). Os índices em tabelas grandes podem melhorar significativamente a performance de seleção, mas também podem degradar a performance das instruções DML. As instruções DDL, como ALTER TABLE, podem ser significativamente mais lentas para as grandes tabelas porque essas operações podem reconstruir completamente uma tabela em alguns casos. Essas instruções DDL podem bloquear as tabelas durante a operação.

A quantidade de memória exigida pelo MariaDB para leituras e gravações depende das tabelas envolvidas nas operações. É uma melhor prática ter pelo menos RAM suficiente para manter os índices de tabelas usadas ativamente. Para encontrar as dez maiores tabelas e índices em um banco de dados, use a seguinte consulta:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Número de tabelas

Seu sistema de arquivos subjacente pode ter um limite no número de arquivos que representam tabelas. No entanto, o MariaDB não tem limite para o número de tabelas. No entanto, o número total de tabelas no mecanismo de armazenamento MariaDB InnoDB pode contribuir para a degradação da performance, independentemente do tamanho dessas tabelas. Para limitar o impacto no sistema operacional, você pode dividir as tabelas em vários bancos de dados na mesma instância de banco de dados MariaDB. Isso pode limitar o número de arquivos em um diretório, mas não resolverá o problema geral.

Quando há degradação da performance devido a um grande número de tabelas (mais de dez mil), o motivo é porque o MariaDB está trabalhando com arquivos de armazenamento. Esse trabalho inclui a abertura e o fechamento de arquivos de armazenamento do MariaDB. Para resolver esse problema, você pode aumentar o tamanho dos parâmetros table_open_cache e table_definition_cache. No entanto, aumentar os valores desses parâmetros pode aumentar significativamente a quantidade de memória que o MariaDB utiliza. Ele pode até usar toda a memória disponível. Para obter mais informações, consulte Optimizing table_open_cache na documentação do MariaDB.

Além disso, muitas tabelas podem afetar significativamente o tempo de inicialização do MariaDB. Tanto um desligamento limpo quanto uma reinicialização e uma recuperação de falha podem ser afetados. Recomendamos ter menos de dez mil tabelas no total em todos os bancos de dados em uma instância de banco de dados.

Mecanismo de armazenamento

Os recursos Point-In-Time Restore e Snapshot Restore do Amazon RDS for MariaDB exigem um mecanismo de armazenamento de recuperação de falhas. Embora o MariaDB suporte vários mecanismos de armazenamento com recursos variados, nem todos eles são otimizados para durabilidade de dados e recuperação de falha. Por exemplo, embora o Aria seja uma substituição segura contra falhas para o MyISAM, isso ainda pode impedir que uma Point-In-Time Restore ou uma restauração de snapshot funcione conforme o previsto. Isso pode resultar em dados perdidos ou corrompidos quando o MariaDB for reiniciado após uma falha. O XtraDB é o mecanismo de armazenamento recomendado e compatível com instâncias de banco de dados MariaDB no Amazon RDS. Se você ainda optar por usar o Aria com o Amazon RDS, seguir as etapas descritas em Backups automáticos com mecanismos de armazenamento MariaDB sem suporte pode ser útil em certos cenários para a funcionalidade de restauração de snapshot.

Se você quiser converter tabelas do MyISAM existentes em tabelas do InnoDB, pode usar o processo descrito na documentação do MariaDB. O MyISAM e a InnoDB têm pontos fortes e fracos diferentes. Portanto, é necessário que você avalie totalmente o impacto que essas alterações terão em seus aplicativos antes de fazê-las.

Práticas recomendadas para trabalhar com o Oracle

Para obter informações sobre as práticas recomendadas para trabalhar com o Amazon RDS for Oracle, consulte Práticas recomendadas para execução do banco de dados Oracle no Amazon Web Services.

Um workshop virtual da AWS de 2020 teve uma apresentação sobre a execução de bancos de dados Oracle de produção no Amazon RDS. Um vídeo da apresentação está disponível aqui:

Práticas recomendadas para trabalhar com PostgreSQL

Das duas áreas importantes em que você pode melhorar a performance do RDS para PostgreSQL, uma é ao carregar dados em uma instância de banco de dados. Outra é ao usar o recurso autovacuum do PostgreSQL. As seções a seguir abrangem algumas das práticas que recomendamos para essas áreas.

Para obter informações sobre como Amazon RDS implementar outras tarefas comuns de DBA PostgreSQL, consulte Tarefas comuns de DBA do Amazon RDS para PostgreSQL.

Carregamento de dados em uma instância de banco de dados PostgreSQL

Ao carregar dados em uma instância de banco de dados do Amazon RDS para PostgreSQL, modifique as configurações de instância de banco de dados e os valores do grupo de parâmetros. Configure-os para permitir a importação mais eficiente de dados para sua instância de banco de dados.

Modifique as configurações da instância de banco de dados da seguinte forma:

• Desabilite os backups de instâncias de banco de dados (defina backup_retention como 0)

• Desabilite o Multi-AZ

Modifique o parameter group de banco de dados para incluir as seguintes configurações. Teste também as configurações dos parâmetros para encontrar as que forem mais eficientes para a instância do banco de dados.

• Aumente o valor do parâmetro maintenance_work_mem. Para obter mais informações sobre os parâmetros de consumo de recursos do PostgreSQL, consulte a documentação do PostgreSQL.

• Aumente o valor dos parâmetros max_wal_size e checkpoint_timeout para reduzir o número de gravações no log write-ahead (WAL).

• Desativar o parâmetro synchronous_commit.

• Desabilite o parâmetro autovacuum do PostgreSQL.

• Verifique se alguma das tabelas que você está importando não está registrada. Os dados armazenados em tabelas não registradas podem ser perdidos durante um failover. Para obter mais informações, consulte CREATE TABLE UNLOGGED.

Use os comandos pg_dump -Fc (compactado) ou pg_restore -j (paralelo) com essas configurações.

Após a conclusão da operação de carregamento, retorne a instância de banco de dados e os parâmetros de banco de dados para as configurações normais.

Trabalhar com o recurso autovacuum do PostgreSQL

O recurso autovacuum para bancos de dados PostgreSQL é um recurso o qual recomendamos que você use para manter a integridade de sua instância de banco de dados PostgreSQL. O autovacuum automatiza a execução do comando VACUUM e ANALYZE. O uso do autovacuum é exigido pelo PostgreSQL, não imposto pelo Amazon RDS, e é fundamental para a boa performance. O recurso é habilitado por padrão para todas as novas instâncias de banco de dados do Amazon RDS para PostgreSQL e os parâmetros de configuração relacionados são definidos apropriadamente por padrão.

O administrador de banco de dados precisa conhecer e entender esta operação de manutenção. Para obter a documentação do PostgreSQL sobre autovacuum, consulte The Autovacuum Daemon.

O autovacuum não é uma operação "livre de recursos", mas funciona em segundo plano e respeita as operações do usuário o máximo possível. Quando ativado, o autovacuum verifica as tabelas que tiveram um grande número de ênuplas atualizadas ou excluídas. Ele também protege contra a perda de dados muito antigos devido ao encapsulamento do ID de transação. Para obter mais informações, consulte Prevenção contra falhas de encapsulamento de IDs de transação.

O autovacuum não deve ser considerado como uma operação de alta sobrecarga que pode ser reduzida para obter melhor performance. Em contrapartida, as tabelas que têm uma alta velocidade de atualizações e exclusões se deteriorarão rapidamente ao longo do tempo se o autovacuum não for executado.

Importante

Não executar o autovacuum pode resultar em uma eventual interrupção necessária para executar uma operação de vacuum muito mais intrusiva. Em alguns casos, uma instância de banco de dados do RDS para PostgreSQL pode ficar indisponível devido ao uso de autovacuum. Nesses casos, o banco de dados do PostgreSQL é desligado para se proteger. Nesse ponto, o Amazon RDS deve executar um vacuum completo no modo de usuário único diretamente na instância de banco de dados. Esse vacuum completo pode ocasionar uma interrupção de várias horas. Portanto, é altamente recomendável não desativar o autovacuum, que está ativado por padrão.

Os parâmetros de autovacuum determinam quando funciona e a intensidade do autovacuum. Os parâmetros autovacuum_vacuum_threshold e autovacuum_vacuum_scale_factor determinam quando o autovacuum é executado. Os parâmetros autovacuum_max_workers, autovacuum_nap_time, autovacuum_cost_limit e autovacuum_cost_delay determinam a intensidade do autovacuum. Para obter mais informações sobre o autovacuum, quando ele é executado e quais parâmetros são necessários, consulte Routine Vacuuming na documentação do PostgreSQL.

A consulta a seguir mostra o número de tuplas "mortas" em uma tabela chamada table1:

SELECT relname, n_dead_tup, last_vacuum, last_autovacuum FROM 
pg_catalog.pg_stat_all_tables 
WHERE n_dead_tup > 0 and relname = 'table1';

Os resultados da consulta serão os seguintes:

relname | n_dead_tup | last_vacuum | last_autovacuum
---------+------------+-------------+-----------------
 tasks   |   81430522 |             |
(1 row) 

Amazon RDS for PostgreSQL vídeo de práticas recomendadas

A conferência AWS re:Invent de 2020 teve uma apresentação sobre novos recursos e práticas recomendadas para trabalhar com o PostgreSQL no Amazon RDS. Um vídeo da apresentação está disponível aqui:

Práticas recomendadas para trabalhar com o SQL Server

As práticas recomendadas para uma implantação Multi-AZ com uma instância de banco de dados SQL Server incluem o seguinte:

• Usar eventos de banco de dados do Amazon RDS para monitorar failovers. Por exemplo, você pode ser notificado por mensagem de texto ou por e-mail quando uma instância de banco de dados falhar. Para obter mais informações sobre eventos do Amazon RDS, consulte Trabalhar com a notificação de eventos do Amazon RDS.

• Se seu aplicativo armazenar em cache os valores de DNS, defina o tempo de vida (TTL) para menos de 30 segundos. Definir o TTL dessa forma é uma prática recomendada caso haja um failover. Em um failover, o endereço IP pode mudar e o valor em cache pode não estar mais funcionando.

• Recomendamos que você não habilite os seguintes modos porque eles desligam o registro de log das transações, o que é necessário para o Multi-AZ:

  • Modo de recuperação simples

  • Modo off-line

  • Modo somente leitura

• Teste para determinar quanto tempo leva para ocorrer um failover na sua instância de banco de dados. O tempo de failover pode variar devido ao tipo de banco de dados, a classe da instância e o tipo de armazenamento que você usa. Você também deve testar a capacidade de continuar trabalhando do seu aplicativo caso ocorra um failover.

• Para reduzir o tempo de failover, faça o seguinte:

  • Certifique-se de ter IOPS provisionadas suficientes alocadas para sua workload. A E/S inadequada pode prolongar os tempos de failover. A recuperação do banco de dados requer E/S.

  • Use transações menores. A recuperação do banco de dados depende das transações, portanto, se for possível dividir grandes transações em várias transações menores, seu tempo de failover deverá ser menor.

• Leve em consideração que, durante um failover, haverá latências elevadas. Como parte do processo de failover, o Amazon RDS replica automaticamente seus dados para uma nova instância em espera. Essa replicação significa que novos dados estão sendo confirmados em duas instâncias de banco de dados diferentes. Portanto, pode haver alguma latência até que a instância de banco de dados de espera tenha alcançado a nova instância de banco de dados primária.

• Implante seus aplicativos em todas as zonas de disponibilidade. Se uma zona de disponibilidade ficar inativa, seus aplicativos nas outras zonas de disponibilidade ainda estarão disponíveis.

Ao trabalhar com uma implantação Multi-AZ do SQL Server, lembre-se de que o Amazon RDS cria réplicas para todos os bancos de dados do SQL Server na instância. Se você não quiser que bancos de dados específicos tenham réplicas secundárias, configure uma instância de banco de dados separada que não use o Multi-AZ nesses bancos de dados.

Amazon RDS for SQL Server vídeo de práticas recomendadas

A conferência AWS re:Invent de 2019 teve uma apresentação sobre novos recursos e práticas recomendadas para trabalhar com o SQL Server no Amazon RDS. Um vídeo da apresentação está disponível aqui:

Trabalhar com grupos de parâmetros de banco de dados

Recomendamos que você experimente fazer mudanças de parameter group de banco de dados em uma instância de banco de dados de teste antes de aplicar alterações de parameter group às instâncias de banco de dados de produção. Definir incorretamente os parâmetros do mecanismo de banco de dados em um parameter group de banco de dados pode causar efeitos adversos não intencionais, inclusive diminuição no performance e instabilidade do sistema. Sempre tenha cuidado ao modificar os parâmetros do mecanismo de banco de dados e faça backup de sua instância de banco de dados antes de modificar um parameter group de banco de dados.

Para obter informações sobre o backup da instância de banco de dados, consulte Backup, restauração e exportação de dados.

Práticas recomendadas para automatizar a criação de instâncias de banco de dados

É uma prática recomendada do Amazon RDS criar uma instância de banco de dados com a versão secundária preferida do mecanismo de banco de dados. Você pode usar a AWS CLI, a API do Amazon RDS ou o AWS CloudFormation para automatizar a criação de instâncias de banco de dados. Ao usar esses métodos, você pode especificar apenas a versão principal e o Amazon RDS cria automaticamente a instância com a versão secundária preferida. Por exemplo, se a versão 12.5 do PostgreSQL for a versão secundária preferida e você especificar a 12 com create-db-instance, a instância de banco de dados será da versão 12.5.

Para determinar a versão secundária preferida, você pode executar o comando describe-db-engine-versions com a opção --default-only, conforme mostrado no exemplo a seguir.

aws rds describe-db-engine-versions --default-only --engine postgres

{
    "DBEngineVersions": [
        {
            "Engine": "postgres",
            "EngineVersion": "12.5",
            "DBParameterGroupFamily": "postgres12",
            "DBEngineDescription": "PostgreSQL",
            "DBEngineVersionDescription": "PostgreSQL 12.5-R1",
            ...some output truncated...
        }
    ]
}

Para obter informações sobre como criar instâncias de banco de dados programaticamente, consulte os seguintes recursos:

• Usar a AWS CLI: create-db-instance

• Usar a API do Amazon RDS – CreateDBInstance

• Usar o AWS CloudFormation: AWS::RDS::DBInstance

Vídeo de apresentação de novos recursos e práticas recomendadas do Amazon RDS

A conferência AWS re:Invent de 2019 teve uma apresentação sobre novos recursos do Amazon RDS e práticas recomendadas para monitorar, analisar e ajustar a performance do banco de dados usando o RDS. Um vídeo da apresentação está disponível aqui: