Migrar para o Aurora Serverless v2 - Amazon Aurora
Usar o Aurora Serverless v2 com um cluster existenteAlternar de um cluster provisionadoComparação entre o Aurora Serverless v2 e o Aurora Serverless v1Atualizar a partir do Aurora Serverless v1 para o Aurora Serverless v2Migrar de um banco de dados on-premises para o Aurora Serverless v2

Migrar para o Aurora Serverless v2

Para converter um cluster de banco de dados existente para usar o Aurora Serverless v2, é possível fazer o seguinte:

  • Realizar upgrade usando um cluster de banco de dados provisionado do Aurora.

  • Realizar a atualização a partir de um cluster do Aurora Serverless v1.

  • Migrar de um banco de dados on-premises para um cluster do Aurora Serverless v2.

Quando o cluster atualizado estiver executando a versão do mecanismo apropriada, conforme listado em Requisitos e limitações do Aurora Serverless v2, você poderá começar a adicionar instâncias de banco de dados do Aurora Serverless v2 a ele. A primeira instância de banco de dados adicionada ao cluster atualizado deve ser uma instância de banco de dados provisionada. Depois, você pode alternar o processamento para a workload de gravação, a workload de leitura ou ambas para as instâncias de banco de dados do Aurora Serverless v2.

nota

Esses tópicos descrevem como converter um cluster de banco de dados existente. Para obter informações sobre como criar um cluster de banco de dados do Aurora Serverless v2, consulte Criar um cluster de banco de dados que usa o Aurora Serverless v2.

Atualizar ou alternar clusters existentes para usar o Aurora Serverless v2

Se o cluster provisionado tiver uma versão do mecanismo que seja compatível com o Aurora Serverless v2, alternar para o Aurora Serverless v2 não exigirá atualização. Nesse caso, você pode adicionar instâncias de banco de dados do Aurora Serverless v2 ao cluster original. Você pode alternar o cluster para usar todas as instâncias de banco de dados do Aurora Serverless v2. Também é possível usar uma combinação de Aurora Serverless v2 e instâncias de banco de dados provisionadas no mesmo cluster de banco de dados. Sobre as versões do mecanismo do Aurora que são compatíveis com o Aurora Serverless v2, consulte Regiões e mecanismos de banco de dados do Aurora compatíveis com o Aurora Serverless v2.

Se você estiver executando uma versão inferior do mecanismo que não seja compatível com o Aurora Serverless v2, realize estas etapas gerais:

  1. Atualize o cluster.

  2. Crie uma instância de banco de dados do gravador provisionada para o cluster atualizado.

  3. Modifique o cluster para usar instâncias de banco de dados do Aurora Serverless v2.

Importante

Ao realizar uma atualização de versão principal para uma versão compatível com o Aurora Serverless v2 usando restauração ou clonagem de snapshot, a primeira instância de banco de dados que você adicionar ao novo cluster deverá ser uma instância de banco de dados provisionada. Essa adição inicia a fase final do processo de atualização.

Até que esse estágio final aconteça, o cluster não terá a infraestrutura necessária para compatibilidade com o Aurora Serverless v2. Dessa forma, esses clusters atualizados sempre começam com uma instância de banco de dados do gravador provisionada. Depois, você pode converter ou fazer failover da instância de banco de dados provisionada para um Aurora Serverless v2.

A atualização do Aurora Serverless v1 para o Aurora Serverless v2 envolve a criação de um cluster provisionado como etapa intermediária. Depois, realize as mesmas etapas de atualização que são realizadas quando você começa com um cluster provisionado.

Caminhos de atualização para que clusters compatíveis com MySQL usem o Aurora Serverless v2

Se o cluster original estiver executando o Aurora MySQL, escolha o procedimento apropriado dependendo da versão do mecanismo e do modo de mecanismo do cluster.

Se o cluster original do Aurora MySQL for este Faça isso para alternar para o Aurora Serverless v2
Cluster provisionado executando o Aurora MySQL versão 3, compatível com o MySQL 8.0

Esta é a fase final de todas as conversões de clusters existentes do Aurora MySQL.

Se necessário, realize uma atualização de versão secundária para a versão 3.02.0 ou posterior. Use uma instância de banco de dados provisionada para a instância de banco de dados do gravador. Adicione uma instância de banco de dados do leitor do Aurora Serverless v2. Depois, realize um failover para transformá-la na instância de banco de dados do gravador.

