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 verso Aurora Serverless v2

Per convertire un cluster DB esistente da utilizzare Aurora Serverless v2, puoi fare quanto segue:

Quando il cluster aggiornato esegue la versione del motore appropriata, come elencato inRequisiti e limitazioni per Aurora Serverless v2, puoi iniziare ad aggiungere Aurora Serverless v2 Istanze DB ad esso. La prima istanza database aggiunta al cluster aggiornato deve essere un'istanza database con provisioning. Quindi puoi passare l'elaborazione per il carico di lavoro di scrittura, il carico di lavoro di lettura o entrambi a Aurora Serverless v2 Istanze DB.

Aggiornamento o modifica dei cluster esistenti da utilizzare Aurora Serverless v2

Se il cluster predisposto dispone di una versione del motore che supporta Aurora Serverless v2, passaggio a Aurora Serverless v2 non richiede un aggiornamento. In tal caso, puoi aggiungere Aurora Serverless v2 Istanze DB al cluster originale. Puoi cambiare il cluster in modo che utilizzi tutto Aurora Serverless v2 Istanze DB. Puoi anche usare una combinazione di Aurora Serverless v2 e ha effettuato il provisioning di istanze DB nello stesso cluster DB. 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 versione inferiore del motore che non supporta Aurora Serverless v2, esegui questi passaggi generali:

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

Percorsi di aggiornamento da utilizzare per i cluster SQL compatibili con My Aurora Serverless v2

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

Percorsi di aggiornamento da utilizzare per i cluster SQL compatibili con Postgre Aurora Serverless v2

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

Passaggio da un cluster fornito a Aurora Serverless v2

Per passare da un cluster predisposto all'uso Aurora Serverless v2, segui questi passaggi:

L' AWS CLI esempio seguente mostra il processo di switchover utilizzando un cluster con provisioning che esegue Aurora My versione 3.02.0. SQL 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à. Altrimenti, viene visualizzato un errore quando ne aggiungiamo uno Aurora Serverless v2 Istanze DB al cluster. Se utilizziamo il AWS Management Console per questa procedura, quel passaggio è automatico quando aggiungiamo il primo Aurora Serverless v2 Istanza DB.

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

Ne creiamo due Aurora Serverless v2 lettori che sostituiranno le istanze DB 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

Eseguiamo un failover per creare uno dei Aurora Serverless v2 DB installa il nuovo writer 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 quel punto, abbiamo un Aurora Serverless v2 scrittore e un Aurora Serverless v2 lettore. 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 ultimo controllo, confermiamo che la tabella originale è accessibile e scrivibile dal Aurora Serverless v2 istanza Writer DB.

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)

Ci colleghiamo anche a Aurora Serverless v2 leggiamo l'istanza DB e confermiamo che i dati appena scritti siano disponibili anche lì.

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 lo stai già utilizzando Aurora Serverless v1, puoi scoprire le principali differenze tra Aurora Serverless v1 e Aurora Serverless v2. Le differenze architetturali, come il supporto per le istanze Reader DB, aprono nuovi tipi di casi d'uso.

È possibile utilizzare le seguenti tabelle per comprendere le differenze più importanti tra Aurora Serverless v2 e Aurora Serverless v1.

Confronto tra Aurora Serverless v2 e Aurora Serverless v1 requisiti

La tabella seguente riassume i diversi requisiti per eseguire il database utilizzando Aurora Serverless v2 oppure Aurora Serverless v1. Aurora Serverless v2 offre versioni superiori dei motori Aurora My e Aurora SQL Postgre DB rispetto a SQL Aurora Serverless v1 fa.

Confronto tra Aurora Serverless v2 e Aurora Serverless v1 scalabilità e disponibilità

La tabella seguente riassume le differenze tra Aurora Serverless v2 e Aurora Serverless v1 per scalabilità e disponibilità.

Aurora Serverless v2 la scalabilità è più reattiva, più granulare e meno dirompente rispetto alla scalabilità in Aurora Serverless v1. Aurora Serverless v2 può scalare sia modificando la dimensione dell'istanza DB sia aggiungendo altre istanze DB al cluster DB. Può anche scalare aggiungendo cluster in altro Regioni AWS a un database globale Aurora. Al contrario, Aurora Serverless v1 scala solo aumentando o diminuendo la capacità dello scrittore. Tutta la potenza di calcolo per un Aurora Serverless v1 il cluster viene eseguito in un'unica zona di disponibilità e in un'unica Regione AWS.

