Como o Aurora Serverless v1 funciona - Amazon Aurora

Como o Aurora Serverless v1 funciona

O Amazon Aurora oferece dois modos de mecanismo de banco de dados diferentes destinados a dois modelos de uso amplamente diferentes.

O modo de mecanismo de banco de dados provisionado foi projetado para workloads previsíveis. Quando você trabalha com clusters de banco de dados do Aurora provisionados, você escolhe o tamanho da classe da instância de banco de dados e várias outras opções de configuração. Por exemplo, você pode criar uma ou mais réplicas do Aurora para aumentar a taxa de transferência de leitura. Se a workload for alterada, você poderá modificar o tamanho da classe da instância do banco de dados e alterar o número de réplicas do Aurora. O modelo provisionado funciona bem quando você pode ajustar a capacidade antes dos padrões de consumo esperados.

O modo de mecanismo de banco de dados sem servidor foi projetado para um padrão de uso diferente inteiramente. Por exemplo, o uso do banco de dados pode ser pesado por um curto período de tempo, seguido por longos períodos de atividade leve ou nenhuma atividade. Alguns exemplos são sites de varejo com eventos de vendas intermitentes, bancos de dados que produzem relatórios quando necessário, ambientes de desenvolvimento e teste e novos aplicativos com requisitos incertos. Para casos como esses e muitos outros, configurar a capacidade corretamente antecipadamente nem sempre é possível com o modelo provisionado. Também pode resultar em custos mais elevados se você provisionar em excesso e tem capacidade que você não usa.

Usando o Aurora Serverless v1, é possível criar um endpoint de banco de dados sem especificar o tamanho da classe da instância de banco de dados. Você especifica apenas o intervalo mínimo e máximo para a capacidade do cluster de banco de dados do Aurora Serverless v1. O endpoint do banco de dados do Aurora Serverless v1 compõe uma frota de roteadores que suporta conexões contínuas e distribui a workload entre os recursos. O Aurora Serverless v1 dimensiona os recursos automaticamente com base em suas especificações de capacidade mínima e máxima.

Não é necessário alterar o código da aplicação cliente de seu banco de daos para usar a frota de roteadores. O Aurora Serverless v1 gerencia as conexões automaticamente. O escalonamento é rápido graças a um grupo de recursos “quente” que está sempre pronto para atender solicitações. O armazenamento e o processamento são separados, portanto, seu cluster de banco de dados do Aurora Serverless v1 pode ser reduzido para zero quando terminar o processamento de workloads. Quando o cluster de banco de dados do Aurora Serverless v1 é dimensionado para zero, você será cobrado apenas pelo armazenamento.

Aurora Serverless v1Arquitetura do

A imagem a seguir mostra uma visão geral da arquitetura do Aurora Serverless v1.


                  Aurora Serverless v1Arquitetura do

Em vez de provisionar e gerenciar servidores de banco de dados, você especifica capacity units (ACUs - unidades de capacidade) do Aurora. Cada ACU é uma combinação de aproximadamente 2 gigabytes (GB) de memória, CPU correspondente e rede. O armazenamento do banco de dados escala automaticamente de 10 gibibytes (GiB) para 128 tebibytes (TiB), o mesmo que o armazenamento em um cluster de banco de dados padrão do Aurora.

Você pode especificar as ACUs mínima e máxima. A unidade de capacidade mínima do Aurora é a ACU mais baixa para a qual o cluster de banco de dados pode ser reduzido. A unidade de capacidade máxima do Aurora é a ACU mais alta para a qual o cluster de banco de dados pode ser expandido. Com base em suas configurações, o Aurora Serverless v1 cria automaticamente as regras de escalabilidade para os limites de utilização de CPU, conexões e memória disponível.

O Aurora Serverless v1 gerencia o grupo quente de recursos em uma região da AWS para minimizar o tempo de escalabilidade. Quando o Aurora Serverless v1 adiciona recursos ao cluster de banco de dados do Aurora, ele usa a frota de roteadores para alternar as conexões de clientes ativas para os novos recursos. Em algum momento específico, você será cobrado somente pelas ACUs que estão sendo usadas ativamente em seu cluster de banco de dados Aurora.

Autoscaling for Aurora Serverless v1

A capacidade alocada para o cluster de banco de dados do Aurora Serverless v1 é expandida ou reduzida perfeitamente com base na carga gerada pela aplicação cliente. Aqui, a carga é a utilização da CPU e a quantidade de conexões. Quando a capacidade é limitada por qualquer um desses, o Aurora Serverless v1 se expande. O Aurora Serverless também se expande quando detecta problemas de performance que podem ser resolvidos ao fazê-lo.

