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

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:

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 arquivos de banco de dados subjacentes são excluídos ou reorganizados para exigir menos espaço. Assim, é possível reduzir as cobranças de armazenamento excluindo tabelas, índices, bancos de dados, etc., 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ê exclui dados:

    • Aurora MySQL 3 (compatível com MySQL 8.0), todas as versões secundárias

    • Aurora MySQL 2.09 (compatível com MySQL 5.7) e superior

    • Aurora MySQL versão 1.23 (compatível com MySQL 5.6) e versões posteriores

    • Todas as versões do Aurora PostgreSQL 13

    • Aurora PostgreSQL versão 12.4 e versões posteriores

    • Aurora PostgreSQL versão 11.8 e versões posteriores

    • Aurora PostgreSQL versão 10.13 e versões posteriores

  • Em versões anteriores do Aurora às da lista anterior, o volume do cluster pode reutilizar o espaço que foi liberado quando eliminou 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 arquivos de dados 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 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, use a configuração innodb_file_per_table=1 para clusters do Aurora MySQL a fim de aproveitar ao máximo o redimensionamento dinâmico.

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 banco de dados Aurora MySQL

Amazon Aurora PostgreSQL

Consulte Dimensionar instâncias de banco de dados do 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 banco de dados Aurora MySQL

Amazon Aurora PostgreSQL

Consulte Número máximo de conexões com uma instância de banco de dados do Aurora PostgreSQL

Se suas aplicações abrem e fecham conexões com frequência ou têm conexões de longa duração que se aproximam de ou excedem os limites especificados, 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 Uso do Amazon RDS Proxy.

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.