(Opcional) Converta outras instâncias de banco de dados provisionadas no cluster em Aurora Serverless v2. Ou adicione novas instâncias de banco de dados do Aurora Serverless v2 e remova as instâncias de banco de dados provisionadas.

Para saber o procedimento completo e ver os exemplos, consulte Alternar de um cluster provisionado para o Aurora Serverless v2.
Cluster provisionado executando o Aurora MySQL versão 2, compatível com o MySQL 5.7 Realize uma atualização de versão principal para o Aurora MySQL versão 3.02.0 ou posterior. Depois, siga o procedimento relativo ao Aurora MySQL versão 3 para alternar o cluster para usar instâncias de banco de dados do Aurora Serverless v2.
Cluster do Aurora Serverless v1 executando o Aurora MySQL versão 2, compatível com o MySQL 5.7

Para ajudar a planejar sua conversão do Aurora Serverless v1, primeiro consulte Comparação entre o Aurora Serverless v2 e o Aurora Serverless v1.

Depois, siga o procedimento em Atualizar a partir de um cluster do Aurora Serverless v1 para o Aurora Serverless v2.

Caminhos de atualização para que clusters compatíveis com PostgreSQL usem o Aurora Serverless v2

Se o cluster original estiver executando o Aurora PostgreSQL, escolha o procedimento apropriado dependendo da versão do mecanismo e do modo de mecanismo do cluster.

Se o cluster original do Aurora PostgreSQL for este Faça isso para alternar para o Aurora Serverless v2
Cluster provisionado executando o Aurora PostgreSQL versão 13

Esta é a fase final de todas as conversões de clusters existentes do Aurora PostgreSQL.

Se necessário, realize uma atualização de versão secundária para a versão 13.6 ou superior. Adicione uma instância de banco de dados provisionada para a instância de banco de dados do gravador. Adicione uma instância de banco de dados do leitor do Aurora Serverless v2. Realize um failover para transformar essa instância do Aurora Serverless v2 na instância de banco de dados do gravador.

(Opcional) Converta outras instâncias de banco de dados provisionadas no cluster em Aurora Serverless v2. Ou adicione novas instâncias de banco de dados do Aurora Serverless v2 e remova as instâncias de banco de dados provisionadas.

Para saber o procedimento completo e ver os exemplos, consulte Alternar de um cluster provisionado para o Aurora Serverless v2.
Cluster provisionado executando o Aurora PostgreSQL versão 11 ou 12 Realize uma atualização de versão principal para o Aurora PostgreSQL versão 13.6 ou superior. Depois, siga o procedimento relativo ao Aurora PostgreSQL versão 13 para alternar o cluster para usar instâncias de banco de dados do Aurora Serverless v2.
Cluster do Aurora Serverless v1 executando o Aurora PostgreSQL versão 11 ou 13

Para ajudar a planejar sua conversão do Aurora Serverless v1, primeiro consulte Comparação entre o Aurora Serverless v2 e o Aurora Serverless v1.

Depois, siga o procedimento em Atualizar a partir de um cluster do Aurora Serverless v1 para o Aurora Serverless v2.

Alternar de um cluster provisionado para o Aurora Serverless v2

