Protocole de test

• Une base de données de dump brute de 7Go avec innodb a été utilisée
• Cela tourne sous MySQL 5.7, c’est une veille app comme il en reste beaucoup. Il faudra tester également avec MySQL 8.0.
• VM sous ESXi avec 12 vCPU intel Xeon qui ont 5ans.

Compressions utilisées

La compression de texte se passant mal pour bzip2, je l’ai d’office exclus. J’envisage donc Gzip et XZ. Il y a le monde un seul thread avec :

• Gzip
• XZ

Et multi-thread avec :

• pigz
• pixz

Quand il n’y a plus de gain selon le niveau de compression (pouvant aller de 1 à 9), j’arrête les tests inutiles.

Tableau benchmark compression Mysqldump

Pour Gzip, il n’y a plus de gain de taille après une compression de 7.

Pour XZ, il n’y a plus de gain de taille après un niveau de 5.

Résultats de compression Mysqldump

Le meilleur temps qui ne consomme pas trop de ressources, c’est pigz avec 4 threads et une compression de niveau 3. La compression est très bonne un niveau 7, mais 3% de taille en moins pour 28% de temps en plus, est-ce utile ? Vous savez quoi utilise pour gagner 5,5x l’espace disque en impactant très peu la charge CPU.

Comme vous pouvez le voir, il y a deux options si vous avez besoin d’archiver à long terme beaucoup de données :

• soit vous cherchez la rapidité et avoir un gain important de place par rapport à gzip et vous utiliserez pixz avec un niveau 1 de compression et 2 processus.
• soit vous cherchez une compression importante et vous utiliserez pixz avec un niveau 3 de compression et 5 processus. Un niveau plus haut que 3 ne sert à rien, trop de temps perdu pour un gain minime de compression, comme on peut le voir avec un niveau 5

Si vous avez une architecture master/slave MySQL, je vous conseille de le faire sur votre slave pour éviter les lock tables sur votre master.

J’ai effectué un comparatif également pour les backups compressés d’XtraBackup.

L’article Mysqldump benchmark compression est apparu en premier sur Mon linux.

Installation du rôle Ansible Automysqlbackup

Pour installer ce rôle de configuration sous Debian ou Ubuntu rien de plus simple :

ansible-galaxy install belgotux.automysqlbackup

Pré-requis

Il est préférable de créer un utilisateur spécifique pour automysqlbackup sur chaque serveur devant être sauvegardé. Pour cela les droits suivants sont nécessaire :

CREATE USER 'automysqlbackup'@'serverA' IDENTIFIED BY  '<your_password_secret>';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER,USAGE ON *.* TO 'automysqlbackup'@'serverA' ;

Pour utiliser le rôle Ansible Automysqlbackup en local, les droits suivants :

CREATE USER 'automysqlbackup'@'localhost' IDENTIFIED BY  '<your_password_secret>';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER,USAGE ON *.* TO 'automysqlbackup'@'localhost' ;

Configuration des variables Ansible

Nécessaires

Configuration du serveur :

• automysqlbackup_repo répertoire où déposer le projet git (défaut /opt)
• automysqlbackup_client binaire sql client à utiliser, soit mariadb-client ou mysql-client (défaut mariadb-client)
• automysqlbackup_bin répertoire où copier le script (défaut /usr/local/bin)
• automysqlbackup_conf répertoire des configurations (défaut /etc/automysqlbackup)
• automysqlbackup_backupdir répertoire des sauvegardes

Configuration du client SQL

• automysqlbackup_default_user utilisateur MySQL utilisé par défaut pour les serveurs (défaut automysqlbackup)
• automysqlbackup_default_passwd mot de passe MySQL utilisé par défaut pour les serveurs
• automysqlbackup_configurations liste des serveurs à sauvegarder. Prend la valeur de automysqlbackup_default_user, automysqlbackup_default_passwd, etc si user, passwd, etc n’est pas défini

