Escalar para zero ACUs com pausa e retomada automáticas no Aurora Serverless v2 - Amazon Aurora
Visão geral da pausa automática Pré-requisitos e limitações Ativar e desativar a pausa automática Como funciona a pausa automática Pausa automática e configurações do cluster do Aurora Monitorar a pausa automática Solucionar problemas da pausa automática Design da aplicação para pausa automática

Escalar para zero ACUs com pausa e retomada automáticas no Aurora Serverless v2

Se as instâncias de banco de dados do Aurora Serverless v2 não tiverem conexões iniciadas por atividade do usuário dentro de um período especificado, é possível especificar que elas reduzam a escala verticalmente para zero ACU e pausem automaticamente. É possível fazer isso especificando um valor mínimo de ACU de zero para seu cluster de banco de dados. Não há cobranças pela capacidade da instância enquanto ela estiver no estado de pausa. Habilitar o recurso de pausa e retomada automáticas (pausa automática) em clusters do Aurora que são pouco usados ou têm longos períodos de inatividade pode ajudar no gerenciamento de custos da frota de bancos de dados.

nota

O recurso de pausa automática está disponível no Aurora Serverless v2 com Aurora PostgreSQL e Aurora MySQL. Talvez seja necessário atualizar a versão do mecanismo de banco de dados do Aurora para aproveitar esse recurso. Consulte Capacidade do Aurora Serverless v2 para ver as versões do mecanismo com disponibilidade de capacidade mínima de 0 ACUs.

Visão geral do recurso de pausa automática do Aurora Serverless v2

As instâncias de banco de dados do Aurora Serverless v2 podem pausar automaticamente após um período sem conexões de usuário e retomar automaticamente quando chega uma solicitação de conexão. O recurso de pausa/retomada automática do Aurora Serverless v2 ajuda no gerenciamento dos custos de sistemas que não têm um objetivo de nível de serviço (SLO) rigoroso. Por exemplo, você pode habilitar esse recurso em clusters usados para desenvolvimento e testes ou para aplicações internas em que uma breve pausa é aceitável enquanto o banco de dados é retomado. Se a workload tiver períodos de inatividade e puder tolerar pequenos atrasos na conexão enquanto a instância é retomada, considere usar a pausa automática nas instâncias do Aurora Serverless v2 para reduzir custos.

É possível controlar esse comportamento especificando se as instâncias de banco de dados do Aurora Serverless v2 em um cluster podem ou não pausar automaticamente e por quanto tempo cada instância deve ficar ociosa antes de pausar. Para habilitar o comportamento de pausa automática para todas as instâncias de banco de dados do Aurora Serverless v2 em um cluster do Aurora, defina o valor mínimo da capacidade do cluster para zero ACUs.

Se você anteriormente aproveitou o recurso do Aurora Serverless v1 que escalava para zero ACUs após um período de inatividade, você pode atualizar para o Aurora Serverless v2 e usar seu recurso de pausa automática correspondente.

Os benefícios da economia de custos do recurso de pausa automática são semelhantes ao uso do recurso interromper/iniciar cluster. A pausa automática no Aurora Serverless v2 tem os benefícios adicionais de uma retomada mais rápida do que iniciar um cluster interrompido e da automatização do processo de determinação de quando pausar e retomar cada instância de banco de dados.

O recurso de pausa automática também fornece granularidade adicional no controle dos custos dos recursos computacionais no cluster. É possível habilitar algumas instâncias de leitura para pausarem mesmo enquanto a instância de gravação e outros leitores no cluster permanecem ativos o tempo todo. Para fazer isso, atribua às instâncias de leitura que podem pausar independentemente de outras instâncias uma prioridade de failover no intervalo de 2 a 15.

As instâncias de gravação e todas as instâncias de leitura com prioridade de failover 0 e 1 sempre pausam e retomam ao mesmo tempo. Assim, as instâncias desse grupo pausam depois que nenhuma delas tem conexões no intervalo de tempo especificado.

Os clusters de banco de dados do Aurora podem conter uma combinação de instâncias de banco de dados de gravação e leitura e instâncias de banco de dados do Aurora Serverless v2 e provisionadas. Portanto, para usar esse recurso de forma eficaz, é útil entender os seguintes aspectos do mecanismo de pausa automática:

  • As circunstâncias nas quais uma instância de banco de dados pode ser pausada automaticamente.

  • Quando uma instância de banco de dados pode ser impedida de pausar. Por exemplo, habilitar alguns recursos do Aurora ou realizar determinados tipos de operações no cluster pode impedir que as instâncias pausem, mesmo sem nenhuma conexão com essas instâncias.

  • As consequências para o monitoramento e o faturamento enquanto uma instância está pausada.

  • Quais ações fazem com que uma instância de banco de dados retome o processamento.

  • Como a capacidade de uma instância de banco de dados muda em torno dos eventos de pausa e retomada.

  • Como controlar o intervalo de inatividade antes da pausa de uma instância de banco de dados.

  • Como codificar a lógica da aplicação para lidar com o período em que uma instância de banco de dados está retomando o processamento.

Pré-requisitos e limitações do recurso de pausa automática do Aurora Serverless v2

Antes de usar o recurso de pausa automática, verifique quais versões do mecanismo usar. Além disso, verifique se a pausa automática funciona se combinada com os outros recursos do Aurora que você pretende usar. Não é possível ativar a pausa automática se você estiver usando uma versão do mecanismo que não oferece suporte ao recurso. Você não receberá nenhum erro se usar recursos incompatíveis em combinação com a pausa automática. Se o cluster estiver usando recursos ou configurações incompatíveis, as instâncias do Aurora Serverless v2 não serão pausadas automaticamente.

Certas condições ou configurações impedem que as instâncias do Aurora Serverless v2 sejam pausadas automaticamente. Para ter mais informações, consulte Situações em que o Aurora Serverless v2 não faz pausas automáticas.

