Migration vers Aurora Serverless v2 - Amazon Aurora
Utilisation d'Aurora Serverless v2 avec un cluster existantBasculement d'un cluster approvisionnéComparaison d'Aurora Serverless v2 avec Aurora Serverless v1Mise à niveau d'Aurora Serverless v1 vers Aurora Serverless v2Migration d'une base de données sur site vers Aurora Serverless v2

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 bases de données existant afin qu'il utilise Aurora Serverless v2, vous pouvez effectuer les actions suivantes :

  • Effectuer une mise à niveau à partir d'un cluster de bases de données Aurora provisionné.

  • Effectuer une mise à niveau à partir d'un cluster Aurora Serverless v1.

  • Migration d'une base de données sur site vers un cluster Aurora Serverless v2.

Lorsque votre cluster mis à niveau exécute la version appropriée du moteur, comme indiqué à la rubrique Exigences et limites pour Aurora Serverless v2, vous pouvez commencer à lui ajouter des instances de base de données Aurora Serverless v2. 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 basculer le traitement de la charge de travail d'écriture et/ou de la charge de travail de lecture vers les instances de base de données Aurora Serverless v2.

Note

Ces rubriques expliquent comment convertir un cluster de bases de données existant. Pour obtenir des informations sur la création d'un nouveau cluster de bases de données Aurora Serverless v2, consultez Création d'un cluster de base de données qui utilise Aurora Serverless v2.

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

Si votre cluster approvisionné dispose d'une version de moteur qui prend en charge Aurora Serverless v2, le basculement vers Aurora Serverless v2 n'exige pas de mise à niveau. Dans ce cas, vous pouvez ajouter des instances de base de données Aurora Serverless v2 à votre cluster d'origine. Vous pouvez basculer le cluster de sorte qu'il utilise toutes les instances de base de données Aurora Serverless v2. Vous pouvez également utiliser une combinaison d'instances de base de données Aurora Serverless v2 et approvisionnées dans le même cluster de bases de données. Pour obtenir les versions du moteur Aurora prenant en charge Aurora Serverless v2, consultez Régions et moteurs de base de données Aurora pris en charge pour Aurora Serverless v2.

Si vous exécutez une version antérieure du moteur qui ne prend pas en charge Aurora Serverless v2, suivez ces étapes générales :

  1. Mettez à niveau le cluster.

  2. Créez une instance de base de données d'enregistreur approvisionnée pour le cluster mis à niveau.

  3. Modifiez le cluster de sorte qu'il utilise des instances de base de données Aurora Serverless v2.

Important

Lorsque vous effectuez une mise à niveau de version majeure vers une version compatible avec Aurora Serverless v2 en utilisant la restauration ou le clonage d'instantané, la première instance de base de données que vous ajoutez au nouveau cluster doit être une instance de base de données approvisionnée. Cet ajout amorce la dernière étape du processus de mise à niveau.

Tant que cette dernière étape n'intervient pas, le cluster ne dispose pas de l'infrastructure requise pour prendre en charge Aurora Serverless v2. Par conséquent, ces clusters mis à niveau commencent toujours avec une instance de base de données d'enregistreur approvisionnée. Vous pouvez ensuite convertir ou basculer l'instance de base de données approvisionnée vers une instance Aurora Serverless v2.

La mise à niveau d'Aurora Serverless v1 vers Aurora Serverless v2 implique la création d'un cluster approvisionné en tant qu'é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 pour les clusters compatibles avec MySQL pour utiliser Aurora Serverless v2

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

Si votre cluster Aurora MySQL d'origine est le suivant Procédez comme suit pour basculer vers Aurora Serverless v2
Cluster approvisionné exécutant Aurora MySQL version 3, compatible avec MySQL 8.0

Il s'agit de la dernière étape pour toutes les conversions à partir de clusters Aurora MySQL existants.

