PolarDB:FAQ sur la sauvegarde et la restauration

Les sauvegardes PolarDB utilisent deux métriques : la taille logique de chaque sauvegarde et la taille physique de l'ensemble des sauvegardes.

• Taille logique : volume de données (données et journaux) à un instantané cohérent.

• Taille physique : taille de la chaîne d'instantanés de sauvegarde. PolarDB utilise un mécanisme de chaîne d'instantanés incrémentiels pour les sauvegardes. Ce mécanisme conserve l'état de l'instantané à chaque instant. Lorsqu'un bloc de données est modifié, le système conserve la version historique du bloc pour l'instantané. Les données ne sont supprimées de la chaîne qu'à l'expiration des instantanés antérieurs.

  Exemple : supposons que le volume de données d'un cluster soit de 100 Go. Le cycle de sauvegarde pour les sauvegardes de niveau 1/sauvegardes de données est quotidien et la période de rétention est de 3 jours.

  Date	Processus de modification des données	Taille des données dans le stockage	Taille correspondante de la chaîne d'instantanés (sauvegarde physique)
  Lundi	Ajout de 100 Go de données	100 Go + 100 Go = 200 Go	+ 0 Go = 0 Go Remarque Cela ne tient pas compte de la taille de la chaîne d'instantanés (sauvegarde physique) avant lundi. Dans un scénario réel, l'incrément n'est pas de 0 Go. Les blocs de données référencés par un instantané peuvent ne pas être entièrement écrits. Si de nouvelles données doivent être écrites dans ces blocs, une nouvelle copie est créée. Par conséquent, l'écriture de données après la création d'un instantané augmente également la taille de la chaîne d'instantanés (sauvegarde physique).
  Mardi	Modification de 1 Go de données et ajout de 1 Go de données	200 Go + 1 Go = 201 Go	0 Go + 1 Go = 1 Go
  Mercredi	Suppression de 100 Go de données Remarque Les données supprimées correspondent aux données ajoutées lundi.	201 Go - 100 Go = 101 Go	1 Go + 100 Go = 101 Go
  Jeudi	Modification de 1 Go de données et ajout de 1 Go de données	101 Go + 1 Go = 102 Go	101 Go + 1 Go = 102 Go
  Vendredi	Modification de 1 Go de données et ajout de 1 Go de données	102 Go + 1 Go = 103 Go	102 Go + 1 Go = 103 Go Remarque À ce stade, l'instantané de lundi a expiré. Cependant, la taille de la chaîne d'instantanés (sauvegarde physique) ne diminue pas. Le système continue de conserver la version historique des blocs de données pour l'ensemble de sauvegarde de mardi.
  Samedi	Modification de 1 Go de données et ajout de 1 Go de données	103 Go + 1 Go = 104 Go	103 Go + 1 Go - 100 Go = 4 Go Remarque À ce stade, l'instantané de mardi a expiré. Le système n'a plus besoin de conserver la version historique des blocs de données pour les données ajoutées lundi et supprimées mercredi. Par conséquent, la taille de la chaîne d'instantanés (sauvegarde physique) diminue de 100 Go.

  Remarque

  • L'exemple précédent est fourni à titre indicatif uniquement. Il prend en compte uniquement les données métier du cluster et n'inclut pas les fichiers système. La taille réelle peut différer.

  • Pour réduire la taille de la sauvegarde physique sans modifier la fréquence des modifications des blocs de données, réduisez le cycle de sauvegarde et la période de rétention. Pour plus d'informations, consultez Comment puis-je réduire le volume de données et les coûts des sauvegardes de niveau 1, des sauvegardes de niveau 2 et des sauvegardes de journaux ?

Non. La taille physique représente des métriques différentes selon le type de sauvegarde.

Sauvegarde de niveau 1

La taille physique des sauvegardes de niveau 1 ne correspond pas à la somme de toutes les tailles de sauvegarde logique. Elle correspond à la somme de l'espace physique exclusivement occupé par toutes les sauvegardes de niveau 1 (instantanés).

Sauvegarde de données

La taille physique des sauvegardes de données ne correspond pas à la somme de toutes les tailles de sauvegarde logique. Elle correspond à la somme de l'espace physique exclusivement occupé par toutes les sauvegardes de données (instantanés).

