Escalabilidade de armazenamento Escalabilidade de instâncias Escalabilidade de leitura Como gerenciar conexões Gerenciar planos de execução de consulta

Como gerenciar a performance e a escalabilidade de clusters de banco de dados do Aurora

Você pode usar as seguintes opções para gerenciar a performance e a escalabilidade de clusters e instâncias de banco de dados do Aurora:

Tópicos

Escalabilidade de armazenamento
Escalabilidade de instâncias
Escalabilidade de leitura
Como gerenciar conexões
Gerenciar planos de execução de consulta

Escalabilidade de armazenamento

O armazenamento do Aurora escala automaticamente com os dados no volume do cluster. À medida que seus dados aumentam, o armazenamento do volume do cluster aumenta até um máximo de 128 tebibytes (TiB) ou 64 TiB. O tamanho máximo depende da versão do mecanismo de banco de dados. Para saber quais tipos de dados estão incluídos no volume do cluster, consulte Armazenamento e confiabilidade do Amazon Aurora. Para obter detalhes sobre o tamanho máximo de uma versão específica, consulte Limites de tamanho do Amazon Aurora.

O tamanho do volume do cluster é avaliado de hora em hora para determinar os custos de armazenamento. Para obter informações sobre a definição de preço, consulte a página da definição de preço do Aurora.

Embora um volume de cluster do Aurora possa aumentar até muitos tebibytes, você só é cobrado pelo espaço que usa no volume. O mecanismo para determinar o espaço de armazenamento cobrado depende da versão do cluster do Aurora.

Quando os dados do Aurora são removidos do volume do cluster, o espaço cobrado global diminui em um valor comparável. Esse comportamento de redimensionamento dinâmico ocorre quando espaços de tabela subjacentes são excluídos ou reorganizados para exigir menos espaço. Assim, é possível reduzir as cobranças de armazenamento excluindo tabelas e bancos de dados que não são mais necessários. O redimensionamento dinâmico se aplica a determinadas versões do Aurora. Veja a seguir as versões do Aurora em que o volume do cluster é redimensionado dinamicamente à medida que você remove dados:

Aurora MySQL	Versão 3 (compatível com MySQL 8.0): todas as versões compatíveis Versão 2 (compatível com MySQL 5.7): 2.09 e posteriores Versão 1 (compatível com MySQL 5.6): 1.23 e posteriores
Aurora PostgreSQL	Todas as versões 14 e 13 Versão 12.4 e posterior Versão 11.8 e posterior Versão 10.13 e posterior

Em versões do Aurora anteriores às da lista anterior, o volume do cluster pode reutilizar o espaço que foi liberado quando removeu dados, mas o volume em si nunca diminui.
Esse recurso está sendo implantado em fases nas regiões da AWS em que o Aurora está disponível. Dependendo da região em que o cluster está, esse recurso pode não estar disponível ainda.

O redimensionamento dinâmico se aplica a operações que removem ou redimensionam fisicamente espaços de tabela no volume do cluster. Assim, ele se aplica a instruções de SQL, como DROP TABLE, DROP DATABASE, TRUNCATE TABLE e ALTER TABLE ... DROP PARTITION. Ele não se aplica à exclusão de linhas usando a instrução DELETE. Se você excluir um grande número de linhas de uma tabela, será possível executar a instrução OPTIMIZE TABLE do Aurora MySQL ou a extensão pg_repack do Aurora PostgreSQL posteriormente para reorganizar a tabela e redimensionar dinamicamente o volume do cluster.

nota

Para o Aurora MySQL, o parâmetro innodb_file_per_table afeta como o armazenamento de tabela é organizado. Quando as tabelas fazem parte do espaço de tabela do sistema, descartar a tabela não reduz o tamanho do espaço de tabela do sistema. Portanto, defina innodb_file_per_table como 1 para clusters de banco de dados do Aurora MySQL a fim de aproveitar ao máximo o redimensionamento dinâmico.