Si nécessaire, effectuez une mise à niveau d'une version mineure vers la version 3.02.0 ou ultérieure. Utilisez une instance de base de données approvisionnée pour l'instance de base de données d'enregistreur. Ajoutez une instance de base de données de lecteur Aurora Serverless v2. Procédez à un basculement pour en faire l'instance de base de données d'enregistreur.

(Facultatif) Convertissez les autres instances de base de données provisionnées dans le cluster en Aurora Serverless v2. Ou ajoutez de nouvelles instances de base de données Aurora Serverless v2 et supprimez les instances de base de données provisionnées.

Pour obtenir la procédure complète et des exemples, consultez Basculement d'un cluster approvisionné vers Aurora Serverless v2.
Cluster approvisionné exécutant Aurora MySQL version 2, compatible avec MySQL 5.7 Effectuez une mise à niveau d'une version majeure vers Aurora MySQL version 3.02.0 ou ultérieure. Suivez ensuite la procédure propre à Aurora MySQL version 3 pour basculer le cluster de sorte à utiliser les instances de base de données Aurora Serverless v2.
Cluster Aurora Serverless v1 exécutant Aurora MySQL version 2, compatible avec MySQL 5.7

Pour vous aider à planifier votre conversion depuis Aurora Serverless v1, commencez par consulter Comparaison d'Aurora Serverless v2 avec Aurora Serverless v1.

Suivez ensuite la procédure décrite dans Mise à niveau d'un cluster Aurora Serverless v1 vers Aurora Serverless v2.

Chemins de mise à niveau pour les clusters compatibles avec PostgreSQL pour utiliser Aurora Serverless v2

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

Si votre cluster Aurora PostgreSQL d'origine est le suivant Procédez comme suit pour basculer vers Aurora Serverless v2
Cluster approvisionné exécutant Aurora PostgreSQL version 13

Il s'agit de la dernière étape pour toutes les conversions à partir de clusters Aurora PostgreSQL existants.

Si nécessaire, effectuez une mise à niveau d'une version mineure vers la version 13.6 ou ultérieure. Ajoutez une instance de base de données approvisionnée pour l'instance de base de données d'enregistreur. Ajoutez une instance de base de données de lecteur Aurora Serverless v2. Procédez à un basculement pour faire de cette instance Aurora Serverless v2 l'instance de base de données d'enregistreur.

(Facultatif) Convertissez les autres instances de base de données provisionnées dans le cluster en Aurora Serverless v2. Ou ajoutez de nouvelles instances de base de données Aurora Serverless v2 et supprimez les instances de base de données provisionnées.

Pour obtenir la procédure complète et des exemples, consultez Basculement d'un cluster approvisionné vers Aurora Serverless v2.
Cluster provisionné exécutant Aurora PostgreSQL version 11 ou 12 Effectuez une mise à niveau d'une version majeure vers Aurora PostgreSQL version 13.6 ou ultérieure. Suivez ensuite la procédure propre à Aurora PostgreSQL version 13 pour basculer le cluster de sorte à utiliser les instances de base de données Aurora Serverless v2.
Cluster Aurora Serverless v1 exécutant Aurora PostgreSQL version 11 ou 13

Pour vous aider à planifier votre conversion depuis Aurora Serverless v1, commencez par consulter Comparaison d'Aurora Serverless v2 avec Aurora Serverless v1.

Suivez ensuite la procédure décrite dans Mise à niveau d'un cluster Aurora Serverless v1 vers Aurora Serverless v2.

Basculement d'un cluster approvisionné vers Aurora Serverless v2

