Migrazione a Aurora Serverless v2 - Amazon Aurora
Utilizzo di Aurora Serverless v2 con un cluster esistentePassaggio di un cluster con provisioningConfronto tra Aurora Serverless v2 e Aurora Serverless v1Aggiornamento da Aurora Serverless v1 a Aurora Serverless v2Migrazione di un database on-premise a Aurora Serverless v2

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Migrazione a Aurora Serverless v2

Per convertire un cluster database esistente in modo che utilizzi Aurora Serverless v2, eseguire le operazioni seguenti:

  • Eseguire l'aggiornamento da un cluster Aurora con provisioning.

  • Aggiornamento da un cluster Aurora Serverless v1.

  • Migrare da un database on-premise a un cluster Aurora Serverless v2.

Quando il cluster aggiornato esegue la versione del motore appropriata come elencato in Requisiti e limitazioni per Aurora Serverless v2, puoi iniziare ad aggiungere istanze database Aurora Serverless v2. La prima istanza database aggiunta al cluster aggiornato deve essere un'istanza database con provisioning. Sarà quindi passare all'elaborazione del carico di lavoro di scrittura, del carico di lavoro di lettura o di entrambi nell'istanze database Aurora Serverless v2.

Nota

Questi argomenti descrivono come convertire un cluster database esistente. Per ulteriori informazioni sulla creazione di un nuovo cluster database Aurora Serverless v2, consulta Creazione di un cluster DB che utilizza Aurora Serverless v2.

Aggiornamento o conversione di cluster esistenti per l'uso di Aurora Serverless v2

Se il cluster con provisioning dispone di una versione del motore che supportaAurora Serverless v2, il passaggio ad Aurora Serverless v2 non richiede un aggiornamento. In questo caso, puoi aggiungere istanze database Aurora Serverless v2 al cluster originale. È possibile cambiare il cluster in modo che utilizzi tutte le istanze database Aurora Serverless v2. È inoltre possibile utilizzare una combinazione di istanze database Aurora Serverless v2 e con provisioning nello stesso cluster di database. Per le versioni del motore Aurora che supportano Aurora Serverless v2, consulta Regioni supportate e motori Aurora DB per Aurora Serverless v2.

Se utilizzi una precedente versione del motore che non supporta Aurora Serverless v2, esegui le seguenti operazioni di carattere generale:

  1. Aggiornare il cluster.

  2. Creare un'istanza database di scrittura con provisioning per il cluster aggiornato.

  3. Modificare il cluster in modo che utilizzi istanze database Aurora Serverless v2.

Importante

Quando esegui un aggiornamento della versione principale su una versione compatibile con Aurora Serverless v2 utilizzando il ripristino o la clonazione di snapshot, la prima istanza database aggiunta al nuovo cluster deve essere un'istanza database con provisioning. Questa aggiunta avvia la fase finale del processo di aggiornamento.

Fino a quando non si verifica la fase finale, il cluster non dispone dell'infrastruttura necessaria per il supporto di Aurora Serverless v2. Pertanto, i cluster aggiornati iniziano sempre con un'istanza database di scrittura con provisioning. Sarà quindi possibile convertire o eseguire il failover dell'istanza database con provisioning in un'istanza Aurora Serverless v2.

L'aggiornamento da Aurora Serverless v1 in Aurora Serverless v2 comporta la creazione di un cluster con provisioning come fase intermedia. Vengono quindi eseguiti gli stessi passaggi di aggiornamento utilizzati quando si inizia con un cluster con provisioning.

Percorsi di aggiornamento per cluster compatibili con MySQL per l'uso di Aurora Serverless v2

Se il cluster originale esegue Aurora MySQL, è necessario scegliere la procedura appropriata in base alla versione e alla modalità del motore del cluster.

Se il cluster Aurora MySQL originale è Procedura per il passaggio ad Aurora Serverless v2
Cluster con provisioning che esegue Aurora MySQL versione 3, compatibile con MySQL 8.0

Questa è la fase finale per tutte le conversioni da cluster Aurora MySQL esistenti.

Se necessario, eseguire un aggiornamento della versione secondaria alla versione 3.02.0 o successiva. Utilizzare un'istanza database con provisioning per l'istanza database di scrittura. Aggiungere un'istanza database Aurora Serverless v2 di lettura. Eseguire un failover per convertire l'istanza in istanza database di scrittura.

