Restauration d’un cluster de bases de données Aurora Serverless v1 - Amazon Aurora

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.

Restauration d’un cluster de bases de données Aurora Serverless v1

Important

AWS a annoncé la date de fin de vie d’Aurora Serverless v1, qui sera le 31 mars 2025. Tous les clusters Aurora Serverless v1 qui ne seront pas migrés avant le 31 mars 2025 seront migrés vers Aurora Serverless v2 pendant la période de maintenance. Si la mise à niveau échoue, Amazon Aurora convertira le cluster sans serveur v1 en cluster provisionné avec la version de moteur équivalente pendant la période de maintenance. Le cas échéant, Amazon Aurora inscrira le cluster provisionné converti dans Amazon RDS Extended Support. Pour plus d’informations, consultez Support étendu Amazon RDS avec Amazon Aurora.

Vous pouvez configurer un cluster de bases de données Aurora Serverless v1 lorsque vous restaurez un instantané de cluster de bases de données provisionné avec l’AWS CLI ou l’API RDS.

Lorsque vous restaurez un instantané dans un cluster de bases de données Aurora Serverless v1, vous pouvez définir les valeurs spécifiques suivantes :

  • Unité de capacité Aurora minimale – Aurora Serverless v1 peut réduire la capacité jusqu’à cette unité de capacité.

  • Unité de capacité Aurora maximale – Aurora Serverless v1 peut augmenter la capacité jusqu’à cette unité de capacité.

  • Action d’expiration – Action à effectuer quand une modification de capacité expire parce qu’elle ne trouve pas de point de mise à l’échelle.Aurora Serverless v1 Le cluster de bases de données peut forcer l’application des nouveaux paramètres de capacité à votre cluster de bases de données si vous définissez l’option Forcer la mise à l’échelle de la capacité aux valeurs spécifiées.... Si vous n’activez pas cette option, il peut également annuler la modification de capacité. Pour plus d’informations, consultez Action de délai d’attente pour les modifications de capacité.

  • Pause after inactivity (Mise en pause après inactivité) – Durée sans trafic de base de données avant mise à l’échelle à une capacité de traitement égale à zéro. Lors de la reprise du trafic de base de données, Aurora reprend automatiquement la capacité de traitement et effectue une mise à l’échelle pour gérer le trafic.

Pour obtenir des informations générales sur la restauration d’un cluster de bases de données à partir d’un instantané, consultez Restauration à partir d’un instantané de cluster de bases de données.

Vous pouvez configurer un cluster de bases de données Aurora Serverless lorsque vous restaurez un instantané de cluster de bases de données provisionné avec l’AWS Management Console, l’AWS CLI ou l’API RDS.

Lorsque vous restaurez un instantané dans un cluster de bases de données Aurora Serverless, vous pouvez définir les valeurs spécifiques suivantes :

  • Unité de capacité Aurora minimale – Aurora Serverless peut réduire la capacité jusqu’à cette unité de capacité.

  • Unité de capacité Aurora maximale – Aurora Serverless peut augmenter la capacité jusqu’à cette unité de capacité.

  • Action d’expiration – Action à effectuer quand une modification de capacité expire parce qu’elle ne trouve pas de point de mise à l’échelle.Aurora Serverless v1 Le cluster de bases de données peut forcer l’application des nouveaux paramètres de capacité à votre cluster de bases de données si vous définissez l’option Forcer la mise à l’échelle de la capacité aux valeurs spécifiées.... Si vous n’activez pas cette option, il peut également annuler la modification de capacité. Pour plus d’informations, consultez Action de délai d’attente pour les modifications de capacité.

  • Pause after inactivity (Mise en pause après inactivité) – Durée sans trafic de base de données avant mise à l’échelle à une capacité de traitement égale à zéro. Lors de la reprise du trafic de base de données, Aurora reprend automatiquement la capacité de traitement et effectue une mise à l’échelle pour gérer le trafic.

Note

La version de l’instantané du cluster de bases de données doit être compatible avec Aurora Serverless v1. Pour obtenir la liste des versions prises en charge, consultez Aurora Serverless v1.

Pour restaurer un instantané dans un cluster Aurora Serverless v1 avec compatibilité MySQL 5.7, incluez les paramètres supplémentaires suivants :

  • --engine aurora-mysql

  • --engine-version 5.7

Les paramètres --engine et --engine-version vous permettent de créer un cluster Aurora Serverless v1 compatible MySQL 5.7 à partir d’un instantané Aurora compatible MySQL 5.6 ou Aurora Serverless v1. L’exemple suivant restaure un instantané de cluster compatible MySQL 5.6 nommé mydbclustersnapshot vers un cluster Aurora Serverless v1 compatible MySQL 5.7 nommé mynewdbcluster.

Pour Linux, macOS ou Unix :

aws rds restore-db-cluster-from-snapshot \
    --db-cluster-identifier mynewdbcluster \
    --snapshot-identifier mydbclustersnapshot \
    --engine-mode serverless \
    --engine aurora-mysql \
    --engine-version 5.7

Pour Windows :

aws rds restore-db-cluster-from-snapshot ^
    --db-instance-identifier mynewdbcluster ^
    --db-snapshot-identifier mydbclustersnapshot ^
    --engine aurora-mysql ^
    --engine-version 5.7

Vous pouvez, si vous le souhaitez, spécifier l’option --scaling-configuration pour configurer la capacité minimale, la capacité maximale et la mise en pause automatique s’il n’y a aucune connexion. Les valeurs de capacité valides sont notamment les suivantes :

  • Aurora MySQL: 1, 2, 4, 8, 16, 32, 64, 128 et 256.

  • Aurora PostgreSQL : 2, 4, 8, 16, 32, 64, 192 et 384.

Dans l’exemple suivant, vous restaurez à partir d’un instantané de cluster de bases de données créé précédemment nommé mydbclustersnapshot vers un nouveau cluster de bases de données nommé mynewdbcluster. Vous définissez le --scaling-configuration afin que le nouveau cluster de bases de données Aurora Serverless v1 puisse évoluer de 8 ACU à 64 ACU (unités de capacité Aurora) selon les besoins pour traiter la charge de travail. Une fois le traitement terminé et après 1 000 secondes sans connexion à prendre en charge, le cluster s’arrête jusqu’à ce que les demandes de connexion l’invitent à redémarrer.

Pour Linux, macOS ou Unix :

aws rds restore-db-cluster-from-snapshot \
    --db-cluster-identifier mynewdbcluster \
    --snapshot-identifier mydbclustersnapshot \
    --engine-mode serverless --scaling-configuration MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoPause=true

Pour Windows :

aws rds restore-db-cluster-from-snapshot ^
    --db-instance-identifier mynewdbcluster ^
    --db-snapshot-identifier mydbclustersnapshot ^
    --engine-mode serverless --scaling-configuration MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoPause=true

Pour configurer un cluster de bases de données Aurora Serverless v1 lorsque vous procédez à une restauration à partir d’un cluster de bases de données avec l’API RDS, exécutez l’opération RestoreDBClusterFromSnapshot et spécifiez serverless pour le paramètre EngineMode.

Vous pouvez, si vous le souhaitez, spécifier le paramètre ScalingConfiguration pour configurer la capacité minimale, la capacité maximale et la mise en pause automatique s’il n’y a aucune connexion. Les valeurs de capacité valides sont notamment les suivantes :

  • Aurora MySQL: 1, 2, 4, 8, 16, 32, 64, 128 et 256.

  • Aurora PostgreSQL : 2, 4, 8, 16, 32, 64, 192 et 384.