Para alternar um cluster provisionado para usar o Aurora Serverless v2, siga estas etapas:

  1. Confira se o cluster provisionado precisa ser atualizado para ser usado com instâncias de banco de dados do Aurora Serverless v2. Sobre as versões do Aurora compatíveis com o Aurora Serverless v2, consulte Requisitos e limitações do Aurora Serverless v2.

    Se o cluster provisionado estiver executando uma versão do mecanismo que não esteja disponível para o Aurora Serverless v2, atualize a versão do mecanismo do cluster:

    • Se você tiver um cluster provisionado compatível com o MySQL 5.7, siga as instruções de atualização do Aurora MySQL versão 3. Use os procedimentos em Como realizar uma atualização local.

    • Se você tiver um cluster provisionado compatível com PostgreSQL que esteja executando o PostgreSQL versão 11 ou 12, siga as instruções de atualização do Aurora PostgreSQL versão 13. Use os procedimentos em Como realizar uma atualização de versão principal.

  2. Configure todas as outras propriedades do cluster para corresponder aos requisitos do Aurora Serverless v2 usando o Requisitos e limitações do Aurora Serverless v2.

  3. Defina a configuração de escalabilidade do cluster. Siga o procedimento em Configurar o intervalo de capacidade de Aurora Serverless v2 para um cluster.

  4. Adicione uma ou mais instâncias de banco de dados do Aurora Serverless v2 ao cluster. Siga o procedimento geral em Adicionar réplicas do Aurora a um cluster de banco de dados. Sobre cada nova instância de banco de dados, especifique o nome da classe de instância de banco de dados sem servidor no AWS Management Console ou db.serverless na AWS CLI ou na API do Amazon RDS.

    Em alguns casos, talvez você já tenha uma ou mais instâncias de banco de dados do leitor provisionadas no cluster. Se esse for o caso, será possível converter um dos leitores em uma instância de banco de dados do Aurora Serverless v2 em vez de criar outra instância. Para fazer isso, siga o procedimento em Converter um gravador ou leitor provisionado em Aurora Serverless v2.

  5. Realize uma operação de failover para tornar uma das instâncias de banco de dados do Aurora Serverless v2 a instância de banco de dados do gravador do cluster.

  6. (Opcional) Converta todas as instâncias de banco de dados provisionadas no Aurora Serverless v2 ou os remova do cluster. Siga o procedimento geral em Converter um gravador ou leitor provisionado em Aurora Serverless v2 ou em Excluir uma instância de banco de dados de um cluster de banco de dados do Aurora.

    dica

    A remoção das instâncias de banco de dados provisionadas não é obrigatória. É possível configurar um cluster que contenha instâncias de banco de dados provisionadas e do Aurora Serverless v2. No entanto, até você se familiarizar com as características de performance e escalabilidade das instâncias de banco de dados do Aurora Serverless v2, recomendamos que você configure seus clusters com instâncias de banco de dados do mesmo tipo.

O exemplo da AWS CLI a seguir mostra o processo de alternância usando um cluster provisionado que está executando o Aurora MySQL versão 3.02.0. O cluster é chamado mysql-80. O cluster começa com duas instâncias de banco de dados provisionadas chamadas provisioned-instance-1 e provisioned-instance-2, um gravador e um leitor. As duas usam a classe de instância de banco de dados db.r6g.large.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' --output text
mysql-80
provisioned-instance-2     False
provisioned-instance-1     True

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-1 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-1     db.r6g.large

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-2 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-2     db.r6g.large

Criamos uma tabela com alguns dados. Dessa forma, podemos confirmar que os dados e a operação do cluster são os mesmos antes e depois da alternância. 

mysql> create database serverless_v2_demo;
mysql> create table serverless_v2_demo.demo (s varchar(128));
mysql> insert into serverless_v2_demo.demo values ('This cluster started with a provisioned writer.');
Query OK, 1 row affected (0.02 sec)

Primeiro, adicionamos um intervalo de capacidade ao cluster. Caso contrário, obteremos um erro ao adicionar instâncias de banco de dados do Aurora Serverless v2 ao cluster. Se usarmos o AWS Management Console para este procedimento, esta etapa será automática quando adicionarmos a primeira instância de banco de dados do Aurora Serverless v2.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql

An error occurred (InvalidDBClusterStateFault) when calling the CreateDBInstance operation:
Set the Serverless v2 scaling configuration on the parent DB cluster before creating a Serverless v2 DB instance.

$ # The blank ServerlessV2ScalingConfiguration attribute confirms that the cluster doesn't have a capacity range set yet.
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 --query 'DBClusters[*].ServerlessV2ScalingConfiguration'
[]

$ aws rds modify-db-cluster --db-cluster-identifier mysql-80 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16
{
  "DBClusterIdentifier": "mysql-80",
  "ServerlessV2ScalingConfiguration": {
    "MinCapacity": 0.5,
    "MaxCapacity": 16
  }
}

Criamos dois leitores do Aurora Serverless v2 para substituir as instâncias de banco de dados originais. Fazemos isso especificando a classe de instância de banco de dados do db.serverless para as novas instâncias de banco de dados.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-2 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-2",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ # Wait for both DB instances to finish being created before proceeding.
$ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1 && \
  aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-2

Realize um failover para tornar uma das instâncias de banco de dados do Aurora Serverless v2 o novo gravador do cluster.

$ aws rds failover-db-cluster --db-cluster-identifier mysql-80 \
  --target-db-instance-identifier serverless-v2-instance-1
{
  "DBClusterIdentifier": "mysql-80",
  "DBClusterMembers": [
    {
      "DBInstanceIdentifier": "serverless-v2-instance-1",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "serverless-v2-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-1",
      "IsClusterWriter": true,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    }
  ],
  "Status": "available"
}