(Facoltativo) Convertire altre istanze database di cui è stato effettuato il provisioning nel cluster in Aurora Serverless v2. Oppure aggiungere nuove istanze database Aurora Serverless v2 e rimuovere le istanze database con provisioning.

Per la procedura completa e alcuni esempi, consultare Passaggio di un cluster con provisioning ad Aurora Serverless v2.
Cluster con provisioning che esegue Aurora MySQL versione 2, compatibile con MySQL 5.7 Eseguire un aggiornamento della versione principale ad Aurora MySQL versione 3.02.0 o successive. Eseguire quindi la procedura per Aurora MySQL versione 3 per convertire il cluster per l'uso di istanze database Aurora Serverless v2.
Cluster Aurora Serverless v1 che esegue Aurora MySQL versione 2, compatibile con MySQL 5.7

Per informazioni sulla pianificazione della conversione da Aurora Serverless v1, prima di iniziare consultare Confronto tra Aurora Serverless v2 e Aurora Serverless v1.

Quindi segui la procedura in Aggiornamento da un cluster Aurora Serverless v1 ad Aurora Serverless v2.

Percorsi di aggiornamento per cluster compatibili con PostgreSQL per l'uso di Aurora Serverless v2

Se il cluster originale esegue Aurora PostgreSQL, scegliere la procedura appropriata in base alla versione e alla modalità del motore del cluster.

Se il cluster Aurora PostgreSQL originale è Procedura per il passaggio ad Aurora Serverless v2
Cluster con provisioning che esegue Aurora PostgreSQL versione 13

Questa è la fase finale per tutte le conversioni da cluster Aurora PostgreSQL esistenti.

Se necessario, eseguire un aggiornamento della versione secondaria alla versione 13.6 o successiva. Aggiungere un'istanza database con provisioning per l'istanza database di scrittura. Aggiungere un'istanza database Aurora Serverless v2 di lettura. Eseguire un failover per convertire tale istanza Aurora Serverless v2 in istanza database di scrittura.

(Facoltativo) Convertire altre istanze database di cui è stato effettuato il provisioning nel cluster in Aurora Serverless v2. Oppure aggiungere nuove istanze database Aurora Serverless v2 e rimuovere le istanze database con provisioning.

Per la procedura completa e alcuni esempi, consultare Passaggio di un cluster con provisioning ad Aurora Serverless v2.
Cluster con provisioning che esegue Aurora PostgreSQL versione 11 o 12 Eseguire un aggiornamento della versione principale ad Aurora PostgreSQL versione 13.6 o successiva. Eseguire quindi la procedura per Aurora PostgreSQL versione 1.3 per convertire il cluster per l'uso delle istanze database Aurora Serverless v2.
Cluster Aurora Serverless v1 che esegue Aurora PostgreSQL versione 11 o 13

Per informazioni sulla pianificazione della conversione da Aurora Serverless v1, prima di iniziare consultare Confronto tra Aurora Serverless v2 e Aurora Serverless v1.

Quindi segui la procedura in Aggiornamento da un cluster Aurora Serverless v1 ad Aurora Serverless v2.

Passaggio di un cluster con provisioning ad Aurora Serverless v2

