Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migration vers Aurora Serverless v2

Pour convertir un cluster de base de données existant afin d'utiliser Aurora Serverless v2, vous pouvez effectuer les opérations suivantes :

Lorsque votre cluster mis à niveau exécute la version de moteur appropriée, comme indiqué dansExigences et limites pour Aurora Serverless v2, vous pouvez commencer à ajouter Aurora Serverless v2 Des instances de base de données y sont associées. La première instance de base de données que vous ajoutez au cluster mis à niveau doit être une instance de base de données approvisionnée. Vous pouvez ensuite transférer le traitement de la charge d'écriture, de la charge de lecture, ou des deux, à Aurora Serverless v2 Instances de base de données.

Mise à niveau ou changement de clusters existants pour les utiliser Aurora Serverless v2

Si votre cluster provisionné possède une version du moteur qui prend en charge Aurora Serverless v2, en passant à Aurora Serverless v2 ne nécessite pas de mise à niveau. Dans ce cas, vous pouvez ajouter Aurora Serverless v2 Instances de base de données vers votre cluster d'origine. Vous pouvez changer de cluster pour utiliser tous Aurora Serverless v2 Instances de base de données. Vous pouvez également utiliser une combinaison de Aurora Serverless v2 et des instances de base de données provisionnées dans le même cluster de base de données. Pour les versions du moteur Aurora qui prennent en charge Aurora Serverless v2, voir Régions et moteurs de base de données Aurora pris en charge pour Aurora Serverless v2.

Si vous utilisez une version inférieure du moteur qui ne prend pas en charge Aurora Serverless v2, vous devez suivre les étapes générales suivantes :

Mise à niveau depuis Aurora Serverless v1 to Aurora Serverless v2 implique la création d'un cluster provisionné comme étape intermédiaire. Vous effectuez ensuite les mêmes étapes de mise à niveau que lorsque vous commencez avec un cluster approvisionné.

Chemins de mise à niveau à utiliser pour SQL les clusters compatibles My Aurora Serverless v2

Si votre cluster d'origine exécute Aurora MySQL, choisissez la procédure appropriée en fonction de la version du moteur et du mode moteur de votre cluster.

Chemins de mise à niveau à utiliser par les clusters SQL compatibles avec Postgre Aurora Serverless v2

Si votre cluster d'origine exécute Aurora PostgreSQL, choisissez la procédure appropriée en fonction de la version du moteur et du mode moteur de votre cluster.

Passage d'un cluster provisionné à Aurora Serverless v2

Pour changer de cluster provisionné afin d'utiliser Aurora Serverless v2, procédez comme suit :

L' AWS CLI exemple suivant montre le processus de basculement à l'aide d'un cluster provisionné qui exécute Aurora My SQL version 3.02.0. Le cluster se nomme mysql-80. Il commence par deux instances de base de données approvisionnées nommées provisioned-instance-1 et provisioned-instance-2, l'une enregistreur, l'autre lecteur. Elles utilisent toutes les deux la classe d'instance de base de données 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

Créons une table contenant des données. Nous pouvons ainsi confirmer que les données et le fonctionnement du cluster sont identiques avant et après le basculement.

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)

Commençons par ajouter une plage de capacité au cluster. Sinon, nous obtenons une erreur lors de l'ajout de Aurora Serverless v2 Instances de base de données vers le cluster. Si nous utilisons le AWS Management Console pour cette procédure, cette étape est automatique lorsque nous ajoutons la première Aurora Serverless v2 Instance de base de données.

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

Nous créons deux Aurora Serverless v2 lecteurs pour remplacer les instances de base de données d'origine. Pour cela, nous spécifions la classe d'instance de base de données db.serverless pour les nouvelles instances de base de données.

$ 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

Nous effectuons un basculement pour créer l'un des Aurora Serverless v2 Les instances de base de données sont le nouveau rédacteur du 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"
}

Il faut compter quelques secondes pour que cette modification soit appliquée. À ce stade, nous avons Aurora Serverless v2 écrivain et Aurora Serverless v2 lecteur. Par conséquent, nous n'avons besoin d'aucune des instances de base de données approvisionnées d'origine.

$ 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

La dernière étape de la procédure de basculement consiste à supprimer les deux instances de base de données approvisionnées.

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

En guise de vérification finale, nous confirmons que le tableau d'origine est accessible et inscriptible à partir du Aurora Serverless v2 instance de base de données Writer.

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)

Nous nous connectons également au Aurora Serverless v2 lisez l'instance de base de données et confirmez que les données nouvellement écrites y sont également disponibles.

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)

Comparaison de Aurora Serverless v2 and Aurora Serverless v1

Si vous utilisez déjà Aurora Serverless v1, vous pouvez découvrir les principales différences entre Aurora Serverless v1 and Aurora Serverless v2. Les différences architecturales, telles que la prise en charge des instances de base de données de lecture, ouvrent la voie à de nouveaux types de cas d'utilisation.

Vous pouvez utiliser les tableaux suivants pour comprendre les principales différences entre Aurora Serverless v2 and Aurora Serverless v1.

Comparaison de Aurora Serverless v2 and Aurora Serverless v1 exigences

Le tableau suivant récapitule les différentes conditions requises pour exécuter votre base de données à l'aide de Aurora Serverless v2 or Aurora Serverless v1. Aurora Serverless v2 propose des versions supérieures des moteurs de SQL base de données Aurora My SQL et Aurora Postgre à celles Aurora Serverless v1 fait.

Comparaison de Aurora Serverless v2 and Aurora Serverless v1 mise à l'échelle et disponibilité

Le tableau suivant récapitule les différences entre Aurora Serverless v2 and Aurora Serverless v1 pour l'évolutivité et la disponibilité.

