Backup et restauration pour Amazon RDS - AWS Directives prescriptives

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.

Backup et restauration pour Amazon RDS

Amazon RDS inclut des fonctionnalités permettant d'automatiser les sauvegardes de bases de données. Amazon RDS crée un instantané du volume de stockage de votre instance de données, en sauvegardant l'intégralité de ce dernier et pas uniquement les bases de données. À l'aide d'Amazon RDS, vous pouvez créer une fenêtre de sauvegarde pour les sauvegardes automatisées, créer des instantanés d'instances de base de données, et partager et copier des instantanés entre les régions et les comptes.

Amazon RDS propose deux options différentes pour sauvegarder et restaurer vos instances de base de données :

  • Les sauvegardes automatisées assurent point-in-time la restauration (PITR) de votre instance de base de données. Les sauvegardes automatiques sont activées par défaut lorsque vous créez une nouvelle instance de base de données.

    Amazon RDS effectue une sauvegarde quotidienne complète de vos données au cours d'une fenêtre de sauvegarde que vous définissez lorsque vous créez l'instance de base de données. Vous pouvez configurer une période de rétention allant jusqu'à 35 jours pour la sauvegarde automatique. Amazon RDS charge également les journaux de transaction pour les instances de données Amazon S3 toutes les 5 minutes. Amazon RDS utilise vos sauvegardes quotidiennes ainsi que vos journaux de transactions de base de données pour restaurer votre instance de base de données. Vous pouvez restaurer l'instance à tout moment pendant votre période de rétention, jusqu'àLatestRestorableTime (généralement, les cinq dernières minutes).

    Pour connaître l'heure de restauration la plus récente pour vos instances de base de données, utilisez l'appelDescribeDBInstances d'API. Vous pouvez également consulter l'onglet Description pour accéder à la base de données sur la console Amazon RDS.

    Lorsque vous lancez un PITR, les journaux de transactions sont combinés à la sauvegarde quotidienne la plus appropriée pour restaurer votre instance de base de données à l'heure requise.

  • Les snapshots DB sont des sauvegardes initiées par l'utilisateur que vous pouvez utiliser pour restaurer l'instance de données à un état connu aussi souvent que vous le souhaitez. Vous pouvez ensuite revenir à cet état à tout moment. Vous pouvez utiliser la console Amazon RDS ou l'appel d'CreateDBSnapshotAPI pour créer des instantanés de base de données. Ces instantanés sont conservés jusqu'à ce que vous utilisiez la console ou l'appel d'DeleteDBSnapshotAPI pour les supprimer explicitement.

Ces deux options de sauvegarde sont prises en charge par Amazon RDS inAWS Backup, qui fournit également d'autres fonctionnalités. AWS BackupEnvisagez de configurer un plan de sauvegarde standard pour vos bases de données Amazon RDS et d'utiliser les options de sauvegarde d'instance initiées par l'utilisateur lorsque vos plans de sauvegarde pour une base de données particulière sont uniques.

Amazon RDS empêche l'accès direct au stockage sous-jacent utilisé par l'instance de base de données. Cela vous empêche également d'exporter directement la base de données d'une instance de base de données RDS vers son disque local. Dans certains cas, vous pouvez utiliser des fonctions de sauvegarde et de restauration natives à l'aide d'utilitaires clients. Par exemple, vous pouvez utiliser la commande mysqldump avec une base de données MySQL Amazon RDS pour exporter une base de données vers votre ordinateur client local. Dans certains cas, Amazon RDS propose également des options avancées pour effectuer une sauvegarde et une restauration natives d'une base de données. Par exemple, Amazon RDS fournit des procédures stockées pour exporter et importer des sauvegardes de bases de données SQL Server dans les bases de données RDS.

Assurez-vous de tester minutieusement votre processus de restauration de base de données et son impact sur les clients de base de données dans le cadre de votre approche globale de sauvegarde et de restauration.

Utilisation d'enregistrements DNS CNAME pour réduire l'impact sur le client lors d'une restauration de base de données