Para o Aurora MySQL versão 2.10 e posterior, o espaço de tabela temporário do InnoDB é excluído e recriado na reinicialização. Isso libera o espaço ocupado pelo espaço de tabela temporário para o sistema. Depois, o volume do cluster é redimensionado. Para aproveitar ao máximo o recurso de redimensionamento dinâmico, recomendamos que você atualize seu cluster de banco de dados para o Aurora MySQL versão 2.10 ou posterior.

O recurso de redimensionamento dinâmico recupera espaço dos espaços de tabela excluídos ao longo do tempo, não imediatamente, quando as tabelas nesses espaços de tabela são eliminadas. O espaço no espaço de tabela do sistema não é recuperado porque ele nunca é removido. O espaço livre não recuperado em um espaço de tabela é reutilizado quando uma operação precisa de espaço nesse espaço de tabela.

Essas versões do Aurora também têm um limite de armazenamento mais alto para o volume do cluster do que versões anteriores. Assim, será possível considerar a atualização para uma dessas versões se você estiver próximo de exceder o tamanho original do volume 64 TiB.

É possível verificar quanto espaço de armazenamento um cluster está usando monitorando a métrica VolumeBytesUsed no CloudWatch.

No AWS Management Console, é possível ver essa figura em um gráfico exibindo a guia Monitoring na página de detalhes do cluster.

Com a AWS CLI, é possível executar um comando semelhante ao seguinte exemplo do Linux. Substitua seus próprios valores pelas horas de início e término e o nome do cluster.


aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '6 hours ago')" --end-time "$(date -d 'now')" --period 60 \
  --namespace "AWS/RDS" \
  --statistics Average Maximum Minimum \
  --dimensions Name=DBClusterIdentifier,Value=my_cluster_identifier

Este comando gerará uma saída semelhante à seguinte:


{
    "Label": "VolumeBytesUsed",
    "Datapoints": [
        {
            "Timestamp": "2020-08-04T21:25:00+00:00",
            "Average": 182871982080.0,
            "Minimum": 182871982080.0,
            "Maximum": 182871982080.0,
            "Unit": "Bytes"
        }
    ]
}

Os exemplos a seguir mostram como é possível rastrear o uso do armazenamento de um cluster do Aurora ao longo do tempo usando comandos da AWS CLI em um sistema Linux. Os parâmetros --start-time e --end-time definem o intervalo de tempo geral como um dia. O parâmetro --period solicita as medições em intervalos de uma hora. Não faz sentido escolher um valor pequeno de --period, porque as métricas são coletadas em intervalos, não continuamente. Além disso, as operações de armazenamento do Aurora às vezes continuam por um tempo em segundo plano após a conclusão da instrução SQL relevante.

O primeiro exemplo retorna a saída no formato JSON padrão. Os pontos de dados são retornados em ordem arbitrária, não classificados por carimbo de data/hora. É possível importar esses dados JSON em uma ferramenta de gráficos para fazer classificação e visualização.


