FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Internet : 3,6 millions de serveurs MySQL sont accessibles sur le port par défaut

1 juin 2022 à 08:21

Nous sommes en 2022, la sécurité des systèmes est au cœur des préoccupations, et pourtant, des chercheurs en sécurité ont trouvé un total de 3,6 millions de serveurs MySQL exposés sur Internet directement via le port par défaut.

Les chercheurs en sécurité de la Fondation Shadowserver ont effectué un scan d'Internet à partir de l'outil nmap et ils sont parvenus à identifier 3,6 millions de serveurs MySQL exposés sur Internet. Ces serveurs sont exposés publiquement et ils répondent aux requêtes sur le port par défaut (3306).

Sur ce total de 3,6 millions de serveurs, il y en a 2,3 millions (2 279 908 pour être précis) qui sont connectés via des adresses IPv4 et 1,3 million via des adresses IPv6 (1 343 993 pour être précis).

Admettons qu'un serveur de base de données MySQL soit accessible depuis Internet pour qu'un serveur Web puisse l'exploiter, cela peut se comprendre. Néanmoins, ce type de configuration nécessite de prendre des précautions, à commencer par utiliser un port d'écoute différent de celui par défaut (3306 en TCP), mais aussi surveiller les requêtes, restreindre les accès au strict minimum, etc...

Ce qui est intéressant, c'est qu'il y a une carte correspondante à l'emplacement de ces serveurs MySQL, avec une répartition par pays. Cette carte montre qu'en France, il y a 55 000 serveurs MySQL disponibles sur Internet via le port par défaut. À titre de comparaison, aux États-Unis, il y a plus de 740 000 serveurs, en Allemagne il y a 174 900 serveurs et en Pologne 207 800 serveurs.

Au total, la Fondation Shadowserver a identifié environ 5,3 millions de serveurs MySQL et 67% de tous les services MySQL trouvés sont accessibles depuis Internet, ce qui correspond au total de 3,6 millions de serveurs.

Les propriétaires de ces serveurs MySQL feraient mieux d'agir pour sécuriser leur instance (guide MySQL) car c'est une surface d'attaque intéressante pour les pirates informatiques. Reste à savoir si ces serveurs sont réellement utilisés et quelles sont les bases de données qu'ils hébergent, mais ça, la Fondation Shadowserver n'a pas cherché à le savoir.

Source

The post Internet : 3,6 millions de serveurs MySQL sont accessibles sur le port par défaut first appeared on IT-Connect.

Comment mettre en place MariaDB Galera Cluster sur Debian 11 ?

18 mai 2022 à 13:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à mettre en place MariaDB Galera Cluster afin de créer un cluster de trois serveurs de bases de données MySQL / MariaDB et assurer la haute disponibilité d'une base de données. Il existe plusieurs solutions techniques pour assurer la disponibilité des bases de données, et la solution Galera Cluster en est une. Ce qui est appréciable avec cette solution, au-delà du fait qu'elle soit open source et gratuite, c'est qu'elle offre plusieurs avantages, notamment :

  • Cluster avec une topologie multi maîtres, donc si un nœud tombe, les autres nœuds continuent d'assurer le service de façon transparente sans avoir besoin d'effectuer des manipulations complexes pour retrouver l'état initial (contrairement à MySQL Replication)
  • Cluster actif-actif avec l'ensemble des nœuds
  • Réplication synchrone des informations, c'est-à-dire en temps réel
  • Lecture et écriture sur l'ensemble des nœuds
  • Souple : fonctionne aussi bien sur le LAN que sur le WAN
  • Support des environnements géo-distribués : plusieurs centres de données, multi-Cloud, etc.
  • Ajout d'un nouveau nœud au cluster en quelques minutes (avec les bons paquets et un seul fichier de configuration)

Enfin, sachez que Galera Cluster est un projet soutenu par MariaDB, Red Hat et la Commission Européenne.

II. Les prérequis

Avant de mettre en place un cluster Galera, il faut prendre en compte certains prérequis, et notamment le nombre de nœuds qui constituent ce cluster : il doit être forcément impair, donc vous pouvez constituer un cluster avec 3 nœuds, 5 nœuds voire même 7 nœuds. La raison est simple : c'est pour éviter le phénomène du split-brain car si vous avez seulement deux nœuds et qu'il y a un nœud qui crash, le nœud restant ne sait pas si l'autre nœud est réellement en panne, ou si c'est lui-même qui a un problème, car il ne voit plus le second. De ce fait, il se peut que la bascule ne fonctionne pas !