Confronto tra Aurora Serverless v2 e Aurora Serverless v1 supporto per le funzionalità

La tabella seguente si riferisce ai seguenti argomenti:

Aurora Serverless v2 include molte funzionalità dei cluster predisposti che non sono disponibili per Aurora Serverless v1.

Adattamento Aurora Serverless v1 casi d'uso per Aurora Serverless v2

A seconda del caso d'uso per Aurora Serverless v1, potresti adattare questo approccio per trarne vantaggio Aurora Serverless v2 presenta le seguenti caratteristiche.

Supponiamo di avere un Aurora Serverless v1 cluster con un carico leggero e la cui priorità è mantenere la disponibilità continua riducendo al minimo i costi. Con Aurora Serverless v2, è possibile configurare un'ACUimpostazione minima inferiore di 0,5, rispetto a un minimo di 1 ACU per Aurora Serverless v1. È possibile aumentare la disponibilità creando una configurazione Multi-AZ, con anche l'istanza Reader DB con un minimo di 0,5ACUs.

Supponiamo di avere un Aurora Serverless v1 cluster da utilizzare 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, Aurora Serverless v2 non si interrompe automaticamente quando il cluster è completamente inattivo. È invece possibile arrestare manualmente il cluster quando non è necessario e avviarlo al successivo ciclo di test o sviluppo.

Supponiamo di avere un Aurora Serverless v1 cluster con un carico di lavoro pesante. Un cluster equivalente che utilizza Aurora Serverless v2 può scalare con maggiore granularità. Ad esempio, Aurora Serverless v1 scala raddoppiando la capacità, ad esempio da 64 a 128. ACUs Al contrario, il tuo Aurora Serverless v2 L'istanza DB può essere scalata in ACU incrementi di 0,5.

Supponiamo che il carico di lavoro richieda una capacità totale superiore a quella disponibile in Aurora Serverless v1. Puoi usarne più Aurora Serverless v2 istanze Reader DB per scaricare le parti del carico di lavoro ad alta intensità di lettura dall'istanza DB di Writer. È 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. Potresti farlo insieme a uno o più Aurora Serverless v2 istanze Reader DB.

Aggiornamento da un Aurora Serverless v1 cluster a Aurora Serverless v2

Il processo di aggiornamento di un cluster DB da Aurora Serverless v1 in Aurora Serverless v2 prevede più passaggi. Questo perché non puoi convertire direttamente da Aurora Serverless v1 in Aurora Serverless v2. C'è sempre un passaggio intermedio che prevede la conversione di Aurora Serverless v1 Cluster DB in un cluster predisposto.

Cluster DB compatibili con Aurora My SQL

Puoi convertire i tuoi Aurora Serverless v1 Un cluster DB in un cluster DB fornito, quindi utilizza una distribuzione blu/verde per aggiornarlo e convertirlo in un Aurora Serverless v2 Cluster DB. Consigliamo questa procedura per gli ambienti di produzione. Per ulteriori informazioni, consulta Utilizzo di Amazon RDS Blue/Green Deployments per gli aggiornamenti del database.

Cluster DB compatibili con Aurora SQL Postgre

Puoi convertire i tuoi Aurora Serverless v1 Un cluster DB in un cluster DB fornito, quindi utilizza una distribuzione blu/verde per aggiornarlo e convertirlo in un Aurora Serverless v2 Cluster DB. Consigliamo questa procedura per gli ambienti di produzione. Per ulteriori informazioni, consulta Utilizzo di Amazon RDS Blue/Green Deployments per gli aggiornamenti del database.

Puoi anche aggiornare il tuo Aurora Serverless v1 Cluster DB direttamente dalla SQL versione 11 alla versione 13 di Aurora Postgre, convertilo in un cluster DB con provisioning e quindi converti il cluster di cui è stato eseguito il provisioning in un Aurora Serverless v2 Cluster DB.

In Aurora Serverless v1 Cluster DB che eseguono Aurora SQL Postgre versione 13, converti il Aurora Serverless v1 cluster in un cluster DB di cui è stato eseguito il provisioning, quindi converte il cluster di cui è stato eseguito il provisioning in un Aurora Serverless v2 Cluster DB.

Migrazione da un database locale a Aurora Serverless v2

Puoi migrare i tuoi database locali a Aurora Serverless v2, proprio come con Aurora My SQL e Aurora Postgre fornite. SQL