Lorsque vous restaurez une base de données à l'aide du PITR ou d'un instantané d'instance de base de données RDS, une nouvelle instance de base de données avec un nouveau point de terminaison est créée. De cette façon, vous pouvez créer plusieurs instances de base de données à partir d'un instantané de base de données ou d'un moment précis. Des considérations particulières s'appliquent lorsque vous restaurez une instance de base de données RDS pour remplacer une instance de base de données RDS active. Par exemple, vous devez déterminer comment vous allez rediriger vos clients de base de données existants vers la nouvelle instance avec un minimum d'interruptions et de modifications. Vous devez également garantir la continuité et la cohérence des données au sein de la base de données en tenant compte du temps de restauration des données et du temps de restauration lorsque la nouvelle instance commence à recevoir des écritures.

Vous pouvez créer un enregistrement DNS CNAME distinct qui pointe vers le point de terminaison de votre instance de base de données et demander à vos clients d'utiliser ce nom DNS. Vous pouvez ensuite mettre à jour le CNAME pour qu'il pointe vers un nouveau point de terminaison restauré sans avoir à mettre à jour vos clients de base de données.

Réglez la durée de vie (TTL) pour votre enregistrement CNAME à une valeur appropriée. Le TTL que vous spécifiez détermine la durée pendant laquelle l'enregistrement est mis en cache auprès des résolveurs DNS avant qu'une autre demande ne soit effectuée. Il est important de noter que certains résolveurs ou applications DNS peuvent ne pas respecter le TTL et qu'ils peuvent mettre en cache l'enregistrement plus longtemps que le TTL. Pour Amazon Route 53, si vous spécifiez une valeur plus longue (par exemple, 172 800 secondes, ou deux jours), vous réduirez le nombre d'appels que les résolveurs récursifs DNS doivent passer à Route 53 pour obtenir les dernières informations de cet enregistrement. Cela réduit la latence et votre facture pour le service Route 53. Pour plus d'd'd'informations, consultez Comment Amazon Route 53 achemine le trafic de votre domaine.

Les applications et les systèmes d'exploitation clients peuvent également mettre en cache les informations DNS que vous devez vider ou redémarrer pour lancer une nouvelle demande de résolution DNS et récupérer l'enregistrement CNAME mis à jour.

Lorsque vous lancez une restauration de base de données et que vous transférez le trafic vers votre instance restaurée, vérifiez que tous vos clients écrivent sur votre instance restaurée plutôt que sur votre instance précédente. Votre architecture de données peut prendre en charge la restauration de votre base de données, la mise à jour du DNS pour transférer le trafic vers votre instance restaurée, puis la correction de toutes les données qui peuvent encore être écrites sur votre instance précédente. Si ce n'est pas le cas, vous pouvez arrêter votre instance existante avant de mettre à jour l'enregistrement DNS CNAME. Tous les accès se font alors à partir de votre instance récemment restaurée. Cela peut entraîner temporairement des problèmes de connexion pour certains de vos clients de base de données que vous pouvez gérer individuellement. Pour réduire l'impact sur le client, vous pouvez effectuer la restauration de la base de données pendant une fenêtre de maintenance.

Écrivez vos applications de manière à gérer les échecs de connexion à la base de données avec élégance, en réessayant en utilisant un backoff exponentiel. Cela permet à votre application de se rétablir lorsqu'une connexion à la base de données devient indisponible lors d'une restauration sans provoquer de panne inattendue de votre application.

Une fois le processus de restauration terminé, vous pouvez conserver votre instance précédente dans un état arrêté. Vous pouvez également utiliser les règles des groupes de sécurité pour limiter le trafic vers votre instance précédente jusqu'à ce que vous soyez certain qu'elle n'est plus nécessaire. Pour une approche de mise hors service progressive, limitez d'abord l'accès du groupe de sécurité à une base de données en cours d'exécution. Vous pouvez éventuellement arrêter l'instance quand elle n'est plus nécessaire. Enfin, prenez un instantané de l'instance de données et supprimez-la.