automysqlbackup_configurations:
- name: server1
  server: xxx.yourdomain.tld
  port: 3306            # default use 3306
  user: test            # default use `automysqlbackup_default_user`
  passwd: testpwd       # default use `automysqlbackup_default_passwd`
  cron: "0 23 * * *"    # default use `automysqlbackup_default_cron`
  montly: 01            # default use `automysqlbackup_monthly`
  weekly: 5             # default use `automysqlbackup_weekly`
  daily_to_keep: 5      # default use `automysqlbackup_daily_to_keep`
  weekly_to_keep: 4     # default use `automysqlbackup_weekly_to_keep`
  monthly_to_keep: 3    # default use `automysqlbackup_monthly_to_keep`
- name: server2
  server: 192.168.x.x

• automysqlbackup_default_db_exclude liste des bases de données exclues par défaut si la variable db_names n’est pas remplie sur la configuration serveur (défaut « ('information_schema' 'performance_schema' 'sys' )« )
• automysqlbackup_default_table_exclude liste des tables à exclure au format db_name.table_name (défaut « ('mysql.event')« )
• automysqlbackup_default_cron défini le cron par défaut à utiliser pour tous les serveurs, exemple "0 23 * * *"
• automysqlbackup_create_user utilisateur système à créer par le rôle, true or false ? Crée automysqlbackup_default_cron_user (défaut true)

Facultatif

Server configuration

• automysqlbackup_multicore utilisation de compression multicore pigz pour gzip ou pbzip2 pour bzip2. Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_multicore_threads nombre de cpu à utiliser. Peut être un nombre ou auto pour laisser pigz ou pbzip2 choisir (défaut auto)
• automysqlbackup_default_cron_user utilisateur à utiliser pour exécuter le cron (default automysqlbackup)
• automysqlbackup_default_cron_group groupe à utiliser pour le dossier de backup (défaut users)
• automysqlbackup_default_cron_path répertoire cron (défaut /etc/cron.d)

SQL client configuration

• automysqlbackup_monthly quelle jour faire le backup mensuel ? (01 à 31) mettre 0 pour désactivé le backup mensuel (défaut 01)
• automysqlbackup_weekly uelle jour faire le backup hebdomadaire ? (1 à 7 ou 1 est lundi) mettre 0 pour désactivé le backup hebdomadaire (défaut 5)
• automysqlbackup_daily_to_keep combien de backups journaliers à garder (défaut 6)
• automysqlbackup_weekly_to_keep combien de backups hebdomadaires à garder (défaut 28)
• automysqlbackup_monthly_to_keep combien de backups mensuels à garder (défaut 180)
• automysqlbackup_no_tablespaces le droits sql PROCESS est nécessaire depuis MySQL 5.7.31 et 8.0.21, l’option –no-tablespaces permet d’éviter d’avoir l’erreur. Peut être 'yes' ou 'no' (défaut 'yes')
• automysqlbackup_dump_usessl Utiliser le chiffrement SSL avec mysqldump ? Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_dump_single_transaction Lors de l’utilisation de cette option, il est important de noter que seules les tables InnoDB sont sauvegardées dans un état cohérent. Par exemple, toutes les tables MyISAM ou MEMORY sauvegardées lors de l’utilisation de cette option peuvent encore changer d’état. Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_dump_dbstatus Statut de sauvegarde de table(s) dans un fichier texte. Cela est très utile lors de la restauration des sauvegardes, car cela donne une idée des changements survenus entre-temps. Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_dump_create_database Inclure la commande CREATE DATABASE dans le backup. Peut être 'yes' ou 'no' (défaut 'no')
• automysqlbackup_dump_use_separate_dirs séparer le répertoire de backup pour chaque base de données. Peut être 'yes' ou 'no' (défaut 'yes')
• automysqlbackup_dump_compression choisir une compression du type gzip or bzip2 (défaut gzip)
• automysqlbackup_dump_latest Stocker une copie supplémentaire (lien physique) de la dernière sauvegarde dans un emplacement standard afin qu’elle puisse être téléchargée par des scripts tiers. Peut être 'yes' ou 'no' (défaut 'yes')
• automysqlbackup_dump_latest_clean_filenames Supprimer toutes les informations de date et d’heure des noms de fichiers dans le dossier le plus récent. (défaut yes)
• automysqlbackup_mailcontent Que souhaitez-vous recevoir par courrier électronique : log (envoi les log), files (envoie les logs et fichiers sql en attaché), stdout (affiche les log dans la sortie standard utile pour l’exécution manuelle), quiet (envoie les log uniquement si une erreur apparait) (défaut log)
• automysqlbackup_mail_address addresse mail du destinataire
• automysqlbackup_dryrun Simulation de ce qui sera fait, ne fait rien en réalité. 0 mode inactif, 1 mode actif (défaut 0)