São necessários alguns segundos para que essa alteração entre em vigor. Nesse momento, temos um gravador do Aurora Serverless v2 e um leitor do Aurora Serverless v2. Dessa forma, não precisamos de nenhuma das instâncias de banco de dados provisionadas originais.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output text
mysql-80
serverless-v2-instance-1        True
serverless-v2-instance-2        False
provisioned-instance-2          False
provisioned-instance-1          False

A última etapa no procedimento de alternância é excluir ambas as instâncias de banco de dados provisionadas.

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-2 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-2",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-1 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-1",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

Como verificação final, confirmamos que a tabela original é acessível e gravável a partir da instância de banco de dados do Aurora Serverless v2.

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
+---------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into serverless_v2_demo.demo values ('And it finished with a Serverless v2 writer.');
Query OK, 1 row affected (0.01 sec)

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

Também nos conectamos à instância de banco de dados do leitor do Aurora Serverless v2 e confirmamos se os dados recém-gravados estão disponíveis também. 

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

Comparação entre o Aurora Serverless v2 e o Aurora Serverless v1

Se você já estiver usando o Aurora Serverless v1, saiba as principais diferenças entre o Aurora Serverless v1 e o Aurora Serverless v2. As diferenças de arquitetura, como compatibilidade com instâncias de banco de dados de leitor, abrem novos tipos de casos de uso.

Você pode usar as tabelas a seguir para entender as diferenças mais importantes entre o Aurora Serverless v2 e o Aurora Serverless v1.

Comparação entre os requisitos do Aurora Serverless v2 e do Aurora Serverless v1

A tabela a seguir resume os diferentes requisitos para executar o banco de dados usando o Aurora Serverless v2 ou o Aurora Serverless v1. O Aurora Serverless v2 oferece versões posteriores dos mecanismos de banco de dados do Aurora MySQL e do Aurora PostgreSQL em comparação com o Aurora Serverless v1.

Atributo Requisito do Aurora Serverless v2 Requisito do Aurora Serverless v1
Mecanismos de banco de dados Aurora MySQL, Aurora PostgreSQL Aurora MySQL, Aurora PostgreSQL
Versões compatíveis do Aurora MySQL Consulte Aurora Serverless v2 com o Aurora MySQL. Consulte Aurora Serverless v1 com o Aurora MySQL.
Versões compatíveis do Aurora PostgreSQL Consulte Aurora Serverless v2 com o Aurora PostgreSQL. Consulte Aurora Serverless v1 com o Aurora PostgreSQL.
Atualizar um cluster de banco de dados

Da mesma forma que os clusters de banco de dados provisionados, você pode realizar atualizações manualmente sem esperar que o Aurora atualize o cluster de banco de dados para você. Para ter mais informações, consulte Modificar um cluster de bancos de dados Amazon Aurora.

nota

Para realizar um upgrade de versão principal de 13.x para 14.x ou 15.x para um cluster de banco de dados compatível com o Aurora PostgreSQL, a capacidade máxima de seu cluster deve ser de pelo menos 2 ACUs.

As atualizações de versões secundárias são aplicadas automaticamente à medida que se tornam disponíveis. Para ter mais informações, consulte Versões de mecanismos de banco de dados do Aurora Serverless v1 e do Aurora.

Você pode realizar atualizações de versões principais manualmente. Para ter mais informações, consulte Modificar um cluster de banco de dados do Aurora Serverless v1.
Converter do cluster de banco de dados provisionado É possível usar os seguintes métodos:

  • Adicione uma ou mais instâncias de banco de dados de leitor do Aurora Serverless v2 para um cluster provisionado existente. Para usar o Aurora Serverless v2 para o gravador, realize um failover para uma das instâncias de banco de dados do Aurora Serverless v2. Para o cluster inteiro usar instâncias de banco de dados do Aurora Serverless v2, remova todas as instâncias de banco de dados do gravador provisionadas depois de promover a instância de banco de dados do Aurora Serverless v2 para o gravador.

  • Crie um cluster com o mecanismo de banco de dados e versão do mecanismo de banco de dados apropriados. Use qualquer um dos métodos padrão. Por exemplo, restaure um snapshot de cluster ou crie um clone de um cluster existente. Escolha Aurora Serverless v2 para algumas ou todas as instâncias de banco de dados do novo cluster.

    Se você criar o cluster por meio da clonagem, não poderá atualizar a versão do mecanismo simultaneamente. Verifique se o cluster original já está executando uma versão do mecanismo compatível com o Aurora Serverless v2.

