Ce script est très simple mais il permet malgré tout d’effectuer la sauvegarde de chaque schéma d’une instance MySQL dans un fichier horodaté séparé et compressé avec bzip2 (c’est avec cet algorithme que j’obtiens le meilleur taux de compression sur mes sauvegardes MySQL) . Il ne reste plus qu’à le paramétrer sous crontab (toutes les nuits par exemple) et c’est parti !

#!/bin/bash
# Script de sauvegarde MySQL v5.0
MYSQL_LOGIN=backup_login
MYSQL_PASSWORD=backup_password
BACKUP_DUMP_ROOT=/backup/mysql
echo "# Sauvegarde des Bases MySql"
echo "# DUMP=${BACKUP_DUMP_ROOT}"
timestamp="$(date +%Y%m%d-%H%M%S)"
prefix=`hostname`
# Sauvegarde de chaque Base dans un fichier
for database in `echo "show databases" | mysql -u${MYSQL_LOGIN} -p${MYSQL_PASSWORD} -N`
do
	BACKUP_FILE="${BACKUP_DUMP_ROOT}/${prefix}-mysql-backup-${timestamp}-${database}.sql"
	echo "#$(date +%Y%m%d-%H%M%S)# DEBUT Sauvegarde de [${database}] in [${BACKUP_FILE}]"

	mysqldump --quick --add-locks --extended-insert --lock-tables --allow-keywords --default-character-set=latin1 -c -u${MYSQL_LOGIN} -p${MYSQL_PASSWORD} ${database} | bzip2 -9 > ${BACKUP_FILE}.bz
	retour=$?
	if [ "$retour" -eq "0" ]
	then
			echo "#$(date +%Y%m%d-%H%M%S)# La sauvegarde s'est correctement deroulee"
	else
			echo "#$(date +%Y%m%d-%H%M%S)# La sauvegarde s'est terminee en ERREUR"
	fi
	echo "#$(date +%Y%m%d-%H%M%S)# FIN Sauvegarde de [${database}] in [${BACKUP_FILE}]"
done
exit $retour

Voici la liste des options utilisées dans le script :

ne garde pas en buffer les requêtes mais écrit immediatement sur la sortie

ajoute dans le fichier de sauvegarde une instruction LOCK TABLES avant et UNLOCK TABLES après pour accélérer les insertions dans MySQL

utilise la nouvelle syntaxe INSERT multi-ligne (plus courtes et plus efficaces)

Verrouille toutes les tables avant de commencer l’export. Les tables sont verrouillées avec READ LOCAL pour permettre des insertions concurrentes sur les tables MyISAM

Permet la création de colonnes ayant des noms de mots réservés. Cela fonctionne en préfixant chaque nom de colonne avec le nom de la table.

le charset par defaut (si ce paramètre n’est pas spécifié alors utf8 est utilisé)

insertion complete avec les noms de colonnes

Pour plus d’options de paramétrage de mysqldump, n’hésitez pas à aller consulter la documentation MySQL en ligne et à partager vos trouvailles ou optimisations.

Apache JMeter est un outils graphique écrit 100% en java permettant d’exécuter des tests fonctionnels et de mesurer les performances du système sur lequel ces tests sont executés.  Initialement, JMeter était prévu pour tester des pages web mais rapidement, des extensions ont été ajoutées pour pouvoir tester différents type de serveurs (base de données, ldap, jms, mail, …).

Une des fonctionnalités de JMeter est de pouvoir simuler autant d’utilisateurs que nous voulons afin de pouvoir effectuer des tests de montée en charge mais lorsque nous souhaitons simuler un grand nombre d’utilisateurs, une seule machine pour effectuer l’injection peut être insuffisante, il faut donc configurer l’outils pour les tests soient executés par plusieurs machines en parrallèle.

Pour se faire, JMeter doit être installé sur chaque machine devant jouer les tests.

Démarrez l’ensemble des noeuds esclaves (les machines qui exécuterons les tests) avec le script ${JMETER_HOME}\bin\jmeter-server.bat et notez leurs adresses IP.

Ensuite, avant de démarrer la console graphique de JMeter pour pouvoir lancer nos tests, il faut déclarer les noeuds esclaves dans les fichiers de configuration de JMeter. Pour cela, il faut éditer le fichier de configuration  ${JMETER_HOME}\bin\jmeter.properties et renseigner la variable remote_hosts avec les IP des machines esclaves :

#---------------------------------------------------------------------------
# Remote hosts and RMI configuration
#---------------------------------------------------------------------------

# Remote Hosts - comma delimited
remote_hosts=127.0.0.1, 192.168.0.57
#remote_hosts:localhost:1099,localhost:2010

# RMI port to be used by the server (must start rmiregistry with same port)
#server_port=1099

