PolarDB:FAQ sur la sauvegarde et la restauration

Les sauvegardes PolarDB s'évaluent selon 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 dans le temps.

• Taille physique : Taille de la chaîne de snapshots de sauvegarde. PolarDB utilise un mécanisme de chaîne de snapshots incrémentiels pour les sauvegardes. Ce mécanisme conserve l'état du snapshot à chaque instant. Lorsqu'un bloc de données est modifié, le système conserve la version historique de ce bloc pour le snapshot. Les données ne sont supprimées de la chaîne de snapshots que lorsque les snapshots antérieurs expirent.

  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 d'une fois par jour, avec une période de rétention de 3 jours.

  Date	Processus de modification des données	Taille des données en stockage	Taille correspondante de la chaîne de snapshots (sauvegarde physique)
  Lundi	Ajout de 100 Go de données	100 Go + 100 Go = 200 Go	+ 0 Go = 0 Go Remarque Ceci ne prend pas en compte la taille de la chaîne de snapshots (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 snapshot peuvent ne pas être entièrement écrits. Si de nouvelles données doivent être écrites dans ces blocs, une nouvelle copie de ceux-ci est créée. Par conséquent, l'écriture de données après la création d'un snapshot augmente également la taille de la chaîne de snapshots (sauvegarde physique).
  Mardi	Modification d'1 Go de données et ajout d'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 à celles ajoutées lundi.	201 Go - 100 Go = 101 Go	1 Go + 100 Go = 101 Go
  Jeudi	Modification d'1 Go de données et ajout d'1 Go de données	101 Go + 1 Go = 102 Go	101 Go + 1 Go = 102 Go
  Vendredi	Modification d'1 Go de données et ajout d'1 Go de données	102 Go + 1 Go = 103 Go	102 Go + 1 Go = 103 Go Remarque À ce stade, le snapshot de lundi a expiré. Cependant, la taille de la chaîne de snapshots (sauvegarde physique) ne diminue pas. Le système continue de conserver la version historique des blocs de données pour le jeu de sauvegarde de mardi.
  Samedi	Modification d'1 Go de données et ajout d'1 Go de données	103 Go + 1 Go = 104 Go	103 Go + 1 Go - 100 Go = 4 Go Remarque À ce stade, le snapshot 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 de snapshots (sauvegarde physique) diminue de 100 Go.

  Remarque

  • L'exemple ci-dessus est fourni à titre indicatif uniquement. Il ne considère que les données métier du cluster et n'inclut pas les fichiers système. La taille réelle peut varier.

  • Pour réduire la taille des sauvegardes physiques sans modifier la fréquence des modifications de blocs de données, réduisez le cycle de sauvegarde et la période de rétention. Pour plus d'informations, consultez Comment 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 différentes métriques 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 sauvegardes logiques. Elle représente la somme de l'espace physique occupé exclusivement par toutes les sauvegardes de niveau 1 (snapshots).

Sauvegarde de données

La taille physique des sauvegardes de données ne correspond pas à la somme de toutes les tailles de sauvegardes logiques. Elle représente la somme de l'espace physique occupé exclusivement par toutes les sauvegardes de données (snapshots).

Les sauvegardes PolarDB comportent deux métriques de taille : la taille logique de chaque jeu de sauvegarde et la taille physique de l'ensemble des sauvegardes. PolarDB utilise un mécanisme de chaîne de snapshots 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.

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 est facturé. Les sauvegardes de niveau 1/sauvegardes de données et les sauvegardes de journaux sont activées par défaut, avec un quota gratuit fourni. Les sauvegardes de niveau 2 sont désactivées par défaut. Pour plus d'informations, consultez Stockage de sauvegarde (facturé 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, and AutoPL)

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

  • Quota gratuit : Capacité de stockage × 50 %

  Exemple : En Chine continentale, si la taille totale des sauvegardes 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 de sauvegarde (facturé pour l'utilisation dépassant le quota gratuit).

• PSL4/PSL5

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

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

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

    • Pay-as-you-go (facturé par capacité) : Utilisation du stockage × 50 %.

  Exemple : Pour la classe de stockage PSL5 en Chine continentale, si la taille totale des sauvegardes de niveau 1 (snapshot) 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 de sauvegarde (facturé pour l'utilisation dépassant le quota gratuit).

• Raccourcissez 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 jeu de sauvegarde dont vous avez besoin est antérieur à la période de rétention, vous ne pouvez pas l'utiliser pour restaurer des 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 pouvez pas effectuer de restauration à un point dans le temps antérieur au journal de sauvegarde conservé le plus ancien.

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

  • Diminuez 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 pour une restauration à un point dans le temps.

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

• Supprimez les jeux de sauvegarde inutiles de la corbeille du cluster afin de 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 manuelle 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 (snapshots) ainsi que le quota gratuit.

Si vous choisissez de conserver les jeux de sauvegarde lors de la libération d'un cluster, consultez-les dans la corbeille du cluster via la console PolarDB. Pour plus d'informations, consultez Corbeille de 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. Utilisez-les plutôt pour restaurer des données d'un fichier de sauvegarde vers une base de données MySQL auto-gé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. Procédez comme suit :

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

  2. Configurez manuellement un plan de sauvegarde logique pour PolarDB for MySQL. Une fois la sauvegarde terminée, gérez le jeu de sauvegarde. Par exemple, interrogez les jeux de sauvegarde ou téléchargez les jeux de sauvegarde.

• Utilisez mysqldump ou Data Management (DMS) pour exporter les fichiers de sauvegarde, puis téléchargez-les vers OSS. Procédez comme suit :

  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. Cependant, mettez 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 état et déclenchez une alerte personnalisée, telle qu'un e-mail, un SMS ou une notification sur une plateforme de surveillance, si l'état 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 que lorsqu'un fichier de 1 Go est complètement écrit. Si un cluster a été créé récemment 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 point dans le temps restaure d'abord une sauvegarde complète des données antérieure au point sélectionné vers le cluster. Ensuite, elle utilise les journaux redo pour restaurer incrémentiellement les données jusqu'au point dans le temps sélectionné.

Pris en charge.

Pris en charge.

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.