Afin de respecter ce prérequis, je vais utiliser trois machines virtuelles sous Debian 11 dans le cadre de ce tutoriel :

  • SRV-DEB-1
    • Adresse IP : 192.168.100.51/24
  • SRV-DEB-2
    • Adresse IP : 192.168.100.52/24
  • SRV-DEB-3
    • Adresse IP : 192.168.100.53/24

Mon objectif étant d'héberger sur ce cluster la base de données d'un site sous WordPress et accessible par l'intermédiaire d'un serveur Web représenté par une quatrième machine virtuelle. Actuellement, la base de données est hébergée uniquement sur le serveur SRV-DEB-1. Les machines virtuelles utilisées dans le cadre de cette démonstration ont peu de ressources : 2 Go de RAM (512 Mo, ça peut suffire pour tester), 2 vCPU et 20 Go d'espace disque. En production, il sera nécessaire de prévoir plus large, notamment pour l'espace disque, en fonction de la taille de la base de données et du nombre de connexions à gérer.

Si vous n'avez pas la possibilité d'avoir trois nœuds, ce qui peut se comprendre, car cela nécessite des ressources supplémentaires, vous devez tout de même envisager un troisième serveur avec le rôle Galera Arbitrator.

Tenez compte également des informations suivantes :

  • Utilisez des nœuds avec les mêmes ressources, car le cluster sera aussi lent que le nœud du cluster le plus lent
  • Galera Cluster fonctionne uniquement sur Linux / Unix
  • Avec un cluster géo-distribués, vous devez contrôler la latence entre vos différents nœuds, car l'idéal c'est qu'elle ne dépasse pas 300 ms
  • Vos bases de données (et vos serveurs) doivent utiliser le moteur de stockage InnoDB ou XtraDB, donc MyISAM n'est pas pris en charge
  • Toutes les tables de votre base de données répliquée doivent avoir une clé primaire
  • Le pare-feu de vos serveurs doit autoriser les ports suivants : 3306, 4444, 4567 et 4568

En complément, vous pouvez lire cet article qui regroupe les limitations connues de MariaDB Galera Cluster.

III. Quel est le moteur de stockage utilisé ?

Commençons par regarder quel est le moteur de stockage utilisé par la base de données que vous souhaitez intégrer au cluster. Je vous rappelle qu'il doit être InnoDB ou XtraDB, et que MyISAM n'est pas pris en charge. En fait, InnoDB est le plus populaire, mais il vaut mieux vérifier cette information dès maintenant.

À partir de mon serveur SRV-DEB-1, où se situe actuellement ma base de données, je vais me connecter à l'instance MariaDB :

mysql -u root -p

Ensuite, la requête ci-dessous va m'afficher quel est le moteur de stockage utilisé par défaut sur cette instance :

show variables like 'default_storage_engine';

La valeur retournée est "InnoDB", ce qui est une bonne nouvelle !

Néanmoins, cela ne signifie pas que votre base de données en elle-même n'utilise pas un autre moteur... Pour être sûr que les tables de votre base de données n'utilisent pas le moteur MyISAM, exécutez la requête ci-dessous en remplaçant "wordpress" par le nom de votre base de données.

SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'wordpress' and ENGINE = 'myISAM';

Dans l'idéal, cette requête ne retourne aucune table. Si ce n'est pas le cas, vous pouvez suivrez le tutoriel ci-dessous pour basculer sur InnoDB.

IV. Installation de MariaDB et Galera 4 sur tous les nœuds

Désormais, nous allons commencer la préparation des différents serveurs ! Pour ma part, je vais utiliser Galera 4, car mes instances MariaDB vont utiliser MariaDB 10.5 qui est actuellement disponible par défaut dans les dépôts de Debian 11. Vous devez utiliser la même version de MariaDB sur l'ensemble de votre cluster !

  • MariaDB 10.4 est compatible avec Galera 4
  • MariaDB 10.3 est compatible avec Galera 3

Au sujet des compatibilités entre les versions, regardez cette documentation : Galera Versions.

Sur mon serveur SRV-DEB-1, MariaDB est actuellement installé en version 10.5.15 et Galera 4 s'installe automatiquement lorsque l'on met en place cette version, et même si l'on n’envisage pas de l'utiliser.