Per convertire un cluster con provisioning per l'uso di Aurora Serverless v2, procedi nel seguente modo:

  1. Verificare se è necessario aggiornare il cluster con provisioning per poter essere utilizzato con istanze database Aurora Serverless v2. Per le versioni Aurora compatibili con Aurora Serverless v2, consultare Requisiti e limitazioni per Aurora Serverless v2.

    Se il cluster con provisioning esegue una versione del motore che non è disponibile per Aurora Serverless v2, aggiornare la versione del motore del cluster:

    • Se disponi di un cluster con provisioning compatibile con MySQL 5.7, segui le istruzioni di aggiornamento per Aurora MySQL versione 3. Utilizzare la procedura descritta in Come eseguire un aggiornamento in loco.

    • Se disponi di un cluster con provisioning compatibile con PostgreSQL che esegue PostgreSQL versione 11 o 12, segui le istruzioni di aggiornamento per Aurora PostgreSQL versione 13. Utilizzare la procedura descritta in Come eseguire l'aggiornamento a una versione principale.

  2. Configurare qualsiasi altra proprietà del cluster in modo da soddisfare i requisiti Aurora Serverless v2 riportati in Requisiti e limitazioni per Aurora Serverless v2.

  3. Definire la configurazione di dimensionamento per il cluster. Segui la procedura riportata in Impostazione dell'intervallo di capacità di Aurora Serverless v2 per un cluster.

  4. Aggiungere una o più istanze database Aurora Serverless v2 al cluster. Eseguire la procedura generale descritta in Aggiunta di repliche di Aurora a un cluster di database. Per ogni nuova istanza DB, specifica il nome speciale della classe di istanza DB Serverless nella AWS Management Console AWS CLI o db.serverless nell'API Amazon RDS.

    In alcuni casi, è possibile che nel cluster siano già presenti una o più istanze database di lettura con provisioning. In questo caso, è possibile convertire una delle istanze di lettura in un'Istanza database Aurora Serverless v2 invece di creare una nuova istanza database. A tale scopo, segui la procedura in Conversione di un'istanza di lettura o scrittura con provisioning per Aurora Serverless v2.

  5. Eseguire un'operazione di failover per convertire una delle istanze database Aurora Serverless v2l'istanza database di scrittura per il cluster.

  6. (Facoltativo) Convertire le istanze database con provisioning in Aurora Serverless v2 o rimuoverle dal cluster. Eseguire la procedura generale descritta in Conversione di un'istanza di lettura o scrittura con provisioning per Aurora Serverless v2 o Eliminazione di un'istanza database da un cluster database Aurora.

    Suggerimento

    La rimozione delle istanze database con provisioning non è obbligatoria. È possibile configurare un cluster contenente sia istanze database Aurora Serverless v2 che istanze database con provisioning. Tuttavia, fino a quando non si acquisisce una certa familiarità con le prestazioni e le caratteristiche di dimensionamento delle istanze database Aurora Serverless v2, si consiglia di configurare i cluster con istanze database dello stesso tipo.

L' AWS CLI esempio seguente mostra il processo di switchover utilizzando un cluster con provisioning che esegue Aurora MySQL versione 3.02.0. Il cluster è denominato mysql-80. Inizialmente il cluster include due istanze database con provisioning denominate provisioned-instance-1 e provisioned-instance-2, ovvero un'istanza di scrittura e una di lettura. Entrambe usano la classe di istanza database 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

Viene creata una tabella contenente alcuni dati. In questo modo, è possibile confermare che i dati e il funzionamento del cluster sono gli stessi prima e dopo il passaggio. 

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)

Come prima cosa, al cluster viene aggiunto un intervallo di capacità. Se non si esegue questa operazione, viene visualizzato un errore quando al cluster vengono aggiunte istanze database Aurora Serverless v2. Se utilizziamo il AWS Management Console per questa procedura, tale passaggio è automatico quando aggiungiamo la prima istanza DB. 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
  }
}

Vengono creati due lettori Aurora Serverless v2 per sostituire le istanze database originali. Questa operazione viene eseguita specificando la classe di istanza database db.serverless per le nuove istanze database.

$ 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

Viene eseguito un failover per impostare una delle istanze database Aurora Serverless v2 come nuova istanza di scrittura per il 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"
}

Sono necessari alcuni secondi per rendere effettiva la modifica. A questo punto, sono disponibili un'istanza Aurora Serverless v2 di scrittura e un'istanza Aurora Serverless v2 di lettura. Pertanto, le istanze database con provisioning originali non sono più necessarie.

$ 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

L'ultimo passaggio della procedura di conversione prevede l'eliminazione delle istanze database con provisioning.

$ 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"
}

Come controllo finale, si verifica che la tabella originale sia accessibile e scrivibile dall'istanza database Aurora Serverless v2 di scrittura.

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)

Viene inoltre stabilita una connessione all'istanza database Aurora Serverless v2 di lettura e si verifica che in essa siano disponibili in nuovi dati scritti. 

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)

Confronto tra Aurora Serverless v2 e Aurora Serverless v1