Pour basculer un cluster approvisionné pour utiliser Aurora Serverless v2, procédez comme suit :

  1. Vérifiez si le cluster approvisionné doit être mis à niveau pour être utilisé avec les instances de base de données Aurora Serverless v2. Pour connaître les versions d'Aurora compatibles avec Aurora Serverless v2, consultez Exigences et limites pour Aurora Serverless v2.

    Si le cluster approvisionné exécute une version de moteur qui n'est pas disponible pour Aurora Serverless v2, mettez à niveau la version de moteur du cluster :

    • Si vous disposez d'un cluster provisionné compatible avec MySQL 5.7, suivez les instructions de mise à niveau pour Aurora MySQL version 3. Procédez comme décrit à la rubrique Comment effectuer une mise à niveau sur place.

    • Si vous disposez d'un cluster provisionné compatible avec PostgreSQL exécutant PostgreSQL version 11 ou 12, suivez les instructions de mise à niveau pour Aurora PostgreSQL version 13. Procédez comme décrit à la rubrique Comment effectuer une mise à niveau de version majeure.

  2. Configurez toutes les autres propriétés du cluster de sorte qu'elles satisfassent aux exigences Aurora Serverless v2 de la rubrique Exigences et limites pour Aurora Serverless v2.

  3. Définissez la configuration de mise à l'échelle du cluster. Suivez la procédure décrite dans Définition de la plage de capacité Aurora Serverless v2 d'un cluster.

  4. Ajoutez une ou plusieurs instances de base de données Aurora Serverless v2 au cluster. Suivez la procédure générale de la rubrique Ajout de réplicas Aurora à un cluster de bases de données. Pour chaque nouvelle instance de base de données, spécifiez le nom de classe d'instance de base de données spécial Serverless dans ou db.serverless dans l' AWS CLI API Amazon RDS. AWS Management Console

    Dans certains cas, le cluster peut déjà comporter une ou plusieurs instances de base de données de lecteur approvisionnées. Si tel est le cas, vous pouvez convertir l'un des lecteurs en instance de base de données Aurora Serverless v2 au lieu de créer une instance de base de données. Pour ce faire, suivez la procédure décrite dans Conversion d'un lecteur ou d'un enregistreur approvisionné en Aurora Serverless v2.

  5. Effectuez une opération de basculement pour faire de l'une des instances de base de données Aurora Serverless v2 l'instance de base de données d'enregistreur du cluster.

  6. (Facultatif) Convertissez toutes les instances de base de données approvisionnées en Aurora Serverless v2 ou retirez-les du cluster. Suivez la procédure générale décrite à la rubrique Conversion d'un lecteur ou d'un enregistreur approvisionné en Aurora Serverless v2 ou Suppression d'une instance de base de données d'un cluster de bases de données Aurora.

    Astuce

    Le retrait d'instances de base de données approvisionnées n'est pas obligatoire. Vous pouvez configurer un cluster contenant à la fois des instances de base de données Aurora Serverless v2 et approvisionnées. Cependant, tant que vous n'êtes pas familiarisé avec les caractéristiques de performance et de mise à l’échelle des instances de base de données Aurora Serverless v2, nous vous recommandons de configurer vos clusters avec des instances de base de données du même type.

L' AWS CLI exemple suivant montre le processus de commutation à l'aide d'un cluster provisionné qui exécute Aurora MySQL 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. Dans le cas contraire, nous obtiendrions une erreur lors de l'ajout d'instances de base de données Aurora Serverless v2 au 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 lecteurs Aurora Serverless v2 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 faire de l'une des instances de base de données Aurora Serverless v2 le nouvel enregistreur 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 disposons d'un enregistreur Aurora Serverless v2 et d'un lecteur Aurora Serverless v2. 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"
}

À titre de vérification finale, nous confirmons que la table d'origine est accessible et accessible en écriture à partir de l'instance de base de données d'enregistreur 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)

Nous nous connectons également à l'instance de base de données de lecteur Aurora Serverless v2 et confirmons que les données récemment é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 d'Aurora Serverless v2 avec Aurora Serverless v1

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

Vous pouvez utiliser les tableaux suivants pour mieux comprendre les différences les plus importantes entre Aurora Serverless v2 et Aurora Serverless v1.

Comparaison des exigences d'Aurora Serverless v2 et d'Aurora Serverless v1

Le tableau ci-dessous récapitule les différentes exigences pour exécuter votre base de données à l'aide d'Aurora Serverless v2 ou d'Aurora Serverless v1. Aurora Serverless v2 offre des versions supérieures des moteurs de base de données Aurora MySQL et Aurora PostgreSQL par rapport à Aurora Serverless v1.