L’article Rôle Ansible Automysqlbackup est apparu en premier sur Mon linux.

L’utilisation est presque la même, hormis l’utilisation préférable d’un fichier my.cnf pour ne plus avoir les identifiants MySQL dans la ligne de commande… Le mot de passe est stocké dans un fichier à devoir remplir dans la variable CONFIG_mysql_mycnf_file .

D’autres bugfix ont été réglés pour des arguments actuellement dépréciés –ssl, ainsi que des problèmes lié à un accès refusé pour les tablespaces.

Pour ceux qui ne connaissent pas, AutoMySQLBackup permet un fonctionnement en mode whitelist ou blacklist des bases de données à sauvegarder. Souvent, on va lui dire que tout sauvegarder sauf information_schema, performance_schema, sys. C’est donc une sauvegarde MySQL automatique ! Et toute nouvelle base de données ajoutée sur le serveur mutualisé sera automatiquement sauvegardée ! Il permet de gérer une rétention différente pour les backups journaliers, hebdomadaires ou mensuels.

Installation d’AutoMySQLBackup

Voici les étapes d’installation :

• Pré-requis de bonne pratique, créer un utilisateur dédié au dump MySQL pour AutoMySQLBackup

CREATE USER 'automysqlbackup'@'localhost' IDENTIFIED BY  '<MOT_DE_PASSE>';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER,USAGE ON *.* TO 'automysqlbackup'@'localhost' ;

• Copier le répertoire git OU directement le dernière version de l’archive

git clone https://github.com/belgotux/automysqlbackup.git
wget https://github.com/belgotux/automysqlbackup/archive/refs/heads/main.zip && unzip main.zip

• Installer le script et les fichiers de configuration

sudo bash install.sh

• Créer le fichier contenant les identifiants de connexion /etc/automysqlbackup/votre-server.cnf

[mysqldump]
user=automysqlbackup
password=""
[mysql]
user=automysqlbackup
password=""
[mysqlshow]
user=automysqlbackup
password=""

• Créer le fichier de configuration /etc/automysqlbackup/votre-server.conf en vous basant sur le template. Les points importants sont :

CONFIG_mysql_mycnf_file='/etc/automysqlbackup/votre-server.cnf'
CONFIG_mysql_dump_host='localhost'
CONFIG_backup_dir='/backup/db'
CONFIG_db_names=()  # laisser vide pour sauvegarder toutes les bases de données
CONFIG_db_month_names=() # idem
CONFIG_db_exclude=( 'information_schema' 'performance_schema' 'sys' ) # exclus ces bases
CONFIG_table_exclude=('mysql.event') # exclus cette table
CONFIG_do_monthly="01"
CONFIG_do_weekly="6"
CONFIG_rotation_daily=7
CONFIG_rotation_weekly=4
CONFIG_rotation_monthly=180
CONFIG_mysql_no_tablespaces='yes'
CONFIG_mysql_dump_use_separate_dirs='yes'
CONFIG_mysql_dump_compression='gzip'
CONFIG_mysql_dump_latest='yes'
CONFIG_mysql_dump_latest_clean_filenames='no'
CONFIG_mailcontent='quiet'
CONFIG_mail_address='root'

• Créer le cron /etc/cron.d/automysqlbackup