Se usi già Aurora Serverless v1, puoi scoprire ulteriori informazioni sulle principali differenze traAurora Serverless v1 e Aurora Serverless v2. Le differenze a livello di architettura, ad esempio il supporto delle istanze database di lettura, offrono nuovi tipi di casi d'uso.

Puoi fare riferimento alle seguenti tabelle per informazioni dettagliate sulle principali differenze tra Aurora Serverless v2 e Aurora Serverless v1.

Confronto dei requisiti di Aurora Serverless v2 e Aurora Serverless v1

La tabella seguente fornisce un riepilogo dei diversi requisiti per l'esecuzione di database con Aurora Serverless v2 o Aurora Serverless v1. Rispetto ad Aurora Serverless v1, Aurora Serverless v2 offre versioni superiori dei motori Aurora PostgreSQL e Aurora MySQL.

Funzionalità Requisiti di Aurora Serverless v2 Requisiti di Aurora Serverless v1
Motori database Aurora MySQL, Aurora PostgreSQL Aurora MySQL, Aurora PostgreSQL
Versioni supportate di Aurora MySQL Consulta Aurora Serverless v2 con Aurora MySQL. Per informazioni, consulta Aurora Serverless v1 con Aurora MySQL.
Versioni supportate di Aurora PostgreSQL Consulta Aurora Serverless v2 con Aurora PostgreSQL. Per informazioni, consulta Aurora Serverless v1 con Aurora PostgreSQL.
Aggiornamento di un cluster di database

Come per i cluster di database sottoposti a provisioning, puoi eseguire gli aggiornamenti manualmente senza dover attendere che Aurora aggiorni il cluster di database automaticamente. Per ulteriori informazioni, consulta Modifica di un cluster database Amazon Aurora.

Nota

Per eseguire un aggiornamento della versione principale da 13.x a 14.x o 15.x per un cluster database compatibile con Aurora PostgreSQL, la capacità massima del cluster deve essere di almeno 2 ACU.

Gli aggiornamenti della versione secondaria vengono applicati automaticamente non appena diventano disponibili. Per ulteriori informazioni, consulta Versioni del motore del database di Aurora Serverless v1 e Aurora.

È possibile eseguire manualmente gli aggiornamenti della versione principale. Per ulteriori informazioni, consulta Modifica di un cluster di database Aurora Serverless v1.
Conversione da cluster di database con provisioning È possibile utilizzare i seguenti metodi:

  • Aggiungere una o più istanze database Aurora Serverless v2 di lettura a un cluster con provisioning esistente. Per utilizzare Aurora Serverless v2 per l'istanza di scrittura, eseguire un failover su una delle istanze database Aurora Serverless v2. Affinché l'intero cluster utilizzi le istanze database Aurora Serverless v2, rimuovere le istanze database di scrittura con provisioning dopo aver promosso l'istanza database Aurora Serverless v2 a istanza di scrittura.

  • Creare un nuovo cluster con il motore di database e la versione del motore appropriati. Utilizzare un qualsiasi metodo standard. Ad esempio, ripristinare uno snapshot del cluster o creare un clone di un cluster esistente. Scegliere Aurora Serverless v2 per alcune o tutte le istanze database nel nuovo cluster.

    Se si crea il nuovo cluster tramite la clonazione, non è possibile aggiornare contemporaneamente la versione del motore. Assicurarsi che il cluster originale esegua già una versione del motore compatibile con Aurora Serverless v2.

Ripristinare lo snapshot del cluster con provisioning per creare il nuovo cluster Aurora Serverless v1.
Conversione da cluster Aurora Serverless v1 Segui la procedura riportata in Aggiornamento da un cluster Aurora Serverless v1 ad Aurora Serverless v2. Non applicabile
Classi di istanze database disponibili Classe di istanza database speciale db.serverless. Nel AWS Management Console, è etichettato come Serverless. Non applicabile. Aurora Serverless v1 utilizza la modalità di motore serverless.
Porta Qualsiasi porta compatibile con MySQL o PostgreSQL Solo porta MySQL o PostgreSQL di default
Indirizzo IP pubblico consentito? Sì No
Cloud privato virtuale (VPC, Virtual private cloud) obbligatorio? Sì Sì. Ogni cluster Aurora Serverless v1 utilizza 2 endpoint di bilanciamento del carico interfaccia e gateway allocati al VPC.