Fonctionnalité Exigence Aurora Serverless v2 Exigence Aurora Serverless v1
Moteurs de base de données Aurora MySQL, Aurora PostgreSQL Aurora MySQL, Aurora PostgreSQL
Versions d'Aurora MySQL prises en charge veuillez consulter Aurora Serverless v2 avec Aurora MySQL. veuillez consulter Aurora Serverless v1 avec Aurora MySQL.
Versions d'Aurora PostgreSQL prises en charge veuillez consulter Aurora Serverless v2 avec Aurora PostgreSQL. veuillez consulter Aurora Serverless v1 avec Aurora PostgreSQL.
Mise à niveau d'un cluster de bases de données

Comme pour les clusters de bases de données provisionnés, vous pouvez effectuer des mises à niveau manuellement sans attendre qu'Aurora mette à niveau le cluster de bases de données pour vous. Pour plus d’informations, consultez Modification d'un cluster de bases de données Amazon Aurora.

Note

Pour effectuer une mise à niveau de version majeure de 13.x à 14.x ou 15.x pour un cluster de bases de données compatible avec Aurora PostgreSQL, la capacité maximale de votre cluster doit être d'au moins 2 ACU.

Les mises à jour des versions mineures sont appliquées automatiquement dès qu'elles sont disponibles. Pour plus d’informations, consultez Versions de moteur de base de données Aurora Serverless v1 et Aurora.

Vous pouvez effectuer des mises à niveau de versions majeures manuellement. Pour plus d’informations, consultez Modification d'un cluster de bases de données Aurora Serverless v1.
Conversion à partir d'un cluster de bases de données approvisionné Vous pouvez utiliser les méthodes suivantes :

  • Ajouter une ou plusieurs instances de base de données de lecteur Aurora Serverless v2 à un cluster approvisionné existant. Pour utiliser Aurora Serverless v2 pour l'enregistreur, effectuez un basculement vers l'une des instances de base de données Aurora Serverless v2. Pour que l'ensemble du cluster utilise les instances de base de données Aurora Serverless v2, retirez toutes les instances de base de données d'enregistreur approvisionnées après avoir promu l'instance de base de données Aurora Serverless v2 en enregistreur.

  • Créer un cluster avec le moteur de base de données et la version du moteur appropriés. Utilisez l'une des méthodes standard. Par exemple, restaurez un instantané de cluster ou créez un clone d'un cluster existant. Choisissez Aurora Serverless v2 pour certaines ou la totalité des instances de base de données du nouveau cluster.

    Si vous créez le cluster via le clonage, vous ne pouvez pas mettre à niveau la version du moteur en même temps. Assurez-vous que le cluster d'origine exécute déjà une version de moteur compatible avec Aurora Serverless v2.

Restaurer l'instantané du cluster approvisionné afin de créer un cluster Aurora Serverless v1.
Conversion à partir d'un cluster Aurora Serverless v1 Suivez la procédure décrite dans Mise à niveau d'un cluster Aurora Serverless v1 vers Aurora Serverless v2. Ne s’applique pas
Classes d'instance de base de données disponibles La classe d'instance de base de données spéciale db.serverless. Dans le AWS Management Console, il est étiqueté Serverless. Non applicable. Aurora Serverless v1 utilise le mode moteur serverless.
Port Tous les ports compatibles avec MySQL ou PostgreSQL Port MySQL ou PostgreSQL par défaut uniquement
Adresse IP publique autorisée ? Oui Non
Cloud privé virtuel (VPC) requis ? Oui Oui. Chaque cluster Aurora Serverless v1 consomme 2 points de terminaison d’équilibreur de charge d’interface et de passerelle alloués à votre VPC.

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

Le tableau suivant résume les différences entre Aurora Serverless v2 et Aurora Serverless v1 en termes de capacité de mise à l’échelle et de disponibilité.

