Auparavant, nous avions blogué sur la sauvegarde de votre base de données MySQL Moodle. Cette fois, il s'agit de sauvegarder votre base de données Moodle MariaDB. En fait, il partage la même approche lors de la sauvegarde de votre base de données Moodle MySQL qu'avec votre base de données Moodle MariaDB. Cependant, depuis MariaDB 10.2, il a lentement dévié et continue d'avoir des différences drastiques avec la version MySQL. À cet égard, faites attention aux approches que vous devrez peut-être envisager lorsque vous sauvegardez votre MariaDB, contrairement à MySQL si vous en étiez.
Meilleures pratiques pour créer votre sauvegarde Moodle MariaDB
Considérons d'abord ce sujet. Faire une sauvegarde de vos données Moodle doit appliquer les meilleures pratiques pour votre sauvegarde MariaDB car cela vous offre sécurité et assurance, en particulier en cas de catastrophe ou de catastrophe dans des situations imprévisibles.
Alors qu'est-ce qui se passe avec ça ? Faire une sauvegarde pour votre Moodle concerne au moins les sauvegardes suivantes :
- Sauvegarde logique
- Copie physique de votre sauvegarde
- Récupération ponctuelle (incrémentielle)
Sauvegarde logique
Une sauvegarde logique des données est stockée dans un format lisible par l'homme comme SQL. Les sauvegardes logiques enregistrent les informations représentées sous forme de structure de base de données logique (instructions CREATE DATABASE, CREATE TABLE) et de contenu (instructions INSERT ou fichiers texte délimités). Ce type de sauvegarde convient aux petites quantités de données où vous pouvez modifier les valeurs de données ou la structure de la table, ou recréer les données sur une architecture de machine différente. Si vous avez tendance à utiliser une énorme sauvegarde de base de données, assurez-vous que la compression est activée. Attention car cela peut prendre beaucoup d'espace disque en particulier.
Dans MariaDB, un outil commun à utiliser utilise mysqldump, mais changera à l'avenir avec mariadb-dump à partir de MariaDB 10.4.6 ou 10.5.2. Alternativement, un outil commun à utiliser pour les DBA MySQL/MariaDB est mydumper si vous voulez une sauvegarde parallèle pour votre copie de sauvegarde logique. Bien qu'il y ait des problèmes dans certaines versions ou des problèmes, en particulier pour les dernières versions de MariaDB. Si vous souhaitez l'utiliser, faites attention à vos journaux de sauvegarde lors de la création d'une copie.
Sauvegarde physique
La sauvegarde physique contient les données binaires de la base de données qui consistent en des copies brutes des répertoires et des fichiers qui stockent le contenu de la base de données. Il s'agit d'une action appropriée à prendre, en particulier pour une grande base de données et il est plus rapide de récupérer une copie complète de la base de données par rapport à une copie de sauvegarde logique. D'un autre côté, effectuer une sauvegarde physique complète prend du temps, surtout si vous avez un très grand ensemble de données. Cela dépend également des paramètres que vous avez activés ou définis et qui peuvent avoir un impact sur son ETA de sauvegarde.
Un outil commun à utiliser pour MariaDB utilise mariabackup. Mariabackup est un outil open source fourni par MariaDB. Il s'agit d'un fork de Percona XtraBackup conçu pour fonctionner avec des tables cryptées et compressées. Il s'agit de la méthode de sauvegarde recommandée pour les bases de données MariaDB.
Récupération ponctuelle (PITR)
La récupération ponctuelle fait référence à la récupération des modifications de données jusqu'à un moment donné. Ce moment donné est l'objectif de récupération souhaité qui a été déterminé et doit être remis en place, qui est appliqué lors de la récupération. PITR est une récupération en avant et cela signifie que vous pouvez restaurer les données de l'heure de début souhaitée à l'heure de fin souhaitée, pour le contraire, lisez Utilisation de MariaDB Flashback sur un serveur MySQL. Le PITR est également considéré comme une méthode supplémentaire de protection des données, car il protège la perte d'informations importantes.
Dans des situations courantes, votre sauvegarde PITR applicable à votre type de restauration est effectuée après la restauration d'une sauvegarde complète qui ramène le serveur à son état au moment où la sauvegarde a été effectuée. La restauration ponctuelle met ensuite à jour le serveur de manière incrémentielle depuis l'heure de la sauvegarde complète jusqu'à une heure plus récente. Cela accélère également la création d'un réplica au sein d'un cluster de réplication en rattrapant votre retard sur votre base de données principale ou d'écriture active MariaDB.
Quelles sont donc ces sauvegardes ? Dans MariaDB, les sauvegardes communes applicables à votre PITR sont vos journaux binaires. La journalisation binaire doit être correctement configurée dans votre base de données MariaDB et doit être activée. Si vous utilisez ClusterControl, cela ne vous sera peut-être pas difficile à configurer car il est configuré automatiquement pour vous et est activé en particulier lors de la configuration d'un cluster de réplication.
Lors de l'application du PITR, l'outil le plus couramment utilisé est mysqlbinlog ou mariadb-binlog pour MariaDB 10.5.2 et versions ultérieures.
Meilleure approche pour sauvegarder votre base de données Moodle MariaDB
Lors de l'exécution de votre base de données Moodle MariaDB, effectuez toujours votre sauvegarde pendant les heures creuses ou lorsque le trafic est trop faible. Avant de faire cela, assurez-vous que vous avez testé la sauvegarde et qu'elle s'est terminée avec succès. Une fois terminé, testez une restauration si votre sauvegarde est utile ou non et qu'elle répond à vos besoins lorsque la récupération de données est nécessaire ou lorsque vous avez besoin de votre sauvegarde pour créer un autre ensemble de clusters (AQ, développement ou extension à un autre centre de données). Fondamentalement, les sous-sections suivantes seront l'approche et la configuration que vous devez gérer.
Configurer une réplique et effectuer la sauvegarde sur la réplique
Si vous n'êtes pas familiarisé avec la réplication, lisez notre livre blanc Réplication MySQL pour la haute disponibilité. Fondamentalement, n'épargnez pas votre enregistreur actif ou votre nœud de base de données principal pour effectuer ou exécuter une sauvegarde. La réalisation d'une sauvegarde doit être testée et elle ne doit pas être effectuée en production si elle n'a pas encore été testée avec un ensemble de commandes et sa politique de sauvegarde que vous avez créées. Une fois bien, il suffit de le laisser et de le viser sur une réplique. Vous pouvez effectuer une sauvegarde de votre base de données MariaDB primaire/maître si vous n'avez pas le choix ou si vous êtes sûr de ce que vous faites.
Exécuter la sauvegarde pendant les heures creuses
Lorsque vous effectuez une sauvegarde, assurez-vous qu'il s'agit de vos heures de pointe. Votre réplique doit être sans décalage autant que possible afin que les données les plus à jour soient masquées.
Créer une politique de sauvegarde
La politique de sauvegarde se compose de vos paramètres et de la planification de votre sauvegarde. Pour les paramètres, assurez-vous qu'ils suffisent à vos besoins, c'est-à-dire la sécurité, la compression, etc. La planification doit être permanente afin que votre la sauvegarde doit être là en cas de besoin en cas de catastrophe et la récupération des données est nécessaire. Vous pourrez également déterminer votre objectif de temps de récupération afin de pouvoir déterminer la fréquence d'exécution de votre planification de sauvegarde et quand.
Comment créer une sauvegarde de votre base de données Moodle MariaDB
Utiliser mariadb-dump/mysqldump
La commande ci-dessous créera votre sauvegarde de base de données pour Moodle. Dans cet exemple, le nom de la base de données est moodle. Nous avons inclus des déclencheurs, des procédures stockées ou des routines et des événements. Imprimez le GTID et les informations principales qui sont utiles lorsque vous souhaitez provisionner une réplique à partir du nœud de base de données principal ou principal.
$ /usr/bin/mariadb-dump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --skip-lock-tables --triggers --routines --events --gtid --databases moodleVous pouvez simplement remplacer mariadb-dump par mysqldump si vous utilisez la version MariaDB <10.5.2. Si vous avez besoin de compresser, vous pouvez exécuter la commande ci-dessous :
$ /usr/bin/mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --skip-lock-tables --triggers --routines --events --gtid --databases moodle |gzip -6 -c > /backups/backup-n1/mysqldump_2021-01-25_182643_schemaanddata.sql.gzUtiliser mariabackup
Le mariabackup peut être pris simplement. Pour cela, nous utiliserons mbstream comme format de diffusion et d'archivage souhaité. Vous pouvez utiliser la commande ci-dessous :
$ /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --parallel 1 --stream=xbstream > backup.xbstreamSi vous souhaitez le compresser, vous pouvez exécuter la commande suivante :
$ /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --parallel 1 --stream=xbstream | gzip -6 - > backup.xbstream.gzUtiliser ClusterControl
Si vous passez à une solution gérée spécialement pour la sauvegarde de votre Moodle, ClusterControl prend les choses en main mais offre des fonctionnalités avancées pour la sauvegarde. Regardez la capture d'écran ci-dessous :
Réaliser une sauvegarde est très simple et facile à créer. Tout ce que vous avez à faire est d'aller dans
Dans la capture d'écran ci-dessus, j'ai mysqldump, mysqldump compatible PITR et mariabackup. Vous pouvez sélectionner l'hôte sur lequel effectuer la sauvegarde. Comme mentionné précédemment, assurez-vous que vous effectuez la sauvegarde sur la réplique ou l'esclave. Cela signifie, assurez-vous que l'esclave est sélectionné. Voir capture d'écran ci-dessous :
Lors de la sélection ou du choix de mysqldump, ClusterControl permet à l'utilisateur de choisir le type de données à vider. Cela inclut également un vidage compatible PITR pour la sauvegarde. Voir capture d'écran ci-dessous :
Pour votre sauvegarde binaire ou physique, à part mysqldump comme sauvegarde logique, vous pouvez choisir mariabackup complet ou incrémentiel. Voir ci-dessous :
Les emplacements de stockage permettent uniquement à l'utilisateur de choisir de rester sur le nœud ou diffusez-le sur l'hôte ClusterControl. Si vous avez un serveur externe qui n'est pas enregistré dans le ClusterControl, vous pouvez utiliser NFS pour monter le volume sur lequel vous souhaitez que votre sauvegarde soit vidée. Bien que cela ne soit peut-être pas idéal, mais dans certains cas, cela satisfera en particulier si la bande passante du réseau ou le transfert réseau est suffisamment rapide pour diffuser les données localement vers l'autre nœud via le réseau.
Essentiellement, vous pouvez choisir les sauvegardes à télécharger sur le cloud. Vous pouvez voir la capture d'écran plus tôt et cocher simplement la case pour l'activer comme ci-dessous :
Comme mentionné précédemment, ClusterControl prend la sauvegarde de manière simple à utiliser mais fournit fonctionnalités avancées, voici les options que vous pouvez définir.
Pour mysqldump,
Pour mariabackup,
très facile à utiliser. ClusterControl propose également une vérification de sauvegarde et une restauration de sauvegarde afin qu'il vous soit facile de déterminer si la sauvegarde est utile ou non. Cela aide à rendre la sauvegarde de votre base de données Moodle utile, en particulier lorsque la récupération de données doit être appliquée en cas d'urgence et de récupération.
Conclusion
Il peut être facile de sauvegarder votre base de données Moodle MariaDB, mais lorsque les données deviennent plus volumineuses et que le trafic augmente, cela peut être un grand défi. Il vous suffit de suivre les meilleures pratiques, de vous assurer que vous avez sécurisé vos données, de vous assurer que votre sauvegarde est vérifiée et qu'elle est utile lorsque la récupération de données doit être appliquée.