Ativar e desativar o recurso de pausa automática

É possível ativar e desativar o recurso de pausa automática no nível do cluster. Para fazer isso, use os mesmos procedimentos usados ao ajustar as capacidades mínima e máxima do cluster. O recurso de pausa automática é representado por uma capacidade mínima de 0 ACUs.

Ativar a pausa automática para instâncias do Aurora Serverless v2 em um cluster

Siga o procedimento em Configurar o intervalo de capacidade de Aurora Serverless v2 para um cluster. Para a capacidade mínima, escolha 0 ACUs. Ao escolher uma capacidade mínima de 0 ACUs, você também pode especificar por quanto tempo a instância ficará ociosa antes de ser pausada automaticamente.

O exemplo de CLI a seguir mostra como criar um cluster do Aurora com o recurso de pausa automática habilitado e o intervalo de pausa automática definido para 10 minutos (600 segundos). 

aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \
    --master-username myuser \
    --manage-master-user-password

O exemplo de CLI a seguir mostra como você pode ativar o recurso de pausa automática em um cluster existente do Aurora. Este exemplo define o intervalo de pausa automática como 1 hora (3.600 segundos). 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=80,SecondsUntilAutoPause=3600

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 0,
    "MaxCapacity": 80.0,
    "SecondsUntilAutoPause": 3600
}

Intervalo de tempo limite de pausa automática configurável do Aurora Serverless v2

O intervalo de tempo limite é representado no atributo ServerlessV2ScalingConfiguration do seu cluster do Aurora. É possível especificar esse intervalo no AWS Management Console ao criar ou modificar um cluster do Aurora, se a capacidade mínima estiver definida como zero ACUs. Você pode especificá-lo na AWS CLI usando o parâmetro --serverless-v2-scaling-configuration ao criar ou modificar um cluster do Aurora. Você pode especificá-lo na API do RDS usando o parâmetro ServerlessV2ScalingConfiguration ao criar ou modificar um cluster do Aurora.

O intervalo mínimo que pode ser definido é de 300 segundos (5 minutos). Esse é o padrão se nenhum intervalo for especificado. O intervalo máximo que pode ser definido é de 86.400 segundos (um dia).

Suponha que você desative o recurso de pausa automática de um cluster alterando a capacidade mínima do cluster para um valor diferente de zero. Nesse caso, a propriedade de intervalo é removida do atributo ServerlessV2ScalingConfiguration. A ausência dessa propriedade fornece uma confirmação extra de que o recurso de pausa automática está desativado para esse cluster. Se, posteriormente, você reativar a pausa automática, poderá especificar qualquer intervalo personalizado novamente naquele momento.

Retomar uma instância do Aurora Serverless v2 pausada automaticamente

  • Ao se conectar a uma instância do Aurora Serverless v2 pausada, ela automaticamente é retomada e aceita a conexão.

  • Uma tentativa de conexão que não inclui credenciais válidas ainda faz com que a instância de banco de dados seja retomada.

  • Se você se conectar pelo endpoint do gravador, o Aurora retomará a instância de banco de dados do gravador se ela estiver pausada automaticamente. Ao mesmo tempo, o Aurora retoma todas as instâncias de leitura pausadas automaticamente que tenham prioridade de failover 0 ou 1, o que significa que sua capacidade está vinculada à capacidade da instância de gravação.

  • Se você se conectar pelo endpoint do leitor, o Aurora escolherá uma instância do leitor aleatoriamente. Se essa instância do leitor estiver pausada, o Aurora a retomará. O Aurora também retoma primeiro a instância do gravador porque a instância do gravador deve estar sempre ativa se alguma instância do leitor estiver ativa. Quando o Aurora retoma essa instância do gravador, isso também faz com que todas as instâncias do leitor nos níveis zero e um de promoção de failover sejam retomadas.

  • Se você enviar uma solicitação ao seu cluster pela da API de dados do RDS, o Aurora retomará a instância do gravador se ela estiver pausada. Em seguida, o Aurora processa a solicitação da API de dados.

  • Ao alterar o valor de um parâmetro de configuração em um grupo de parâmetros de cluster de banco de dados, o Aurora retoma automaticamente todas as instâncias do Aurora Serverless v2 pausadas em todos os clusters que usam esse grupo de parâmetros de cluster. De forma semelhante, ao alterar um valor de parâmetro em um grupo de parâmetros de banco de dados, o Aurora retoma automaticamente quaisquer instâncias do Aurora Serverless v2 pausadas que usam esse grupo de parâmetros de banco de dados. O mesmo comportamento de retomada automática se aplica ao modificar um cluster para atribuir um grupo de parâmetros de cluster diferente ou ao modificar uma instância para atribuir um grupo de parâmetros de banco de dados diferente.

  • Executar uma solicitação de retrocesso automaticamente retoma a instância do gravador do Aurora Serverless v2 se ela estiver pausada. O Aurora processa a solicitação de retrocesso após a retomada da instância do gravador. Você pode retroceder para um momento em que uma instância do Aurora Serverless v2 estava pausada.

  • Tirar um snapshot do cluster ou excluir um snapshot não retoma nenhuma instância do Aurora Serverless v2.

  • Criar um clone do Aurora faz com que o Aurora retome a instância do gravador do cluster que está sendo clonado.

  • Se uma instância pausada receber muitas solicitações de conexão antes de terminar de ser retomada, algumas sessões talvez não consigam se conectar. Recomendamos implementar a lógica de repetição para conexões com clusters do Aurora que têm algumas instâncias do Aurora Serverless v2 com pausa automática habilitada. Por exemplo, você pode tentar novamente qualquer conexão com falha três vezes.

  • O Aurora pode realizar alguns tipos de pequenas manutenções internas sem ativar uma instância. No entanto, alguns tipos de manutenção que ocorrem durante a janela de manutenção do cluster exigem que o Aurora retome a instância. Quando a manutenção é concluída, a instância é automaticamente pausada novamente se não houver mais atividade após o intervalo especificado.

    nota

    O Aurora não retoma automaticamente uma instância pausada para trabalhos agendados específicos do mecanismo, como os realizados na extensão pg_cron do PostgreSQL ou no programador de eventos do MySQL. Para garantir que esses trabalhos sejam executados, inicie uma conexão com a instância manualmente antes do horário agendado. O Aurora não coloca na fila nenhum trabalho cujo horário agendado ocorra enquanto a instância de banco de dados está pausada. Esses trabalhos são ignorados quando a instância é retomada posteriormente.

  • Se o cluster do Aurora passar por um failover enquanto uma instância do Aurora Serverless v2 estiver pausada automaticamente, o Aurora pode retomar uma instância e, em seguida, promover essa instância para ser o gravador. O mesmo pode acontecer se uma ou mais instâncias de banco de dados forem removidas do cluster enquanto uma instância estiver pausada. Nesse caso, a instância se torna o gravador imediatamente quando é retomada.

  • As operações que alteram as propriedades do cluster também fazem com que todas as instâncias do Aurora Serverless v2 pausadas automaticamente sejam retomadas. Por exemplo, uma instância pausada automaticamente é retomada para operações como:

    • Alterar o intervalo de escalabilidade do cluster.

    • Atualizar a versão do mecanismo do cluster.

    • Descrever ou baixar arquivos de log de uma instância pausada. Você pode examinar dados históricos de log de instâncias pausadas habilitando uploads de log para o CloudWatch e analisando os logs pelo CloudWatch.

