# 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:
**Topics**
+ [Escalabilidade de armazenamento](#Aurora.Managing.Performance.StorageScaling)
+ [Escalabilidade de instâncias](#Aurora.Managing.Performance.InstanceScaling)
+ [Escalabilidade de leitura](#Aurora.Managing.Performance.ReadScaling)
+ [Como gerenciar conexões](#Aurora.Managing.MaxConnections)
+ [Gerenciar planos de execução de consulta](#Aurora.Managing.Optimizing)
## Escalabilidade de armazenamento
O armazenamento do Aurora escala automaticamente com os dados no volume do cluster. À medida que os dados aumentam, o armazenamento do volume do cluster se expande com base na versão do mecanismo de banco de dados. Para ter informações sobre os tamanhos máximos de volume do cluster do Aurora para cada versão de mecanismo, consulte [Limites de tamanho do Amazon Aurora](CHAP_Limits.md#RDS_Limits.FileSize.Aurora). Para saber quais tipos de dados estão incluídos no volume do cluster, consulte [Armazenamento do Amazon Aurora](Aurora.Overview.StorageReliability.md). Para obter detalhes sobre o tamanho máximo de uma versão específica, consulte [Limites de tamanho do Amazon Aurora](CHAP_Limits.md#RDS_Limits.FileSize.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](https://aws.amazon.com/rds/aurora/pricing).
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:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html)
+ Em versões do Aurora anteriores às dessa lista, o volume do cluster pode reutilizar o espaço que foi liberado quando você removeu dados, mas o volume em si nunca diminui.
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.
Para o Aurora MySQL, as seguintes considerações se aplicam:
+ Depois de fazer upgrade do cluster de banco de dados para uma versão de mecanismo de banco de dados compatível com o redimensionamento dinâmico, e quando o recurso estiver habilitado nessa Região da AWS específica, qualquer espaço que for liberado posteriormente por determinadas instruções SQL, como `DROP TABLE`, será recuperável.
Se o recurso estiver explicitamente desabilitado em uma Região da AWS específica, só será possível reutilizar (e não recuperar) o espaço, mesmo em versões compatíveis com o redimensionamento dinâmico.
O recurso foi habilitado para versões específicas do mecanismo de banco de dados (de 1.23.0 a 1.23.4, de 2.09.0 a 2.09.3 e 2.10.0) entre novembro de 2020 e março de 2022 e está habilitado por padrão em todas as versões subsequentes.
+ Uma tabela é armazenada internamente em um ou mais fragmentos contíguos de tamanhos variados. Durante a execução das operações `TRUNCATE TABLE`, o espaço correspondente ao primeiro fragmento é reutilizável e não recuperável. Outros fragmentos são recuperáveis. Durante as operações `DROP TABLE`, o espaço correspondente a todo o espaço de tabela é recuperável.
+ O parâmetro `innodb_file_per_table` afeta como o armazenamento da 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.
+ Na versão 2.11 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 o cluster de banco de dados para a versão 2.11 ou posterior.
**nota**
O recurso de redimensionamento dinâmico não recupera espaço imediatamente quando as tabelas nos espaços de tabela são eliminadas, mas gradualmente a uma taxa de aproximadamente 10 TB por dia. 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. O atributo de redimensionamento dinâmico pode recuperar espaço de armazenamento somente quando o cluster está no estado disponível.
É possível verificar quanto espaço de armazenamento um cluster está usando monitorando a métrica `VolumeBytesUsed` no CloudWatch. Para receber mais informações sobre faturamento do armazenamento, consulte [Como o armazenamento de dados do Aurora é faturado](Aurora.Overview.StorageReliability.md#aurora-storage-data-billing).
+ No Console de gerenciamento da AWS, é 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`.
```
$ 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 140530528288768.0 2023-02-23T19:25: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 2.09 ou posterior, ou Aurora PostgreSQL, 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 que, para clusters que estão executando versões compatíveis do Aurora MySQL ou Aurora PostgreSQL, o tamanho livre relatado por `AuroraVolumeBytesLeftTotal` reflete o limite de tamanho de 256 TiB. Para ter mais informações sobre versões compatíveis, consulte [Limites de tamanho do Amazon Aurora](CHAP_Limits.md#RDS_Limits.FileSize.Aurora).
```
$ 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"
256 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](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.Performance.InstanceScaling) |
| Amazon Aurora PostgreSQL | Consulte [Dimensionar instâncias de bancos de dados Aurora PostgreSQL](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.Performance.InstanceScaling) |
## Escalabilidade de leitura
Você pode obter uma escalabilidade de leitura para o cluster de banco de dados Aurora criando até 15 réplicas do Aurora em um cluster de banco de dados. 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](aurora-replicas-adding.md).
## 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\$1connections |
| --- | --- |
| Amazon Aurora MySQL | Consulte [Número máximo de conexões com uma instância de bancos de dados Aurora MySQL](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections) |
| Amazon Aurora PostgreSQL | Consulte [Número máximo de conexões com uma instância de bancos de dados Aurora PostgreSQL](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.MaxConnections) |
**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 [Amazon RDS Proxypara Aurora](rds-proxy.md).
## 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](AuroraPostgreSQL.Optimize.md).