View a markdown version of this page

Requisitos e limitações do Aurora Serverless v2 - Amazon Aurora
Disponibilidade de região e versãoClusters que usam o Aurora Serverless v2 devem ter um intervalo de capacidade especificado.Configuração de escalabilidade incompatívelAlguns recursos provisionados não são compatíveis com o Aurora Serverless v2

Requisitos e limitações do Aurora Serverless v2

Ao criar um cluster onde você pretende usar instâncias de banco de dados do Aurora Serverless v2, preste atenção aos requisitos e às limitações a seguir.

Disponibilidade de regiões e versões

A disponibilidade e a compatibilidade de recursos variam entre versões específicas de cada mecanismo de banco de dados do Aurora e entre Regiões da AWS. Para obter mais informações sobre a disponibilidade de versões e regiões com o Aurora e Aurora Serverless v2, consulte Regiões e mecanismos de banco de dados do Aurora compatíveis com o Aurora Serverless v2.

O exemplo a seguir mostra comandos do AWS CLI para confirmar os valores exatos do mecanismo de banco de dados que você pode usar com Aurora Serverless v2 para um Região da AWS específico. O parâmetro --db-instance-class para Aurora Serverless v2 é sempre db.serverless. O parâmetro --engine pode ser aurora-mysql ou aurora-postgresql. Substitua os valores --region e --engine apropriados para confirmar os valores --engine-version que você pode usar. Se o comando não produzir nenhuma saída, o Aurora Serverless v2 não estará disponível para essa combinação de Região da AWS e mecanismo de banco de dados.

aws rds describe-orderable-db-instance-options --engine aurora-mysql --db-instance-class db.serverless \
  --region my_region --query 'OrderableDBInstanceOptions[].[EngineVersion]' --output text

aws rds describe-orderable-db-instance-options --engine aurora-postgresql --db-instance-class db.serverless \
  --region my_region --query 'OrderableDBInstanceOptions[].[EngineVersion]' --output text

Clusters que usam o Aurora Serverless v2 devem ter um intervalo de capacidade especificado.

Um cluster do Aurora deve ter um atributo ServerlessV2ScalingConfiguration para que você possa adicionar qualquer instância de banco de dados que use a classe db.serverless de instância de banco de dados. Esse recurso especifica o intervalo de capacidade. A capacidade do Aurora Serverless v2 varia de, no mínimo, 0 unidade de capacidade do Aurora (ACU) a, no máximo, 256 ACUs, em incrementos de 0,5 ACU. O valor mínimo permitido depende da versão do Aurora. Cada ACU fornece o equivalente a aproximadamente 2 gibibytes (GiB) da RAM e da CPU e dos trabalhos em rede associados. Para obter detalhes sobre como o Aurora Serverless v2 usa as configurações de intervalo de capacidade, consulte Como funciona o Aurora Serverless v2.

Consulte os intervalos de capacidade permitidos de várias versões do mecanismo de banco de dados e versões da plataforma em Aurora Serverless v2Capacidade do. O intervalo de ajuste de escala disponível para um cluster específico é influenciado tanto pela versão do mecanismo quanto pelo hardware (versão da plataforma).

Você pode especificar os valores de ACU mínimo e máximo no Console de gerenciamento da AWSao criar um cluster e a instância de banco de dados do Aurora Serverless v2 associada. Também é possível especificar a opção --serverless-v2-scaling-configuration no AWS CLI. Também é possível especificar o parâmetro ServerlessV2ScalingConfiguration com a API do Amazon RDS. Você pode especificar esse atributo ao criar um cluster ou modificar um existente. Para saber os procedimentos que definem o intervalo de capacidade, consulte Configurar o intervalo de capacidade de Aurora Serverless v2 para um cluster. Para ler uma discussão detalhada sobre como escolher valores de capacidade mínima e máxima e como essas configurações afetam alguns parâmetros do banco de dados, consulte escolher o intervalo de capacidade do Aurora Serverless v2 para um cluster do Aurora.

Configuração de escalabilidade incompatível

Quando você modificar o cluster do Aurora PostgreSQL com uma capacidade máxima menor, cada instância será reduzida para corresponder à nova configuração. Se o Aurora detectar que alguma de suas instâncias está com problemas para reduzir a escala verticalmente, ela poderá cancelar e reverter a atualização da configuração de escalabilidade. Como resultado, as instâncias voltarão à configuração anterior. Esse problema poderá ocorrer se a nova capacidade máxima for insuficiente para lidar com o workload atual ou se os parâmetros personalizados aplicados ao grupo de parâmetros do banco de dados do cluster ou das instâncias estiverem definidos como altos demais.

Quando a reversão começar, você vai receber uma notificação por meio de um evento do Amazon RDS contendo informações sobre instâncias que não puderam aplicar a configuração de escalabilidade desejada. Depois que a reversão for concluída, a capacidade máxima da configuração de escalabilidade retornará ao valor original mais alto. Devido à reversão, você pode observar que a capacidade do banco de dados do Aurora Serverless em todas as instâncias do seu cluster também pode aumentar, levando a custos mais altos.

