Un élément essentiel de la prévention de tout type de perte de données dans n'importe quelle situation consiste à disposer de politiques de sauvegarde et de récupération appropriées. Il est également essentiel d'assurer la récupération des données à tout moment du cycle de vie du workflow de l'application. MySQL et MariaDB proposent des solutions pour ces cas. Cet article explore les options et procédures existantes ainsi que d'autres options de sauvegarde potentielles pour MySQL et MariaDB.
Stratégies de sauvegarde
Comme les données sont la partie la plus importante de toute application, la protection de leur intégrité est vitale pour survivre dans la bataille de l'existence. Toute interruption de l'accessibilité ou de l'intégrité des données à tout moment est susceptible de nuire gravement à l'application et à l'entreprise/au service qu'elle fournit.
Pour assurer le succès du flux de travail des applications et de la continuité des activités, vous devez mettre en œuvre des politiques de sauvegarde et de récupération appropriées avec des sauvegardes quotidiennes, hebdomadaires, mensuelles et annuelles. Ces sauvegardes s'exécuteront à des périodes critiques, telles que :
- avant une fenêtre de lot quotidienne ;
- avant les ingestions massives de données ;
- avant toute mise à jour de l'application ;
- sauvegardes hebdomadaires, mensuelles et annuelles pour satisfaire aux exigences réglementaires ;
- ou autre maintenance planifiée quotidienne/hebdomadaire.
Outils de sauvegarde
MySQL et MariaDB offrent plusieurs façons de configurer et d'exécuter des plans de sauvegarde et de récupération. Ces méthodes incluent des sauvegardes physiques avec l'outil MySQL Enterprise mysqlbackup , l'outil mariabackup de MariaDB , ou l'outil XtraBackup de Percona . Aussi, les sauvegardes logiques créées avec l'outil mysqldump de MySQL peut être utile. Une autre option est la récupération ponctuelle avec les journaux bin des bases de données (les journaux de transactions) en combinaison avec les outils mentionnés précédemment.
Vous pouvez assimiler des méthodes appropriées dans votre stratégie de sauvegarde afin de maximiser la capacité de restauration de la base de données en cas de panne ou de sinistre.
Remarque :dans la version 10.4.6 de MariaDB, le lien symbolique de mysqldump s'appelle mariadb-dump . Dans les versions ultérieures, y compris 10.5.2, les noms ont encore changé - mysqldump est devenu lien symbolique .
Pour illustrer les procédures, j'utiliserai l'outil mariabackup pour créer des sauvegardes physiques. La fonctionnalité de base de l'outil est la même que dans les outils susmentionnés, bien qu'il existe de légères différences propres à chaque outil.
Sauvegardes de bases de données physiques
Les sauvegardes physiques sont des sauvegardes de niveau fichier qui vous offrent des méthodes de copie de fichiers rapides. De telles sauvegardes sont préférables dans les scénarios de reprise après sinistre, le clonage de bases de données et/ou la création de bases de données esclaves.
Lorsque vous effectuez des sauvegardes physiques, vous pouvez choisir de créer des sauvegardes complètes ou incrémentielles. Les sauvegardes complètes incluent une sauvegarde complète du serveur de base de données. Les sauvegardes incrémentielles enregistrent uniquement les modifications apportées à la dernière sauvegarde complète ou incrémentielle.
Important :La taille de la base de données régule l'heure de la sauvegarde. Pour cette raison, une bonne stratégie pour sauvegarder une très grande base de données peut consister à combiner des sauvegardes complètes et incrémentielles. De cette façon, vous économisez à la fois l'espace de stockage des sauvegardes et le temps total de sauvegarde et de restauration.
Un autre moment que vous devriez remarquer est que lorsque vous récupérez les données à partir d'une sauvegarde physique, vous devez arrêter votre processus d'instance de base de données MySQL/MariaDB jusqu'à ce que les étapes de récupération finales soient terminées.
Vous pouvez effectuer l'exécution d'une simple sauvegarde physique complète comme suit :
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220 \
--user=backupuser --password=backuppasswd
Le –target-dir L'option indique à l'outil de sauvegarde où placer la sauvegarde.
Dans cet exemple, j'ai organisé ma sauvegarde dans le répertoire appelé DYYYYMMDD où chaque sauvegarde complète est stockée (D signifie Quotidien). Ce faisant, nous disposons d'un plan d'action simple pour restaurer la base de données à partir de la sauvegarde effectuée à une date précise.
L'exemple suivant illustre l'exécution d'une sauvegarde incrémentielle simple :
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc1/ \
--incremental-basedir=/data/backups/mariadb/D20210220/ \
--user=backupuser --password=backuppasswd
La sauvegarde incrémentielle suivante ressemblerait à ces lignes :
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc2/ \
--incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
--user=backupuser --password=backuppasswd
Le –incrémental-basedir L'option indique à l'outil de sauvegarde d'utiliser la sauvegarde complète ou incrémentielle effectuée précédemment comme point de départ pour créer des fichiers delta incrémentiels pour la sauvegarde actuelle. De cette façon, il construit une chaîne d'une sauvegarde complète avec des sauvegardes incrémentielles ultérieures. Ensemble, ils forment une seule sauvegarde à restaurer en cas de besoin.
Voyons maintenant quel est le nom du fichier de base de données physique dans lequel toutes les données du répertoire sont stockées. La base de données située sur les contrôleurs de domaine est un Active Directory. Ce répertoire est utilisé pour gérer les utilisateurs, les données, etc. Le cœur d'un Active Directory est le fichier de base de données NTDS.DIT qui se compose d'un lien, d'un descripteur de sécurité et de tables de données. Toutes les données du répertoire sont conservées dans ce fichier de base de données physique.
Il est nécessaire de faire la distinction entre les fichiers physiques et logiques. Les données système réelles se trouvent dans des fichiers physiques, tandis que les fichiers logiques contiennent la description des enregistrements stockés dans des fichiers physiques.
La tâche de restauration de la base de données MySQL à partir de fichiers physiques peut parfois être difficile. Le mysqldump La commande peut être utile dans ce cas. Nous aborderons ce sujet plus loin.
Sauvegardes de bases de données logiques
Les sauvegardes logiques sont créées avec mysqldump outil. Cette méthode de sauvegarde est plus flexible que la sauvegarde physique. Il se compose de toutes les instructions SQL DML et/ou DDL nécessaires pour former une sauvegarde cohérente, combinant toutes les données validées et les modifications apportées avant et pendant la sauvegarde. Si vous souhaitez en savoir plus sur la sauvegarde et la restauration de toutes les bases de données, vous pouvez lire cet article.
La sauvegarde logique peut être un seul fichier ou plusieurs fichiers (créés avec un script spécifique). De plus, vous pouvez restaurer la structure et/ou les données sans arrêter votre instance MySQL/MariaDB (processus). En conséquence, les sauvegardes logiques sont effectuées au niveau de la base de données et/ou de la table, tandis que les sauvegardes physiques sont effectuées au niveau du système de fichiers (répertoires et fichiers).
Notez également que les sauvegardes logiques sont exclusivement des images de sauvegardes complètes des bases de données et/ou tables prévues.
La création d'une sauvegarde logique de l'intégralité de l'instance MySQL/MariaDB est ci-dessous :
mysqldump --all-databases --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql
Notez que les sauvegardes physiques et les sauvegardes logiques sont spécifiquement distinguées dans le système de fichiers à des fins de gestion des sauvegardes.
Contrairement à l'exemple précédent, une sauvegarde logique d'une seule base de données (schéma) est créée de la manière suivante :
mysqldump empdb --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Enfin, pour créer une sauvegarde logique d'une seule table dans une base de données, ajoutez le nom de la table après la base de données :
mysqldump empdb departments --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Lorsque vous devez modifier et ajouter les instructions DROP DATABASE ou DROP TABLE au scénario de récupération, travailler avec des fichiers de sauvegarde volumineux peut avoir des effets contraignants sur les éditeurs de texte au point de les étouffer.
Dans de tels cas, envisagez d'ajouter d'autres options, telles que –add-drop-database et/ou –add-drop-table pour inclure ces instructions DROP dans la sauvegarde. Dans d'autres scénarios, vous pouvez exclure ces instructions et les remplacer par –skip-add-drop-table option à la commande.
Cependant, vous pouvez également créer des sauvegardes de données uniquement ou DDL uniquement à l'aide de –no-create-info ou –pas de données options. Des sauvegardes de données et de structure séparées peuvent être un bon choix dans certains scénarios de récupération, en particulier lorsque vous n'avez besoin que de la structure DDL pour créer une base de données clonée vide et/ou ses tables.
Sauvegarde de la base de données à l'aide d'instantanés de disque
Au fur et à mesure que les données grandissent, il peut devenir nécessaire de les organiser sur plusieurs disques et/ou systèmes de fichiers. Outre les raisons de performances, étant donné que les E/S sont réparties sur plusieurs disques/systèmes de fichiers, vous devez vous assurer que des stratégies de sauvegarde et de récupération efficaces incluent les capacités d'instantané du disque et du système de fichiers.
Commencez par concevoir et créer les dispositions du système de fichiers où résident chaque base de données, groupe de tables et index. Ensuite, organisez vos tables et configurez le système de base de données. Ils doivent soit résider tous dans un seul répertoire :
innodb_home_dir = /<path where your InnoDB tables will reside>Ou, vous pouvez utiliser le DATA_DIRECTORY et INDEX_DIRECTORY options dans CRÉER table pour les distribuer séparément à différents emplacements du système de fichiers.
Pour InnoDB, assurez-vous d'utiliser file_per_table =ON (activé par défaut dans les versions les plus récentes). Choisissez soigneusement le chemin des tables InnoDB lorsque vous les créez. Il est impossible de modifier le chemin sans supprimer et recréer la table.
Il est utile d'avoir des systèmes de fichiers appropriés avec des capacités d'instantané intégrées, par ex. XFS et ZFS sous Linux. Notez que la création des sauvegardes d'instantanés est similaire à la création de sauvegardes physiques, mais elle a des spécificités. Il nécessite l'arrêt du processus d'écriture (FLUSH avec READ LOCK ou similaire - voir ÉTAPE DE SAUVEGARDE dans la documentation en ligne de MariaDB) avant de prendre l'instantané et de libérer les LOCKS immédiatement après la fin de l'instantané. Il est nécessaire d'assurer la cohérence des données.
Vous devez envisager et utiliser les sauvegardes de clichés dans les scénarios de reprise après sinistre. Cependant, ils conviennent également au clonage d'instances de bases de données.
Stratégies de récupération
Récupération à partir de sauvegardes physiques
Auparavant, nous avons décrit les étapes de sauvegarde physique. De cette façon, vous pouvez soit créer une chaîne de sauvegardes complètes, soit une chaîne de sauvegardes complètes et incrémentielles. Cette dernière option signifie qu'une sauvegarde complète suivie d'une sauvegarde incrémentielle ultérieure est le point zéro en cas d'échec.
Par exemple, un administrateur de base de données effectue des sauvegardes complètes le dimanche et des sauvegardes incrémentielles les autres jours. Un échec se produit après avoir effectué une sauvegarde incrémentielle mercredi. Par conséquent, ils doivent restaurer la base de données. Dans de telles circonstances, notre DBA doit utiliser la sauvegarde complète effectuée le dimanche et les sauvegardes incrémentielles effectuées les lundi, mardi et mercredi. S'il y avait des sauvegardes complètes quotidiennes, il suffirait de restaurer la sauvegarde du mercredi.
Pour récupérer la sauvegarde "la plus proche" après une panne, qu'il s'agisse d'une sauvegarde complète ou incrémentielle, vous devez vous assurer que TOUS les fichiers de sauvegarde sont cohérents à un instant donné avec l'heure de la fin de sauvegarde la plus proche. Sinon, le moteur InnoDB rejettera les données en les jugeant corrompues.
Un autre point clé est que, lorsque vous préparez des sauvegardes, copiez les sauvegardes complètes concernées vers un autre emplacement avant d'appliquer les étapes pour assurer une cohérence ponctuelle. De cette façon, vous conservez l'état de sauvegarde d'origine, ce qui peut être utile plus tard. Je recommande fortement de s'en tenir à cette approche.
Pour préparer une sauvegarde complète, choisissez la plus proche de l'échec, copiez-la à l'emplacement préféré et exécutez la commande suivante :
mariabackup --prepare \
--target-dir=data/backups/mariadb/COPY_D20210220
Pour restaurer vers la sauvegarde incrémentielle la plus proche, préparez une copie de la sauvegarde complète la plus proche et ajoutez toutes les sauvegardes incrémentielles pertinentes dans une commande ultérieure . L'image de la base de données restaurée doit être la suivante :
Nous y parvenons en exécutant la préparation commande pour chaque sauvegarde incrémentielle comme indiqué ci-dessous :
mariabackup --prepare \
--target-dir=/data/backups/mariadb/COPY_D20210220 \
--incremental-dir=/data/backups/mariadb/D20210220_INC#
Après avoir préparé la copie de sauvegarde, nous devons arrêter l'instance de base de données (processus). De plus, nous devons vider le répertoire de la base de données avant de terminer le processus de restauration. Vous pouvez émettre soit la commande avec le –copy-back possibilité
mariabackup --copy-back \
--target-dir=data/backups/mariadb/COPY_D20210220
ou avec le –retour en arrière choix :
mariabackup --move-back \
--target-dir=data/backups/mariadb/COPY_D20210220
Cette dernière commande déplace le répertoire copié dans le répertoire de la base de données. Copier la sauvegarde d'origine vers un autre emplacement est un choix judicieux. Sinon, la sauvegarde sera perdue, car vous ne pourrez pas l'utiliser pour d'autres situations et scénarios.
La dernière étape avant de démarrer l'instance de base de données consiste à ajuster la propriété des fichiers pour qu'elle corresponde à l'utilisateur et au groupe du propriétaire du processus. Généralement, il s'agit de MySQL.
Récupération à partir de sauvegardes logiques
Très souvent, nous négligeons un point clé lors de la restauration de bases de données et/ou de tables à l'aide de sauvegardes logiques. Ce point définit le max_allowed_packet taille de la session (il peut être plus judicieux de la définir globalement) à la valeur maximale de 1073741824. Il est nécessaire de s'assurer que les tampons volumineux et les instructions INSERT tiennent dans un seul paquet entre le client et le serveur. Cela devrait réduire le temps de récupération.
Un autre aspect clé lors d'une sauvegarde est d'inclure ou d'exclure les instructions DROP comme mentionné précédemment. Nous en avons besoin pour assurer l'exécution du processus de restauration de sauvegarde aussi fluide que possible. Dans cet esprit, utilisez le code ci-dessous pour exécuter la restauration de sauvegarde :
mysql -u backupuser -p backuppasswd < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlSi aucune base de données n'est incluse dans la sauvegarde, comme pour les sauvegardes de bases de données individuelles, ou si vous devez rediriger la restauration vers une autre base de données, utilisez un code différent :
mysql -u backupuser -p backuppasswd newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlRécupération avec des instantanés de disque
Pour récupérer à partir de l'instantané du disque toujours commencer pars'assurer que le système de base de données est fermé avant le processus de récupération est exécuté . Toute tentative de récupération d'une base de données active à l'aide de l'instantané de disque entraînera des incohérences de données et, plus probablement, une corruption des données.
Récupération ponctuelle
La récupération à un moment donné (PITR) est, comme son nom l'indique, une méthode pour récupérer des bases de données et des tables au plus près du moment précédant la panne. Ou, si le traitement par lots quotidien a échoué et doit être réexécuté, vous avez également la seule option :effectuer une récupération de sauvegarde PITR.
Il est essentiel d'activer le journal bin de la base de données et de définir le format du journal bin sur une journalisation basée sur des instructions, sur des lignes ou mixte, selon le type de charge de travail que votre base de données exécute. De plus, vous devrez peut-être activer la compression en utilisant log_bin_compress =ON (OFF par défaut) pour économiser de l'espace disque.
Comme bin-log est un journal de transactions et créé dans une séquence, il est crucial de faire une sauvegarde de tous les fichiers journaux. Quant au processus PITR, il est impossible sans fichiers journaux. En outre, la maintenance et le cycle de vie du bin-log doivent suivre le cycle de vie de toutes les sauvegardes complètes et incrémentielles. Ainsi, assurez-vous de ne purger que les journaux qui sont plus anciens que la sauvegarde la plus ancienne dans la politique de sauvegarde.
Vous pouvez purger les journaux binaires de deux manières. Tout d'abord, c'est en déclarant le nom du journal bin le plus proche de la sauvegarde la plus ancienne, comme indiqué dans la commande de purge ci-dessous :
PURGE BINARY LOGS TO 'mariadb-bin.000063';Deuxièmement, c'est en déclarant la date de la sauvegarde la plus ancienne conservée dans la commande purge :
PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';Pour préparer la reprise, nous devons récupérer toutes les déclarations nécessaires pour les rejouer au moment voulu. Collectez tous les journaux bin disponibles depuis le début de la sauvegarde jusqu'au moment de la restauration.
Commencez par examiner la liste des journaux depuis la fin de la sauvegarde jusqu'à l'heure PITR :
mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql
Ensuite, examinez les fichiers temporaires pour trouver les positions exactes du journal que vous souhaitez appliquer et utiliser. Ce sont –start-position et –position d'arrêt qui définissent les positions exactes dans la commande et ré-exécutent le mysqlbinlog commande :
mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql
À ce stade, le processus de récupération a commencé. Il utilise des sauvegardes physiques ou logiques, complètes ou incrémentielles.
Terminer la restauration en appliquant le final_temporary_PITR_file.sql en utilisant le client MySQL comme indiqué ci-dessous :
mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sqlNous avons terminé la récupération PITR en restaurant la sauvegarde et les transactions rejouées à partir du journal au point le plus proche du moment de l'incident.
Établi
Pour la conception et le développement de bases de données, les tests et la maintenance dans MySQL et MariaDB, nous pouvons utiliser une application Windows Workbench. Cela fonctionne aussi sous Linux. Avec cette application, les utilisateurs peuvent concevoir des bases de données, afficher et modifier des métadonnées, transférer des données et des métadonnées, et bien plus encore. Il convient d'ajouter qu'il est possible d'utiliser dbForge Studio for MySQL au lieu de Workbench.
Conclusion
Dans l'ensemble, nous avons brièvement discuté et illustré les techniques de sauvegarde et de récupération de base de données avec des outils et des méthodes disponibles dans MySQL et MariaDB.
Pour récupérer avec succès le système de base de données après toute défaillance, nous devons implémenter une sauvegarde physique et logique méthodes mentionnées ci-dessus dans les politiques et les plans, de l'ensemble du système jusqu'aux tables individuelles.
Pour effectuer un PITR avec succès, nous avons besoin du bin-log activé et des besoins de gestion des journaux appropriés en place.
Cependant, l'utilisation d'une seule méthode de sauvegarde et l'absence de journaux bin seraient une mauvaise approche. Cela peut entraîner une perte de données et nuire à la continuité des activités de votre application. Ainsi, combinez différentes méthodes et incluez toujours les fichiers journaux dans les politiques de sauvegarde et de restauration !
