Restaurer un Aurora Serverless v1 Cluster DB - 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.

Restaurer un Aurora Serverless v1 Cluster DB

Important

AWS a annoncé la end-of-life date de Aurora Serverless v1: 31 mars 2025. Tous Aurora Serverless v1 les clusters qui ne seront pas migrés d'ici le 31 mars 2025 seront migrés vers Aurora Serverless v2 pendant la fenêtre de maintenance. Si la mise à niveau échoue, Amazon Aurora convertit le cluster Serverless 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 de plus amples informations, veuillez consulter Support étendu d'Amazon RDS avec ).

Vous pouvez configurer un Aurora Serverless v1 Cluster de base de données lorsque vous restaurez un instantané de cluster de base de données provisionné à l'aide de l'API AWS CLI ou de l'API RDS.

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

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

  • Unité de capacité maximale d'Aurora — Aurora Serverless v1 peut augmenter la capacité jusqu'à cette unité de capacité.

  • Action d'expiration – Action à effectuer lorsqu'une modification de capacité expire car 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 base de données à partir d'un instantané, consultez Restauration à partir d'un instantané de cluster de base de données.

Vous pouvez configurer un Aurora Serverless Cluster de base de données lorsque vous restaurez un instantané de cluster de base de données provisionné à l'aide de l' AWS Management Console API, de AWS CLI, ou de l'API RDS.

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

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

  • Unité de capacité maximale d'Aurora — Aurora Serverless peut augmenter la capacité jusqu'à cette unité de capacité.

  • Action d'expiration – Action à effectuer lorsqu'une modification de capacité expire car 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 du snapshot du cluster de base de données doit être compatible avec Aurora Serverless v1. Pour obtenir la liste des versions prises en charge, consultezAurora Serverless v1.

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

  • --engine aurora-mysql

  • --engine-version 5.7

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

Dans 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

Dans 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 effectuez une restauration à partir d'un instantané de cluster de base de données créé précédemment et nommé mydbclustersnapshot vers un nouveau cluster de base de données nommémynewdbcluster. Vous définissez le --scaling-configuration pour que le nouveau Aurora Serverless v1 Le cluster de base de données peut évoluer de 8 ACUs à 64 ACUs (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.

Dans 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

Dans 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 Aurora Serverless v1 Cluster de base de données lorsque vous effectuez une restauration à partir d'un cluster de base de données à l'aide de l'API RDS, exécutez l'DBClusterFromSnapshotopération de restauration et spécifiez serverless le EngineMode paramètre.

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.