Présentation de la sauvegarde et de la restauration d'un cluster de bases de données Aurora - Amazon Aurora

Présentation de la sauvegarde et de la restauration d'un cluster de bases de données Aurora

Dans les sections suivantes, vous pourrez trouver des informations sur les sauvegardes Aurora et sur la manière de restaurer votre cluster de bases de données Aurora à l'aide d'AWS Management Console.

Note

Vous pouvez aussi utiliser AWS Backup pour gérer les sauvegardes des instances de base de données Aurora. Les sauvegardes gérées par AWS Backup sont considérées comme des instantanés de cluster manuels pour le quota d’instantanés de cluster manuels. Les noms des sauvegardes créées avec AWS Backup se terminent par awsbackup:AWS-Backup-job-number. Pour de plus amples informations sur AWS Backup, veuillez consulter le Manuel du développeur AWS Backup.

Tolérance aux pannes pour un cluster de base de données Aurora

Un cluster de base de données Aurora est tolérant aux pannes par définition. Le volume de cluster couvre plusieurs zones de disponibilité d'une même région AWS et chacune d'elles contient une copie des données du volume de cluster. Cette fonctionnalité signifie que votre cluster de base de données peut tolérer une défaillance d'une zone de disponibilité sans perte de données et uniquement une brève interruption de service.

Si l'instance principale d'un cluster de base de données utilisant la réplication à un seul maître échoue, Aurora bascule automatiquement vers une nouvelle instance principale de l'une des deux façons suivantes :

  • Par la promotion d'un réplica Aurora existant vers la nouvelle instance principale

  • Par la création d'une nouvelle instance principale

Si le cluster de bases de données possède un ou plusieurs réplicas Aurora, un réplica Aurora est promu vers l'instance principale lors d'un événement d'échec. Un événement d'échec se traduit par une brève interruption, pendant laquelle les opérations de lecture et d'écriture échouent avec une exception. Cependant, le service est généralement restauré en moins de 120 secondes, et souvent en moins de 60 secondes. Pour augmenter la disponibilité de votre cluster de base de données, nous vous recommandons de créer au moins un ou plusieurs réplicas Aurora dans deux zones de disponibilité ou plus.

Vous pouvez personnaliser l'ordre dans lequel vos réplicas Aurora sont promus vers l'instance principale après un échec, en affectant à chaque réplica une priorité. Les priorités s'étendent de la valeur 0 pour la plus haute priorité à la valeur 15 pour la plus basse priorité. Si l'instance principale échoue, Amazon RDS promeut le réplica Aurora avec la plus haute priorité vers la nouvelle instance principale. Vous pouvez modifier la priorité d'un réplica Aurora à tout moment. La modification de la priorité ne déclenche pas un basculement.

Plusieurs réplicas Aurora peuvent partager la même priorité, ce qui se traduit par des niveaux de promotion. Si deux réplicas Aurora ou plus partagent la même priorité, Amazon RDS promeut le réplica le plus grand en taille. Si deux réplicas Aurora ou plus partagent les mêmes priorité et taille, Amazon RDS promeut un réplica arbitraire du même niveau de promotion.

Si le cluster de base de données ne contient aucun réplica Aurora, l'instance principale est recréée pendant un événement d'échec. Un événement d'échec se traduit par une interruption, pendant laquelle les opérations de lecture et d'écriture échouent avec une exception. Le service est rétabli quand la nouvelle instance principale est créée, ce qui prend généralement moins de 10 minutes. La promotion d'un réplica Aurora vers l'instance principale est beaucoup plus rapide que la création d'une nouvelle instance principale.

Note

Amazon Aurora prend aussi en charge la réplication avec une base de données MySQL externe ou une instance de base de données MySQL RDS. Pour plus d'informations, consultez Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires).

Sauvegardes

Aurora sauvegarde automatiquement votre volume de cluster et conserve les données de restauration pendant la période de rétention des sauvegardes. Les sauvegardes Aurora étant continues et incrémentielles, vous pouvez rapidement procéder à une restauration à un point quelconque de la période de rétention des sauvegardes. Aucun impact sur les performances ou interruption du service de base de données ne se produit lors de l'écriture des données de sauvegarde. Vous pouvez spécifier une période de rétention des sauvegardes, comprise entre 1 et 35 jours, lorsque vous créez ou modifiez un cluster de base de données. Les sauvegardes Aurora sont stockées dans Amazon S3.