Confronto di dimensionamento e disponibilità tra Aurora Serverless v2 e Aurora Serverless v1

La tabella seguente riepiloga le differenze tra Aurora Serverless v2 e Aurora Serverless v1 relativamente a dimensionamento e disponibilità.

Il dimensionamento in Aurora Serverless v2 è più reattivo, più granulare e meno 'sconvolgente' rispetto al dimensionamento in Aurora Serverless v1. Aurora Serverless v2 può implementare il dimensionamento sia modificando le dimensioni dell'istanza database che aggiungendo altre istanze database al cluster di database. Può anche scalare aggiungendo cluster in altro Regioni AWS a un database globale Aurora. Per contro, Aurora Serverless v1 implementa il dimensionamento solo aumentando o riducendo la capacità dell'istanza di scrittura. Tutte le operazioni di calcolo per un cluster Aurora Serverless v1 vengono eseguite in un'unica zona di disponibilità singola e in un'unica Regione AWS.

Funzionalità di scalabilità e alta disponibilità Aurora Serverless v2comportamento Aurora Serverless v1comportamento
Unità di capacità Aurora (ACU) minime (Aurora MySQL) 0,5 1 quando il cluster è in esecuzione, 0 quando il cluster è in pausa.
ACU minime (Aurora PostgreSQL) 0,5 2 quando il cluster è in esecuzione, 0 quando il cluster è in pausa.
ACU massime (Aurora MySQL) 128 256
ACU massime (Aurora PostgreSQL) 128 384
Arresto di un cluster È possibile arrestare e avviare manualmente il cluster utilizzando la stessa funzione di arresto e avvio del cluster valida per i cluster con provisioning. Il cluster si interrompe automaticamente dopo un timeout. Alla ripresa dell'attività, è necessario attendere un po' di tempo prima che il cluster torni disponibile.
Dimensionamento delle istanze database Aumentare e ridurre con incrementi minimi di 0,5 ACU. Aumentare e ridurre con il raddoppio o il dimezzamento delle ACU.
Numero di istanze database Stesso valore valido per un cluster con provisioning: 1 istanza database di scrittura, fino a 15 istanze database di lettura. 1 istanza database che gestisce sia le operazioni di lettura che le operazioni di scrittura.
Il dimensionamento può avvenire durante l'esecuzione di istruzioni SQL? Sì. Aurora Serverless v2 non richiede l'attesa di un momento di inattività. No. Ad esempio, il dimensionamento attende il completamento di transazioni con tempi di esecuzione lunghi, tabelle temporanee e blocchi di tabella.
Le istanze database di lettura vengono dimensionate assieme all'istanza di scrittura Facoltativo. Non applicabile.
Spazio di archiviazione massimo 128 TiB 128 TiB o 64 TiB, a seconda del motore e della versione del database.
Conservazione della cache del buffer durante il dimensionamento Sì. La cache del buffer viene dimensionata dinamicamente. No. La cache del buffer viene riavviata a caldo dopo il dimensionamento.
Failover Sì, con procedura analoga a quella valida per i cluster con provisioning. Solo modalità "Best effort", soggetto alla disponibilità della capacità. Più lento che in Aurora Serverless v2.
Funzionalità Multi-AZ Sì, come per le istanze con provisioning. Un cluster Multi-AZ richiede un'istanza database di lettura in una seconda zona di disponibilità. Per un cluster Multi-AZ, Aurora esegue il failover Multi-AZ in caso di guasto a livello di zona di disponibilità. I cluster Aurora Serverless v1 eseguono tutte le operazioni di calcolo in un'unica zona di disponibilità. Il ripristino in caso di guasto a livello di zona di disponibilità viene eseguito solo in modalità "Best effort" ed è soggetto alla disponibilità della capacità.
Database globali di Aurora Sì No
Dimensionamento basato sul carico della memoria Sì No
Dimensionamento basato sul carico della CPU Sì Sì
Dimensionamento basato sul traffico di rete Sì, in base alla memoria e al sovraccarico della CPU del traffico di rete. Il parametro max_connections rimane costante per evitare l'interruzione delle connessioni durante il dimensionamento. Sì, in base al numero di connessioni.
Operazione di timeout per gli eventi di dimensionamento No Sì
aggiunta di nuove istanze DB al cluster tramite AWS Auto Scaling Non applicabile. Puoi creare istanze database Aurora Serverless v2 di lettura nei livelli di promozione 2-15, lasciandole ridotte alla capacità inferiore. No. Le istanze database di lettura non sono disponibili.