Desativar a pausa automática para instâncias do Aurora Serverless v2 em um cluster

Siga o procedimento em Configurar o intervalo de capacidade de Aurora Serverless v2 para um cluster. Para a capacidade mínima, escolha um valor de 0,5 ou maior. Ao desativar o recurso de pausa automática, o intervalo de ociosidade da instância é redefinido. Se você reativar a pausa automática, precisará especificar um novo intervalo de tempo limite.

O exemplo de CLI a seguir mostra como você pode desativar o recurso de pausa automática em um cluster existente do Aurora. A saída describe-db-clusters mostra que o atributo SecondsUntilAutoPause é removido quando a capacidade mínima é definida como um valor diferente de zero. 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 2,
    "MaxCapacity": 80.0
}

Como funciona o recurso de pausa automática do Aurora Serverless v2

Você pode usar as informações a seguir para planejar o uso do recurso de pausa automática. Compreender as circunstâncias em que as instâncias são pausadas, retomadas ou permanecem ativas pode ajudar você a equilibrar as compensações entre disponibilidade, capacidade de resposta e economia de custos.

O que acontece quando as instâncias do Aurora Serverless v2 são pausadas

Quando uma instância de banco de dados do Aurora Serverless v2 faz uma pausa após um período sem conexões:

  • O Aurora começa a pausar a instância após o término do intervalo especificado sem nenhuma conexão com a instância, independentemente de quantas ACUs a instância tenha no momento.

  • O mecanismo de pausa não é instantâneo. Uma instância do Aurora Serverless v2 que está prestes a ser pausada automaticamente pode esperar um pouco para acompanhar todas as alterações no armazenamento do Aurora.

  • As cobranças para essa instância são suspensas. A métrica ServerlessV2Usage tem um valor de 0 enquanto a instância está pausada.

  • O valor do status para a instância não é alterado. O status ainda é exibido como "disponível".

  • A instância para de gravar nos arquivos de log do banco de dados. Ela para de enviar métricas para o CloudWatch, além de registrar 0% para CPUUtilization e ACUUtilization e 0 para ServerlessDatabaseCapacity.

  • O Aurora emite eventos quando uma instância de banco de dados do Aurora Serverless v2 começa e termina a pausa e se o mecanismo de pausa é interrompido ou não é bem-sucedido. Consulte Eventos de instância de banco de dados para obter detalhes sobre esses eventos.

O que acontece quando as instâncias do Aurora Serverless v2 pausadas automaticamente são retomadas

Quando uma instância de banco de dados do Aurora Serverless v2 é retomada após ser pausada automaticamente, as seguintes condições se aplicam:

  • Quaisquer alterações de parâmetros que estão em pending-reboot são aplicadas quando a instância é retomada.

  • O Aurora emite eventos no nível da instância quando cada instância de banco de dados do Aurora Serverless v2 começa a ser retomada, termina de ser retomada e se a instância não puder ser retomada por algum motivo. Consulte Eventos de instância de banco de dados para obter detalhes sobre esses eventos.

  • Todas as conexões solicitadas são estabelecidas após a conclusão da retomada da instância de banco de dados. Como o tempo típico de retomada pode ser de aproximadamente 15 segundos, recomendamos que você ajuste as configurações de tempo limite do cliente para mais de 15 segundos. Por exemplo, nas configurações do driver JDBC, você pode ajustar os valores das configurações connectTimeout e sslResponseTimeout para que sejam acima de 15 segundos.

nota

Se uma instância do Aurora Serverless v2 permanecer pausada por mais de 24 horas, o Aurora pode colocar a instância em uma suspensão mais profunda que demora mais para ser retomada. Nesse caso, o tempo de retomada pode ser de 30 segundos ou mais, aproximadamente equivalente a uma reinicialização da instância. Se o banco de dados tiver períodos de inatividade que durem mais de um dia, recomendamos definir os tempos limite de conexão para 30 segundos ou mais.

Como o faturamento de instâncias funciona para clusters do Aurora Serverless v2 pausados automaticamente

Enquanto uma instância do Aurora Serverless v2 está pausada automaticamente, sua cobrança de instância é zero. A métrica ServerlessV2Usage é zero durante esse período. A AWS ainda cobra pelo armazenamento do Aurora e por outros aspectos do cluster que não estão vinculados a essa instância específica de banco de dados.