Restaurar o snapshot do cluster provisionado para criar um cluster do Aurora Serverless v1
Converter do cluster do Aurora Serverless v1 Siga o procedimento em Atualizar a partir de um cluster do Aurora Serverless v1 para o Aurora Serverless v2. Não aplicável
Classes disponíveis da instância de banco de dados A classe da instância de banco de dados especial db.serverless. No AWS Management Console, é rotulado como Serverless (Sem servidor). Não aplicável. O Aurora Serverless v1 usa o modo de mecanismo serverless.
Porta Qualquer porta compatível com o MySQL ou o PostgreSQL Somente porta do MySQL ou do PostgreSQL padrão
Endereço IP público permitido? Sim Não
Uma nuvem privada virtual (VPC) é obrigatória? Sim Sim. Cada cluster do Aurora Serverless v1 consome dois endpoints do Gateway Load Balancer alocados para sua VPC.

Comparação de escalabilidade e disponibilidade entre o Aurora Serverless v2 e o Aurora Serverless v1

A tabela a seguir resume as diferenças de escalabilidade e disponibilidade entre o Aurora Serverless v2 e o Aurora Serverless v1.

A escalabilidade do Aurora Serverless v2 é mais responsiva, mais granular e menos disruptivo da que a escalabilidade do Aurora Serverless v1. O Aurora Serverless v2 pode ser escalado alterando o tamanho da instância de banco de dados e adicionando mais instâncias ao cluster de banco de dados. Ele também pode ser escalado adicionando clusters em outro Regiões da AWSa um banco de dados global do Aurora. Em contrapartida, o Aurora Serverless v1 só é escalado aumentando ou diminuindo a capacidade do gravador. Toda a computação para um cluster do Aurora Serverless v1 é executada em uma única zona de disponibilidade e uma única Região da AWS.

Recurso de escalabilidade e alta disponibilidade Comportamento do Aurora Serverless v2 Comportamento do Aurora Serverless v1
Unidades de capacidade mínima do Aurora (ACUs) (Aurora MySQL) 0,5 1 quando o cluster estiver em execução, 0 quando o cluster estiver pausado.
Mínimo de ACUs (Aurora PostgreSQL) 0,5 2 quando o cluster estiver em execução, 0 quando o cluster estiver pausado.
Máximo de ACUs (Aurora MySQL) 128 256
Mínimo de ACUs (Aurora PostgreSQL) 128 384
Interromper um cluster Você pode interromper e iniciar manualmente o cluster usando o mesmo recurso de parada e início de cluster que os clusters provisionados. O cluster é pausado automaticamente após um tempo limite. Leva algum tempo para se tornar disponível quando a atividade é retomada.
Escalabilidade para instâncias de banco de dados Aumente e reduza a escala verticalmente com incremento mínimo de 0,5 ACU. Aumente e reduza a escala verticalmente dobrando as ACUs ou diminuindo-as pela metade.
Número de instâncias de banco de dado O mesmo que um cluster provisionado: uma instância de banco de dados do gravador, até 15 instâncias de banco de dados do leitor. Uma instância de banco de dados que processa leituras e gravações.
A escalabilidade pode acontecer enquanto as instruções SQL estão em execução? Sim. O Aurora Serverless v2 não precisa esperar por um ponto de silêncio. Não. Por exemplo, a escalabilidade aguarda a conclusão de transações de longa duração, tabelas temporárias e bloqueios de tabela.
As instâncias de banco de dados do leitor são escaladas com o gravador Opcional. Não aplicável.
Armazenamento máximo 128 TiB 128 TiB ou 64 TiB, dependendo do mecanismo de banco de dados e da versão.
Cache de buffer preservado na escalabilidade Sim. O cache de buffer é redimensionado dinamicamente. Não. O cache de buffer é reaquecido após a escalabilidade.
Failover Sim, o mesmo que para clusters provisionados. Apenas o melhor esforço, sujeito à disponibilidade de capacidade. Mais lento do que em Aurora Serverless v2.
Capacidade multi-AZ Sim, o mesmo que para provisionados. Um cluster multi-AZ requer uma instância de banco de dados do leitor em uma segunda zona de disponibilidade (AZ). Para um cluster multi-AZ, o Aurora realiza failover multi-AZ em caso de falha da AZ. Os clusters do Aurora Serverless v1 executam toda a computação em uma única AZ. A recuperação em caso de falha da AZ é apenas o melhor esforço e está sujeita à disponibilidade de capacidade.
Bancos de dados globais do Aurora Sim Não
Escalabilidade baseada na pressão da memória Sim Não
Escalabilidade com base na carga da CPU Sim Sim
Escalabilidade com base no tráfego de rede Sim, com base na sobrecarga de memória e CPU do tráfego de rede. O parâmetro max_connections permanece constante para evitar a queda de conexões ao diminuir a escala na vertical. Sim, com base no número de conexões.
Ação de tempo limite para eventos de escalabilidade Não Sim
Adicionar novas instâncias de banco de dados ao cluster por meio do AWS Auto Scaling Não aplicável. É possível criar instâncias de banco de dados do leitor do Aurora Serverless v2 em níveis de promoção 2 a 15 e deixá–las com a escala reduzida na vertical para baixa capacidade. Não. Instâncias de banco de dados do leitor não estão disponíveis.