Confronto del supporto delle caratteristiche di Aurora Serverless v2 e Aurora Serverless v1

La tabella seguente si riferisce ai seguenti argomenti:

  • Caratteristiche disponibili in Aurora Serverless v2 ma non in Aurora Serverless v1

  • Caratteristiche che funzionano in modo diverso in Aurora Serverless v1 e Aurora Serverless v2

  • Caratteristiche attualmente non disponibili in Aurora Serverless v2

In Aurora Serverless v2 sono presenti molte caratteristiche dei cluster con provisioning che non sono disponibili in Aurora Serverless v1.

Funzionalità Supporto di Aurora Serverless v2 Supporto di Aurora Serverless v1
Topologia dei cluster Aurora Serverless v2 è una proprietà delle singole istanze database. Un cluster può contenere più istanze database Aurora Serverless v2 o una combinazione di istanze Aurora Serverless v2 e istanze database con provisioning. I cluster Aurora Serverless v1 non utilizzano la nozione di istanze database. Non sarà possibile modificare la proprietà Aurora Serverless v1 dopo aver creato il cluster.
Parametri di configurazione È possibile modificare quasi tutti gli stessi parametri come avviene per i cluster con provisioning. Per informazioni dettagliate, vedi Uso di gruppi di parametri per Aurora Serverless v2. È possibile modificare solo un sottoinsieme di parametri.
Gruppi di parametri Uso di gruppi di parametri a livello di cluster e gruppi di parametri a livello di database Sono disponibili i parametri con il valore provisioned nell'attributo SupportedEngineModes. In Aurora Serverless v1 è disponibile un maggior numero di parametri. Solo gruppo di parametri a livello di cluster. Sono disponibili i parametri con il valore serverless nell'attributo SupportedEngineModes.
Crittografia per volume di cluster Facoltativo Obbligatorio. Le limitazioni in Limiti relativi a istanze database crittografate Amazon Aurora si applicano a tutti i cluster Aurora Serverless v1.
Snapshot tra regioni Sì L'istantanea deve essere crittografata con la propria chiave AWS Key Management Service (AWS KMS).
Backup automatici conservati dopo l'eliminazione del cluster DB Sì No
TLS/SSL Sì. Stesso supporto disponibile per i cluster con provisioning. Per informazioni sull'utilizzo, consulta Utilizzo di TLS/SSL con Aurora Serverless v2. Sì. Esistono alcune differenze rispetto al supporto TLS per i cluster con provisioning. Per informazioni sull'utilizzo, consulta Utilizzo di TLS/SSL con Aurora Serverless v1.
Clonazione Solo versioni di database di origine e destinazione compatibili con Aurora Serverless v2. Non è possibile utilizzare la clonazione per eseguire l'aggiornamento da Aurora Serverless v1 o da una versione precedente di un cluster con provisioning. Solo versioni di database di origine e destinazione compatibili con Aurora Serverless v1.
Integrazione con Amazon S3 Sì Sì
Integrazione con AWS Secrets Manager No No
Esportazione di snapshot cluster DB in S3 Sì No
Associazione di un ruolo IAM Sì No
Caricamento dei log su Amazon CloudWatch Facoltativo. Sei tu a scegliere quali registri attivare e su quali registri caricare. CloudWatch Tutti i log attivati vengono caricati automaticamente. CloudWatch
API di dati disponibile Sì Sì
Editor di query disponibile Sì Sì
Approfondimenti sulle prestazioni Sì No
Amazon RDS Proxy disponibile Sì No
Babelfish per Aurora PostgreSQL disponibile Sì. Supportato per versioni di Aurora PostgreSQL compatibili con Babelfish e Aurora Serverless v2. No

Adattamento dei casi d'uso di Aurora Serverless v1 ad Aurora Serverless v2

A seconda del caso d'uso relativo ad Aurora Serverless v1, potresti adattare l'approccio in modo da avvalerti delle caratteristiche di Aurora Serverless v2 nel seguente modo.