Situações em que o Aurora Serverless v2 não faz pausas automáticas

  • Se o valor mínimo da capacidade do cluster de banco de dados for maior que zero ACUs, as instâncias do Aurora Serverless v2 no cluster não serão pausadas automaticamente. Se houver clusters existentes com instâncias do Aurora Serverless v2 de antes da disponibilidade do recurso de pausa automática, a configuração de capacidade mínima mais baixa era de 0,5 ACUs. Para usar o recurso de pausa automática com esses clusters, modifique a configuração de capacidade mínima para zero ACUs.

  • Se alguma conexão iniciada pelo usuário estiver aberta em uma instância do Aurora Serverless v2, a instância não será pausada. A instância também não será pausada enquanto atividades como aplicação de patches e atualizações estiverem em andamento. As conexões administrativas que o Aurora usa para verificações de integridade não são contadas como atividade e não impedem a pausa da instância.

  • Em um cluster do Aurora PostgreSQL com a replicação lógica habilitada, ou em um cluster do Aurora MySQL com replicação de binlog habilitada, a instância do gravador e quaisquer instâncias do leitor nos níveis zero e um de promoção de failover não pausam automaticamente. O Aurora executa uma quantidade mínima constante de atividade para verificar a integridade da conexão de replicação.

    Para clusters com replicação habilitada, é possível ter instâncias do leitor do Aurora no cluster de origem que pausam automaticamente. Para fazer isso, defina a prioridade de failover delas como um valor diferente de zero ou um. Dessa forma, elas podem ser pausadas independentemente da instância do gravador.

  • Caso seu cluster Aurora tenha um proxy RDS associado, o proxy manterá uma conexão aberta com cada instância de banco de dados no cluster. Portanto, nenhuma instância do Aurora Serverless v2 desse cluster será pausada automaticamente.

  • Se o cluster for o principal em um banco de dados global do Aurora, o Aurora não pausará automaticamente a instância do gravador do Aurora Serverless v2. Isso porque é necessário um nível constante de atividade na instância do gravador para gerenciar os outros clusters no banco de dados global. Como a instância do gravador permanece ativa, quaisquer instâncias do leitor do Aurora Serverless v2 com prioridade de failover zero ou um também não são pausadas automaticamente.

  • As instâncias do Aurora Serverless v2 nos clusters secundários de um banco de dados global do Aurora não pausam automaticamente. Se um cluster de banco de dados for promovido a um cluster autônomo, o recurso de pausa automática se tornará efetivo se todas as outras condições forem atendidas.

  • Em um cluster com uma integração ETL zero associada ao Redshift, a instância do gravador e quaisquer instâncias do leitor nos níveis zero e um de promoção de failover não são pausadas automaticamente.

  • Além da atividade na porta principal do banco de dados da instância, se uma instância do Aurora PostgreSQL tiver o recurso Babelfish habilitado, quaisquer conexões e atividades na porta T-SQL evitarão que a instância seja pausada automaticamente.

Como a pausa automática funciona com o recurso interromper/iniciar do cluster

Você pode interromper e iniciar um cluster do Aurora quando o recurso de pausa automática estiver habilitado. Não importa se algumas instâncias estão pausadas. Ao iniciar o cluster novamente, todas as instâncias do Aurora Serverless v2 pausadas são retomadas automaticamente.

Enquanto um cluster do Aurora está interrompido, nenhuma instância do Aurora Serverless v2 pausada é retomada automaticamente com base nas tentativas de conexão. Assim que o cluster é iniciado novamente, os mecanismos normais de pausa e retomada das instâncias do Aurora Serverless v2 se aplicam.

Como a manutenção e as atualizações funcionam para clusters do Aurora Serverless v2 pausados automaticamente

  • Enquanto uma instância do Aurora Serverless v2 está pausada automaticamente, se você tentar atualizar o cluster do Aurora, o Aurora retoma a instância e a atualiza.

  • O Aurora retoma periodicamente todas as instâncias do Aurora Serverless v2 pausadas automaticamente para realizar a manutenção, como pequenas atualizações de versões e alterações em propriedades, como grupos de parâmetros.

  • Depois que uma instância do Aurora Serverless v2 é ativada para uma operação administrativa, como uma atualização ou manutenção, o Aurora espera pelo menos 20 minutos antes de pausar a instância novamente. Isso serve para permitir que quaisquer operações em segundo plano sejam concluídas. O período de 20 minutos também evita pausar e retomar a instância várias vezes se a instância passar por múltiplas operações administrativas em sucessão.

Diferenças no comportamento de pausa automática entre o Aurora Serverless v2 e o Aurora Serverless v1

  • O tempo de retomada é melhorado no Aurora Serverless v2 em comparação com o Aurora Serverless v1. O tempo de retomada é normalmente de cerca de 15 segundos se a instância estiver pausada por menos de 24 horas. Se a instância estiver pausada por mais de 24 horas, o tempo de retomada poderá ser maior.

  • A forma como o Aurora Serverless v2 se aplica aos clusters multi-AZ significa que algumas instâncias de banco de dados no cluster podem ser pausadas enquanto outras estão ativas. A instância do gravador é retomada sempre que algum leitor estiver em execução, porque o gravador é necessário para coordenar determinadas atividades no cluster. Como o Aurora Serverless v1 não usa instâncias do leitor, todo o cluster sempre estaria pausado ou ativo.

  • Quando o endpoint do leitor escolhe aleatoriamente uma instância do leitor à qual se conectar, essa instância do leitor pode já estar ativa ou pausada automaticamente. Assim, o tempo para acessar a instância do leitor pode variar e ser mais difícil de prever. Portanto, os clusters multi-AZ que usam o Aurora Serverless v2 e pausam automaticamente podem se beneficiar da configuração de endpoints personalizados para casos de uso específicos de somente leitura, em vez de direcionar todas as sessões somente leitura para o endpoint do leitor.

  • As instâncias do Aurora Serverless v2 passam por operações de manutenção com a mesma frequência que as instâncias provisionadas. Como o Aurora retoma automaticamente as instâncias quando essa manutenção é necessária, é possível notar que algumas instâncias do Aurora Serverless v2 são retomadas com mais frequências do que os clusters do Aurora Serverless v1 eram retomados.