Si vous souhaitez conserver une sauvegarde au-delà de la période de rétention, vous pouvez aussi prendre un instantané des données dans votre volume de cluster. Comme Aurora conserve les données des restaurations incrémentielles pendant la totalité de la période de rétention des sauvegardes, vous avez uniquement besoin de créer un instantané pour les données que vous voulez garder au-delà de la période de rétention des sauvegardes. Vous pouvez créer un nouveau cluster de base de données à partir de l'instantané.

Note
  • Pour les clusters de bases de données Amazon Aurora, la période de rétention des sauvegardes par défaut est d'une journée quel que soit le mode de création du cluster de bases de données.

  • Vous ne pouvez pas désactiver les sauvegardes automatiques sur Aurora. La période de rétention des sauvegardes pour Aurora est gérée par le cluster de base de données.

Le coût de stockage des sauvegardes dépend du volume de données d'instantanés et de sauvegardes Aurora que vous conservez et de la durée pendant laquelle vous les conservez. Pour plus d'informations sur le stockage associé aux instantanés et aux sauvegardes Aurora, consultez Présentation de l'utilisation du stockage des sauvegardes Aurora. Pour plus d'informations sur les coûts de stockage des sauvegardes Aurora, consultez Tarification d'Amazon RDS pour Aurora. Après la suppression du cluster Aurora associé à un instantané, le stockage de cet instantané est soumis aux frais standard de stockage des sauvegardes pour Aurora.

Restauration des données

Vous pouvez récupérer vos données en créant un cluster de bases de données Aurora à partir des données de sauvegarde qu'Aurora conserve ou d'un instantané de cluster de bases de données que vous avez enregistré. Vous pouvez restaurer rapidement une nouvelle copie d'un cluster de bases de données créé à partir des données de sauvegarde à un point quelconque de la période de rétention des sauvegardes. La nature continue et incrémentielle des sauvegardes Aurora pendant la période de rétention signifie que vous n'avez pas besoin de prendre fréquemment des instantanés de vos données pour pouvoir améliorer les temps de restauration.

Pour déterminer la date de restauration la plus ancienne ou la plus récente d'une instance de base de données, recherchez les valeurs Latest Restorable Time ou Earliest Restorable Time sur la console RDS. Pour obtenir des informations sur l'affichage de ces valeurs, consultez Affichage d'un cluster de base de données Amazon Aurora. La dernière date de restauration d'un cluster de base de données est le point le plus récent auquel vous pouvez restaurer votre cluster de base de données, généralement dans les 5 minutes qui précèdent l'heure actuelle. L'heure de restauration la plus ancienne spécifie jusqu'à quelle date vous pouvez remonter au sein de la période de rétention des sauvegardes pour restaurer votre volume de cluster.

Vous pouvez déterminer à quel moment la restauration d'un cluster de bases de données est complète à l'aide des valeurs Latest Restorable Time et Earliest Restorable Time. Les valeurs Latest Restorable Time et Earliest Restorable Time retournent NULL tant que l'opération de restauration n'est pas terminée. Vous ne pouvez pas demander une opération de sauvegarde ou de restauration si les valeurs Latest Restorable Time ou Earliest Restorable Time retournent NULL.

Pour plus d'informations sur la restauration d'un cluster de bases de données à une date spécifiée, consultez Restauration d'une cluster de base de données à une date spécifiée.

Clonage de bases de données pour Aurora

Vous pouvez aussi utiliser le clonage de base de données pour cloner les bases de données de votre cluster de bases de données Aurora dans un nouveau cluster de bases de données au lieu de restaurer un instantané de cluster de bases de données. Les bases de données clones n'utilisent qu'un espace supplémentaire minime lorsqu'elles sont créées la première fois. Les données sont copiées uniquement lorsqu'elles changent, sur les bases de données sources ou sur les bases de données clones. Vous pouvez créer plusieurs clones à partir du même cluster de base de données ou créer des clones supplémentaires même à partir d'autres clones. Pour plus d'informations, consultez Clonage de bases de données dans un cluster de base de données Aurora.

Retour sur trace

Aurora MySQL permet désormais d'effectuer un retour sur trace d'un cluster de base de données à une heure spécifique, sans restaurer les données à partir d'une sauvegarde. Pour plus d'informations, consultez Retour sur trace d'un cluster de base de données Aurora.