Você pode visualizar eventos de dimensionamento para o seu cluster do Aurora Serverless no AWS Management Console. Durante a escalabilidade automática, o Aurora Serverless v1 redefine a métrica EngineUptime. O valor da métrica de redefinição não significa que o dimensionamento contínuo tenha problemas nem que o Aurora Serverless perdeu suas conexões. É simplesmente o ponto de partida para o tempo de atividade na nova capacidade. Para saber mais sobre as métricas, consulte Métricas Amazon Aurora de monitoramento com Amazon CloudWatch.

Quando o seu cluster de banco de dados do Aurora Serverless v1 não tem conexões ativas, ele pode reduzir até a capacidade zero (0 ACUs). Para saber mais, consulte Pausa e retomada para o Aurora Serverless v1.

Quando é preciso executar uma operação de dimensionamento, o Aurora Serverless v1 primeiro tenta identificar um ponto de dimensionamento, um momento em que nenhuma consulta esteja em processamento. O Aurora Serverless talvez não consiga encontrar um ponto de dimensionamento pelos seguintes motivos:

  • Consultas de longa duração

  • Transações em andamento

  • As tabelas temporárias ou bloqueios de tabela estão em uso

Para aumentar a taxa de sucesso em encontrar um ponto de dimensionamento do seu cluster de banco de dados Aurora Serverless, recomendamos evitar consultas e transações de longa duração. Para saber mais sobre operações que impedem o dimensionamento e como evitá-las, consulte Best practices for working with Amazon Aurora Serverless.

Por padrão, o Aurora Serverless v1 tenta encontrar um ponto de escalabilidade por cinco minutos (300 segundos). É possível especificar um período de tempo limite diferente ao criar ou modificar o cluster. O tempo limite pode ter entre 60 segundos e 10 minutos (600 segundos). Se o Aurora Serverless não conseguir encontrar um ponto de escalabilidade no período especificado, o tempo limite da operação de autoescalabilidade é excedido.

Por padrão, se a autoescalabilidade não encontrar um ponto de escalabilidade antes do tempo limite, o Aurora Serverless v1 manterá o cluster na capacidade atual. Você pode alterar esse comportamento padrão ao criar ou modificar o seu cluster de banco de dados do Aurora Serverless selecionando a opção Force the capacity change (Forçar a alteração da capacidade). Para obter mais informações, consulte . Ação de tempo limite para alterações na capacidade.

Ação de tempo limite para alterações na capacidade

Se a autoescalabilidade ultrapassar o tempo limite sem encontrar um ponto de escalabilidade, por padrão, o Aurora manterá a capacidade atual. Você pode optar por deixar o Aurora forçar a mudança habilitando a opção Force the capacity change (Forçar a mudança de capacidade). Essa opção está disponível na seção Autoscaling timeout and action (Tempo limite e ação de autoescalabilidade) da página Create database (Criar banco de dados), quando você cria o cluster.

  • [ ] Force the capacity change ([ ] Forçar a mudança de capacidade): por padrão, esta opção está desmarcada. Deixe-a desmarcada para que a capacidade do seu cluster de banco de dados do Aurora Serverless permaneça inalterada, se a operação de dimensionamento ultrapassar o tempo limite sem encontrar um ponto de dimensionamento.

  • [X] Force the capacity change ([X] Forçar a mudança de capacidade): escolher esta opção faz com que o cluster de bando de dados do Aurora Serverless imponha a alteração de capacidade, mesmo sem um ponto de dimensionamento. Antes de habilitar esta opção, esteja ciente das consequências dessa escolha.

    • Quaisquer transações em andamento são interrompidas e a seguinte mensagem de erro é exibida.

      Aurora MySQL 5.6ERROR 1105 (HY000): The last transaction was aborted due to an unknown error. Please retry.

      Aurora MySQL 5.7ERROR 1105 (HY000): The last transaction was aborted due to Seamless Scaling. Please retry.

      Você pode reenviar as transações assim que seu cluster de banco de dados do Aurora Serverless v1 estiver disponível.

    • As conexões com tabelas temporárias e bloqueios são descartadas.

nota

Recomendamos que você escolha a opção “force” (forçar) somente se sua aplicação puder se recuperar de conexões descartadas ou transações incompletas.