La mise à l'échelle d'Aurora Serverless v2 est plus réactive, plus granulaire et moins perturbatrice que la mise à l'échelle d'Aurora Serverless v1. Aurora Serverless v2 peut faire l'objet d'une mise à l’échelle en modifiant la taille de l'instance de base de données et en ajoutant des instances de base de données supplémentaires au cluster de bases 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, la mise à l’échelle d'Aurora Serverless v1 n'est appliquée qu'en augmentant ou en diminuant la capacité de l'enregistreur. L'ensemble de la capacité de calcul d'un cluster Aurora Serverless v1 s'exécute dans une seule zone de disponibilité et une seule Région AWS.

Fonctionnalité de mise à l'échelle et de haute disponibilité Aurora Serverless v2comportement Aurora Serverless v1comportement
Unités de capacité Aurora (ACU) minimales (Aurora MySQL) 0.5 1 lorsque le cluster est en cours d'exécution, 0 lorsque le cluster est en pause.
Nombre minimal d'ACU (Aurora PostgreSQL) 0.5 2 lorsque le cluster est en cours d'exécution, 0 lorsque le cluster est en pause.
Nombre maximal d'ACU (Aurora MySQL) 128 256
Nombre maximal d'ACU (Aurora PostgreSQL) 128 384
Arrêt d'un cluster Vous pouvez arrêter et démarrer manuellement le cluster à l'aide de la même fonction d'arrêt et de démarrage du cluster que les clusters approvisionnés. Le cluster est mis en pause automatiquement après un certain délai. Sa disponibilité prend un certain temps lorsque l'activité reprend.
Mise à l’échelle d'instances de base de données Augmentez et réduisez l'échelle par incrément minimal de 0,5 ACU. Augmentez et réduisez l'échelle en doublant ou en réduisant de moitié le nombre d'ACU.
Nombre d'instances de base de données Identique à un cluster approvisionné : 1 instance de base de données d'enregistreur, jusqu'à 15 instances de base de données de lecteur. 1 instance de base de données gérant à la fois les lectures et les écritures.
La mise à l'échelle peut intervenir pendant l'exécution des instructions SQL ? Oui. Aurora Serverless v2 n'exige pas d'attendre un point silencieux. Non. Par exemple, la mise à l'échelle attend que les transactions de longue durée, les tables temporaires et les verrous de table se terminent.
Les instances de base de données de lecteur sont mises à l'échelle en même temps que l'enregistreur Facultatif. Non applicable.
Stockage maximum 128 Tio 128 Tio ou 64 Tio, selon le moteur de base de données et la version.
Cache de mémoire tampon conservé lors de la mise à l’échelle Oui. Le cache de mémoire tampon est redimensionné dynamiquement. Non. Le cache de mémoire tampon est rechargé après la mise à l'échelle.
Basculement Oui, comme pour les clusters approvisionnés. Seulement dans la mesure du possible, sous réserve de disponibilité de la capacité. Plus lent que dans Aurora Serverless v2.
Fonctionnalité multi-AZ Oui, comme pour les clusters approvisionnés. Un cluster multi-AZ exige une instance de base de données de lecteur dans une deuxième zone de disponibilité. Pour un cluster multi-AZ, Aurora effectue un basculement multi-AZ en cas de défaillance de la zone de disponibilité. Les clusters Aurora Serverless v1 exécutent l'ensemble de leurs calculs dans une seule zone de disponibilité. La reprise en cas de défaillance de la zone de disponibilité est effectuée dans la mesure du possible seulement et sous réserve de disponibilité de la capacité.
Bases de données globales Aurora Oui Non
Mise à l'échelle en fonction de la sollicitation de la mémoire Oui Non
Mise à l'échelle en fonction de la charge du processeur Oui Oui
Mise à l'échelle en fonction du trafic réseau Oui, en fonction de la charge de mémoire et d'UC du trafic réseau. Le paramètre max_connections reste constant pour éviter l'interruption des connexions lors de la réduction d'échelle. Oui, selon le nombre de connexions.
Action de délai d'attente pour les événements de mise à l’échelle Non Oui
Ajouter de nouvelles instances de base de données au cluster via AWS Auto Scaling Non applicable. Vous pouvez créer des instances de base de données de lecteur Aurora Serverless v2 aux niveaux de promotion 2 à 15 en conservant leur faible capacité. Non. Les instances de base de données de lecteur ne sont pas disponibles.