Comparação de compatibilidade de recursos entre o Aurora Serverless v2 e o Aurora Serverless v1

A tabela a seguir resume o seguinte:

  • Recursos que estão disponíveis no Aurora Serverless v2, mas não no Aurora Serverless v1

  • Recursos que funcionam de forma diferente entre o Aurora Serverless v1 e o Aurora Serverless v2

  • Recursos que não estão disponíveis no momento no Aurora Serverless v2

O Aurora Serverless v2 inclui muitos recursos de clusters provisionados que não estão disponíveis para o Aurora Serverless v1.

Atributo Suporte do Aurora Serverless v2 Suporte do Aurora Serverless v1
Topologia de cluster O Aurora Serverless v2 é uma propriedade de instâncias de banco de dados individuais. Um cluster pode conter várias instâncias de banco de dados do Aurora Serverless v2 ou uma combinação de instâncias de banco de dados provisionadas e do Aurora Serverless v2. Clusters do Aurora Serverless v1 não usam a noção de instâncias de banco de dados. Não será possível alterar a propriedade Aurora Serverless v1 depois de criar o cluster.
Parâmetros de configuração Quase todos os mesmos parâmetros podem ser modificados como em clusters provisionados. Para obter detalhes, consulte Trabalhar com grupos de parâmetros para o Aurora Serverless v2. Apenas um subconjunto de parâmetros pode ser modificado.
Grupos de parâmetros Grupo de parâmetros de cluster e grupos de parâmetros de banco de dados. Parâmetros com o valor provisioned no atributo SupportedEngineModes estão disponíveis. São muito mais parâmetros do que no Aurora Serverless v1. Somente o grupo de parâmetros do cluster. Parâmetros com o valor serverless no atributo SupportedEngineModes estão disponíveis.
Criptografia do volume do cluster Opcional Obrigatório. As limitações no Limitações dos clusters de banco de dados criptografados do Amazon Aurora se aplicam a todos os clusters do Aurora Serverless v1.
Snapshots entre regiões Sim O snapshot deve ser criptografado com sua própria chave AWS Key Management Service (AWS KMS).
Backups automatizados retidos após a exclusão do cluster de banco de dados Sim Não
TLS/SSL Sim. O suporte é o mesmo que para clusters provisionados. Para ter mais informações, consulte Usar TLS/SSL com o Aurora Serverless v2. Sim. Existem algumas diferenças em relação à compatibilidade com o TLS para clusters provisionados. Para ter mais informações, consulte Usar TLS/SSL com o Aurora Serverless v1.
Clonagem Somente entre versões do mecanismo de banco de dados compatíveis com o Aurora Serverless v2. Você não pode usar a clonagem para realizar a atualização a partir do Aurora Serverless v1 nem de uma versão anterior de um cluster provisionado. Somente entre versões do mecanismo de banco de dados compatíveis com o Aurora Serverless v1.
Integração com o Amazon S3 Sim Sim
Integração com AWS Secrets Manager Não Não
Exportar snapshots de cluster de banco de dados para o S3 Sim Não
Associar um perfil do IAM Sim Não
Carregar logs do no Amazon CloudWatch Opcional. Você escolhe quais logs serão ativados e quais logs devem ser carregados para o CloudWatch. Todos os logs ativados são carregados para o CloudWatch automaticamente.
API de dados disponível Sim Sim
Editor de consultas disponível Sim Sim
Performance Insights Sim Não
Proxy do Amazon RDS disponível Sim Não
Babelfish para Aurora PostgreSQL disponível Sim. Suporte para as versões do Aurora PostgreSQL que são compatíveis com Babelfish e Aurora Serverless v2. Não

