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
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 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:
Mecanismo do banco de dados Versões com redimensionamento dinâmico 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.11 e posterior
Aurora PostgreSQL Todas as versões compatíveis Aurora Serverless v2 Todas as versões compatíveis Aurora Serverless v1 Todas as versões compatíveis -
-
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.
-
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 atributo 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.
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çõesDROP TABLE, o espaço correspondente a todo o espaço de tabela é recuperável. -
O parâmetro
innodb_file_per_tableafeta 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, definainnodb_file_per_tablecomo 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.
-
No AWS Management Console, é possível ver essa figura em um gráfico exibindo a guia
Monitoringna 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_identifierEste 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 3VolumeBytesUsed 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 3AuroraVolumeBytesLeftTotal 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 4VolumeBytesUsed 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 o tamanho livre relatado por AuroraVolumeBytesLeftTotal reflete o limite de tamanho de 128 TiB com um cluster executando o Aurora MySQL versão 2.09 ou posterior, ou Aurora PostgreSQL.
$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 3AuroraVolumeBytesLeftTotal 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
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.
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.