Supponi di avere un cluster Aurora Serverless v1 con un leggero carico e che la priorità sia mantenere una disponibilità continua e contemporaneamente ridurre al minimo i costi. Con Aurora Serverless v2, è possibile configurare un'impostazione ACU minima minore di 0,5, rispetto a un'impostazione minima di 1 ACU in Aurora Serverless v1. È possibile aumentare la disponibilità creando una configurazione Multi-AZ, con anche l'istanza database di lettura avente un minimo di 0,5 ACU.

Supponi di disporre di un cluster Aurora Serverless v1 utilizzato in uno scenario di sviluppo e test. In questo caso, anche il costo è una priorità elevata, ma il cluster non deve essere sempre disponibile. Attualmente, in Aurora Serverless v2 non si verifica automaticamente la pausa del sistema quando il cluster è completamente inattivo. È invece possibile arrestare manualmente il cluster quando non è necessario e avviarlo al successivo ciclo di test o sviluppo.

Si supponga di avere un cluster Aurora Serverless v1 con un carico di lavoro pesante. Un cluster equivalente che utilizza Aurora Serverless v2 può essere dimensionato con maggiore granularità. Ad esempio, Aurora Serverless v1 implementa il dimensionamento raddoppiando la capacità, ad esempio da 64 a 128 ACU. Per contro, l'istanza database Aurora Serverless v2 può essere dimensionata fino a un valore approssimativamente compreso tra questi numeri.

Si supponga che il carico di lavoro richieda una capacità totale superiore a quella disponibile in Aurora Serverless v1. È possibile utilizzare più istanze database Aurora Serverless v2 di lettura per alleggerire l'istanza database di scrittura dalle aree del carico di lavoro a uso più intensivo di operazioni di lettura. È inoltre possibile suddividere il carico di lavoro a uso più intensivo di operazioni di lettura tra più istanze database di lettura.

Per un carico di lavoro intensivo di scrittura, potrebbe essere necessario configurare il cluster con un'istanza database di grandi dimensioni di cui è stato effettuato il provisioning come l'istanza di scrittura. Questa operazione può essere eseguita insieme a una o più istanze database di lettura Aurora Serverless v2.

Aggiornamento da un cluster Aurora Serverless v1 ad Aurora Serverless v2

Il processo di aggiornamento di un cluster database da Aurora Serverless v1 a Aurora Serverless v2 implica diversi passaggi. Questo perché non puoi convertire direttamente da Aurora Serverless v1 a Aurora Serverless v2. C'è sempre un passaggio intermedio che prevede la conversione del cluster database Aurora Serverless v1 in un cluster con provisioning.

Cluster database compatibili con Aurora MySQL

È possibile convertire il cluster Aurora Serverless v1 DB in un cluster DB assegnato, quindi utilizzare una distribuzione blu/verde per aggiornarlo e convertirlo in un cluster DB. Aurora Serverless v2 Consigliamo questa procedura per gli ambienti di produzione. Per ulteriori informazioni, consulta Utilizzo delle implementazioni blu/verde Amazon RDS per gli aggiornamenti del database.

Per utilizzare una distribuzione blu/verde per aggiornare un Aurora Serverless v1 cluster che esegue Aurora MySQL versione 2 (compatibile con MySQL 5.7)

  1. Converti il cluster di database Aurora Serverless v1 in un cluster Aurora MySQL versione 2 allocato. Segui la procedura riportata in Conversione da istanza Aurora Serverless v1 in istanza con provisioning.

  2. Crea una distribuzione blu/verde. Segui la procedura riportata in Creazione di un'implementazione blu/verde.

  3. Scegli una versione di Aurora MySQL per il cluster verde compatibile con, ad esempio, 3.04.1. Aurora Serverless v2

    Per le versioni compatibili, consulta Aurora Serverless v2 con Aurora MySQL.

  4. Modifica l'istanza Writer DB del cluster verde per utilizzare la classe di istanze DB Serverless v2 (db.serverless).

    Per informazioni dettagliate, vedi Conversione di un'istanza di lettura o scrittura con provisioning per Aurora Serverless v2.

  5. Quando il cluster Aurora Serverless v2 DB aggiornato è disponibile, passa dal cluster blu al cluster verde.

Cluster database compatibili con Aurora PostgreSQL