As escolhas que você faz no AWS Management Console ao criar um cluster de banco de dados do Aurora Serverless são armazenadas no objeto ScalingConfigurationInfo, nas propriedades SecondsBeforeTimeout e TimeoutAction. O valor da propriedade TimeoutAction é definido como um dos seguintes valores quando você cria o cluster:

  • RollbackCapacityChange: este valor é definido quando você escolhe a opção Roll back the capacity change (Reverter a alteração na capacidade). Esse é o comportamento padrão.

  • ForceApplyCapacityChange: este valor é definido quando você escolhe a opção Force the capacity change (Forcar a alteração da capacidade).

Você pode obter o valor dessa propriedade em um cluster de banco de dados do Aurora Serverless existente usando o comando describe-db-clusters da AWS CLI, como mostrado a seguir.

Para Linux, macOS ou Unix:

aws rds describe-db-clusters --region region \ --db-cluster-identifier your-cluster-name \ --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

Para Windows:

aws rds describe-db-clusters --region region ^ --db-cluster-identifier your-cluster-name ^ --query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"

O exemplo a seguir mostra a consulta e a resposta de um cluster de banco de dados do Aurora Serverless v1 chamado west-coast-sles na região Oeste dos EUA (Norte da Califórnia).

$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}' [ { "ScalingConfigurationInfo": { "MinCapacity": 1, "MaxCapacity": 64, "AutoPause": false, "SecondsBeforeTimeout": 300, "SecondsUntilAutoPause": 300, "TimeoutAction": "RollbackCapacityChange" } } ]

Como mostra a resposta, esse cluster de banco de dados do Aurora Serverless v1 usa a configuração padrão.

Para obter mais informações, consulte Criar um cluster de banco de dados do Aurora Serverless v1. Após criar seu Aurora Serverless v1, você também pode modificar a ação de tempo limite e outras configurações de capacidade a qualquer momento. Para saber como, consulte Modificar um cluster de banco de dados do Aurora Serverless v1.

Pausa e retomada para o Aurora Serverless v1

É possível escolher pausar o cluster de banco de dados do Aurora Serverless v1 depois de um certo tempo sem atividade. Você especifica o tempo sem atividade para que o cluster de banco seja pausado. Ao selecionar essa opção, o tempo de inatividade padrão é cinco minutos, mas é possível alterar esse valor. Esta definição é opcional.

Quando o cluster de banco é pausado, não ocorre nenhuma atividade de computação ou de memória, e você é cobrado somente pelo armazenamento. Se forem solicitadas conexões ao banco de dados quando um cluster de banco de dados do Aurora Serverless estiver pausado, o cluster de banco de dados será retomado automaticamente e atenderá às solicitações de conexão.

Quando o cluster de banco de dados retoma a atividade, ele tem a mesma capacidade que tinha quando o Aurora pausou o cluster. O número de ACUs depende de quanto o Aurora expandiu ou reduziu o cluster antes de pausá-lo.

nota

Se um cluster de banco de dados for pausado por mais de sete dias, o backup do cluster de banco de dados poderá ser feito com um snapshot. Nesse caso, o Aurora restaura o cluster de banco de dados do snapshot quando há uma solicitação de conexão.

Grupos de parâmetros e Aurora Serverless v1

Quando você cria o seu cluster de banco de dados do Aurora Serverless v1, você escolhe um mecanismo de banco de dados do Aurora específico e um grupo de parâmetros de cluster de banco de dados associado. Ao contrário dos clusters de banco de dados do Aurora provisionado, um cluster de banco de dados do Aurora Serverless tem uma única instância de banco de dados de leitura/gravação configurada apenas com um grupo de parâmetros de cluster de banco de dados. Ele não tem um grupo de parâmetros de banco de dados separado. Durante o dimensionamento automático, o Aurora Serverless precisa ser capaz de alterar os parâmetros para que o cluster funcione melhor com a capacidade aumentada ou reduzida. Assim, com um cluster de banco de dados do Aurora Serverless, algumas das alterações que você pode fazer nos parâmetros para um determinado tipo de mecanismo de banco de dados podem não se aplicar.

Por exemplo, um cluster de banco de dados do Aurora Serverless baseado no Aurora PostgreSQL não pode usar apg_plan_mgmt.capture_plan_baselines e outros parâmetros para gerenciamento de planos de consulta que podem ser usados em clusters de banco de dados do Aurora PostgreSQL provisionados.

Você pode obter uma lista de valores padrão para os grupos de parâmetros padrão dos vários mecanismos de banco de dados do Aurora usando o comando da CLI describe-engine-default-cluster-parameters e consultando a região da AWS. A seguir estão os valores que você pode usar para a opção --db-parameter-group-family.