Aurora Serverless v2 la mise à l'échelle est plus réactive, plus granulaire et moins perturbatrice que la mise à l'échelle intégrée Aurora Serverless v1. Aurora Serverless v2 peut évoluer à la fois en modifiant la taille de l'instance de base de données et en ajoutant d'autres instances de base de données au cluster de base de données. Il peut également évoluer en ajoutant des clusters dans d'autres Régions AWS à une base de données globale Aurora. En revanche, Aurora Serverless v1 évolue uniquement en augmentant ou en diminuant la capacité du graveur. Tous les calculs nécessaires pour Aurora Serverless v1 le cluster s'exécute dans une seule zone de disponibilité et une seule Région AWS.

Comparaison de Aurora Serverless v2 and Aurora Serverless v1 prise en charge des fonctionnalités

Le tableau ci-dessous résume les éléments suivants :

Aurora Serverless v2 inclut de nombreuses fonctionnalités issues de clusters provisionnés qui ne sont pas disponibles pour Aurora Serverless v1.

Adaptation Aurora Serverless v1 cas d'utilisation pour Aurora Serverless v2

En fonction de votre cas d'utilisation pour Aurora Serverless v1, vous pouvez adapter cette approche pour tirer parti de Aurora Serverless v2 fonctionnalités comme suit.

Supposons que vous ayez Aurora Serverless v1 cluster peu chargé et dont la priorité est de maintenir une disponibilité continue tout en minimisant les coûts. Avec Aurora Serverless v2, vous pouvez configurer un ACU paramètre minimum inférieur de 0,5, par rapport à un minimum de 1 ACU pour Aurora Serverless v1. Vous pouvez augmenter la disponibilité en créant une configuration multi-AZ, l'instance de base de données du lecteur ayant également un minimum de 0,5ACUs.

Supposons que vous ayez Aurora Serverless v1 cluster que vous utilisez dans un scénario de développement et de test. Dans ce cas, le coût est également une priorité élevée, mais le cluster n'a pas besoin d'être disponible en permanence. À l'heure actuelle, Aurora Serverless v2 ne s'arrête pas automatiquement lorsque le cluster est complètement inactif. Au lieu de cela, vous pouvez arrêter manuellement le cluster lorsqu'il n'est pas nécessaire, et le démarrer au moment du prochain cycle de test ou de développement.

Supposons que vous ayez Aurora Serverless v1 cluster avec une charge de travail importante. Un cluster équivalent utilisant Aurora Serverless v2 peut évoluer avec plus de granularité. Par exemple, Aurora Serverless v1 évolue en doublant la capacité, par exemple de 64 à 128ACUs. En revanche, votre Aurora Serverless v2 L'instance de base de données peut être mise à l'échelle ACU par incréments de 0,5.

Supposons que votre charge de travail nécessite une capacité totale supérieure à celle disponible dans Aurora Serverless v1. Vous pouvez utiliser plusieurs Aurora Serverless v2 instances de base de données de lecteur pour décharger les parties de la charge de travail gourmandes en lecture de l'instance de base de données d'écriture. Vous pouvez également répartir la charge de travail exigeante en lecture entre plusieurs instances de base de données de lecteur.

Pour une charge de travail exigeante en écriture, vous pouvez configurer le cluster avec une instance de base de données approvisionnée volumineuse en tant qu'enregistreur. Vous pouvez le faire en même temps qu'un ou plusieurs Aurora Serverless v2 instances de base de données de lecteur.

Mise à niveau à partir d'un Aurora Serverless v1 cluster vers Aurora Serverless v2

Le processus de mise à niveau d'un cluster de base de données à partir de Aurora Serverless v1 to Aurora Serverless v2 comporte plusieurs étapes. C'est parce que vous ne pouvez pas convertir directement depuis Aurora Serverless v1 to Aurora Serverless v2. Il y a toujours une étape intermédiaire qui consiste à convertir le Aurora Serverless v1 Cluster de base de données vers un cluster provisionné.

Clusters de bases de SQL données compatibles avec Aurora My

Vous pouvez convertir votre Aurora Serverless v1 Un cluster de base de données vers un cluster de base de données provisionné, puis utilisez un déploiement bleu/vert pour le mettre à niveau et le convertir en Aurora Serverless v2 Cluster de bases de données. Nous recommandons cette procédure pour les environnements de production. Pour de plus amples informations, veuillez consulter Utilisation d'Amazon RDS Blue/Green Deployments pour les mises à jour de bases de données.

Clusters de bases de données SQL compatibles avec Aurora Postgre

Vous pouvez convertir votre Aurora Serverless v1 Un cluster de base de données vers un cluster de base de données provisionné, puis utilisez un déploiement bleu/vert pour le mettre à niveau et le convertir en Aurora Serverless v2 Cluster de bases de données. Nous recommandons cette procédure pour les environnements de production. Pour de plus amples informations, veuillez consulter Utilisation d'Amazon RDS Blue/Green Deployments pour les mises à jour de bases de données.

Vous pouvez également améliorer votre Aurora Serverless v1 Cluster de base de données directement d'Aurora Postgre SQL version 11 à version 13, convertissez-le en cluster de base de données provisionné, puis convertissez le cluster provisionné en Aurora Serverless v2 Cluster de bases de données.

Dans Aurora Serverless v1 Clusters de bases de données exécutant Aurora Postgre SQL version 13, vous convertissez le Aurora Serverless v1 cluster en cluster de base de données provisionné, puis convertissez le cluster provisionné en un Aurora Serverless v2 Cluster de bases de données.

Migration d'une base de données locale vers Aurora Serverless v2

Vous pouvez migrer vos bases de données locales vers Aurora Serverless v2, comme avec Aurora My SQL et Aurora SQL Postgre provisionnés.