Sur les serveurs SRV-DEB-2 et SRV-DEB-3, nous allons installer le serveur MariaDB (vous devez le faire aussi sur le premier nœud si vous partez de zéro).

sudo apt-get update
sudo apt-get install mariadb-server

En complément, et si vous avez un doute sur le fait que Galera 4 soit bien installé, exécutez cette commande :

sudo apt-get install galera-4

Ce paquet permet de bénéficier du provider "wsrep" indispensable pour la réplication des données.

V. Configuration de MariaDB Galera Cluster

Nous allons déclarer la configuration de notre cluster sur le serveur SRV-DEB-1. Pour cela, nous devons modifier le fichier de configuration "60-galera.cnf" qui se situe dans le dossier "/etc/mysql/mariadb.conf.d/". Vous pouvez le vérifier avec cette commande :

ls /etc/mysql/mariadb.conf.d/

Normalement, ce fichier est livré par défaut avec les versions récentes de MariaDB. Si ce n'est pas le cas, vous pouvez éditer directement un autre fichier de configuration de votre instance (exemple : "my.cnf"). C'est le moment d'éditer le fichier "60-galera.cnf" sur le premier nœud :

sudo nano /etc/mysql/mariadb.conf.d/60-galera.cnf

Actuellement, le contenu est le suivant :

Fichier 60-galera.cnf

C'est un template, comme nous pouvons le voir, tout en sachant qu'il y a un autre fichier utile sur lequel s'appuyer pour créer notre configuration :

/usr/share/mysql/wsrep.cnf

Voici la configuration que je vous propose d'utiliser au sein du fichier "60-galera.cnf" :

[galera]
# Mandatory settings
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = "Galera_Cluster_IT-Connect"
wsrep_cluster_address = gcomm://192.168.100.51,192.168.100.52,192.168.100.53
binlog_format = row
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
innodb_force_primary_key = 1

# Allow server to accept connections on all interfaces.
bind-address = 0.0.0.0

# Optional settings
#wsrep_slave_threads = 1
#innodb_flush_log_at_trx_commit = 0
log_error = /var/log/mysql/error-galera.log