$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id
{
    "Label": "VolumeBytesUsed",
    "Datapoints": [
        {
            "Timestamp": "2020-08-04T19:40:00+00:00",
            "Maximum": 182872522752.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-05T00:40:00+00:00",
            "Maximum": 198573719552.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-05T05:40:00+00:00",
            "Maximum": 206827454464.0,
            "Unit": "Bytes"
        },
        {
            "Timestamp": "2020-08-04T17:40:00+00:00",
            "Maximum": 182872522752.0,
            "Unit": "Bytes"
        },
... output omitted ...

Este exemplo retorna os mesmos dados que o anterior. O parâmetro --output representa os dados em formato de texto simples compacto. O comando aws cloudwatch canaliza sua saída para o comando sort. O parâmetro -k do comando sort classifica a saída pelo terceiro campo, que é o carimbo de data/hora no formato no Tempo Universal Coordenado (UTC).


$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id \
  --output text | sort -k 3
VolumeBytesUsed
DATAPOINTS  182872522752.0  2020-08-04T17:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T18:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T19:41:00+00:00 Bytes
DATAPOINTS  182872522752.0  2020-08-04T20:41:00+00:00 Bytes
DATAPOINTS  187667791872.0  2020-08-04T21:41:00+00:00 Bytes
DATAPOINTS  190981029888.0  2020-08-04T22:41:00+00:00 Bytes
DATAPOINTS  195587244032.0  2020-08-04T23:41:00+00:00 Bytes
DATAPOINTS  201048915968.0  2020-08-05T00:41:00+00:00 Bytes
DATAPOINTS  205368492032.0  2020-08-05T01:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T02:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T03:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T04:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T05:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T06:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T07:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T08:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T09:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T10:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T11:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T12:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T13:41:00+00:00 Bytes
DATAPOINTS  206827454464.0  2020-08-05T14:41:00+00:00 Bytes
DATAPOINTS  206833664000.0  2020-08-05T15:41:00+00:00 Bytes
DATAPOINTS  206833664000.0  2020-08-05T16:41:00+00:00 Bytes

A saída classificada mostra quanto armazenamento foi usado no início e no término do período de monitoramento. Também é possível encontrar os pontos durante esse período quando o Aurora alocou mais armazenamento para o cluster. O exemplo a seguir usa comandos do Linux para reformatar os valores de início e término de VolumeBytesUsed como gigabytes (GB) e como gibibytes (GiB). Gigabytes representam unidades medidas em potências de 10 e são comumente usadas em discussões de armazenamento para discos rígidos rotacionais. Os gibibytes representam unidades medidas em potências de 2. As medidas e os limites de armazenamento do Aurora normalmente são indicados nas unidades de potência de 2, como gibibytes e tebibytes.


$ GiB=$((1024*1024*1024))
$ GB=$((1000*1000*1000))
$ echo "Start: $((182872522752/$GiB)) GiB, End: $((206833664000/$GiB)) GiB"
Start: 170 GiB, End: 192 GiB
$ echo "Start: $((182872522752/$GB)) GB, End: $((206833664000/$GB)) GB"
Start: 182 GB, End: 206 GB

A métrica de VolumeBytesUsed informa quanto armazenamento no cluster está incorrendo em cobranças. Assim, é melhor minimizar esse número quando for prático. No entanto, essa métrica não inclui um armazenamento que o Aurora usa internamente no cluster e não cobra por isso. Se o cluster estiver se aproximando do limite de armazenamento e puder ficar sem espaço, será mais útil monitorar a métrica AuroraVolumeBytesLeftTotal e tentar maximizar esse número. O exemplo a seguir executa um cálculo semelhante ao anterior, mas para AuroraVolumeBytesLeftTotal, em vez de VolumeBytesUsed. É possível ver que o tamanho livre para esse cluster reflete o limite original de 64 TiB, porque o cluster está executando o Aurora MySQL versão 1.22.


$ aws cloudwatch get-metric-statistics --metric-name "AuroraVolumeBytesLeftTotal" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_old_cluster_id \
  --output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS      69797193744384.0        2020-08-05T17:52:00+00:00       Count
DATAPOINTS      69797193744384.0        2020-08-05T18:52:00+00:00       Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((69797067915264 / $TB)) TB remaining for this cluster"
69 TB remaining for this cluster
$ echo "$((69797067915264 / $TiB)) TiB remaining for this cluster"
63 TiB remaining for this cluster

Para um cluster executando o Aurora MySQL versão 1.23 ou 2.09 e posterior ou Aurora PostgreSQL 3.3.0 ou 2.6.0 e posterior, o tamanho livre relatado por VolumeBytesUsed aumenta quando os dados são adicionados e diminui quando os dados são removidos. O exemplo a seguir mostra como. Este relatório mostra o tamanho máximo e mínimo de armazenamento de um cluster em intervalos de 15 minutos à medida que tabelas com dados temporários são criadas e descartadas. O relatório lista o valor máximo antes do valor mínimo. Assim, para entender como o uso do armazenamento mudou no intervalo de 15 minutos, interprete os números da direita para a esquerda.


$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
  --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
  --namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id
  --output text | sort -k 4
VolumeBytesUsed
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T20:49:00+00:00	Bytes
DATAPOINTS	14545305600.0	14545305600.0	2020-08-05T21:19:00+00:00	Bytes
DATAPOINTS	22022176768.0 14545305600.0	2020-08-05T21:49:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:19:00+00:00	Bytes
DATAPOINTS	22022176768.0	22022176768.0	2020-08-05T22:49:00+00:00	Bytes
DATAPOINTS	22022176768.0 15614263296.0	2020-08-05T23:19:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-05T23:49:00+00:00	Bytes
DATAPOINTS	15614263296.0	15614263296.0	2020-08-06T00:19:00+00:00	Bytes

O exemplo a seguir mostra como com um cluster executando o Aurora MySQL versão 1.23 ou 2.09 e posterior ou Aurora PostgreSQL 3.3.0 ou 2.6.0 e posterior, o tamanho livre relatado pelo AuroraVolumeBytesLeftTotal reflete o limite de tamanho de 128 TiB mais alto.


$ aws cloudwatch get-metric-statistics --region us-east-1 --metric-name "AuroraVolumeBytesLeftTotal" \
  --start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
  --namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBClusterIdentifier,Value=pq-57 \
  --output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS	140515818864640.0	2020-08-05T20:56:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-05T21:26:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-05T21:56:00+00:00	Count
DATAPOINTS	140514866757632.0	2020-08-05T22:26:00+00:00	Count
DATAPOINTS	140511020580864.0	2020-08-05T22:56:00+00:00	Count
DATAPOINTS	140503168843776.0	2020-08-05T23:26:00+00:00	Count
DATAPOINTS	140503168843776.0	2020-08-05T23:56:00+00:00	Count
DATAPOINTS	140515818864640.0	2020-08-06T00:26:00+00:00	Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((140515818864640 / $TB)) TB remaining for this cluster"
140 TB remaining for this cluster
$ echo "$((140515818864640 / $TiB)) TiB remaining for this cluster"
127 TiB remaining for this cluster

Escalabilidade de instâncias

Você pode escalar o cluster de banco de dados do Aurora, conforme a necessidade, modificando a classe da instância de banco de dados para cada instância de banco de dados do cluster. O Aurora é compatível com várias classes de instância de banco de dados otimizada para Aurora, dependendo da compatibilidade do mecanismo de banco de dados.

Mecanismo do banco de dados	Escalabilidade de instâncias
Amazon Aurora MySQL	Consulte Dimensionar instâncias de bancos de dados Aurora MySQL
Amazon Aurora PostgreSQL	Consulte Dimensionar instâncias de bancos de dados Aurora PostgreSQL

Escalabilidade de leitura

É possível obter uma escalabilidade de leitura para o cluster de banco de dados do Aurora criando até 15 réplicas do Aurora no cluster de banco de dados que usa a replicação de mestre único. Cada réplica do Aurora retorna os mesmos dados do volume de cluster com atraso de réplica mínimo, geralmente considerado inferior a 100 milissegundos após a instância primária ter escrito uma atualização. Conforme seu tráfego de leitura aumenta, você pode criar mais réplicas do Aurora e conectar-se diretamente a elas para distribuir a carga de leitura para o seu cluster de banco de dados. As réplicas do Aurora não precisam ser da mesma classe da instância de banco de dados que a instância primária.

Para obter informações sobre como adicionar réplicas do Aurora a um cluster de banco de dados, consulte Adicionar réplicas do Aurora a um cluster de banco de dados.

Como gerenciar conexões

O número máximo de conexões permitido para uma instância de banco de dados do Aurora é determinado pelo parâmetro max_connections no parameter group do nível da instância para a instância de banco de dados. O valor padrão do parâmetro varia de acordo com a classe de instância de banco de dados usada para compatibilidade com a instância e o mecanismo de banco de dados.

Mecanismo do banco de dados	Valor padrão de max_connections
Amazon Aurora MySQL	Consulte Número máximo de conexões com uma instância de bancos de dados Aurora MySQL
Amazon Aurora PostgreSQL	Consulte Número máximo de conexões com uma instância de bancos de dados Aurora PostgreSQL

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.

Gerenciar planos de execução de consulta

Se você usar o gerenciamento do plano de consultas do Aurora PostgreSQL, obterá controle sobre quais planos o otimizador executará. Para obter mais informações, consulte Gerenciar planos de execução de consultas do Aurora PostgreSQL.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Adicionar réplicas do Aurora

Clonar um volume para um cluster de banco de dados do Aurora