Como a pausa automática do Aurora Serverless v2 funciona para diferentes tipos de clusters do Aurora

As considerações sobre o recurso de pausa automática dependem de quantas instâncias estão em seu cluster do Aurora, dos níveis de promoção de failover das instâncias do leitor e se todas as instâncias são do Aurora Serverless v2 ou uma combinação de instâncias do Aurora Serverless v2 e provisionadas.

Quando o recurso de pausa automática está habilitado, você pode organizar seu cluster do Aurora para obter o equilíbrio ideal entre alta disponibilidade, resposta rápida e escalabilidade de acordo com seu caso de uso. Você faz isso escolhendo a combinação de instâncias do Aurora Serverless v2, instâncias provisionadas e níveis de promoção de failover para as instâncias de banco de dados em seu cluster.

Os seguintes tipos de configurações demonstram diferentes compensações entre alta disponibilidade e otimização de custos para seu cluster:

  • Para um sistema de desenvolvimento e teste, você pode configurar um cluster de banco de dados de zona de disponibilidade única com uma instância de banco de dados do Aurora Serverless v2. A única instância atende a todas as solicitações de leitura e gravação. Quando o cluster não é usado por intervalos de tempo significativos, a instância de banco de dados é pausada. Nesse ponto, os custos de computação do banco de dados para o cluster também são pausados.

  • Em um sistema que executa uma aplicação em que a alta disponibilidade é uma prioridade, mas o cluster ainda tem períodos em que está totalmente ocioso, é possível configurar um cluster multi-AZ onde as instâncias de banco de dados do gravador e do leitor são do Aurora Serverless v2. Defina a instância do leitor como prioridade de failover zero ou um, desta forma, o gravador e a instância do leitor pausam e retomam ao mesmo tempo. Agora você tem o benefício de um failover rápido enquanto o cluster está ativo. Quando o cluster permanece ocioso por mais tempo do que o limite da pausa automática, as cobranças da instância de banco de dados das duas instâncias são pausadas. Quando o cluster retoma o processamento, a primeira sessão do banco de dados demora um pouco para se conectar.

  • Suponha que seu cluster esteja constantemente ativo com uma quantidade mínima de atividade e exija uma resposta rápida para qualquer conexão. Nesse caso, você pode criar um cluster com mais de uma instância do leitor do Aurora Serverless v2 e dissociar as capacidades de algumas instâncias de leitura do gravador. Especifique a prioridade de failover zero ou uma para a instância do gravador e uma instância do leitor. Especifique pelo menos duas prioridades para as outras instâncias do leitor. Dessa forma, as instâncias do leitor nos níveis de prioridade mais alta podem pausar automaticamente, mesmo enquanto o gravador e um dos leitores permanecem ativos.

    Nesse caso, você pode empregar algumas outras técnicas para garantir que o cluster permaneça continuamente disponível e, ao mesmo tempo, reduzir a escala verticalmente para uma baixa capacidade durante os períodos de inatividade:

    • Você pode usar instâncias provisionadas para o gravador e o leitor de prioridade zero ou um. Dessa forma, duas instâncias de banco de dados nunca pausam automaticamente e estão sempre disponíveis para atender ao tráfego do banco de dados e executar failovers.

    • Você pode configurar um endpoint personalizado que inclua as instâncias do Aurora Serverless v2 nos níveis de prioridade mais alta, mas não o gravador ou os leitores do nível de promoção zero ou um. Dessa forma, é possível direcionar sessões somente leitura que não são sensíveis à latência para os leitores que podem ser pausados automaticamente. Você pode evitar usar o endpoint do leitor para essas solicitações, porque o Aurora pode direcionar as conexões do endpoint do leitor para a instância do leitor sempre ativa ou para uma das instâncias pausadas automaticamente. O uso do endpoint personalizado permite que você direcione conexões para diferentes grupos de instâncias com base em sua preferência por resposta rápida ou por capacidade de ajuste de escala extra.

Como a pausa automática do Aurora Serverless v2 funciona para a instância do gravador em um cluster de banco de dados

Quando um cluster de banco de dados do Aurora contém apenas uma única instância de banco de dados, o mecanismo de pausa e retomada automática da instância de banco de dados é simples. Ele depende apenas da atividade na instância do gravador. É possível definir essa configuração para clusters usados para desenvolvimento e testes ou para executar aplicações em que a alta disponibilidade não é crucial. Observe que, em um cluster de instância única, o Aurora direciona as conexões pelo endpoint do leitor para a instância de banco de dados do gravador. Assim, para um cluster de banco de dados de instância única, tentar se conectar ao endpoint do leitor faz com que a instância de banco de dados do gravador pausada automaticamente seja retomada.

Os seguintes fatores adicionais se aplicam aos clusters do Aurora com várias instâncias de banco de dados:

  • Em um cluster de banco de dados do Aurora, a instância de banco de dados do gravador normalmente é acessada com frequência. Portanto, é possível notar que a instância de banco de dados do gravador permanece ativa, mesmo quando uma ou mais das instâncias de banco de dados do leitor pausam automaticamente.

  • Determinadas atividades nas instâncias de banco de dados do leitor exigem que a instância de banco de dados do gravador esteja disponível. Portanto, as instâncias de banco de dados do gravador não podem ser pausadas até que todas as instâncias do leitor também sejam pausadas. A retomada de qualquer instância do leitor automaticamente retoma a instância do gravador, mesmo que a aplicação não esteja acessando a instância do gravador diretamente.

  • As instâncias do leitor do Aurora Serverless v2 nos níveis zero e um de promoção de failover escalam para manter sua capacidade sincronizada com a instância do gravador. Assim, quando uma instância do gravador do Aurora Serverless v2 é retomada, o mesmo acontece com quaisquer instâncias do leitor do Aurora Serverless v2 que estejam nos níveis de promoção zero ou um.