Comparaison de la prise en charge des fonctionnalités d'Aurora Serverless v2 et d'Aurora Serverless v1

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

  • Fonctionnalités qui sont disponibles dans Aurora Serverless v2 mais pas dans Aurora Serverless v1

  • Fonctionnalités qui fonctionnent différemment entre Aurora Serverless v1 et Aurora Serverless v2

  • Fonctionnalités qui ne sont actuellement pas disponibles dans Aurora Serverless v2

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

Fonctionnalité Prise en charge de Aurora Serverless v2 Prise en charge de Aurora Serverless v1
Topologie de cluster Aurora Serverless v2 est une propriété des instances de base de données individuelles. Un cluster peut contenir plusieurs instances de base de données Aurora Serverless v2, ou une combinaison d'instances de base de données Aurora Serverless v2 et approvisionnées. Les clusters Aurora Serverless v1 n'utilisent pas la notion d'instances de base de données. Vous ne pouvez pas modifier la propriété Aurora Serverless v1 après avoir créé le cluster.
Paramètres de configuration Presque tous les paramètres peuvent être modifiés comme dans les clusters approvisionnés. Pour plus de détails, consultez Utilisation des groupes de paramètres pour Aurora Serverless v2. Seul un sous-ensemble de paramètres peut être modifié.
Groupes de paramètres Groupe de paramètres de cluster et groupes de paramètres de base de données. Les paramètres ayant la valeur provisioned dans l'attribut SupportedEngineModes sont disponibles. C'est beaucoup plus de paramètres que dans Aurora Serverless v1. Groupe de paramètres de cluster uniquement. Les paramètres ayant la valeur serverless dans l'attribut SupportedEngineModes sont disponibles.
Chiffrement du volume du cluster Facultatif Obligatoire. Les Limitations des clusters de base de données chiffrées Amazon Aurora s'appliquent à l'ensemble des clusters Aurora Serverless v1.
Instantanés entre régions Oui Le snapshot doit être chiffré avec votre propre clé AWS Key Management Service (AWS KMS).
Sauvegardes automatisées conservées après la suppression du cluster de base de données Oui Non
TLS/SSL Oui. La prise en charge est la même que pour les clusters approvisionnés. Pour plus d'informations, consultez Utilisation de TLS/SSL avec Aurora Serverless v2. Oui. Il existe certaines différences de prise en charge de TLS pour les clusters approvisionnés. Pour plus d'informations, consultez Utilisation de TLS/SSL avec Aurora Serverless v1.
Clonage Uniquement depuis et vers les versions de moteur de base de données compatibles avec Aurora Serverless v2. Vous ne pouvez pas utiliser le clonage pour mettre à niveau Aurora Serverless v1 ou une version antérieure d'un cluster approvisionné. Uniquement depuis et vers les versions de moteur de base de données compatibles avec Aurora Serverless v1.
Intégration à Amazon S3 Oui Oui
Intégration avec AWS Secrets Manager Non Non
Exportation d'instantanés de cluster de base de données vers S3 Oui Non
Association d'un rôle IAM Oui Non
Téléchargement de journaux sur Amazon CloudWatch Facultatif. Vous choisissez les journaux à activer et les journaux vers lesquels vous souhaitez les télécharger CloudWatch. Tous les journaux activés sont chargés CloudWatch automatiquement.
API de données disponible Oui Oui
Éditeur de requête disponible Oui Oui
Performance Insights Oui Non
Proxy Amazon RDS disponible Oui Non
Babelfish for Aurora PostgreSQL disponible Oui. Pris en charge pour les versions d'Aurora PostgreSQL compatibles avec Babelfish et Aurora Serverless v2. Non

Adaptation des cas d'utilisation Aurora Serverless v1 à Aurora Serverless v2

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