Aurora MySQL 5.6

aurora5.6

Aurora MySQL 5.7

aurora-mysql5.7

Aurora PostgreSQL 10.12 (e posterior)

aurora-postgresql10

Recomendamos que você configure a AWS CLI com o seu ID de chave de acesso da AWS e a chave de acesso secreta da AWS, além de definir a sua Região da AWS antes de usar os comandos da AWS CLI. Fornecer a região a sua configuração de CLI torna desnecessário inserir o parâmetro --region ao executar comandos. Para saber mais sobre como configurar a AWS CLI, consulte Configuration basics (Noções básicas de configuração) no Manual do usuário da AWS Command Line Interface.

O exemplo a seguir obtém uma lista de parâmetros do grupo de cluster de banco de dados padrão para Aurora MySQL 5.6.

Para Linux, macOS ou Unix:

aws rds describe-engine-default-cluster-parameters \ --db-parameter-group-family aurora5.6 --query \ 'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \ --output text

Para Windows:

aws rds describe-engine-default-cluster-parameters ^ --db-parameter-group-family aurora5.6 --query ^ "EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^ --output text

Modificação de valores de parâmetro para o Aurora Serverless v1

Como explicado em Como trabalhar com grupos de parâmetros de banco de dados e grupos de parâmetros de cluster de banco de dados, você não pode alterar diretamente os valores em um grupo de parâmetros padrão, independentemente do tipo (grupo de parâmetros de cluster de banco de dados, grupo de parâmetros de banco de dados). Em vez disso, você cria um grupo de parâmetros personalizado com base no grupo de parâmetros do cluster de banco de dados padrão para o seu mecanismo de banco de dados do Aurora e altera as configurações nesse grupo de parâmetros, conforme necessário. Por exemplo, você pode querer alterar algumas das configurações do cluster de banco de dados do Aurora Serverless para consultas de log do ou para fazer upload de logs específicos do mecanismo de banco de dados para o Amazon CloudWatch.

Para criar um grupo de parâmetros de cluster de banco de dados personalizado

  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. Selecione Grupos de parâmetros.

  3. Escolha Create parameter group (Criar grupo de parâmetros) para abrir o painel Parameter group details (Detalhes do grupo de parâmetros).

  4. Escolha o grupo de cluster de banco de dados padrão apropriado para o mecanismo de banco de dados que você deseja usar para seu cluster de banco de dados do Aurora Serverless v1. Certifique-se de escolher as seguintes opções:

    1. Para Parameter group family (Família de grupo de parâmetros), escolha a família apropriada para o mecanismo de banco de dados escolhido. Certifique-se de que sua seleção tem o prefixo aurora- em seu nome.

    2. Em Type (Tipo), escolha DB Cluster Parameter Group (Grupo de parâmetros do cluster de banco de dados).

    3. Em Group name (Nome do grupo) e Description (Descrição), insira nomes significativos para você ou outras pessoas que possam precisar trabalhar com seu cluster de banco de dados do Aurora Serverless v1 e respectivos parâmetros.

    4. Escolha Create (Criar).

Seu grupo de parâmetros de cluster de banco de dados personalizado é adicionado à lista de grupos de parâmetros disponíveis para sua conta na sua Região da AWS. Você pode usar seu grupo de parâmetros de cluster de banco de dados personalizado ao criar novos clusters de banco de dados do Aurora Serverless e pode modificar um cluster de banco de dados do Aurora Serverless para usar seu grupo de parâmetros do cluster de banco de dados personalizado. Uma vez que o cluster de banco de dados do Aurora Serverless começa a usar seu grupo de parâmetros do cluster de banco de dados personalizado, você pode alterar valores para parâmetros dinâmicos usando o AWS Management Console ou a AWS CLI. Você também pode usar o console para exibir uma comparação lado a lado entre os valores no seu grupo de parâmetros do cluster de banco de dados personalizado e no cluster de banco de dados padrão, conforme mostrado na captura de tela a seguir.


          Logs publicados no CloudWatch Logs para clusters de banco de dados do Aurora Serverless v1 para Aurora MySQL e Aurora PostgreSQL

