Si vous modifiez accidentellement des tables, vous pouvez utiliser la fonctionnalité de restauration de bases de données et de tables pour restaurer les tables concernées dans le cluster d'origine.
Vous pouvez restaurer les bases de données et les tables en effectuant une restauration à un instant donné ou à partir d'un ensemble de sauvegarde (snapshot). Si votre point de restauration cible correspond à l'heure de création d'un ensemble de sauvegarde, la restauration à partir de cet ensemble est plus pratique. Si votre point de restauration cible diffère de l'heure de création de tout ensemble de sauvegarde existant, vous devez utiliser une restauration à un instant donné.
Le nouveau workflow de restauration de bases de données et de tables, qui inclut la fonctionnalité Fast Import, est disponible en déploiement progressif pour les clusters PolarDB for MySQL 8.0.1 dont la version mineure est 8.0.1.1.49 ou ultérieure.
Processus global
Que vous utilisiez une restauration à un instant donné ou une restauration à partir d'un ensemble de sauvegarde (snapshot), le processus clé reste identique. Tout d'abord, un nœud temporaire est créé et les données d'un instant précis y sont restaurées. Ensuite, les données sont restaurées depuis le nœud temporaire vers le cluster d'origine.
La nouvelle version de la fonctionnalité de restauration de bases de données et de tables a été publiée le 3 avril 2024. Par rapport à l'ancienne version, celle-ci réduit le temps nécessaire pour restaurer les données dans le cluster d'origine. Les données sont également synchronisées automatiquement avec les clusters Hot Standby et les clusters secondaires GDN, ce qui réduit considérablement la durée de restauration.
Scénarios
La fonctionnalité de restauration de bases de données et de tables prend en charge PolarDB Enterprise Edition et Standard Edition, mais nécessite des versions de révision de cluster spécifiques. Le tableau suivant répertorie les versions de révision minimales requises pour différents scénarios.
Fonctionnalités de base : version de révision minimale requise pour prendre en charge la restauration de bases de données et de tables.
Nouveau processus de restauration : une version de révision plus élevée est requise pour bénéficier de l'optimisation de la vitesse du nouveau processus de restauration.
|
Série d'édition |
Version MySQL |
Architecture |
Fonctionnalités de base (version de révision minimale) |
Nouveau processus de restauration (version de révision minimale) |
|
Enterprise Edition (Cluster Edition) |
5,6 |
X86 |
|
|
|
5,7 |
X86 |
|
|
|
|
8.0.1 |
X86 |
|
|
|
|
8.0.2 |
X86 |
|
|
|
|
Standard Edition |
5,6 |
X86 |
|
|
|
5,7 |
X86 |
|
|
|
|
8.0.1 |
X86 |
|
|
|
|
Yitian (ARM) |
|
|
||
|
8.0.2 |
X86 |
|
|
Vous pouvez afficher la version du noyau de votre cluster dans la section Configurations de la page Basic Information de votre cluster PolarDB for MySQL.
Diagrammes de flux des anciennes et nouvelles versions
Si la version de révision de votre cluster répond aux exigences, le nouveau workflow de restauration de bases de données et de tables est utilisé automatiquement. Les diagrammes suivants illustrent les anciens et nouveaux workflows.
Nous vous recommandons de restaurer les données pendant les heures creuses.
Durée estimée
Durée estimée pour chaque étape
Étape | Durée estimée |
Créez un nœud temporaire et restaurez les données depuis le jeu de sauvegarde vers ce nœud. | Environ 3 à 10 minutes. |
Restaurez les données incrémentielles à partir des journaux redo. Remarque Cette étape est requise uniquement pour une restauration à un instant précis. La durée nécessaire dépend de la taille des journaux redo à appliquer. | 1,5 Go/minute. |
Restaurez les données dans le cluster d'origine. | Pour la durée estimée, consultez la section Référence des tests de vitesse de restauration des bases de données et des tables. |
Les données précédentes sont fournies à titre indicatif uniquement.
La restauration de plusieurs téraoctets de données peut prendre beaucoup de temps. Pour accélérer le processus, utilisez la fonctionnalité de restauration complète à partir d'un jeu de sauvegarde. Cette opération ne prend généralement que quelques minutes. Pour plus d'informations, consultez la rubrique Restauration à partir d'un jeu de sauvegarde.
Référence des tests de vitesse de restauration des bases de données et des tables
CPU et mémoire (dédiés) | Données de test | innodb_io_capacity | innodb_io_capacity_max | Ancien flux de travail | Nouveau flux de travail | Comparaison des vitesses : nouveau par rapport à l'ancien flux de travail | |||||
Activer la standby chaude pour le stockage | Durée de restauration | Vitesse de restauration | Configuration de la vitesse de restauration | Durée de restauration | Vitesse de restauration | Cluster Hot Standby activé (ancien flux de travail) | Augmentation de la vitesse | ||||
2 cœurs, 8 Go | Table unique, environ 200 Go | 4000 | 8000 | Oui | 3 heures 38 minutes 25 secondes | 1,03 Go/minute | Standard | 1 heure 43 minutes 36 secondes | 2,16 Go/minute | Oui | 110 % |
Non | 2 heures 23 minutes 0 seconde | 1,57 Go/minute | Non | 38 % | |||||||
4 cœurs, 16 Go | Table unique, environ 200 Go | 4000 | 8000 | Oui | 3 heures 3 minutes 31 secondes | 1,14 Go/minute | Rapide | 54 minutes 13 secondes | 3,70 Go/minute | Oui | 225 % |
Non | 88 % | ||||||||||
Standard | 1 heure 20 minutes | 2,5 Go/minute | Oui | 119 % | |||||||
Non | 1 heure 45 minutes 53 secondes | 1,97 Go/minute | Non | 27 % | |||||||
Sûr | 2 heures 12 minutes | 1,52 Go/minute | Oui | 33 % | |||||||
Non | -30 % | ||||||||||
8000 | 16000 | Oui | 3 heures 3 minutes 15 secondes | 1,14 Go/minute | Rapide | 42 minutes 18 secondes | 4,76 Go/minute | Oui | 318 % | ||
Non | 142 % | ||||||||||
Standard | 54 minutes 16 secondes | 3,70 Go/minute | Oui | 225 % | |||||||
Non | 1 heure 45 minutes 53 secondes | 1,97 Go/minute | Non | 88 % | |||||||
Sûr | 1 heure 20 minutes | 2,5 Go/minute | Oui | 119 % | |||||||
Non | 27 % | ||||||||||
8 cœurs, 32 Go | Table unique, environ 200 Go | 4000 | 8000 | Oui | 2 heures 50 minutes 56 secondes | 1,19 Go/minute | Rapide | 54 minutes 39 secondes | 3,70 Go/minute | Oui | 211 % |
Non | 80 % | ||||||||||
Standard | 1 heure 21 minutes | 2,47 Go/minute | Oui | 108 % | |||||||
Non | 1 heure 38 minutes 57 secondes | 2,05 Go/minute | Non | 20 % | |||||||
Sûr | 2 heures 12 minutes | 1,52 Go/minute | Oui | 28 % | |||||||
Non | -35 % | ||||||||||
18000 | 36000 | Oui | 2 heures 51 minutes 5 secondes | 1,19 Go/minute | Rapide | 41 minutes 48 secondes | 4,88 Go/minute | Oui | 310 % | ||
Non | 273 % | ||||||||||
Standard | 54 minutes 43 secondes | 3,70 Go/minute | Oui | 211 % | |||||||
Non | 1 heure 38 minutes 33 secondes | 1,31 Go/minute | Non | 182 % | |||||||
Sûr | 1 heure 21 minutes | 2,47 Go/minute | Oui | 108 % | |||||||
Non | 89 % | ||||||||||
16 cœurs, 64 Go | Table unique, environ 200 Go | 4000 | 8000 | Oui | 2 heures 55 minutes 26 secondes | 1,17 Go/minute | Rapide | 53 minutes 28 secondes | 3,77 Go/minute | Oui | 222 % |
Non | 88 % | ||||||||||
Standard | 1 heure 20 minutes | 2,5 Go/minute | Oui | 114 % | |||||||
Non | 1 heure 42 minutes 20 secondes | 2,01 Go/minute | Non | 24 % | |||||||
Sûr | 2 heures 12 minutes | 1,52 Go/minute | Oui | 30 % | |||||||
Non | -32 % | ||||||||||
20000 | 40000 | Oui | 2 heures 53 minutes 49 secondes | 1,19 Go/minute | Rapide | 41 minutes 1 seconde | 4,88 Go/minute | Oui | 310 % | ||
Non | 138 % | ||||||||||
Standard | 54 minutes 5 secondes | 3,70 Go/minute | Oui | 211 % | |||||||
Non | 1 heure 40 minutes 35 secondes | 2,05 Go/minute | Non | 80 % | |||||||
Sûr | 1 heure 20 minutes | 2,5 Go/minute | Oui | 110 % | |||||||
Non | 22 % | ||||||||||
La vitesse de restauration correspond à la vitesse à laquelle les données sont restaurées dans le cluster d'origine. Elle n'inclut pas le temps nécessaire à la création d'un nœud temporaire ni à la restauration des journaux incrémentiels lors du processus de restauration.
La vitesse de restauration dépend de plusieurs facteurs : l'activation ou non d'un cluster Hot Standby, les spécifications du nœud principal, la valeur du paramètre
innodb_io_capacity, la configuration de la vitesse de restauration et le nombre de tables à restaurer.Vous pouvez ajuster la vitesse de restauration en modifiant dynamiquement les valeurs des paramètres
innodb_io_capacityetinnodb_io_capacity_max. La modification de ces paramètres a un effet mineur sur la vitesse de restauration de l'ancien flux de travail, mais un impact majeur sur le nouveau flux de travail.La vitesse de restauration est classée en trois configurations selon les opérations d'entrée/sortie par seconde (IOPS) utilisées : Rapide, Standard et Sûr. Une valeur IOPS plus élevée entraîne une vitesse de restauration plus rapide. L'accélération est particulièrement notable lors de la restauration de grandes tables.
La configuration de la vitesse de restauration a un effet mineur sur la vitesse de restauration de l'ancien flux de travail, mais un impact majeur sur le nouveau flux de travail.
Étant donné que la configuration 2 cœurs, 8 Go est limitée et présente des fluctuations d'E/S importantes, la configuration de la vitesse de restauration peut ne pas avoir d'effet perceptible. Par conséquent, les résultats de test pour cette configuration ne sont pas répertoriés.
Les données de test précédentes ne couvrent pas les scénarios impliquant la restauration d'un grand nombre de tables. Si vous restaurez de nombreuses tables simultanément, la vitesse de restauration est également affectée.
Les données de test précédentes sont fournies à titre indicatif uniquement. La vitesse de restauration réelle dépend de facteurs tels que le modèle de machine sous-jacent et les conditions réseau.