Supposons que vous disposiez d'un cluster Aurora Serverless v1 à faible charge et que votre priorité est de maintenir une disponibilité continue tout en réduisant les coûts. Avec Aurora Serverless v2, vous pouvez réduire le nombre minimal d'ACU à 0,5, comparé au nombre minimal d'ACU de 1 pour Aurora Serverless v1. Vous pouvez augmenter la disponibilité en créant une configuration multi-AZ, l'instance de base de données de lecteur ayant également un nombre minimal d'ACU de 0,5.

Supposons que vous disposiez d'un cluster Aurora Serverless v1 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. Actuellement, Aurora Serverless v2 ne se met pas en pause 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 disposiez d'un cluster Aurora Serverless v1 dont la charge de travail est importante. Un cluster équivalent qui utilise Aurora Serverless v2 peut être mis à l'échelle avec davantage de granularité. Par exemple, Aurora Serverless v1 est mis à l'échelle en doublant la capacité, de 64 à 128 ACU par exemple. En revanche, votre instance de base de données Aurora Serverless v2 peut être mise à l'échelle jusqu'à une valeur comprise entre ces nombres.

Supposons que votre charge de travail exige une capacité totale supérieure à celle disponible dans Aurora Serverless v1. Vous pouvez utiliser plusieurs instances de base de données de lecteur Aurora Serverless v2 pour décharger les parties de la charge de travail exigeantes en lecture de l'instance de base de données d'enregistreur. 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'une ou plusieurs instances de base de données de lecteur Aurora Serverless v2.

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

Le processus de mise à niveau d'un cluster de bases de données d'Aurora Serverless v1 vers Aurora Serverless v2 se compose de plusieurs étapes. Cela s'explique par le fait qu'il n'est pas possible de convertir directement de Aurora Serverless v1 vers Aurora Serverless v2. Il existe toujours une étape intermédiaire qui implique de convertir le cluster de bases de données Aurora Serverless v1 en cluster provisionné.

Clusters de bases de données compatibles avec Aurora MySQL

Vous pouvez convertir votre Aurora Serverless v1 cluster de base de données en cluster de base de données provisionné, puis utiliser un déploiement bleu/vert pour le mettre à niveau et le convertir en cluster de base de données. Aurora Serverless v2 Nous recommandons cette procédure pour les environnements de production. Pour plus d’informations, consultez Utilisation des déploiements bleu/vert Amazon RDS pour les mises à jour de base de données.

Pour utiliser un déploiement bleu/vert pour mettre à niveau un Aurora Serverless v1 cluster exécutant Aurora MySQL version 2 (compatible avec MySQL 5.7)

  1. Convertissez le cluster de bases de données Aurora Serverless v1 en un cluster Aurora MySQL version 2 provisionné. Suivez la procédure décrite dans Conversion d'Aurora Serverless v1 en mode approvisionné.

  2. Créez un déploiement bleu/vert. Suivez la procédure décrite dans Création d'un déploiement bleu/vert.

  3. Choisissez une version d'Aurora MySQL compatible avec le cluster vertAurora Serverless v2, par exemple la version 3.04.1.

    Pour les versions compatibles, consultez Aurora Serverless v2 avec Aurora MySQL.

  4. Modifiez l'instance de base de données Writer du cluster vert pour utiliser la classe d'instance de base de données Serverless v2 (db.serverless).

    Pour plus de détails, consultez Conversion d'un lecteur ou d'un enregistreur approvisionné en Aurora Serverless v2.

  5. Lorsque votre Aurora Serverless v2 cluster de base de données mis à niveau est disponible, passez du cluster bleu au cluster vert.

Clusters de bases de données compatibles avec Aurora PostgreSQL

Vous pouvez convertir votre Aurora Serverless v1 cluster de base de données en cluster de base de données provisionné, puis utiliser un déploiement bleu/vert pour le mettre à niveau et le convertir en cluster de base de données. Aurora Serverless v2 Nous recommandons cette procédure pour les environnements de production. Pour plus d’informations, consultez Utilisation des déploiements bleu/vert Amazon RDS pour les mises à jour de base de données.