È possibile convertire il cluster Aurora Serverless v1 DB in un cluster DB predisposto, quindi utilizzare una distribuzione blu/verde per aggiornarlo e convertirlo in un cluster DB. Aurora Serverless v2 Consigliamo questa procedura per gli ambienti di produzione. Per ulteriori informazioni, consulta Utilizzo delle implementazioni blu/verde Amazon RDS per gli aggiornamenti del database.

Per utilizzare una distribuzione blu/verde per aggiornare un Aurora Serverless v1 cluster che esegue Aurora PostgreSQL versione 11

  1. Converti il cluster di database Aurora Serverless v1 in un cluster Aurora PostgreSQL allocato. Segui la procedura riportata in Conversione da istanza Aurora Serverless v1 in istanza con provisioning.

  2. Crea una distribuzione blu/verde. Segui la procedura riportata in Creazione di un'implementazione blu/verde.

  3. Scegli una versione di Aurora PostgreSQL per il cluster verde compatibile, ad esempio, con la 15.3. Aurora Serverless v2

    Per le versioni compatibili, consulta Aurora Serverless v2 con Aurora PostgreSQL.

  4. Modifica l'istanza Writer DB del cluster verde per utilizzare la classe di istanze DB Serverless v2 (db.serverless).

    Per informazioni dettagliate, vedi Conversione di un'istanza di lettura o scrittura con provisioning per Aurora Serverless v2.

  5. Quando il cluster Aurora Serverless v2 DB aggiornato è disponibile, passa dal cluster blu al cluster verde.

È inoltre possibile aggiornare il cluster Aurora Serverless v1 DB direttamente dalla versione 11 di Aurora PostgreSQL alla versione 13, convertirlo in un cluster DB con provisioning e quindi convertire il cluster di cui è stato eseguito il provisioning in un cluster DB. Aurora Serverless v2

Per eseguire l'aggiornamento, converti un Aurora Serverless v1 cluster che esegue Aurora PostgreSQL versione 11

  1. Aggiorna il Aurora Serverless v1 cluster a una versione di Aurora PostgreSQL versione 13 compatibile, ad esempio, con la 13.12. Aurora Serverless v2 Segui la procedura riportata in Aggiornamento della versione principale.

    Per le versioni compatibili, consulta Aurora Serverless v2 con Aurora PostgreSQL.

  2. Converti il cluster di database Aurora Serverless v1 in un cluster Aurora PostgreSQL allocato. Segui la procedura riportata in Conversione da istanza Aurora Serverless v1 in istanza con provisioning.

  3. Aggiungi un'istanza Aurora Serverless v2 Reader DB al cluster. Per ulteriori informazioni, consulta Aggiunta di un'istanza Aurora Serverless v2 di lettura.

  4. Failover sull'istanza Aurora Serverless v2 DB:

    1. Seleziona l'istanza Writer DB del cluster DB.

    2. Per Actions (Operazioni), scegliere Failover.

    3. Nella pagina di conferma, scegli Failover.

Per i cluster Aurora Serverless v1 DB che eseguono Aurora PostgreSQL versione 13, si converte il cluster in un cluster DB con provisioning, quindi si Aurora Serverless v1 converte il cluster di cui è stato eseguito il provisioning in un cluster DB. Aurora Serverless v2

Per aggiornare un cluster Aurora Serverless v1 che esegue Aurora PostgreSQL versione 13

  1. Converti il cluster di database Aurora Serverless v1 in un cluster Aurora PostgreSQL allocato. Segui la procedura riportata in Conversione da istanza Aurora Serverless v1 in istanza con provisioning.

  2. Aggiungi un'istanza DB reader al clusterAurora Serverless v2. Per ulteriori informazioni, consulta Aggiunta di un'istanza Aurora Serverless v2 di lettura.

  3. Failover sull'istanza Aurora Serverless v2 DB:

    1. Seleziona l'istanza Writer DB del cluster DB.

    2. Per Actions (Operazioni), scegliere Failover.

    3. Nella pagina di conferma, scegli Failover.

Migrazione di un database on-premise a Aurora Serverless v2

Puoi migrare i database on-premise a Aurora Serverless v2, esattamente come con Aurora MySQL e Aurora PostgreSQL con provisioning.