0 21 * * *       root    /usr/local/bin/automysqlbackup /etc/automysqlbackup/votre-server.conf > /dev/null

• Tester manuellement une première fois pour vérifier la création des dossiers daily/weekly/monthly

/usr/local/bin/automysqlbackup /etc/automysqlbackup/votre-server.conf

Voilà, vos sauvegardes MySQL sont maintenant automatisées, vous recevez un mail en cas de problème du script!

Si vous utilisez une architecture MySQL master-slave, je vous conseille de le faire sur le slave, afin de ne pas faire durer un lock table sur le master. Une désynchronisation du slave est préférable, voir un slave dédié si vous ne pouvez vous permettre une désynchro de quelques secondes

L’article AutoMySQLBackup – sauvegarde MySQL est apparu en premier sur Mon linux.

Restaurer un slave via un dump du master

Vous devez avoir créé un dump de votre base de données quand celui-ci est figée, il faut donc faire quelques préparations.

1. Préparation sur le master

Ouvrez 2 consoles SSH sur le master.

Dans la première, ouvrir une console MySQL pour mettre la base de données en read-only (pour ne pas arrêter le service carrément), cela va donc entrainer une interruption de service pour les écritures

FLUSH TABLES WITH READ LOCK;

Dans l’autre fenêtre, obtenir la position du log file via une nouvelle console MySQL et notez le :

show master status \G

Fermez la console MySQL pour revenir en shell pour faire votre dump :

mysqldump  --add-drop-table --user=root -p DB_NAME | gzip -3 --stdout > DB_NAME.sql.gz

Une fois le dump fini, retournez dans la première console MySQL pour faire la commande de libération des tables :

unlock tables;

Vérifiez que les tables sont bien libérées après avoir attendu une minute :

show open tables;

2. Remettre la réplication MySQL en place sur le slave