Pour utiliser un déploiement bleu/vert pour mettre à niveau un Aurora Serverless v1 cluster exécutant Aurora PostgreSQL version 11

  1. Convertissez le cluster de bases de données Aurora Serverless v1 en un cluster Aurora PostgreSQL provisionné. Suivez la procédure décrite dans Conversion d'Aurora Serverless v1 en mode approvisionné.

  2. Créez un déploiement bleu/vert. Suivez la procédure décrite dans Création d'un déploiement bleu/vert.

  3. Choisissez une version d'Aurora PostgreSQL compatible Aurora Serverless v2 avec le cluster vert, par exemple 15.3.

    Pour les versions compatibles, consultez Aurora Serverless v2 avec Aurora PostgreSQL.

  4. Modifiez l'instance de base de données Writer du cluster vert pour utiliser la classe d'instance de base de données Serverless v2 (db.serverless).

    Pour plus de détails, consultez Conversion d'un lecteur ou d'un enregistreur approvisionné en Aurora Serverless v2.

  5. Lorsque votre Aurora Serverless v2 cluster de base de données mis à niveau est disponible, passez du cluster bleu au cluster vert.

Vous pouvez également mettre à niveau votre Aurora Serverless v1 cluster de bases de données directement d'Aurora PostgreSQL version 11 vers la version 13, le convertir en cluster de base de données provisionné, puis convertir le cluster provisionné en cluster de base de données. Aurora Serverless v2

Pour effectuer une mise à niveau, puis convertir un Aurora Serverless v1 cluster exécutant Aurora PostgreSQL version 11

  1. Mettez à niveau le Aurora Serverless v1 cluster vers une version Aurora PostgreSQL version 13 compatible Aurora Serverless v2 avec, par exemple, 13.12. Suivez la procédure décrite dans Mise à niveau de la version majeure.

    Pour les versions compatibles, consultez Aurora Serverless v2 avec Aurora PostgreSQL.

  2. Convertissez le cluster de bases de données Aurora Serverless v1 en un cluster Aurora PostgreSQL provisionné. Suivez la procédure décrite dans Conversion d'Aurora Serverless v1 en mode approvisionné.

  3. Ajoutez une instance de base de données de Aurora Serverless v2 lecteur au cluster. Pour plus d’informations, consultez Ajout d'un lecteur Aurora Serverless v2.

  4. Basculez vers l'Aurora Serverless v2instance de base de données :

    1. Sélectionnez l'instance de base de données Writer du cluster de bases de données.

    2. Pour Actions, choisissez Failover (Basculement).

    3. Sur la page de confirmation, choisissez Failover.

Pour les clusters de Aurora Serverless v1 bases de données exécutant Aurora PostgreSQL version 13, vous convertissez Aurora Serverless v1 le cluster en cluster de base de données provisionné, puis vous convertissez le cluster provisionné en cluster de base de données. Aurora Serverless v2

Pour mettre à niveau un cluster Aurora Serverless v1 exécutant Aurora PostgreSQL version 13

  1. Convertissez le cluster de bases de données Aurora Serverless v1 en un cluster Aurora PostgreSQL provisionné. Suivez la procédure décrite dans Conversion d'Aurora Serverless v1 en mode approvisionné.

  2. Ajoutez une instance de base de données de Aurora Serverless v2 lecteur au cluster. Pour plus d’informations, consultez Ajout d'un lecteur Aurora Serverless v2.

  3. Basculez vers l'Aurora Serverless v2instance de base de données :

    1. Sélectionnez l'instance de base de données Writer du cluster de bases de données.

    2. Pour Actions, choisissez Failover (Basculement).

    3. Sur la page de confirmation, choisissez Failover.

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

Vous pouvez migrer vos bases de données sur site vers Aurora Serverless v2, tout comme avec les bases de données Aurora MySQL et Aurora PostgreSQL provisionnées.