Adaptar casos de uso do Aurora Serverless v1 para o Aurora Serverless v2

Dependendo do caso de uso do Aurora Serverless v1, você pode adaptar essa abordagem para aproveitar os recursos do Aurora Serverless v2 da forma a seguir.

Suponha que você tenha um cluster do Aurora Serverless v1 levemente carregado e sua prioridade é manter a disponibilidade contínua enquanto minimiza os custos. Com o Aurora Serverless v2, é possível configurar uma configuração mínima de ACU menor de 0,5, em comparação com um mínimo de 1 ACU no Aurora Serverless v1. É possível aumentar a disponibilidade criando uma configuração multi-AZ, com a instância de banco de dados do leitor também tendo um mínimo de 0,5 ACUs.

Suponha que você tenha um cluster do Aurora Serverless v1 que usa em um cenário de desenvolvimento e teste. Nesse caso, o custo também é uma alta prioridade, mas o cluster não precisa estar disponível em todos os momentos. Atualmente, o Aurora Serverless v2 não é pausado automaticamente quando o cluster está completamente ocioso. Em vez disso, você pode interromper manualmente o cluster quando ele não for necessário e iniciá-lo quando chegar a hora do próximo ciclo de teste ou desenvolvimento.

Suponha que você tenha um cluster do Aurora Serverless v1 com uma workload pesada. Um cluster equivalente usando o Aurora Serverless v2 pode ser escalado com mais granularidade. Por exemplo, o Aurora Serverless v1 é escalado dobrando a capacidade, por exemplo, de 64 para 128 ACUs. Em contrapartida, sua instância de banco de dados do Aurora Serverless v2 pode ser escalada para um valor entre esses números.

Suponha que sua workload exija uma capacidade total maior do que a disponível no Aurora Serverless v1. Você pode usar várias instâncias de banco de dados do leitor do Aurora Serverless v2 para descarregar as partes de uso intenso de leitura da workload da instância de banco de dados do gravador. Você também pode dividir a workload de uso intenso de leitura entre várias instâncias de banco de dados do leitor.

Para uma workload de uso intenso de gravação, é possível configurar o cluster com uma grande instância de banco de dados provisionada como o gravador. Você pode fazer isso com uma ou mais instâncias de banco de dados do leitor do Aurora Serverless v2.

Atualizar a partir de um cluster do Aurora Serverless v1 para o Aurora Serverless v2

O processo de atualização de um cluster de banco de dados do Aurora Serverless v1 para o Aurora Serverless v2 tem várias etapas. Isso porque não é possível fazer a conversão diretamente de Aurora Serverless v1 paraAurora Serverless v2. Sempre há uma etapa intermediária que envolve a conversão do cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado.

Clusters de banco de dados compatíveis com o Aurora MySQL

É possível converter o cluster de banco de dados do Aurora Serverless v1 em um cluster de banco de dados provisionado e, depois, usar uma implantação azul/verde para atualizá-lo e convertê-lo em um cluster de banco de dados do Aurora Serverless v2. Recomendamos esse procedimento para ambientes de produção. Para ter mais informações, consulte Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados.

Como utilizar uma implantação azul/verde para atualizar um cluster do Aurora Serverless v1 que execute o Aurora MySQL versão 2 (compatível com o MySQL 5.7)

  1. Converta o cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado do Aurora MySQL versão 2. Siga o procedimento em Conversão de Aurora Serverless v1 em provisionado.

  2. Crie uma implantação azul/verde. Siga o procedimento em Criar uma implantação azul/verde.

  3. Escolha uma versão do Aurora MySQL para o cluster verde que seja compatível com o Aurora Serverless v2, por exemplo, 3.04.1.

    Para saber as versões compatíveis, consulte Aurora Serverless v2 com o Aurora MySQL.

  4. Modifique a instância de banco de dados de gravador do cluster verde para usar a classe de instância de banco de dados do Serverless v2 (db.serverless).

    Para obter detalhes, consulte Converter um gravador ou leitor provisionado em Aurora Serverless v2.

  5. Quando o cluster de banco de dados do Aurora Serverless v2 atualizado estiver disponível, mude do cluster azul para o cluster verde.

