MySQL – Améliorer export et import de données

Exporter des données

SELECT name, age, city INTO OUTFILE '/tmp/data' FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n'; FROM test.people;

Exporte le fichier /tmp/data contenant les champs name, age, city de la table people:

"alexandre","30","paris"
"mark","26","new york"

Importer des données

LOAD DATA INFILE '/tmp/data' INTO TABLE people FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';

Importe le fichier /tmp/data dans la table people

App

MySQL – Workbench : Installation à partir d’un paquet sous Linux Ubuntu 8.04

sudo apt-get install liblua5.1-0 libzip1 python-paramiko
python-pexpect python-crypto

wget http://dev.mysql.com/get/Downloads/MySQLGUITools/mysql-workbench-oss-5.2.17-1ubu804-i386.deb/from/http://mirrors.ircam.fr/pub/mysql/

Choisir un autre miroir de téléchargement

sudo dpkg -i mysql-workbench-oss-5.2.17-1ubu804-i386.deb

Site officiel:  http://wb.mysql.com/

App

MySQL – Définition et taille des Types

VARCHAR
Texte, 250 caractères max

TINYINT
Entier compris entre -128 et 127

TEXT
Texte, 65 535 caractères max

DATE
Date, de la forme : YYYY-MM-DD

SMALLINT
Nombre entier, entre -32 768 et 32 767

MEDIUMINT
Nombre entier, entre -8 388 608 et 8 388 607

INT
Nombre entier, entre -2 147 483 648 et 2 147 483 647

BIGINT
Nombre entier, entre -9 223 372 036 854 775 808 et 9 223 372 036 854 775 807

FLOAT
Nombre à virgule flottante

DOUBLE
Nombre à virgule flottante, à double précision

DECIMAL
Nombre à virgule flottante, non-compressé

DATETIME
Date et heure, de la forme : YYYY-MM-DD – HH:MM:SS

TIMESTAMP
Date et heure, de la forme : YYYY-MM-DD – HH:MM:SS

TIME
Heure, dela forme : HH:MM:SS

YEAR
Année (YYYY par défaut)

CHAR
Texte, 250 caractères. Complété par des blancs si ces 250 caractères ne sont pas atteints.

TINYBLOB
Texte, 250 caractères maximum

TINYTEXT
Texte, 250 caractères maximum

BLOB
Texte, 65 535 caractères max

MEDIUMBLOB
Texte, 16 777 215 caractères max

MEDIUMTEXT
Texte, 16 777 215 caractères max

LONGBLOB
Texte, 4 294 967 295 caractères max

LONGTEXT
Texte, 4 294 967 295

ENUM
Enumération

SET
Ensemble d’élements, 64 maximum

Liste non exhaustive :)

App

MySQL – /usr/bin/mysqladmin: connect to server at ‘localhost’ failed error: ‘Access denied for user ‘debian-sys-maint’@'localhost’ (using password: YES)’

Lors de l’upgrade etch -> lenny le paquet mysql-server ne s’installait pas. Mysql ne pouvait être stopé:

/usr/bin/mysqladmin: connect to server at 'localhost' failed error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'

Nous allons pour résoudre ce problème mettre à jour le mot de passe MySQL du user debian-sys-maint.

Récupérer le mot de passe de l’utilisateur debian-sys-maint:
cat /etc/mysql/debian.cnf

user = debian-sys-maint
password = ************

Mettre à jour le mot de passe de l’utilisateur mysql debian:
mysql -uroot -p
GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY '
' WITH GRANT OPTION;

App

MySQL – Haut Disponibilité : Réplication

Avec des bases de données Mysql et des tables contenant plusieurs millions d’enregistrements, les sauvegardes deviennent assez lourdes. Si un serveur tombe, cela peut entrainer plusieurs heures perdues, le temps de mettre en place un nouveau serveur, de réimporter les données depuis la backup. Nous ne parlons même pas des pertes financières potentielles due à cette période. On peut parvenir à une meilleure stabilité avec Mysql soit grâce à un cluster ou une réplication. Nous allons nous concentrer sur la réplication dans cet article. Quoiqu’il en soit, ceci est un rapide tutorial pour mettre une réplication en place; Faîtes un tour dans la documentation Mysql pour en savoir plus.

replication

Le master peut répliquer ses données vers plusieurs esclaves, auxquels des clients web différents peuvent envoyer leurs requêtes. Les écritures doivent toujours être envoyées au master. Si elles sont envoyées à un esclave, elles ne seraient pas répliquées sur les autres serveurs.