Quelques explications sont nécessaires pour que vous puissiez bien comprendre....

  • wsrep_on = ON : activer la réplication en écriture via le provider wsrep
  • wsrep_provider : emplacement de la librairie wsrep
  • wsrep_cluster_name : nom du cluster, doit être identique sur tous les nœuds de votre cluster Galera
  • wsrep_cluster_address : adresses IP (ou le nom, mais préférez l'adresse IP) des différents nœuds du cluster (séparées par une virgule) donc ici les adresses IP de mes trois serveurs
  • binlog_format : format des logs en ROW, par défaut
  • default_storage_engine : moteur de stockage par défaut, ici InnoDB comme définit au niveau de l'instance MariaDB
  • innodb_autoinc_lock_mode : mode pour l'auto-incrémentation, 2 est recommandé, mais les autres valeurs possibles sont "0" ou "1"
  • innodb_force_primary_key : s'assurer que toutes les tables ont bien une clé primaire pour éviter les erreurs
  • bind-address = 0.0.0.0 : accepter les connexions sur toutes les interfaces
  • log_error : emplacement du fichier de log des erreurs (qui contient aussi des logs d'informations, en fait)

Par défaut, dans les journaux, Galera Cluster va utiliser le nom d'hôte du serveur. Si l'on souhaite utiliser une autre valeur, dans ce cas, il faut définir cette option (voir ici) à laquelle on peut aussi ajouter l'adresse IP :

wsrep_node_name = "SRV-DEB-1-Noeud-1"
wsrep_node_address = "192.168.100.51"

Si l'on veut parler un peu d'optimisation des performances, alors l'option "wsrep_applier_threads" est intéressante afin de jouer sur le nombre de threads actifs pour traiter les opérations de réplication. A ce sujet, il n'y a pas de formule magique, mais il faut que ce soit au moins égal au nombre de cœurs de votre processeur, voire même le double ne me choque pas.

wsrep_applier_threads = 2

La configuration est prête : enregistrez le fichier de configuration afin de passer à la suite ! Gardez le contenu de ce fichier de configuration de côté, car il faudra réutiliser les mêmes données sur les autres nœuds du cluster : SRV-DEB-2 et SRV-DEB-3.

VI. Démarrer le cluster Galera

Dans le but d'initialiser notre cluster Galera avec son nœud primaire, nous allons poursuivre sur le serveur SRV-DEB-1 qui contient notre configuration (60-galera.cnf) et la base de données à répliquer. Commençons par stopper MariaDB :

sudo systemctl stop mariadb

Une fois que c'est fait (et c'est important d'arrêter MariaDB), démarrez l'initialisation du cluster Galera avec cette commande :

sudo galera_new_cluster

Maintenant, on va se connecter à notre instance locale MariaDB pour regarder combien de nœuds constituent notre cluster : en toute logique un seul.

mysql -u root -p

Exécutez la requête suivante pour récupérer la valeur de la propriété "wsrep_cluster_size" :

show status like 'wsrep_cluster_size';

Ce qui donne :

On voit bien que c'est égal à "1", ce qui est une bonne nouvelle ! Si vous avez "0", c'est qu'il y a un problème... Dans ce cas, exécutez la requête ci-dessous pour obtenir l'état général du provider wsrep et essayer de comprendre ce qui se passe :

show global status like 'wsrep%';

Nous pouvons passer à la suite : l'ajout des nœuds supplémentaires à notre cluster.

VII. Ajouter des nœuds au cluster Galera

Premièrement, vous devez configurer le fichier "60-galera.cnf" sur les deux autres serveurs, à savoir SRV-DEB-2 et SRV-DEB-3 dans mon cas. Copiez-collez la configuration à l'identique, en reprenant le contenu du fichier du premier nœud (modifiez seulement les options "wsrep_node_name" et "wsrep_node_address" si vous les utilisez).

Remarque : les bases de données existantes des nœuds SRV-DEB-2 et SRV-DEB-3 seront supprimées. Il n'y a que les bases de données du premier nœud qui vont exister suite à l'intégration au cluster.

Actuellement, sur le nœud SRV-DEB-2, je n'ai pas de base de données, à l'exception des bases natives.

Dès que le fichier de configuration "60-galera.cnf" est prêt, il suffit de redémarrer l'instance MariaDB de SRV-DEB-2 pour l'intégrer au cluster :

sudo systemctl restart mariadb

Ensuite, sur le serveur SRV-DEB-1, si je regarde le nombre de nœuds présent dans le cluster, j'ai bien la valeur "2". De plus, si l'on consulte le fichier de log, on peut voir clairement qu'il s'est passé quelque chose et qu'un nouveau nœud a intégré le cluster :

Il ne reste plus qu'à faire la même chose sur le troisième nœud : configuration du fichier "60-galera.cnf" puis redémarrage du service MariaDB. Ensuite, le nombre de nœuds dans notre cluster passe à trois :

Sur les deux nœuds venant d'être intégrés au cluster, si on liste les bases de données (show databases;), nous verrons une nouvelle base de données correspondante à celle répliquée à partir de SRV-DEB-1. Désormais, si une base de données est ajoutée sur l'un des nœuds, elle sera synchronisée avec les autres nœuds !

VIII. L'état des nœuds du cluster Galera

Sur chaque nœud, il est possible d'obtenir des informations sur l'état local, notamment en se connectant à l'instance MariaDB et en regardant certaines propriétés du provider "wsrep". La requête ci-dessous donne l'état du nœud, qui normalement doit être "Synced".

show status like 'wsrep_local_state_comment';

Par ailleurs, la requête ci-dessous permet de voir si le nœud local est capable de traiter suffisamment rapidement les opérations de réplication qu'il reçoit. Lorsque la valeur est égale à "0", c'est tout bon. Par contre, si la valeur est supérieure à 0, cela signifie qu'il n'arrive pas à suivre.

show status like 'wsrep_local_recv_queue_avg';

Enfin, la requête ci-dessous permet de voir si l'hôte est actuelle sur l'état "Primary" ou pas.

show status like 'wsrep_cluster_status';

Dans le cas où il n'est plus dans la grappe primaire, il ne sera plus sollicité même s'il est en ligne, dans ce cas, il faut simplement relancer le service MariaDB sur ce nœud. Ce phénomène peut se produire si le nœud est isolé à cause d'un problème réseau et qu'il ne parvient plus à contacter les deux autres nœuds de notre cluster à trois nœuds.

sudo systemctl restart mariadb

Je vous recommande de regarder la documentation officielle pour la partie monitoring : Monitoring Cluster.

IX. Comment utiliser le cluster Galera ?

Nous venons de voir comment mettre en place le cluster Galera afin d'assurer la haute disponibilité de notre base de données, en l'occurrence ici pour un site WordPress. Par contre, au niveau du serveur Web (même si j'en ai qu'un seul dans cet exemple, en production il en faudrait plusieurs pour aller jusqu'au bout des choses), comment déclarer le cluster ? Si l'on prend l'exemple de WordPress, on déclare uniquement une adresse IP (ou un nom de domaine) pour le serveur de base de données, alors comment faire quand il y en a trois ou plus ?

Pour rappel, c'est dans le fichier wp-config.php, que le serveur de base de données se déclare de cette façon :

/** MySQL hostname */
define( 'DB_HOST', 'db.it-connect.tech:3306' );

Si l'on met l'adresse IP "192.168.100.51" correspondante à notre nœud SRV-DEB-1, cela signifie qu'en cas de panne du nœud, les autres nœuds seront actifs, mais non utilisés par notre serveur Web, donc on peut dire que le cluster ne sera pas réellement utile. L'idéal serait d'utiliser une adresse IP virtuelle (VIP) afin que le cluster soit identifiable par une seule adresse IP grâce à un mécanisme d'IP failover. Pour cela, il existe plusieurs solutions, notamment :

  • Keepalived
  • MariaDB MaxScale
  • HAProxy (en frontal)

Personnellement, il faut que je prenne le temps d'étudier ces différentes solutions (si vous avez des retours sur le sujet, je suis preneur), mais il existe une alternative : l'enregistrement DNS. En créant l'enregistrement DNS "db.it-connect.tech" et en associant à cet enregistrement trois adresses IP (192.168.100.51, 192.168.100.52 et 192.168.100.53) de manière à assurer la continuité de service si une adresse IP ne répond pas. Pour créer cet enregistrement DNS, on peut s'appuyer sur un serveur DNS interne à l'entreprise, ou utiliser le fichier host (/etc/hosts) du serveur Web pour essayer :

192.168.100.51 db.it-connect.tech
192.168.100.52 db.it-connect.tech
192.168.100.53 db.it-connect.tech

Désormais, si un nœud plante, le serveur Web va s'appuyer sur un autre nœud de façon transparente et continuer de travailler. Lorsque le nœud HS sera de nouveau en ligne, il va se resynchroniser avec les autres maîtres du cluster afin de récupérer les dernières informations.

Pour finir, sachez que lorsque le serveur MySQL / MariaDB n'est pas situé sur le même serveur que le serveur Web en lui-même, il faut autoriser les connexions distantes dans MySQL sur chaque nœud. Pour cela, il faut éditer le fichier de configuration suivant :

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Par défaut, la propriété "bind-address" est définie sur "127.0.0.1" donc on autorise uniquement les requêtes provenant de l'hôte local. Cette valeur doit être modifiée pour que le serveur écoute sur une adresse IP spécifique ou toutes ses adresses IP :

#bind-address = 127.0.0.1
bind-address = 0.0.0.0

Ensuite, il faut donner des autorisations à l'utilisateur "utilisateur-bdd-wp" utilisé par WordPress pour administrer la base de données "wordpress" correspondante au site, à partir de l'adresse IP du serveur Web. Ce qui nécessite de se connecter à l'instance MySQL pour créer une autorisation comme ceci :

GRANT ALL privileges ON `wordpress`.* TO 'utilisateur-bdd-wp'@'<adresse-ip-serveur-web>' IDENTIFIED BY 'Mot-de-Passe' WITH GRANT OPTION;
FLUSH PRIVILEGES;

A partir de là, les modifications dans la base de données effectuées par l'intermédiaire de WordPress, sont bien répliquées entre les différents nœuds du cluster. Par exemple, lors de la création d'un nouvel article sur WordPress ou la mise à jour d'un article existant !

Ce premier article sur la mise en place d'un cluster de base de données avec MariaDB Galera Cluster est terminé ! D'autres articles à ce sujet seront certainement mis en ligne par la suite ! 🙂

The post Comment mettre en place MariaDB Galera Cluster sur Debian 11 ? first appeared on IT-Connect.

Comment sauvegarder et restaurer une base de données avec Mysqldump ?

17 mai 2022 à 09:30

I. Présentation

Dans ce tutoriel, nous allons voir comment sauvegarder et restaurer une base de données MySQL (ou plusieurs bases de données MySQL) à partir de l'utilitaire mysqldump. Il s'agit d'un utilitaire livré avec MySQL / MariaDB et qui s'utilise en ligne de commande.

Cet utilitaire est intéressant pour réaliser des sauvegardes d'une ou plusieurs bases de données d'une instance MySQL (ou MariaDB), mais également pour transférer une base de données d'un serveur MySQL à un autre (lors d'une migration, par exemple).

Pour cette démonstration, j'utilise MariaDB 10.5 sur un serveur Debian 11, mais cela fonctionne aussi avec les autres versions et d'autres distributions. Sachez également que mysqldump fonctionne sur Windows.

II. Sauvegarder une base de données avec mysqldump

Comme je le disais en introduction, mysqldump est inclus nativement avec MySQL et MariaDB, donc pour l'utiliser il suffit de l'appeler dans la console. À la suite du nom, il faudra préciser les options que l'on souhaite utiliser, et là, il y a du choix. Toutes les options sont listées dans la documentation officielle (lien).

mysqldump <options>

Voyons comment utiliser mysqldump au travers différents exemples....

A. Sauvegarder une BDD spécifique avec mysqldump

Partons du principe que l'on souhaite sauvegarder une base de données spécifique, identifiée par son nom, à l'aide de mysqldump. Dans cet exemple, je vais sauvegarder la base de données nommée "wordpress" de mon serveur MySQL, au sein d'un fichier SQL qui sera stocké dans "/home/flo", ce qui donne :

mysqldump -u root -p wordpress > /home/flo/wordpress.sql

Il faudra indiquer le mot de passe "root" afin de pouvoir réaliser la sauvegarde. On peut voir que l'on précise le fichier de sortie grâce au caractère ">" suivi du chemin vers le fichier. Dans le cas où l'authentification réussie, la sauvegarde sera effectuée. Si vous souhaitez que le nom soit daté avec la date du jour et que cela soit dynamique, c'est possible :

mysqldump -u root -p wordpress > /home/flo/wordpress-$(date +%Y%m%d).sql

Cela va donner le fichier suivant pour le 9 mai 2022 (le format est adaptable en jouant sur la structure de la commande date ci-dessus) :

wordpress-20220509.sql

Avec cette syntaxe, il sera nécessaire de créer la base de données avant de pouvoir réimporter les données (dans le cas où l'on restaure la BDD sur un autre serveur, ce sera indispensable). Si l'on souhaite que la base de données soit recréée automatiquement, il faut ajouter l'option "--databases" comme ceci :

mysqldump -u root -p --databases wordpress > /home/flo/wordpress-$(date +%Y%m%d).sql

Dans le même esprit, on peut supprimer la base de données existante pour qu'elle soit recréée lors de la restauration via l'option "--add-drop-dabatase" qui va permettre d'ajouter une requête "DROP DATABASE IF EXISTS" dans le dump SQL. Cette option doit être utilisée conjointement avec "--databases".

mysqldump -u root -p --databases wordpress --add-drop-dabatase > /home/flo/wordpress-$(date +%Y%m%d).sql

B. Sauvegarder plusieurs BDD spécifiques avec mysqldump

Dans le même principe, on peut sauvegarder non pas une, mais plusieurs bases de données spécifiques de notre instance MySQL. Pour cela, ce n'est pas utile d'exécuter plusieurs fois la commande mysqldump en modifiant le nom. Par exemple, on peut sauvegarder les bases de données "wordpress" et "moodle" dans le même fichier de sortie "wordpress-et-moodle.sql" de cette façon :

mysqldump -u root -p --databases wordpress moodle > /home/flo/wordpress-et-moodle.sql

Facile, n'est-ce pas ? Grâce à cette commande, on obtient un dump de nos deux bases de données dans un même fichier SQL.

C. Sauvegarder toutes les bases de données avec mysqldump

Il est possible d'aller encore plus loin : sauvegarder toutes les bases de données de notre instance MySQL en une seule fois ! Pour réaliser ce tour de magie, il suffit d'utiliser le paramètre "--all-databases" comme ceci :

mysqldump -u root -p --all-databases > /home/flo/all-databases.sql

Toujours sur le même principe, le mot de passe sera demandé, puis le dump sera effectué.

D. Comment créer des fichiers de sauvegardes indépendants ?

Je peux comprendre que ce ne soit pas très pratique d'avoir toutes les informations des bases de données dans le même dump (même si cela n'empêche pas de restaurer une seule base de données). Grâce à un petit script bash et une boucle for, on peut variabiliser le nom des bases de données et exécuter un mysqldump sur chaque base avec un fichier de sortie différent. En fait, on peut utiliser la commande ci-dessous pour récupérer le nom de toutes les bases de données de notre instance : une liste que l'on peut exploiter dans notre boucle for !

mysql -e 'show databases' -s --skip-column-names

Ensuite, voici un script Bash (à améliorer à votre convenance) pour réaliser la sauvegarde de chaque base de données dans le répertoire "/home/flo" au sein d'un fichier SQL indépendant :

#!/bin/bash
for database in $(mysql -e 'show databases' -s --skip-column-names); do
   echo "Sauvegarde de $database";
   mysqldump -u root -p $database > "/home/flo/$database.sql";
done

Pour ma part, ce fichier s'appelle "mysqldump-loop.sh" donc avant de l'exécuter, il faut lui ajouter les droits d'exécution :

cd /home/flo
chmod +x mysqldump-loop.sh

Puis, on l'exécute pour déclencher une sauvegarde :

./mysqldump-loop.sh

III. Restaurer une base de données avec mysqldump

Nous venons de voir différentes manières de sauvegarder une base de données avec mysqldump. Désormais, nous allons faire l'opération inverse afin de restaurer une base de données via mysqldump. Pour restaurer la base de données sur un serveur MySQL différent du serveur source, vous pouvez copier le fichier SQL au travers du réseau via SCP, à condition qu'un accès SSH vers le serveur distant soit possible.

A. Restaurer une seule base de données avec mysqldump

Tout d'abord, nous allons voir qu'il est possible de restaurer la base de données "wordpress" que l'on a sauvegardée précédemment. Pour restaurer la base de données, nous allons utiliser le fichier "wordpress.sql" qui est un dump uniquement de cette BDD.

mysql -u root -p wordpress < wordpress.sql

Il est possible que cette commande vous indique que la base de données n'existe pas (tout dépend comment est fait le dump). Dans ce cas, il faudra créer la base de données avant de pouvoir importer les données.

Sans ouvrir une console MySQL interactive, on peut exécuter une requête sur l'instance pour créer la base de données en amont :

mysql -u root -p -e "CREATE DATABASE wordpress";

Une fois que c'est fait, la requête précédente permettant d'importer les données du fichier "wordpress.sql" peut-être exécutée de nouveau :

mysql -u root -p wordpress < wordpress.sql

Bien sûr, cette opération sera plus ou moins longue en fonction de la taille du fichier SQL et des performances de votre serveur.

B. Restaurer une base de données à partir d'un dump complet

Maintenant, imaginons que l'on souhaite restaurer la base de données "wordpress" à partir du dump complet nommé "all-databases" et que l'on a créé précédemment. Il sera nécessaire de préciser le nom de la base de données à restaurer, comme ceci :

mysql -u root -p --one-database wordpress < all-databases.sql

IV. Conclusion

Nous venons de voir comment sauvegarder et restaurer une base de données MySQL / MariaDB avec mysqldump au travers différents exemples. Pour aller plus loin, notamment dans la gestion des identifiants pour ne pas avoir à préciser le login et le mot de passe à chaque fois, il est possible d'utiliser un fichier de configuration MySQL.

Le fichier de configuration peut-être créé dans le répertoire "home" de votre utilisateur Linux :

nano ~/.my.cnf

Puis, il contiendra un couple identifiant et mot de passe :

[client]
user = adm-wordpress
password = MotDePasseAdmBddWordPress

Ce fichier étant sensible, on va le sécuriser en ajustant les droits :

chmod 600 ~/.my.cnf

De cette façon, lorsque vous utilisez mysqldump avec cet utilisateur, le fichier "my.cnf" du répertoire "home" sera chargé automatiquement pour l'authentification, simplement en précisant le nom d'utilisateur. L'option "-u" est bien présente, mais plus l'option "-p" correspondante au mot de passe".

mysqldump -u adm-wordpress --databases wordpress > /home/flo/wordpress-$(date +%Y%m%d).sql

Voilà, cette astuce fait office de conclusion pour cet article ! Si vous connaissez d'autres options et astuces intéressantes pour bien utiliser mysqldump, n'hésitez pas à laisser un commentaire sur cet article ! 🙂

The post Comment sauvegarder et restaurer une base de données avec Mysqldump ? first appeared on IT-Connect.
❌