Les sauvegardes PolarDB disposent de deux métriques de taille : la taille logique de chaque ensemble de sauvegarde et la taille physique de l'ensemble des sauvegardes. PolarDB utilise un mécanisme de chaîne d'instantanés pour les sauvegardes, où chaque bloc de données unique n'est stocké qu'une seule fois. Par conséquent, la taille physique totale est inférieure à la somme des tailles logiques et peut parfois être inférieure à la taille logique d'une seule sauvegarde.

Vous êtes facturé pour l'espace de stockage utilisé par les sauvegardes de niveau 1/sauvegardes de données, les sauvegardes de niveau 2 et les sauvegardes de journaux. Les sauvegardes de niveau 1/sauvegardes de données et les sauvegardes de journaux sont activées par défaut et un quota gratuit est fourni. Les sauvegardes de niveau 2 sont désactivées par défaut. Pour plus d'informations, consultez Stockage des sauvegardes (facturation pour l'utilisation dépassant le quota gratuit).

Les coûts de stockage des sauvegardes dépendent du Storage Type de votre cluster.

• Enterprise SSD (PL0, PL1, PL2, PL3 et AutoPL)

  • Formule : Coût horaire = (Taille totale de la sauvegarde de données - Quota gratuit) × Prix horaire

  • Quota gratuit : Capacité de stockage × 50 %

  Exemple : En Chine continentale, si la taille totale de la sauvegarde de données est de 700 Go et que l'utilisation du stockage de la base de données est de 1 000 Go, le coût horaire est de [700 Go - (1 000 Go × 50 %)] × 0,00003231 USD/Go/heure = 0,006462 USD/heure. Pour plus d'informations, consultez Stockage des sauvegardes (facturation pour l'utilisation dépassant le quota gratuit).

• PSL4/PSL5

  • Formule : Coût horaire = (Taille totale de la sauvegarde de niveau 1 - Quota gratuit) × Prix horaire

  • Quota gratuit : La formule de calcul du quota gratuit varie selon la Storage Payment Method. Les formules sont les suivantes :

    • Abonnement (facturé par espace) : Capacité de stockage × 50 %.

    • Paiement à l'utilisation (facturé par capacité) : Utilisation du stockage × 50 %.

  Exemple : Pour la classe de stockage PSL5 en Chine continentale, si la taille totale de la sauvegarde de niveau 1 (instantané) est de 700 Go et que l'utilisation du stockage de la base de données est de 1 000 Go, le coût horaire est de [700 Go - (1 000 Go × 50 %)] × 0,000464 USD/Go/heure = 0,0928 USD/heure. Pour plus d'informations, consultez Stockage des sauvegardes (facturation pour l'utilisation dépassant le quota gratuit).

• Réduisez la période de rétention des données de sauvegarde selon vos besoins. Pour plus d'informations, consultez Configurer une politique de sauvegarde.

  • Réduisez la période de rétention des sauvegardes de niveau 1, par exemple de 7 jours à 3 jours.

  • Réduisez la période de rétention des sauvegardes de niveau 2, par exemple de 70 jours à 30 jours.

    Remarque

    La réduction de la période de rétention des sauvegardes de niveau 1 et de niveau 2 comporte des risques. Si un ensemble de sauvegarde dont vous avez besoin est plus ancien que la période de rétention, vous ne pourrez pas l'utiliser pour restaurer les données.

  • Réduisez la période de rétention des sauvegardes de journaux, par exemple de 7 jours à 3 jours.

    Remarque

    La réduction de la période de rétention des sauvegardes de journaux comporte des risques. Vous ne pourrez pas effectuer de restauration à un instant donné antérieur à la sauvegarde de journal la plus ancienne conservée.

• Réduisez la fréquence de sauvegarde (cycle de sauvegarde) selon vos besoins. Pour plus d'informations, consultez Configurer une politique de sauvegarde.

  Le cycle de sauvegarde ne peut pas être entièrement vidé. Vous devez sélectionner au moins deux jours par semaine, ce qui signifie que les sauvegardes sont effectuées au moins deux fois par semaine. Si vous ne conservez que deux sauvegardes par semaine (par exemple, le dimanche et le vendredi), la restauration des données à un instant donné entre les deux sauvegardes repose sur les sauvegardes de journaux, ce qui augmente le temps nécessaire à la restauration.

  • Réduisez la fréquence des sauvegardes de niveau 1, par exemple d'une fois par jour à trois fois par semaine.

    Remarque

    La réduction de la fréquence des sauvegardes de niveau 1 peut augmenter le temps nécessaire à une restauration à un instant donné.

  • Réduisez la fréquence des sauvegardes de niveau 2, par exemple de trois fois par semaine à deux fois par semaine.

• Supprimez les ensembles de sauvegarde inutiles de la corbeille du cluster pour réduire les coûts des sauvegardes de niveau 2. Pour plus d'informations, consultez Supprimer une sauvegarde.

Oui.

La période de rétention des fichiers de sauvegarde manuels est déterminée par la Backup Retention Period que vous définissez pour la Level-1 Backup ou la Level-2 Backup sous Data Backup dans les Backup Policy Settings.

Consultez la taille d'une sauvegarde de niveau 2 dans l'onglet Data Backups. Pour accéder à cet onglet, accédez à la page Settings and Management > Backup and Restoration dans la console.

Dans l'onglet Backup Sets, la colonne Backup Size affiche la taille de chaque enregistrement de sauvegarde (par exemple, 30,53 Mo ou 22,50 Mo). Le haut de la page affiche également la taille totale des sauvegardes de niveau 1 (instantanés) et le quota gratuit.

Si vous choisissez de conserver les ensembles de sauvegarde lors de la libération d'un cluster, vous pouvez les consulter dans la corbeille du cluster dans la console PolarDB. Pour plus d'informations, consultez Présentation de la corbeille du cluster.

Vous pouvez télécharger un fichier de sauvegarde sur votre ordinateur. Toutefois, vous ne pouvez pas utiliser directement les données de sauvegarde téléchargées pour restaurer un cluster PolarDB for MySQL. Vous pouvez les utiliser pour restaurer des données à partir d'un fichier de sauvegarde vers une base de données MySQL autogérée.

Utilisez l'une des méthodes suivantes pour archiver à long terme les fichiers de sauvegarde PolarDB for MySQL vers OSS :

• Utilisez Alibaba Cloud Database Backup Service (DBS) pour stocker les fichiers de sauvegarde PolarDB for MySQL dans OSS. Effectuez les étapes suivantes :

  1. Dans la console OSS, créez un bucket.

  2. Configurez manuellement une planification de sauvegarde logique pour PolarDB for MySQL. Une fois la sauvegarde terminée, vous pouvez gérer l'ensemble de sauvegarde. Par exemple, vous pouvez interroger les ensembles de sauvegarde ou télécharger les ensembles de sauvegarde.

• Utilisez mysqldump ou Data Management (DMS) pour exporter les fichiers de sauvegarde, puis téléchargez-les vers OSS. Effectuez les étapes suivantes :

  1. Utilisez mysqldump ou DMS pour exporter les fichiers de sauvegarde PolarDB for MySQL.

  2. Téléchargez manuellement les fichiers de sauvegarde exportés vers OSS. Pour plus d'informations, consultez Télécharger des fichiers.

Le produit ne prend pas actuellement en charge la configuration directe d'alertes pour les échecs de sauvegarde. Toutefois, vous pouvez mettre en œuvre votre propre mécanisme d'alerte. Par exemple, appelez périodiquement l'opération DescribeBackups pour récupérer le champ BackupStatus d'une tâche de sauvegarde. Vérifiez ensuite son statut et déclenchez une alerte personnalisée, telle qu'un e-mail, un message texte ou une notification sur une plateforme de surveillance, si le statut est Failed.

Les journaux physiques d'un cluster PolarDB sont des journaux redo. Chaque fichier de journal redo a une taille fixe de 1 Go. Une sauvegarde n'est déclenchée qu'après l'écriture complète d'un fichier de 1 Go. Si un cluster a été récemment créé ou présente un faible volume d'accès, le fichier de journal redo de 1 Go peut ne pas être plein. Dans ce cas, aucune sauvegarde n'est déclenchée et aucun enregistrement n'apparaît dans la liste des sauvegardes de journaux redo.

Cette fonctionnalité est prise en charge.

Non. Une restauration à un instant donné restaure d'abord une sauvegarde complète des données antérieure à l'instant sélectionné dans le cluster. Ensuite, elle utilise les journaux redo pour restaurer de manière incrémentielle les données jusqu'à l'instant sélectionné.

Oui.

Oui.

Non. PolarDB for MySQL crée une nouvelle base de données et une nouvelle table dans le cluster actuel pour l'opération de restauration.