Note La réplication est asynchrone puisque l’esclave a besoin d’un petit délai pour être mis à jour. C’est particulièrement adapté pour les applications comme les datawarehouses.

Fail-over

La réplication ne fournit pas d’auto-failover car elle requiert une intervention manuelle. Un autre article est disponible sur l’implementation du failover avec Heartbeat. Cela donne la possibilité de basculer le trafic automatiquement vers le serveur esclave en quelques secondes.

Démarrage

Nous assumerons avoir un serveur seul contenant déjà les informations précieuses, et où l’on veut implémenter un système de redondance. Procédez de la manière suivante pour que votre serveur soit prêt à la réplication:

  • Activatez le log binaire sur le serveur maître. C’est absolument nécessaire, l’esclave doit lire ces fichiers binaires pour se synchroniser. my.cnf contient log-bin=mysql-bin dans la section [mysqld] dans mon cas
  • Ajoutez server-id=1 dans my.cnf.
    Cet id doit être unique pour chaque serveur (L’esclave sera 2). Redémarrez le service si ces options n’étaient pas activées.
  • Créez un compte pour l’esclave sur le master pour qu’il soit autorisé à répliquer:
    GRANT REPLICATION SLAVE ON *.*
    TO 'slave'@'192.168.0.3' IDENTIFIED BY 'mypassword';

    où ’slave’ est le nom d’utilisateur avec lequel le serveur esclave va se connecter, 192.168.0.3 l’adresse IP de l’esclave.

  • Mettez en place une nouvelle machine pour le serveur esclave et installez Mysql. my.cnf doit contenir ceci:
    [mysqld]
    server-id=2
    . Ne démarrez pas le service maintenant!

Transfer des données vers l’esclave

  • Bloquez tout d’abord les opérations d’écriture sur le master et enregistrez les dernières valeurs depuis le log binaire:
    mysql> FLUSH TABLES WITH READ LOCK;
    mysql> SHOW MASTER STATUS;

    Vous devriez obtenir quelque chose de similaire à ceci:

    +-------------------+----------+--------------+------------------+
    | File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +-------------------+----------+--------------+------------------+
    | my-db1-bin.000002 |      239 |              |                  |
    +-------------------+----------+--------------+------------------+

    Soyez sûrs d’enregistrer ces valeurs, elles seront nécessaires pour la suite.

  • Arrétez le processus Mysql sur le maître et faîtes une copie du répertoire de données avec tar par exemple. Après avoir exécuté tar, redémarrez le service. C’est la seule fois que le master sera arrété.
  • Copiez le fichier tar sur l’esclave dans le répertoire temp par exemple, décompressez le et copiez les fichiers vers le répertoire de données. Ne copiez pas les fichiers de log.
    Vérifiez que les droits sont corrects (Ils doivent être identiques aux fichiers originaux). Vous avez maintenant les données du master sur l’esclave.

Activation de la réplication sur l’esclave

Démarrez l’esclave avec l’option suivante:
–skip-slave-start

Vous pouvez aussi logguer les warnings dans le log d’erreurs pour avoir une meilleure idée de se qui se passe
–log-warnings

Maintenant que le serveur est démarré, connectez-vous dessus avec un client Mysql, et ajoutez les détails du master:

mysql> CHANGE MASTER TO
mysql> MASTER_HOST='192.168.0.2',
mysql> MASTER_USER='slave',
mysql> MASTER_PASSWORD='mypassword',
mysql> MASTER_LOG_FILE='my-db1-bin.000002',
mysql> MASTER_LOG_POS=239;

Les 2 dernières lignes contiennent bien sûr les valeurs récupérées sur le master.

mysql> START SLAVE;

La réplication peut commencer!
Le status de l’esclave peut être vérifiée via la commande suivante:

mysql> show slave status;
+---------------------+-------------+-------------+-///-+---------------+-------------------+
| Slave_IO_State      | Master_Host | Master_User |     | Connect_Retry | Master_Log_File   |
+---------------------+-------------+-------------+-///-+---------------+-------------------+
| Waitin...send event | 192.168.0.2 | slave       |     |            60 | my-db1-bin.000006 |
+---------------------+-------------+-------------+-///-+---------------+-------------------+

+---------------------+---------------+---------------+-----------------------+-----------------+
| Read_Master_Log_Pos | Relay_Log_File| Relay_Log_Pos | Relay_Master_Log_File | Slave_IO_Running|
+---------------------+---------------+---------------+-----------------------+-----------------+
|           514457737 | s...in.000007 |      26082745 | my-db1-bin.000006     | Yes             |
+---------------------+---------------+---------------+-----------------------+-----------------+