Por exemplo, você tem um cluster Aurora PostgreSQL do Aurora Serverless com uma única instância e a configuração de escalabilidade está definida como minCapacity=0.5, maxCapacity=128 e secondsUntilAutopause=null. Além disso, o parâmetro do banco de dados track_activity_query_size é definido como um valor personalizado de 40960. Se você modificar a configuração de escalabilidade do cluster para ter uma capacidade máxima de 1 ACU, poderá notar que, após algumas horas, a modificação não foi concluída. O alto valor do parâmetro track_activity_query_size requer mais recursos do que a nova capacidade máxima pode fornecer. Como resultado, mesmo sem workload, a ServerlessDatabaseCapacity da instância não pode ser reduzida verticalmente para corresponder à nova capacidade máxima de 1 ACU. O Aurora Serverless v2 cancelará a modificação da configuração de escalabilidade e reaplicará a configuração anterior de minCapacity=0.5, maxCapacity=128, secondsUntilAutopause=null. Depois, a instância será ampliada para corresponder à configuração de escalabilidade anterior, encerrando a modificação do cluster. Um evento do Amazon RDS é publicado notificando você de que uma atualização de configuração de escalabilidade incompatível foi detectada, cancelada e revertida para a configuração anterior.

Problemas e correções

A nova configuração de escalabilidade é incompatível com o workload

A capacidade máxima da nova configuração de escalabilidade do Aurora Serverless v2 é muito baixa para lidar com o workload atual.

Recomendações:

  • Reduza o workload antes de reaplicar a capacidade máxima inferior.

  • Se não for possível reduzir o workload, reavalie a capacidade máxima desejada. Para escolher uma capacidade máxima apropriada, verifique a métrica máxima de ServerlessDatabaseCapacity do CloudWatch para seu cluster do Aurora PostgreSQL antes que a atualização da configuração de escalabilidade seja cancelada e revertida. Depois, defina a capacidade máxima da sua nova configuração de escalabilidade para ser, no mínimo, o valor observado de ServerlessDatabaseCapacity. Para obter mais orientações sobre como escolher uma capacidade máxima, consulte escolher o intervalo de capacidade do Aurora Serverless v2 para um cluster do Aurora.

A nova configuração de escalabilidade é incompatível com os parâmetros personalizados do banco de dados

Os grupos de parâmetros de banco de dados personalizados do cluster ou das instâncias exigem recursos adicionais que excedam a capacidade máxima da nova configuração de escalabilidade.

Possíveis parâmetros incompatíveis do banco de dados do Aurora PostgreSQL:

  • max_connections

  • track_activity_query_size

  • min_dynamic_shared_memory

Recomendações:

  • Para escolher um valor de parâmetro de banco de dados apropriado, verifique os valores padrão para cada um dos parâmetros listados acima. Se o valor configurado exceder os valores padrão, reduza os parâmetros aos valores padrão antes de modificar a configuração de escalabilidade com a mesma capacidade máxima reduzida.

  • Se não for possível reduzir os parâmetros do banco de dados, siga as mesmas etapas para escolher uma capacidade máxima apropriada descrita acima em: A nova configuração de escalabilidade é incompatível com o workload.

Alguns recursos provisionados não são compatíveis com o Aurora Serverless v2

Os seguintes recursos das instâncias de banco de dados provisionadas do Aurora atualmente não estão disponíveis para o Amazon Aurora Serverless v2:

  • Fluxos de atividades do banco de dados (DAS).

  • Gerenciamento de cache do cluster do Aurora PostgreSQL. O parâmetro de configuração apg_ccm_enabled não se aplica a instâncias de banco de dados do Aurora Serverless v2.

Alguns recursos do Aurora funcionam com Aurora Serverless v2, mas poderão causar problemas se o intervalo de capacidade for menor do que o necessário para os requisitos de memória desses recursos com sua workload específica. Nesse caso, seu banco de dados pode não funcionar tão bem quanto de costume ou encontrar erros de falta de memória. Para obter recomendações sobre como definir o intervalo de capacidade apropriado, consulte escolher o intervalo de capacidade do Aurora Serverless v2 para um cluster do Aurora. Para obter informações sobre solução de problemas se o banco de dados encontrar erros de falta de memória devido a um intervalo de capacidade configurado incorretamente, consulte Evitar erros de falta de memória.

O Auto Scaling do Aurora não é compatível. Esse é o tipo de escalabilidade que adiciona novos leitores para lidar com a workload de uso intenso de leitura, com base no uso da CPU. No entanto, a escalabilidade com base no uso da CPU não é significativa para o Aurora Serverless v2. Como alternativa, você pode criar instâncias de banco de dados do leitor do Aurora Serverless v2 com antecedência e deixá-las com a escala reduzida na vertical para baixa capacidade. Essa é uma maneira mais rápida e menos disruptiva de escalar a capacidade de leitura de um cluster em comparação com a inclusão de novas instâncias de banco de dados de modo dinâmico.