En premier, démarrez MySQL, injectez le dump (ce qui peut prendre du temps et vérifiez que vos bases de données sont bien là.

zcat DB_NAME.sql.gz | mysql -u root -p VOTRE_DB

Appliquez les commandes suivantes, en remplaçant les valeurs par celle de votre infrastructure :

• HOST : votre serveur master
• USER : l’utilisateur MySQL de réplication si vous en avez défini un sinon le root (je vous conseille un utilisateur dédié avec uniquement les droits nécessaires)
• PASSWORD : le mot de passe
• LOG_FILE et LOG_POS : les valeurs de la position du log file récupérée plus haut sur le master

reset slave;
CHANGE MASTER TO
MASTER_HOST='serveur_master.tld',
MASTER_USER='repl',
MASTER_PASSWORD='passwd',
MASTER_LOG_FILE='mysql-bin.002043',
MASTER_LOG_POS=106;
start slave;

Attendez une minute et puis vérifiez le status du slave :

show slave status \G

Vous devriez avoir ceci parmi la réponse :

Slave_IO_State: Waiting for master to send event
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Votre réplication est donc correcte.

Pour vous rassurez la première fois, vous pouvez faire un « create database toto » sur le master, voir si la base de données apparait sur le slave et ensuite faire un « drop database toto » sur le master.

L’article MySQL rétablir la réplication d’un slave avec un dump du master est apparu en premier sur Mon linux.

• Quelqu’un se connecte sur un slave et fait une modification… (des options readonly permettent de s’en prémunir)
• Mauvaise perte de connexion entre les serveurs
• Crash du master
• …

Pour commencer, je ne le répèterai jamais assez, pensez aux backups de vos bases de données MySQL. Je vais traiter le sujet dans un article sur la sauvegarde de grosse base de données MySQL via xtrabackup, mais autobackup est parfait pour de petites base de données. Ce dernier est basé sur mysqldump, mais gère la journalisation des dumps. J’explique la restauration master-slave à partir d’un dump dans un autre article.

Vous avez maintenant votre roue de secours, on peut donc regarder pour solutionner votre problème de réplication MySQL. Dans la suite de cet article, je traite la restauration à partir des binaires ou d’une sauvegarde Xtrabackup.

Type d’erreur

Avec un show slave status, vous avez une erreur du type :

error ' Duplicate entry '2513' for key 1' on query 'INSERT INTO users VALUES('','400', 'user1', '(hidden)', 'Belgium')'

Restaurer un slave via une copie binaire ou xtrabackup

La première méthode permet de partir des fichiers binaires :

• soit via une sauvegarde xtrabackup, donc pas d’arrêt de service. Xtrabackup sauvegarde le logfile et sa position, très utile pour rétablir la synchronisation.
• soit via une copie rsync des données de /var/lib/mysql du master, mais le rsync doit être fait avec le serveur MySQL éteint! Ou en read-only avec des flush tables pour ne pas trop dégrader…

1. Préparation sur le slave

Arrêtez le service MySQL.

Si vous avez xtrabackup, copiez la dernière sauvegarde et passez l’étape suivante, rien à faire sur le master, direction point 3.

Si vous le faite via rsync, suivez l’étape suivante.

2. Préparation sur le master uniquement via rsync

Ouvrez 2 consoles SSH sur le master.

Dans la première, ouvrir une console mysql pour mettre la base de données en read-only (pour ne pas arrêter le service MySQL carrément)

FLUSH TABLES WITH READ LOCK;

Dans l’autre fenêtre, obtenir la position du log file via une nouvelle console MySQL et notez le :

show master status \G

Fermez la console MySQL pour revenir en shell.

Maintenant, copiez le répertoire /var/lib/mysql avec les options rsync -ahPl du master vers le slave.

Une fois la copie finie, retournez dans la première console MySQL pour faire la commande de libération des tables :

unlock tables;

Vérifiez que les tables sont bien libérées après avoir attendu une minute :

show open tables;

3. Remettre la réplication MySQL en place sur le slave

En premier, démarrez MySQL et vérifiez que vos bases de données sont bien là.

Appliquez les commandes suivantes, en remplaçant les valeurs par celle de votre infrastructure :

• HOST : votre serveur master
• USER : l’utilisateur MySQL de réplication si vous en avez défini un sinon le root (je vous conseille un utilisateur dédié avec uniquement les droits nécessaires)
• PASSWORD : le mot de passe
• LOG_FILE et LOG_POS : les valeurs de la position du log file récupérée plus haut sur le master

reset slave;
CHANGE MASTER TO
MASTER_HOST='serveur_master.tld',
MASTER_USER='repl',
MASTER_PASSWORD='passwd',
MASTER_LOG_FILE='mysql-bin.002043',
MASTER_LOG_POS=106;
start slave;

Attendez une minute et puis vérifiez le status du slave :

show slave status \G

Vous devriez avoir ceci parmi la réponse :

Slave_IO_State: Waiting for master to send event
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Votre réplication est donc correcte.

Pour vous rassurez la première fois, vous pouvez faire un « create database toto » sur le master, voir si la base de données apparait sur le slave et ensuite faire un « drop database toto » sur le master.

L’article MySQL problème de réplication master slave est apparu en premier sur Mon linux.

Bien évidement j’avais prévu le coup et je n’ai rien perdu si ce n’est les logs WordPress de connexion des dernières 24h, ce qui n’a jamais était mon souci. Les logs de mon hébergeur me donne déjà satisfaction.

Voici mon premier dossier consacré à la sauvegarde sécurisée des données de votre site web. Il y a 3 étapes à faire pour avoir un backup sur, simple, complet et surtout entièrement automatisé :

1. Exporter les bases de données MySQL dans la partie privée de son FTP via cron
2. Cloner le contenu de son FTP à distance pour avoir ses backups délocalisées
3. Mettre en place un backup des données FTP en local pour l’historique via rdiff-backup

Par après on pourrait imaginer de mettre ces données dans un backup externalisé de deuxième niveau

L’article [dossier] Sauvegarder les données de son site en 3 étapes – backup est apparu en premier sur Mon linux.

On va sauvegarder ses bases de données MySQL via un script PHP qui pourra être interprété par la grande majorité des hébergeurs. Vous disposez d’une fonction de tâche planifiée pour effectuer vos backups automatiquement. L’hébergeur propose d’envoyer par mail le retour du script, vous pourrez donc visionner le bon déroulement des backups. Ces dump MySQL seront placés dans la partie privée de votre FTP.

Voici le script PHP à mettre dans la partie privée de votre hébergement : backup_mysql.php

• Pour le point backupdir : c’est le répertoire utilisateur de votre compte chez l’hébergeur. Si vous ne l’avez pas, vous pouvez le savoir avec un ‘pwd’ ou un ‘echo $HOME’ mis dans un script dans une tâche planifiée. Mettez bien cela dans la partie privée du FTP de votre hébergement!
• Pour mettre la tâche planifiée, cela dépend de votre interface d’hébergeur. Mais tout hébergeur avec Cpanel le propose, ainsi qu’OVH. Je vous conseille de faire un backup chaque jour de la base de données de votre site. S’il est fort fréquenté, comme un blog WordPress avec commentaires, alors même plusieurs fois par jour…

Voici le script en question :

<?php

$server='';		// serveur mysql
$login='';		//login mysql
$mdp='';		//mot de passe mysql
$backupdir='/home/a4327242/backup_db';		// pour savoir le répertoire local de votre hébergeur si c'est pas indiqué, faite la commande 'pwd' dans l'interface cron
$logfile='/home/a4327242/backup_db/backup_db.log';
$timezone='Europe/Brussels';	// pour les heures des fichier de logs

//un appel par base de données (souvent une seule pour un hébergeur)
backup_tables($server,$login,$mdp,$backupdir,$timezone,$logfile,'nom_base_de_donnees');


/* backup the db OR just a table */
function backup_tables($host,$user,$pass,$backupdir,$timezone,$log,$name,$tables = '*')
{
	$link = mysql_connect($host,$user,$pass);
	mysql_select_db($name,$link);
	
	//get all of the tables
	if($tables == '*')
	{
		$tables = array();
		$result = mysql_query('SHOW TABLES');
		while($row = mysql_fetch_row($result))
		{
			$tables[] = $row[0];
		}
	}
	else
	{
		$tables = is_array($tables) ? $tables : explode(',',$tables);
	}
	
	//cycle through
	foreach($tables as $table)
	{
		$result = mysql_query('SELECT * FROM '.$table);
		$num_fields = mysql_num_fields($result);
		
		$return.= 'DROP TABLE '.$table.';';
		$row2 = mysql_fetch_row(mysql_query('SHOW CREATE TABLE '.$table));
		$return.= "\n\n".$row2[1].";\n\n";
		
		for ($i = 0; $i < $num_fields; $i++) 
		{
			while($row = mysql_fetch_row($result))
			{
				$return.= 'INSERT INTO '.$table.' VALUES(';
				for($j=0; $j<$num_fields; $j++) 
				{
					$row[$j] = addslashes($row[$j]);
					$row[$j] = ereg_replace("\n","\\n",$row[$j]);
					if (isset($row[$j])) { $return.= '"'.$row[$j].'"' ; } else { $return.= '""'; }
					if ($j<($num_fields-1)) { $return.= ','; }
				}
				$return.= ");\n";
			}
		}
		$return.="\n\n\n";
	}
	
	//save file
	$date = new DateTime();
	$date->setTimeZone(new DateTimeZone($timezone));

	$filename=$backupdir.'/db-'.$name.'-'.$date->format('Y-m-d H:i').'-'.(md5(implode(',',$tables))).'.sql';
	$handle = fopen($filename,'w+');
	fwrite($handle,$return);
	fclose($handle);
	echo "File $filename create successful";
}

?>

Pour la 2e étape, clonez le contenu de votre FTP chez vous comme backup! Vos dump MySQL avec

L’article Exporter les bases de données MySQL dans la partie privée de son FTP via cron est apparu en premier sur Mon linux.