Dans cet exemple, j’ai ajouté une machine en plus de la machine maître, mais nous pouvons tout à fait utiliser 15 machines esclaves et supprimer l’IP de la machine maître (127.0.0.1) afin que celle-ci ne se contente de jouer les rôles d’ordonnanceur et de collecteur de résultat (ce qui est vivement conseillé quand il y a beaucoup de machines esclave).

Une fois ce fichier de configuration mis à jour, nous pouvons démarrer la machine maître et utiliser la console :

Sur la capture d’écran, on voit qu’on a maintenant 3 possibilités :

• lancer les tests avec la machine maître (menu: Démarrer)
• lancer les tests avec une seule des machines configurées (menu: Démarrage distant > choisir la machine)
• lancer les tests avec l’ensemble des machines configurées (menu: Démarrage distant de tous)

Voilà, c’est donc très simple

Eclipse Platform - Full -> 28 Go

• Release Builds
• Stable Builds
• Updates Only

Release Trains (Europa, others) -> 2 Go
Callisto Simultaneous Release -> 2 Go

le tout disponible en HTTP sur http://mirror.tarpoon.org/eclipse

Quelques statistiques pour les 2 premiers jours (la journée du 06/07 n’est pas encore terminée) :

On va voir si ma dedibox tient la charge !

A vos téléchargements !

Voici en plus, quelques liens pour aller plus loin ou pour patienter durant le téléchargement :

• les projets concernés par cette release
• la signification de Ganymede
• les trésors cachés de Eclipse 3.4 [en]
  
• blog.benjamin-cabe.com
• new & Noteworthy 3.4M7
• tous les liens sur Google

Réception et déballage de la bête le 19 mai 2008 (rapide quand même !). Installation de ma distibution linux favorite, une Ubuntu 8.04 LTS 64bits, et en quelques minutes et c’était parti.

Méfiant, avant de démarrer la migration de ma bonne “vieille” Dedibox v1 vers cette nouvelle machine, j’installe quelques applications qui vont solliciter la machine pendant quelques jours afin d’être plus confiant de la stabilité de la bécane.

Au bout d’une semaine sans soucis … Go … je démarre ma migration et progressivement, je déplace tous mes services sur le nouvel environnement qui encaisse tout ça sans broncher cool.
Hier soir, alors que ma migration est quasiment terminée, j’active le backup de mon système, je le test … impec … tout s’upload et la première sauvegarde est faite !

Quelle bonne idée j’ai eu de faire ça hier soir car ce matin, alors que ma sauvegarde journalière était en train de se dérouler et de tout transférer sur le serveur de backup … CRASH à 6h45 … plus de Dedibox !!!!! Reboot Soft de la bécane via la console d’admin … rien … reboot Hard … toujours rien … bon et bien il faut tout de même partir au boulot on verra tout ça ce soir mais ça me rappel de mauvais souvenirs avec ma Dedibox v1.

… c’est long une journée …

Ca y’est, tout le monde est couché, c’est reparti.

Reboot en Rescue Mode, montage des partition et lecture des logs et là je tombe sur ces lignes dans /var/log/kern.log qui m’intrigues :

Jun 3 06:54:36 XXXXXXXX kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jun 3 06:54:36 XXXXXXXX kernel: eth0: Transmit timeout, status 00000005 00000000
Jun 3 06:54:44 XXXXXXXX kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jun 3 06:54:44 XXXXXXXX kernel: eth0: Transmit timeout, status 00000005 00000000
…
Jun 3 07:13:08 XXXXXXXX kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jun 3 07:13:08 XXXXXXXX kernel: eth0: Transmit timeout, status 00000005 00000000

et après ___________________________ plus rien

Petite recherche sur Google puis sur http://www.dedibox-news.com et là, je me sens beaucoup moins seul :

• www.placeoweb.com
• www.dedibox-news.com
• …

Donc à priori, la piste remontée par un certain nombre de personnes est des problèmes de carte réseau lors d’ “échanges à fort débit” (tient étrange, pour moi, cela s’est justement passé lors du transfert de mes sauvegardes vers la machine distante), d’autres mettent en cause le kernel Dedibox et disent avoir résolu leurs problèmes en passant sur un kernel standard Ubuntu … qui croire ?

Pour moi ce soir cela va être changement de kernel dans un premier (et au moins je peux le faire moi même), si cela ne donne rien, je tenterai un changement de machine !

… affaire à suivre …

Et bien avec Vi, une commande suffit à tous les enlever -> :1;$ s/r//g

• rediriger STDOUT et STDERR dans un fichier

• rediriger STDOUT et STDERR dans un fichier compressé avec bzip2
  

/mon/script/ou/ma/commande 2>&1 | bzip2 -9 > /mon/fichier/de/sortie.log.bz2 2>&1

Il y a plein d’autres possibilités mais il faudrait plus qu’un post dans un blog pour les détailler.

A chaque fois que j’en ai besoin, j’ai oublié et je suis obligé d’appeler Google au secours donc cette fois, je pousse ça dans mon Blog !