Quando você altera valores de parâmetros em um cluster de banco de dados ativo, o Aurora Serverless inicia um dimensionamento perfeito para aplicar as alterações de parâmetros. Se o seu cluster de banco de dados do Aurora Serverless estiver em um estado “pausado”, ele retomará e começará a dimensionar para que possa fazer a alteração. A operação de dimensionamento para uma alteração de grupo de parâmetros sempre força a mudança de capacidade, portanto esteja ciente de que a modificação de parâmetros pode resultar em conexões descartadas se um ponto de dimensionamento não puder ser encontrado durante o período de dimensionamento.

Registro em log para o Aurora Serverless v1

Por padrão, logs de erros para o Aurora Serverless são ativados e carregados automaticamente no Amazon CloudWatch. Você também pode fazer com que seu cluster de banco de dados do Aurora Serverless carregue logs específicos do mecanismo de banco de dados do Aurora no CloudWatch ativando parâmetros de configuração no seu grupo de parâmetros do cluster de banco de dados personalizado. O seu cluster de banco de dados do Aurora Serverless carrega todos os logs disponíveis no Amazon CloudWatch e você pode usar o CloudWatch para analisar dados de log, criar alarmes e visualizar métricas.

Para o Aurora MySQL, você pode habilitar os seguintes logs para que sejam carregados automaticamente no Amazon CloudWatch a partir do seu cluster de banco de dados do Aurora Serverless.

Aurora MySQL Descrição

general_log

Cria o log geral. Defina como 1 para ativar. O padrão é desativado (0).

log_queries_not_using_indexes

Registra todas as consultas no log de consultas lentas que não usam um índice. O padrão é desativado (0). Defina como 1 para ativar esse log.

long_query_time

Impede que consultas em execução rápida sejam registradas no log de consultas lentas. Pode ser definido como um float entre 0 e 31536000. O padrão é 0 (não ativo).

server_audit_events

A lista de eventos a serem capturados nos logs. Os valores compatíveis são CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML e TABLE.

server_audit_logging

Defina como 1 para ativar o log de auditoria do servidor. Se você ativar isso, você poderá especificar os eventos de auditoria a serem enviados, CloudWatch listando-os no server_audit_events parâmetro.

slow_query_log

Cria um log de consulta lento. Defina como 1 para ativar o log de consulta lenta. O padrão é desativado (0).

Para obter mais informações, consulte Como usar a Auditoria avançada em um cluster de banco de dados Amazon Aurora MySQL.

Para o Aurora PostgreSQL, você pode habilitar os seguintes logs no cluster de banco de dados do Aurora Serverless e enviá-los automaticamente para o Amazon CloudWatch, juntamente com os logs de erros regulares.

Aurora PostgreSQL Descrição

log_connections

Ativado por padrão e não pode ser alterado. Ele registra detalhes para todas as novas conexões de clientes.

log_disconnections

Ativado por padrão e não pode ser alterado. Registra todas as desconexões de clientes.

log_lock_waits

O padrão é 0 (desativado). Defina como 1 para registrar esperas por bloqueio.

log_min_duration_statement

A duração mínima (em milissegundos) para que uma instrução seja executada antes de ser registrada.

log_min_messages

Define os níveis de mensagem registrados. Os valores compatíveis são debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. Para registrar dados de performance no log do postgres, defina o valor como debug1.

log_temp_files

Registra o uso de arquivos temporários que estão acima dos kilobytes (kB) especificados.

log_statement

Controla as instruções SQL específicas que são registradas. Os valores compatíveis são none, ddl, mod e all. O padrão é none.

Depois de habilitar os logs para Aurora MySQL 5.6, Aurora MySQL 5.7 ou Aurora PostgreSQL para o cluster de banco de dados do Aurora Serverless, você pode visualizá-los no CloudWatch.

Visualizar logs do Aurora Serverless v1 com o Amazon CloudWatch

O Aurora Serverless v1 carrega automaticamente (“publica”) no Amazon CloudWatch todos os logs que estão ativados em seu grupo de parâmetros de cluster de banco de dados personalizado. Você não precisa escolher ou especificar os tipos de log. O upload de logs começa assim que você habilita o parâmetro de configuração de log. Se, mais tarde, você desabilitar o parâmetro de log, os uploads serão interrompidos. No entanto, todos os logs que já foram publicados no CloudWatch permanecem até que você os exclua.

Para mais informações sobre como usar o CloudWatch com os logs do Aurora MySQL, consulte Monitorar eventos de log no Amazon CloudWatch.

Para obter mais informações sobre CloudWatch e Aurora PostgreSQL, consulte Publicar logs do Aurora PostgreSQL no Amazon CloudWatch Logs.