Clusters de banco de dados compatíveis com o Aurora PostgreSQL

É possível converter o cluster de banco de dados do Aurora Serverless v1 em um cluster de banco de dados provisionado e, depois, usar uma implantação azul/verde para atualizá-lo e convertê-lo em um cluster de banco de dados do Aurora Serverless v2. Recomendamos esse procedimento para ambientes de produção. Para ter mais informações, consulte Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados.

Como utilizar uma implantação azul/verde para atualizar um cluster do Aurora Serverless v1 que execute o Aurora PostgreSQL versão 11

  1. Converta o cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado do Aurora PostgreSQL. Siga o procedimento em Conversão de Aurora Serverless v1 em provisionado.

  2. Crie uma implantação azul/verde. Siga o procedimento em Criar uma implantação azul/verde.

  3. Escolha uma versão do Aurora PostgreSQL para o cluster verde que seja compatível com o Aurora Serverless v2, por exemplo, 15.3.

    Para saber as versões compatíveis, consulte Aurora Serverless v2 com o Aurora PostgreSQL.

  4. Modifique a instância de banco de dados de gravador do cluster verde para usar a classe de instância de banco de dados do Serverless v2 (db.serverless).

    Para obter detalhes, consulte Converter um gravador ou leitor provisionado em Aurora Serverless v2.

  5. Quando o cluster de banco de dados do Aurora Serverless v2 atualizado estiver disponível, mude do cluster azul para o cluster verde.

Também é possível atualizar o cluster de banco de dados do Aurora Serverless v1 diretamente do Aurora PostgreSQL versão 11 para a versão 13, convertê-lo em um cluster de banco de dados provisionado e, depois, converter o cluster provisionado em um cluster de banco de dados do Aurora Serverless v2.

Como atualizar e, depois, converter um cluster do Aurora Serverless v1 que execute o Aurora PostgreSQL versão 11

  1. Atualize o cluster do Aurora Serverless v1 para uma versão do Aurora PostgreSQL versão 13 compatível com o Aurora Serverless v2, por exemplo, 13.12. Siga o procedimento em Atualizar a versão principal.

    Para saber as versões compatíveis, consulte Aurora Serverless v2 com o Aurora PostgreSQL.

  2. Converta o cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado do Aurora PostgreSQL. Siga o procedimento em Conversão de Aurora Serverless v1 em provisionado.

  3. Adicione uma instância de banco de dados de leitor do Aurora Serverless v2 ao cluster. Para ter mais informações, consulte Adicionar um leitor do Aurora Serverless v2.

  4. Faça o failover para a instância de banco de dados do Aurora Serverless v2:

    1. Selecione a instância de banco de dados de gravador do cluster de banco de dados.

    2. Em Actions (Ações), selecione Failover.

    3. Na página de confirmação, selecione Failover.

Para clusters de banco de dados do Aurora Serverless v1 que executam o Aurora PostgreSQL versão 13, você deve converter o cluster do Aurora Serverless v1 em um cluster de banco de dados provisionado e, depois, converter o cluster provisionado em um cluster de banco de dados do Aurora Serverless v2.

Como atualizar um cluster do Aurora Serverless v1 executando o Aurora PostgreSQL versão 13

  1. Converta o cluster de banco de dados do Aurora Serverless v1 em um cluster provisionado do Aurora PostgreSQL. Siga o procedimento em Conversão de Aurora Serverless v1 em provisionado.

  2. Adicione uma instância de banco de dados de leitor do Aurora Serverless v2 ao cluster. Para ter mais informações, consulte Adicionar um leitor do Aurora Serverless v2.

  3. Faça o failover para a instância de banco de dados do Aurora Serverless v2:

    1. Selecione a instância de banco de dados de gravador do cluster de banco de dados.

    2. Em Actions (Ações), selecione Failover.

    3. Na página de confirmação, selecione Failover.

Migrar de um banco de dados on-premises para o Aurora Serverless v2

Você pode migrar seus bancos de dados on-premises para o Aurora Serverless v2, assim como faz com Aurora MySQL e Aurora PostgreSQL provisionados.