Gerenciar o Amazon Aurora PostgreSQL
As seções a seguir descrevem o gerenciamento da performance e da escalabilidade de um cluster de bancos de dados Amazon Aurora PostgreSQL. Também inclui informações sobre outras tarefas de manutenção.
Tópicos
- Dimensionar instâncias de bancos de dados Aurora PostgreSQL
- Número máximo de conexões com uma instância de bancos de dados Aurora PostgreSQL
- Limites de armazenamento temporário para o Aurora PostgreSQL
- Páginas grandes para o Aurora PostgreSQL
- Teste do Amazon Aurora PostgreSQL usando consultas de injeção de falhas
- Exibir o status do volume para um cluster de bancos de dados Aurora PostgreSQL
- Como especificar o disco de RAM para o stats_temp_directory
- Gerenciar arquivos temporários com o PostgreSQL
Dimensionar instâncias de bancos de dados Aurora PostgreSQL
Você pode escalar instâncias de banco de dados Aurora PostgreSQL de duas maneiras: com escalabilidade de instância e escalabilidade de leitura. Para ter mais informações sobre a escalabilidade de leitura, consulte Escalabilidade de leitura.
Você pode escalar o cluster de bancos de dados Aurora Postgree modificando a classe da instância de banco de dados para cada instância de banco de dados do cluster. O Aurora PostgreSQL é compatível com várias classes de instância de banco de dados otimizada para o Aurora. Não use classes de instância db.t2 ou db.t3 para clusters do Aurora maiores com tamanho superior a 40 terabytes (TB).
nota
Recomendamos usar as classes de instância de banco de dados T somente para servidores de desenvolvimento e teste, ou outros servidores que não sejam de produção. Para obter mais detalhes sobre as classes de instâncias T, consulte Tipos de classe de instância de banco de dados.
A escalabilidade não é instantânea. Pode levar 15 minutos ou mais para concluir a alteração em uma classe de instância de banco de dados diferente. Se você usar essa abordagem para modificar a classe da instância de banco de dados, aplique a alteração durante a próxima janela de manutenção programada (em vez de fazer isso imediatamente) para evitar o impacto nos usuários.
Como alternativa à modificação da classe de instância de banco de dados diretamente, você pode minimizar o tempo de inatividade usando os recursos de alta disponibilidade do Amazon Aurora. Primeiro, adicione uma réplica do Aurora ao cluster. Ao criar a réplica, escolha o tamanho da classe de instância de banco de dados que deseja usar para o cluster. Quando a réplica do Aurora é sincronizada com o cluster, você faz o failover para a réplica recém-adicionada. Para saber mais, consulte Réplicas do Aurora e Failover rápido com o Amazon Aurora PostgreSQL.
Para obter especificações detalhadas das classes de instância de banco de dados compatíveis com o Aurora PostgreSQL, consulte Mecanismos de banco de dados compatíveis para classes de instância de banco de dados.
Número máximo de conexões com uma instância de bancos de dados Aurora PostgreSQL
Um cluster de bancos de dados do Aurora aloca recursos baseados na classe da instância de banco de dados e na memória disponível. Cada conexão com o cluster de banco de dados consome quantidades incrementais desses recursos, como memória e CPU. A memória consumida por conexão varia de acordo com o tipo de consulta, contagem e se tabelas temporárias são usadas. Até mesmo uma conexão ociosa consome memória e CPU. Isso porque quando as consultas são realizadas em uma conexão, mais memória é alocada para cada consulta e ela não é liberada completamente, mesmo quando o processamento é interrompido. Assim, recomendamos que você verifique se suas aplicações não estão segurando conexões ociosas: cada uma desperdiça recursos e afeta negativamente a performance. Para ter mais informações, consulte Recursos consumidos por conexões ociosas do PostgreSQL
O número máximo de conexões permitido para uma instância de bancos de dados Aurora PostgreSQL é determinado pelo valor de parâmetro max_connections especificado no grupo de parâmetros para esta instância de banco de dados. O cenário ideal para o parâmetro max_connections é aquele que suporta todas as conexões do cliente que sua aplicação precisa, sem excesso de conexões não utilizadas, além de pelo menos mais 3 conexões para suportar automação da AWS. Antes de modificar a configuração do parâmetro max_connections, recomendamos considerar o seguinte:
-
Se o valor de
max_connectionsé muito baixo, a instância de bancos de dados Aurora PostgreSQL pode não ter conexões suficientes disponíveis quando os clientes tentam se conectar. Se isso acontecer, ele tentará se conectar usando opsqlpara gerar mensagens de erro, como as seguintes:psql: FATAL: remaining connection slots are reserved for non-replication superuser connections -
Se o valor de
max_connectionsexcede o número de conexões que são realmente necessárias, as conexões não utilizadas podem causar queda de performance.
O valor padrão de max_connections é derivado da seguinte função LEAST do Aurora PostgreSQL:
LEAST({DBInstanceClassMemory/9531392},5000).
Se quiser alterar o valor para max_connections, você precisará criar um grupo de parâmetros de cluster de banco de dados personalizado e alterar seu valor. Depois de aplicar o grupo de parâmetros de banco de dados personalizado ao cluster, reinicialize a instância principal para que o novo valor seja aplicado. Para ter mais informações, consulte Amazon Aurora PostgreSQL parameters e Criar um grupo de parâmetros de cluster de banco de dados.
dica
Se suas aplicações abrem e fecham conexões com frequência ou mantêm um grande número de conexões de longa duração abertas, recomendamos usar o Amazon RDS Proxy. O RDS Proxy é um proxy de banco de dados totalmente gerenciado e altamente disponível que usa grupos de conexões para compartilhar conexões de banco de dados de forma segura e eficiente. Para saber mais sobre o RDS Proxy, consulte Usar o Amazon RDS Proxy para o Aurora.
Para obter detalhes sobre como as instâncias do Aurora Serverless v2 lidam com esse parâmetro, consulte Conexões máximas do Aurora Serverless v2.
Limites de armazenamento temporário para o Aurora PostgreSQL
O Aurora PostgreSQL armazena tabelas e índices no subsistema de armazenamento do Aurora. O Aurora PostgreSQL usa armazenamento temporário separado para arquivos temporários não persistentes. Isso inclui arquivos que são usados para fins como classificar grandes conjuntos de dados durante o processamento de consultas ou para operações de compilação de índice. Para obter mais informações, consulte o artigo Como posso solucionar problemas de armazenamento local em instâncias do Aurora compatível com PostgreSQL?
Esses volumes de armazenamento local são apoiados pelo Amazon Elastic Block Store e podem ser estendidos utilizando uma classe de instância de banco de dados maior. Para ter mais informações sobre armazenamento, consulte Armazenamento e confiabilidade do Amazon Aurora. Também é possível aumentar o armazenamento local para objetos temporários usando um tipo de instância habilitado para NVMe e objetos temporários habilitados para o Aurora Optimized Reads. Para ter mais informações, consulte Melhorar a performance das consultas do Aurora PostgreSQL com o Aurora Optimized Reads.
nota
Você pode ver eventos de storage-optimization ao dimensionar instâncias de banco de dados, por exemplo, de db.r5.2xlarge para db.r5.4xlarge.
A tabela a seguir mostra a quantidade máxima de armazenamento temporário disponível para cada classe de instância de bancos de dados Aurora PostgreSQL. Para ter mais informações sobre o suporte a classes de instância de banco de dados para o Aurora, consulte Classes de instância de banco de dados Aurora.
| Classe de instância de banco de dados | Armazenamento temporário máximo disponível (GiB) |
|---|---|
| db.x2g.16xlarge | 1829 |
| db.x2g.12xlarge | 1606 |
| db.x2g.8xlarge | 1071 |
| db.x2g.4xlarge | 535 |
| db.x2g.2xlarge | 268 |
| db.x2g.xlarge | 134 |
| db.x2g.large | 67 |
| db.r7g.16xlarge | 1008 |
| db.r7g.12xlarge | 756 |
| db.r7g.8xlarge | 504 |
| db.r7g.4xlarge | 252 |
| db.r7g.2xlarge | 126 |
| db.r7g.xlarge | 63 |
| db.r7g.large | 32 |
| db.r6g.16xlarge | 1008 |
| db.r6g.12xlarge | 756 |
| db.r6g.8xlarge | 504 |
| db.r6g.4xlarge | 252 |
| db.r6g.2xlarge | 126 |
| db.r6g.xlarge | 63 |
| db.r6g.large | 32 |
| db.r6i.32xlarge | 1829 |
| db.r6i.24xlarge | 1500 |
| db.r6i.16xlarge | 1008 |
| db.r6i.12xlarge | 748 |
| db.r6i.8xlarge | 504 |
| db.r6i.4xlarge | 249 |
| db.r6i.2xlarge | 124 |
| db.r6i.xlarge | 62 |
| db.r6i.large | 31 |
| db.r5.24xlarge | 1500 |
| db.r5.16xlarge | 1008 |
| db.r5.12xlarge | 748 |
| db.r5.8xlarge | 504 |
| db.r5.4xlarge | 249 |
| db.r5.2xlarge | 124 |
| db.r5.xlarge | 62 |
| db.r5.large | 31 |
| db.r4.16xlarge | 960 |
| db.r4.8xlarge | 480 |
| db.r4.4xlarge | 240 |
| db.r4.2xlarge | 120 |
| db.r4.xlarge | 60 |
| db.r4.large | 30 |
| db.t4g.large | 16.5 |
| db.t4g.medium | 8.13 |
| db.t3.large | 16 |
| db.t3.medium | 7,5 |
nota
Os tipos de instância habilitados para NVMe podem aumentar o espaço temporário disponível em até o tamanho total do NVMe. Para ter mais informações, consulte Melhorar a performance das consultas do Aurora PostgreSQL com o Aurora Optimized Reads.
É possível monitorar o armazenamento temporário disponível para uma instância de banco de dados com a métrica do CloudWatch FreeLocalStorage, descrita em Métricas do Amazon CloudWatch para o Amazon Aurora. (Isso não se aplica ao Aurora Serverless v2.)
Para algumas workloads, é possível reduzir a quantidade de armazenamento temporário alocando mais memória para os processos que estão realizando a operação. Para aumentar a memória disponível para uma operação, aumentando os valores dos parâmetros do PostgreSQL work_mem
Páginas grandes para o Aurora PostgreSQL
Páginas grandes são um recurso de gerenciamento de memória que reduz a sobrecarga quando uma instância de banco de dados está trabalhando com grandes blocos contíguos de memória, como os usados por buffers compartilhados. Esse recurso PostgreSQL é compatível com todas as versões do Aurora PostgreSQL atualmente disponíveis.
O parâmetro Huge_pages é ativado por padrão para todas as classes de instância de banco de dados que não sejam classes de instância de banco de dados t3.medium, db.t3.large, db.t4g.medium e db.t4g.large. Você não pode alterar o valor do parâmetro huge_pages nem desativar esse recurso nas classes de instância compatíveis do Aurora PostgreSQL.