Como a pausa automática do Aurora Serverless v2 funciona em clusters multi-AZ

Em um cluster de banco de dados do Aurora que contém uma instância do gravador e uma ou mais instâncias de banco de dados do leitor, algumas instâncias de banco de dados do Aurora Serverless v2 podem ser pausadas enquanto outras estão ativas. A instância do gravador e quaisquer instâncias do leitor com prioridade de failover 0 e 1 sempre pausam e são retomadas ao mesmo tempo. As instâncias do leitor com prioridade diferente de 0 ou 1 podem pausar e retomar independentemente das outras instâncias.

Ao usar esse recurso para clusters com várias instâncias do leitor, é possível gerenciar custos sem sacrificar a alta disponibilidade. A instância do gravador e outra uma ou duas instâncias do leitor podem permanecer ativas o tempo todo, enquanto instâncias adicionais do leitor podem pausar quando não são necessárias para lidar com tráfego de leitura de alto volume.

A pausa automática de uma instância do leitor depende se sua capacidade pode escalar de forma independente ou se a capacidade estiver vinculada à capacidade da instância de banco de dados do gravador. Essa propriedade de ajuste de escala depende da prioridade de failover da instância de banco de dados do leitor. Quando a prioridade do leitor é zero ou um, a capacidade do leitor acompanha a capacidade da instância de banco de dados do gravador. Portanto, para permitir que as instâncias de banco de dados do leitor sejam pausadas automaticamente na maior variedade de situações, defina a prioridade para um valor maior que um.

O tempo para retomar uma instância do leitor pode ser um pouco maior do que para retomar uma instância do gravador. Para obter uma resposta mais rápida caso as instâncias possam ser pausadas, conecte-se ao endpoint do cluster.

Como a pausa automática do Aurora Serverless v2 funciona em clusters com instâncias provisionadas

Quaisquer instâncias de banco de dados provisionadas no cluster de banco de dados do Aurora não são pausadas automaticamente. Somente instâncias de banco de dados do Aurora Serverless v2, com a classe de instância db.serverless, podem usar o recurso de pausa automática.

Quando o cluster do Aurora contém qualquer instância de banco de dados provisionada, nenhuma instância do gravador do Aurora Serverless v2 faz uma pausa automática. Isso se deve ao requisito de que a instância do gravador permaneça disponível enquanto quaisquer instâncias do leitor estiverem ativas. O fato de o gravador do Aurora Serverless v2 permanecer ativo também significa que quaisquer instâncias do leitor do Aurora Serverless v2 com prioridade de failover 0 e 1 não pausarão automaticamente em um cluster híbrido que contém instâncias provisionadas.

Monitorar clusters do Aurora que usam a pausa automática

Para monitorar o Aurora, é preciso ter familiaridade com os procedimentos de monitoramento em Monitorar métricas do Amazon Aurora com o Amazon CloudWatch e as métricas do CloudWatch listadas em Referência de métricas do Amazon Aurora. Lembre-se de que há algumas considerações especiais ao monitorar clusters do Aurora que usam o recurso de pausa automática:

  • Pode haver períodos em que as instâncias do Aurora Serverless v2 não estão registrando os dados de log e a maioria das métricas porque as instâncias estão pausadas. As únicas métricas enviadas ao CloudWatch enquanto uma instância está pausada são 0% para CPUUtilization e ACUUtilization, e 0 para ServerlessDatabaseCapacity.

  • É possível verificar se as instâncias do Aurora Serverless v2 estão pausando com mais ou menos frequência do que o esperado. Para fazer isso, verifique com que frequência a métrica ServerlessDatabaseCapacity muda de um valor diferente de zero para zero e por quanto tempo ela permanece zero. Se as instâncias não permanecerem pausadas pelo tempo esperado, não haverá uma grande economia de custos. Se as instâncias pausarem e forem retomadas com mais frequência do que o pretendido, o cluster pode ter uma latência desnecessária ao responder às solicitações de conexão. Para obter informações sobre os fatores que afetam se as instâncias do Aurora Serverless v2 podem pausar e com que frequência, consulte Pré-requisitos e limitações do recurso de pausa automática do Aurora Serverless v2, Situações em que o Aurora Serverless v2 não faz pausas automáticas e Solucionar problemas da pausa automática do Aurora Serverless v2.

  • Você também pode examinar um arquivo de log que registra as operações automáticas de pausa e retomada de uma instância do Aurora Serverless v2. Se uma instância não pausou após o término do intervalo de tempo limite, esse arquivo de log também incluirá o motivo pelo qual a pausa automática não ocorreu. Para ter mais informações, consulte Monitorar a atividade de pausa e retomada do Aurora Serverless v2.

Verificar se uma instância do Aurora Serverless v2 está pausada

Para determinar se uma instância do Aurora Serverless v2 está no estado de pausa, observe a métrica ACUUtilization da instância. Essa métrica tem um valor zero enquanto a instância está pausada.

Enquanto uma instância do Aurora Serverless v2 estiver pausada, seu valor de status ainda é listado como Disponível. O mesmo se aplica quando uma instância pausada do Aurora Serverless v2 está em processo de retomada. Isso ocorre porque você pode se conectar com sucesso a essa instância, mesmo que a conexão sofra um pequeno atraso.

Qualquer métrica relacionada à disponibilidade das instâncias do Aurora considera o período em que a instância está pausada como o tempo em que a instância estava disponível.

Eventos para operações de pausa automática e retomada automática

O Aurora emite eventos para instâncias do Aurora Serverless v2 quando as operações de pausa automática e retomada automática começam, terminam ou são canceladas. Os eventos relacionados ao recurso de pausa automática vão de RDS-EVENT-0370 auto RDS-EVENT-0374. Consulte Eventos de instância de banco de dados para obter detalhes sobre esses eventos.