Para exibir logs do cluster de banco de dados do Aurora Serverless

  1. Abra o console do CloudWatch em https://console.aws.amazon.com/cloudwatch/.

  2. Escolha a sua Região da AWS.

  3. Escolha Grupos de logs.

  4. Escolha o log do cluster de banco de dados do Aurora Serverless na lista. Para logs de erros, o padrão de nomenclatura é o seguinte.

    /aws/rds/cluster/cluster-name/error

Por exemplo, na captura de tela a seguir, você pode encontrar listagens para logs publicados para um cluster de banco de dados do Aurora Serverless para Aurora PostgreSQL chamado "western-sles". Você também pode encontrar várias listas para cluster de banco de dados do Aurora Serverless para Aurora MySQL, "west-coast-sles". Escolha o log de interesse para começar a explorar seu conteúdo.


                    Logs publicados no CloudWatch Logs para clusters de banco de dados do Aurora Serverless v1 para Aurora MySQL e Aurora PostgreSQL

Aurora Serverless v1 e manutenção

A manutenção do cluster de banco de dados do Aurora Serverless v1, como a aplicação dos recursos, correções e atualizações de segurança mais recentes, é realizada automaticamente para você. Ao contrário dos clusters de banco de dados do Aurora provisionados, o Aurora Serverless não tem janelas de manutenção configuráveis pelo usuário. No entanto, ele tem uma janela de manutenção que você pode visualizar no AWS Management Console, em Maintenance & backups (Manutenção e backups) para seu cluster de banco de dados do Aurora Serverless. Você pode encontrar a data e a hora em que a manutenção pode ser executada e se alguma manutenção está pendente para o cluster de banco de dados do Aurora Serverless, conforme mostrado a seguir.


              Janela de manutenção para um exemplo de cluster de banco de dados do Aurora Serverless, não configurável pelo usuário, sem manutenção pendente

Sempre que possível, o Aurora Serverless realiza a manutenção sem causar interrupções. Quando a manutenção é necessária, o cluster de banco de dados do Aurora Serverless dimensiona sua capacidade para lidar com as operações necessárias. Antes de dimensionar, o Aurora Serverless procura um ponto de dimensionamento, e o faz por até sete dias, se necessário.

No fim de cada dia em que o Aurora Serverless não consegue encontrar um ponto de dimensionamento, ele cria um evento de cluster. Esse evento notifica você sobre a manutenção pendente e a necessidade de dimensionar para executar a manutenção. A notificação inclui a data em que o Aurora Serverless pode forçar o cluster de banco de dados a dimensionar.

Até esse momento, seu cluster de banco de dados do Aurora Serverless continua procurando um ponto de dimensionamento e se comporta de acordo com sua configuração de TimeoutAction. Ou seja, se ele não conseguir encontrar um ponto de dimensionamento antes do tempo limite, ele abandona a mudança de capacidade se estiver configurado para RollbackCapacityChange. Ou força a mudança se estiver definido para ForceApplyCapacityChange. Tal como acontece com qualquer alteração que seja forçada sem um ponto de escala apropriado, isso pode interromper sua workload.

Para obter mais informações, consulte Ação de tempo limite para alterações na capacidade.

Aurora Serverless v1 e failover

Se a instância de banco de dados de um cluster de banco de dados do Aurora Serverless v1 ficar indisponível ou a zona de disponibilidade (AZ) em que ela está estiver com falha, o Aurora recriará a instância de banco de dados em uma AZ diferente. Nos referimos a esse recurso como failover automático multi-AZ.

Esse mecanismo de failover leva mais tempo do que um cluster provisionado do Aurora. O tempo de failover do Aurora Serverless v1 é indefinido no momento, porque depende da demanda e da disponibilidade da capacidade em outras AZs da região da AWS indicada.

Como o Aurora separa a capacidade computacional e o armazenamento, o volume de armazenamento do cluster é distribuído em várias AZs. Seus dados permanecem disponíveis mesmo que as interrupções afetem a instância de banco de dados ou a AZ associada.

Aurora Serverless v1 e snapshots

O volume do cluster de um cluster do Aurora Serverless v1 é sempre criptografado. É possível escolher a chave de criptografia, mas não é possível desabilitar a criptografia. Para copiar ou compartilhar um snapshot de um cluster do Aurora Serverless v1, criptografe o snapshot usando a sua própria AWS KMS key. Para obter informações, consulte Copiar um snapshot do cluster de banco de dados. Para saber mais sobre a criptografia e o Amazon Aurora, consulte Criptografar recursos do Amazon Aurora.