+-------------------+-///-+---------------------+-----------------+-///-+-----------------------+
| Slave_SQL_Running |     | Exec_Master_Log_Pos | Relay_Log_Space |     | Seconds_Behind_Master |
+-------------------+-///-+---------------------+-----------------+-///-+-----------------------+
| Yes               |     |           514457737 |        26082745 |     |                     0 |
+-------------------+-///-+---------------------+-----------------+-///-+-----------------------+

Si la réplication arrête de fonctionner pour quelque raison que ce soit, la dernière erreur sera affichée ici. Vous pouvez aussi les trouver dans le fichier de log d’erreurs mysql.
Désactivez l’option –skip-slave-start du script de démarrage pour que la réplication soit activée après le redémarrage du serveur.

David Roze

Source: http://www.netexpertise.eu/fr/mysql/replication-haute-disponibilite.html

Plus d’infos sur : http://www.dbnewz.com/tag/replication/

App

MySQL – Erreur #144 – .MYD corrompu

Contexte:
on lance une optimisation sur une table (>100M d’enregistrements), puis on « kill » brusquement la requête MySQL en cours.

>SHOW INDEX FROM `table`;

#144 - Table './database/table' is marked as crashed and last (automatic?) repair failed

Solution:
myisamchk -o /var/lib/mysql/database/table.MYI

- recovering (with keycache) MyISAM-table ‘/var/lib/mysql/database/table.MYI’
Data records: 101432249

App

MySQL – Troubleshooting Réplication : Slave_IO_Running: No

Contexte:
Une réplication MySQL Master/Slave n’est plus opérationnelle.
La machine master1 héberge l’applicatif MySQL Master.
La machine slave1 héberge l’applicatif MySQL Slave.

Sur la machine slave MySQL, en root:
mysql> show slave status\G;

Slave_IO_Running: No
Slave_SQL_Running: Yes

Il s’agit vraisemblablement d’un problème de connectivité entre les deux machines.

Résolution:

Avant toutes choses consulter sur master1 les fichier de logs /var/log/mysql.err et /var/log/mysql.log

Cas d’une machine slave* renommée:

Sur slave1 tester la connectivité MySQL:

  • Vérifier que le flux est ouvert sur le port 3306

telnet master1 3306
Le client MySQL doit répondre sur ce port

  • Vérifier que l’utilisateur MySQL de réplication et son mot de passe est correct pour un hostname défini:

mysql -u user_replication -h master1 -p password_user_replication
Permission Denied

Sur master1 vérifier les informations MySQL suivantes:

select * from mysql.user where user = 'user_replication';

App

MySQL – Concatenation de champs avec la fonction CONCAT()

Problème:

La base de données MySQL musique contient la table titre.
La table titre contient les champs id_auteur, nom_titre.

Cette table titre contient donc des œuvres de musique comme suit:

id_auteurnom_titre
102 – un_titre
27 – un_autre_titre
35 – encore_un_autre_titre

Tentons par exemple de modifier les œuvres de l’artiste 102, en lui ajoutant un titre.

Solution:
Nous utiliserons pour cela la fonction CONCAT().

UPDATE titre
SET nom_titre = CONCAT(nom_titre,'nouveau_titre_a_ajouter')
WHERE id_auteur = '102'

Les oeuvres de l’artiste 102 sont à présent les suivantes:

un_titre
nouveau_titre_ajouté

App

MySQL – Rotation des logs

La rotation des logs MySQL est installée par défaut sur Debian:

  • Durée de rétention: 7 jours
  • Fréquence de la rotation: tous les jours
  • Compression GZIP: oui

/etc/logrotate.d/mysql-server

/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log {
daily
rotate 7
missingok
create 640 mysql adm
compress
sharedscripts
postrotate
test -x /usr/bin/mysqladmin || exit 0
# If this fails, check debian.conf!
export HOME=/etc/mysql/my.cnf
MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
# Really no mysqld or rather a missing debian-sys-maint user?
# If this occurs and is not a error please report a bug.
if ps cax | grep -q mysqld; then
exit 1
fi
else
$MYADMIN flush-logs
fi
endscript
}

On peut vérifier que la rotation est effective.

ls -l /var/log/mysql*

donne:


-rw-r----- 1 mysql adm 0 2008-10-01 07:54 /var/log/mysql.log
-rw-r----- 1 mysql adm 20 2008-09-30 07:50 /var/log/mysql.log.1.gz
-rw-r----- 1 mysql adm 20 2008-09-29 08:01 /var/log/mysql.log.2.gz
-rw-r----- 1 mysql adm 20 2008-09-28 07:42 /var/log/mysql.log.3.gz
-rw-r----- 1 mysql adm 20 2008-09-27 07:43 /var/log/mysql.log.4.gz
-rw-r----- 1 mysql adm 20 2008-09-26 07:37 /var/log/mysql.log.5.gz
-rw-r----- 1 mysql adm 20 2008-09-25 07:40 /var/log/mysql.log.6.gz
-rw-r----- 1 mysql adm 20 2008-09-24 07:59 /var/log/mysql.log.7.gz

App

forum.ubuntu-fr.org down

Détecté (début du problème) sur http://forum.ubuntu-fr.org/:
mercredi 24 Septembre à 15h45.

Fin: 16h30

App

Quelques chiffres sur l’infrastructure de Facebook

Voici quelques chiffres clefs datant d’avril 2008 concernant la volumétrie de la plateforme:

  • Nombre de serveur MySQL – 1 800
  • Nombre d’administrateur MySQL (DBAs) – 2
  • Nombre de serveurs Web – 10 000
  • Nombre de serveurs Memcached – 805
Comme le souligne l’article le ratio 1 800 pour 2 ( nombre de serveurs MySQL / nombre  de personnes qui les administrent) est assez impressionant.

App

Sauvegarder un blog wordpress sur une clef usb

Objectif

Sauvegarder/Restaurer un blog de type WordPress:

  • sauvegarde des fichiers PHP
  • export SQL de la base de données

Langage de script utilisé: Bash

Script de Sauvegarde

wp-backupblog.sh

#!/bin/bash
# wp-backupblog.sh - Backup WordPress Blog
# version: 0.1
# Author: Benjamin Baudouin
# http://www.benjaminbaudouin.com
DEVICE=/dev/sda1
SRCDIR=/var/www/wordpress
USBKEYDIR=/media/usbkey/
TMPDIR=/tmp/backupblog/
ARCHIVE=blog.$(date +%Y%m%d).tar.gz
ARCHIVE_SQL=blog.$(date +%Y%m%d).sql
MYSQL_USER=root
MYSQL_PASS=*****************
MYSQL_DB=wordpress
#creation du repertoire tmp
if [ ! -e ${TMPDIR} ]
then
mkdir ${TMPDIR}
fi
#evaluation de la taille du blog
echo -e "Taille du blog (non compresse):"
du -sh ${SRCDIR}
#creation de l'archive (fichiers sources)
echo -e "Creation de l'archive ${ARCHIVE} ..."
cd ${SRCDIR}
tar cf - ${SRCDIR} | gzip > ${TMPDIR}${ARCHIVE}
echo -e "Taille du blog (archive compresse .tar.gz):"
du -sh ${TMPDIR}${ARCHIVE}
#creation de l'archive (fichier SQL)
echo -e "Creation de l'archive ${ARCHIVE_SQL} ..."
mysqldump -u${MYSQL_USER} -p${MYSQL_PASS} ${MYSQL_DB} > ${TMPDIR}${ARCHIVE_SQL}
echo -e "Taille du blog (archive .sql):"
du -sh ${TMPDIR}${ARCHIVE_SQL}
echo -e "Taille total blog"
du -sh ${TMPDIR}
#si pas d'automount, montage manuel
mount ${DEVICE} ${USBKEYDIR}
#copy
cp -rf ${TMPDIR} ${USBKEYDIR}
echo -e "\nCopie sur la clef usb ..."
#demontage
umount ${DEVICE}
if [ $? -eq 0 ]
then
echo -e "\nDone"
fi
exit 0

Script de Restauration

wp-restoreblog.sh

#!/bin/bash
# wp-restoreblog.sh - Restore WordPress Blog
# version: 0.1
# Author: Benjamin Baudouin
# http://www.benjaminbaudouin.com
DEVICE=/dev/sdb1
USBKEYDIR=/media/usbkey
BACKUPDIR=/media/usbkey/backupblog/
SRCDIR=/var/www/wordpress
SQLFILE=`find ${BACKUPDIR}*.sql`
MYSQL_USER=root
MYSQL_PASS=
#meme si pas d'automount, montage manuel
if [ ! -e ${USBKEYDIR} ]
then
mkdir ${USBKEYDIR}
fi
mount ${DEVICE} ${USBKEYDIR}
cp ${BACKUPDIR}*.tar.gz /
tar xzf /*.tar.gz
chown www-data:www-data ${
SRCDIR}
mysql -u${MYSQL_USER} -p${MYSQL_PASS} < ${SQLFILE}
umount ${DEVICE}


Accéder à la page projet

Recent Tweets

Catégories