Como a pausa automática funciona com o Insights de Performance e o Monitoramento aprimorado

Enquanto uma instância do Aurora Serverless v2 está pausada, o Aurora não coleta informações de monitoramento dessa instância por meio do Insights de Performance ou do Monitoramento aprimorado. Quando a instância é retomada, pode haver um breve atraso até o Aurora retomar a coleta dessas informações de monitoramento.

Como o recurso de pausa automática do Aurora Serverless v2 interage com as métricas do Aurora

Enquanto uma instância do Aurora Serverless v2 está pausada, ela não emite a maioria das métricas do CloudWatch nem grava nenhuma informação nos logs do banco de dados. As únicas métricas enviadas ao CloudWatch enquanto uma instância está pausada são 0% para CPUUtilization e ACUUtilization, e 0 para ServerlessDatabaseCapacity.

Quando o CloudWatch está computando estatísticas relacionadas à disponibilidade e ao tempo de atividade da instância ou do cluster, as instâncias do Aurora Serverless v2 são consideradas disponíveis durante o tempo em que estão pausadas.

Ao iniciar uma ação da AWS CLI ou da API do RDS para descrever ou baixar os logs de uma instância pausada do Aurora Serverless v2, a instância é retomada automaticamente para disponibilizar as informações do log.

Exemplo de métricas do CloudWatch

Os exemplos da AWS CLI a seguir mostram como é possível observar como a capacidade de uma instância muda ao longo do tempo. Durante o período, a instância faz uma pausa automática e depois é retomada. Enquanto está pausada, a métrica ServerlessDatabaseCapacity relata um valor zero. Para determinar se a instância foi pausada em algum momento durante o período, verificamos se a capacidade mínima durante esse período foi zero.

O exemplo de Linux a seguir representa uma instância do Aurora Serverless v2 que foi pausada automaticamente por algum tempo. A métrica ServerlessDatabaseCapacity foi amostrada a cada minuto durante um período de três minutos. O valor mínimo de ACU de 0,0 confirma que a instância foi pausada em algum momento durante cada minuto. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:11:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:12:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None

Em seguida, tentamos fazer uma conexão com a instância pausada do Aurora Serverless v2. Neste exemplo, usamos uma senha incorreta intencionalmente para que a tentativa de conexão não seja bem-sucedida. Apesar da falha, a tentativa de conexão faz com que o Aurora retome a instância pausada. 


$ mysql -h my_cluster_endpoint.rds.amazonaws.com -u admin -pwrong-password

ERROR 1045 (28000): Access denied for user 'admin'@'ip_address' (using password: YES)

O exemplo de Linux a seguir demonstra que a instância pausada foi retomada, permaneceu inativa por aproximadamente cinco minutos, e depois voltou ao estado de pausa. A instância foi retomada com uma capacidade de 2,0 ACUs. Então ela aumentou a escala verticalmente levemente, por exemplo, para realizar alguma limpeza interna. Como ela não recebeu nenhuma tentativa de conexão do usuário dentro do período de tempo limite de cinco minutos, ela passou de 4,0 ACUs diretamente para o estado de pausa. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
DATAPOINTS	2.0	2024-08-02T22:14:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:15:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:16:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:17:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:18:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:19:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:20:00+00:00	None

Se o relatório tivesse a intenção de mostrar a rapidez com que a instância aumentou a escala verticalmente para lidar com a workload, poderíamos especificar Maximum para a estatística em vez de Minimum. Para planejamento de capacidade e estimativa de custos, podemos especificar um período mais longo e usar a estatística Average. Dessa forma, poderíamos determinar os valores de capacidade típicos durante períodos de alta atividade, baixa atividade e estado de pausa. Para examinar o comportamento durante os momentos precisos de pausa e retomada, podemos especificar um período de um segundo e examinar um intervalo de tempo menor. Os valores do carimbo de data e hora na saída, como 2024-08-02T22:13:00+00:00, demonstram o formato para especificar parâmetros precisos para as opções --start-time e --end-time.

Solucionar problemas da pausa automática do Aurora Serverless v2

Se você notar que as instâncias do Aurora Serverless v2 não estão pausando com a frequência esperada, verifique as seguintes possíveis causas:

  • Confirme se a versão do Aurora que você está usando é compatível com uma capacidade mínima de zero ACUs. Consulte Capacidade do Aurora Serverless v2 para obter os intervalos de capacidade das diferentes versões do Aurora.

  • Confirme se o valor mínimo da capacidade do cluster está definido como zero ACUs.

  • Confirme se a instância em questão está realmente usando a instância do Aurora Serverless v2 de classe db.serverless, e não uma das classes de instância provisionadas.

  • Confirme se o cluster não está usando nenhum dos recursos ou configurações incompatíveis de Pré-requisitos e limitações do recurso de pausa automática do Aurora Serverless v2.

  • Examine o arquivo de log que mostra quando as instâncias do Aurora Serverless v2 foram pausadas, retomadas ou quando o Aurora não conseguiu pausar ou retomar uma instância por algum motivo. Para ter mais informações, consulte Monitorar a atividade de pausa e retomada do Aurora Serverless v2.

  • Verifique se algum cliente ou aplicação está mantendo as conexões abertas por longos períodos de tempo. Por outro lado, verifique se alguma aplicação que usa a API de dados do RDS ou as funções do Lambda está enviando solicitações frequentes para que a instância nunca fique ociosa por tempo suficiente para pausar. Você pode examinar as métricas do CloudWatch, como ConnectionAttempts e DatabaseConnections. Para ter mais informações, consulte Métricas no nível da instância do Amazon Aurora.

  • Se uma instância do leitor raramente pausar, verifique sua prioridade de failover. Se o leitor for usado para ajuste de escala de leitura e não como em espera em caso de failover, defina-o com uma prioridade na faixa de 2 a 15.

  • Se a instância do gravador raramente pausar, verifique o uso das instâncias do leitor. O gravador só pode pausar se todo o cluster estiver ocioso. Isso ocorre porque uma conexão com qualquer instância do leitor faz com que o gravador retome.

  • Se sua aplicação atingir os tempos limite durante as solicitações de conexão enquanto as instâncias do Aurora Serverless v2estão retomando, considere aumentar o intervalo de tempo limite usado pelo código da aplicação ou pela estrutura de banco de dados subjacente. Tempos limite de conexão mais longos reduzem a possibilidade de falhas nas conexões enquanto as instâncias do Aurora Serverless v2 estão sendo retomadas. No entanto, os tempos limite mais longos também podem tornar a aplicação mais lenta para detectar problemas de disponibilidade no cluster.

    Por outro lado, considere aumentar o intervalo de pausa automática para que as aplicações não encontrem instâncias pausadas com tanta frequência.

    Se não houver um equilíbrio lógico entre o comportamento de pausa automática e a responsividade do cluster para a aplicação, esse cluster pode não ser um bom candidato para usar o recurso de pausa automática.

  • Se você estimar por quanto tempo as instâncias do Aurora Serverless v2 ficarão pausadas, é preciso ter em mente que há fatores que tornam impraticável fazer previsões precisas.

    • As instâncias podem retomar periodicamente para realizar manutenção, atualizações de versões menores ou aplicar alterações em grupos de parâmetros.

    • Para clusters multi-AZ, há situações em que a retomada de uma instância faz com que outras instâncias também retomem. Retomar qualquer leitor sempre faz com que o escritor retome. Retomar o escritor sempre faz com que quaisquer leitores com prioridade de failover 0 e 1 retomem.

    Recomendamos medir o tempo real de pausa em um período de vários dias, com uma workload realista. Em seguida, use essas medições para definir uma linha de base para a proporção de tempo em que você pode esperar que uma instância esteja pausada.

  • Operações internas, como a limpeza do MySQL, o agendador de eventos do MySQL, o autovacuum do PostgreSQL ou trabalhos do PostgreSQL agendados por meio da extensão pg_cron, não estão em execução ou não estão sendo concluídos. A instância não é retomada automaticamente para realizar essas operações que não envolvem uma conexão do usuário com o banco de dados. Se essas operações internas estiverem em andamento quando o tempo limite da pausa automática expirar, tarefas de manutenção, como a limpeza do MySQL e o autovacuum do PostgreSQL, serão canceladas. Os trabalhos agendados pelo agendador de eventos do MySQL ou pela extensão pg_cron do PostgreSQL também são cancelados se estiverem em andamento quando o Aurora iniciar a operação de pausa.

    Se for necessário garantir que a instância seja ativada periodicamente para realizar operações agendadas, é possível iniciar uma conexão para retomar a instância antes do horário de início do trabalho. Também é possível aumentar o intervalo de tempo limite da pausa automática para que operações como o autovacuum possam ser executadas por mais tempo após o término da atividade do usuário. Você também pode usar mecanismos como as funções do Lambda para realizar operações de banco de dados em um cronograma, de forma que a instância seja retomada automaticamente, se necessário.

Considerações sobre o design da aplicação para o recurso de pausa automática do Aurora Serverless v2

Quando uma instância de banco de dados do Aurora Serverless v2 é retomada após ser pausada automaticamente, ela começa com uma capacidade relativamente pequena e aumenta a escala verticalmente. Essa capacidade inicial se aplica mesmo que a instância de banco de dados tenha tido uma capacidade maior imediatamente antes de ser pausada automaticamente.

Use esse recurso com aplicações que podem tolerar um intervalo de aproximadamente 15 segundos ao estabelecer uma conexão. Isso leva em consideração o caso típico em que uma instância do Aurora Serverless v2 é retomada devido a uma ou a um pequeno número de conexões de entrada. Se a instância estiver pausada por mais de 24 horas, o tempo para retomada poderá ser maior.

Se a aplicação já estava usando o Aurora Serverless v1 e o recurso de pausa automática, talvez já existam intervalos de tempo limite habilitados para tentativas de conexão. Se você já estiver usando o Aurora Serverless v2 em combinação com o recurso interromper/iniciar de cluster, o tempo de retomada para instâncias do Aurora Serverless v2 pausadas automaticamente é geralmente muito menor do que o tempo para iniciar um cluster que está parado.

Ao codificar a lógica de conexão na aplicação, tente a conexão novamente se a primeira tentativa retornar um erro que tenha uma causa transitória. (Se o erro for devido a uma falha de autenticação, corrija as credenciais antes de tentar novamente.) Um erro que ocorre imediatamente após a retomada pode ser um erro de tempo limite ou algum erro relacionado aos limites do banco de dados. Tentar novamente pode lidar com problemas nos casos mais raros em que uma instância do Aurora Serverless v2 é retomada devido a muitas solicitações de conexão simultâneas. Nesse caso, algumas conexões podem levar mais tempo do que o normal para serem processadas ou podem exceder o limite de conexões simultâneas na primeira tentativa.

Durante o desenvolvimento e a depuração da aplicação, não deixe sessões de cliente ou ferramentas de programação com conexões abertas ao banco de dados. O Aurora não pausará uma instância se houver quaisquer conexões abertas iniciadas pelo usuário, independentemente de as conexões não estarem executando nenhuma instrução ou transação SQL. Quando uma instância do Aurora Serverless v2 em um cluster do Aurora não pode pausar, outras instâncias no cluster também podem ser impedidas de pausar. Para ter mais informações, consulte Situações em que o Aurora Serverless v2 não faz pausas automáticas.

O Aurora emite eventos quando uma instância de banco de dados do Aurora Serverless v2 começa a retomar, termina de retomar e se a instância não puder retomar por algum motivo. Consulte Eventos de instância de banco de dados para obter detalhes sobre esses eventos.