MySQL on ZFS (on FreeBSD)

logofreebsdLots of FreeBSD users are coming to ZFS since the release of FreeBSD 10, as it's so easy to install the system on top of that powerful filesystem. ZFS default behavior and settings are perfect for a wide range of workloads and uses, but it's not exactly what you need for databases hosting.
I'm running a FreeBSD 9.x server hosting http, php, mysql, mail, and many other things, so a databases-only optimization would be counterproductive. After a good dive into experts do's & don't's here are few steps I've taken to tune my server.

Datasets

If like me you've started hosting MySQL databases a long time ago (say ~15 years ago) you might have some DB using the old MyISAM engine, and some newer ones using InnoDB. Guess what. They use different block sizes, and they use different caching mechanisms.
On top of that, the block size for InnoDB is not the same when you deal with data files, and when you deal with log files.
In order to get the best block size and cache tuning possible, I've created 3 datasets: one for InnoDB data files, one for innodb logs, and one for everything else, including MyISAM databases.

Block size

The block size is engine dependent. MyISAM uses a 8k block size, InnoDB uses a 16k block size for data and 128k for logs. It's easy to setup datasets for a particular block size at creation with -o option, or after creation with zfs set. You must set the proper block size before putting any data on the dataset, otherwise pre-existing data won't use the desired block size.

Caching

MyISAM engine relies on the underlying filesystem caching mechanism, so you must ensure ZFS will cache both data and metadata (that's the default behavior). On the other hand, InnoDB uses an internal cache, so it would be a waste on memory to cache the same data into ZFS and InnoDB. On a dedicated MySQL server, the proper tuning would require to limit ARC size, and to disable data caching in ZFS. On a general-purpose server, ARC size should not be tweaked, but on InnoDB dedicated datasets it's easy to disable ZFS cache for data by setting the property primarycache to "metadata".

On MySQL's side

You must of course tell mysqld where to find data files and logs. I've set those values in my /var/db/mysql/my.cnf file:

innodb_data_home_dir = /var/db/mysql-innodb
innodb_log_group_home_dir = /var/db/mysql-innodb-logs

where /var/db/mysql-innodb and /var/db/mysql-innodb-logs are mount points for the dataset dedicated to InnoDB data files, and the dataset dedicated to InnoDB log files.

As my zpool is a mirror, I've added this setting too:

skip-innodb_doublewrite

Step by step

I've followed this course of action:

1st step: mailing to users, "MySQL will be unavailable for about 5 minutes, hang on."
2nd step: backup /var/db/mysql and edit your my.cnf
3rd step: shutdown your mysql server

sudo service mysql-server stop

4th step: move /var/db/mysql to /var/db/mysql-origin
5th step: create appropriate datasets:

zfs create -o recordsize=16k -o primarycache=metadata zmirror/var/db/mysql-innodb
zfs create -o recordsize=128k -o primarycache=metadata zmirror/var/db/mysql-innodb-logs
zfs create -o recordsize=8k zmirror/var/db/mysql

6th step: move data from /var/db/mysql-origin to your new datasets

cd /var/db/
sudo mv mysql-origin/ib_logfile* mysql-innodb-logs/
sudo mv mysql-origin/ibdata1 mysql-innodb/
sudo mv mysql-origin/* mysql/

and set proper rights:

sudo chown mysql:mysql mysql-innodb-logs mysql-innodb mysql
sudo chmod o= mysql mysql-innodb-logs mysql-innodb

7th step: restart your mysql server

sudo service mysql-server start & tail -f mysql/${HOSTNAME}.err

8th step: mailing to users, "MySQL's back online maintenance duration 5 min 14 sec."

Further reading & references

MySQL Innodb ZFS Best Practices
A look at MySQL on ZFS
Optimizing MySQL performance with ZFS
ZFS for Databases

Related posts

Nuxeo, round 2

J'ai décidé de donner une seconde chance à Nuxeo. Je m'étais heurté fin 2011 et début 2012 à quelques difficultés qui m'avaient bien refroidi : bug divers, implémentation bancale avec MySQL, problème de proxying derrière mod_ssl, etc.
Fort d'une récente expérience de montage apache+mod_ssl+tomcat qui s'était terminé brillamment avec une application proprement cachée derrière un proxy apache+ssl, je me suis mis en tête de reproduire le montage avec Nuxeo. J'ai donc téléchargé et installé la dernière version de Nuxeo, purgé la base MySQL existante, et lancé la configuration.
Premier point : mea maxima culpa. Le support de MySQL semble bien moins mauvais que ce que j'avais constaté il y a presque un an. En effet, en tournant autour de ma configuration SSL, j'ai été amené à mettre mon nez dans les logs de Nuxeo, constatant que ces derniers contenaient des indications d'erreurs liées à MySQL. En corrigeant le tir, j'ai obtenu un comportement de l'application qui devrait être meilleur. Je reste au conditionnel, car l'année passée, tout avec bien fonctionné en apparence pendant quelques semaines, avant que je commence à constater des dysfonctionnements.
Deuxième point : Ha. Finalement j'ai retrouvé le drag & drop. j'ai perdu le drag & drop. Peut être avais-je rêvé en testant Nuxeo DM 5.4, mais en testant la version 5.6 je ne trouve pas le moyen de glisser-déposer des fichiers d'un répertoires à l'autre pour les ranger simplement. C'est très frustrant, le glisser-déposer de Nuxeo était un avantage majeur face à Alfresco.
Troisième point : j'ai raté mon coup avec le SSL. But initial de ma manipulation, la reconfiguration de la chaîne apache+mod_ssl+tomcat n'a pas donné satisfaction, donc je fonctionne avec les mêmes artifices qu'initialement (redirection des requêtes http vers l'https, notamment).
Quatrième point : lovely WebDAV. J'aime le WebDAV, c'est un protocole sympa, passe partout, supporté out-of-the-box par mon système. Je m'en sers presque tout les jours au boulot et à la maison. J'ai même configuré un programme dans le copieur connecté du bureau pour envoyer les scan de documents que je fais directement sur un serveur WebDAV. Bref, je viens de découvrir que Nuxeo permet d'accéder à mon espace de travail directement en WebDAV. Je peux ajouter des documents, des dossiers, les ranger/déplacer, et même les modifier dans une suite bureautique directement à partir du bureau de mon système.
⌘K, https://monserveur/nuxeo/site/dav/, login/mot de passe, et hop, montage sur le bureau. La vie est belle.
Aller, je vais essayer de m'en servir plusieurs fois par semaine, et voir où cela me mène. Verdict dans un mois.

Related posts

Nuxeo contre Alfresco

Après un mois d'utilisation du logiciel de GED Nuxeo DM, le bilan est plutôt négatif. Je pensais naïvement avoir mis la main sur une application correcte (comme elle est en JAVA, elle peut tout au plus être correcte). Un pré-requis très important pour moi était la possibilité d'utiliser MySQL comme moteur de base de données. En réalité, bien que Nuxeo supporte MySQL officiellement, l'usage de ce moteur est absolument découragé. Les développeurs listent une série de raisons somme-toute valables, et qui peuvent se résumer comme ceci : il aurait fallu coder Nuxeo pour qu'il supporte les spécificités de MySQL, et on a eu la flemme. En réalité, rien ne fonctionne vraiment correctement si on utilise Nuxeo avec MySQL. À tel point qu'il ne devrait même pas être possible de choisir ce serveur de base de données dans les menus de configuration de Nuxeo. Et c'est bien ça qui me met en rogne. J'ai perdu un mois, et de nombreuses heures de travail pour un logiciel qui oscille finalement entre le "peu fiable" et le "carrément inutilisable".
Entre alors en scène Alfresco. Un logiciel concurrent, codé lui aussi en (wait for it) JAVA. Ce dernier fonctionne très bien avec MySQL, je l'ai donc installé sans tarder pour me faire une opinion sur ses capacités. Les différences avec Nuxeo sont importantes.
Continue reading

Related posts

Sauvegarde de bases MySQL via SVN

Il existe de nombreuses possibilités pour sauvegarder et archiver des bases de données, MySQL ou autres. En général, le protocole de sauvegarde dépend largement de l'objectif que l'on s'impose et des moyens dont on dispose.
La rétention des données sur le long terme pose bien sûr des problèmes de format et de support : vais-je pouvoir relire mes sauvegardes dans dix ans ? Elle pose aussi des problèmes de volume : puis-je me permettre d'archiver l'intégralité de mes bases une fois par jour pendant des années ?
Personne n'a de réponses absolues à toutes ces questions, car finalement tout est affaire de compromis. Dans la plupart des cas, j'utilise des scripts qui font un dump de mes bases de données, et qui archivent le résultat avec une rétention, en général, d'une semaine.
Le dump a cela de fantastique que c'est un format texte, il est donc lisible et modifiable par l'homme. Pas besoin de retrouver une version de MySQL compatible pour récupérer le contenu des bases archivées. Néanmoins il peut être assez volumineux suivant les options choisies, et le stockage à long terme peut vite devenir problématique. Dans le cadre de mon travail par exemple, le volume d'un dump pour un jour donné atteint 2,2 Go. Par contre, dans la plupart des bases de données, assez peu de données sont modifiées d'un jour sur l'autre. On pourrait économiser un maximum de place en n'enregistrant que la différence avec la veille. C'est là qu'intervient Subversion (SVN). Cet outil de versioning permet de ne stocker que la différence entre la version originale d'un fichier enregistrée initialement, et les versions ultérieures. Subversion est fourni de base avec Mac OS X, et il est disponible sur de très nombreux systèmes.
Continue reading

Related posts

Sauvegarder des bases MySQL

Dans de précédents articles j'ai répondu brièvement aux questions de l'installation de MySQL 5 sur Mac OS X 10.5 et de la création d'un plist de démarrage launchd pour MySQL. J'ai aussi donné quelques ficelles pour trouver les points de blocage habituels au fonctionnement de MySQL.
Il me reste donc à aborder le problème des sauvegardes. Cet article s'adresse uniquement aux utilisateurs d'un serveur MySQL qui sont root/admin de leur serveur, si vous avez un serveur MySQL chez un hébergeur, alors vous pouvez passer votre chemin.

Le script que je propose ci-dessous doit être lancé en root, une fois par jour. Il fait une sauvegarde de chaque base de données qu'il trouve, et il conserve cette sauvegarde pendant 7 jours. En cas de pépin, il vous est donc possible de restaurer une ou plusieurs bases de données, en remontant de maximum 7 jours dans le passé.
Vous devez adapter absolument les lignes 2 à 5 pour indiquer les chemins suivants :

  • mysqlroot : chemin du dossier contenant les bases de données sur le serveur
  • monbkp : chemin du dossier contenant les sauvegardes des bases sur le serveur
  • hotcopy : chemin de l'exécutable mysqlhotcopy sur le serveur
  • mydump : chemin de l'exécutable mysqldump sur le serveur

Vous devez aussi remplacer LE_PASS_MYSQL par le mot de passe de root de MySQL. Attention, il n'y a pas d'espace entre -p et LE_PASS_MYSQL pour la commande mysqldump, mais il y a bien un espace entre le -p et LE_PASS_MYSQL pour la commande mysqlhotcopy.

Le script supporte un argument ("dump"). Si il est lancé avec cet argument, alors il utilisera mysqldump pour faire la sauvegarde. Vous obtenez alors un dump de chaque base, c'est à dire un fichier texte "plat" contenant les instructions SQL nécessaires à la reconstruction de la base de données. C'est la méthode que je recommande car le fichier obtenu peut être injecté dans presque n'importe quel serveur MySQL. Par ailleurs, le fichier obtenu est plus petit et plus facile à compresser.
Si le script est lancé sans l'argument "dump", alors la méthode de sauvegarde utilisée est mysqlhotcopy. Ce programme duplique physiquement le répertoire de chaque base de données. L'avantage c'est que la sauvegarde est prête à l'emploi, il n'est pas nécessaire de la ré-injecter dans le serveur. L'inconvénient, c'est qu'il vous sera probablement impossible d'utiliser cette sauvegarde sur un autre serveur que le votre, et dans la même version de MySQL. Si vous souhaitez archiver vos sauvegardes de bases de données et pouvoir les restaurer quelques mois ou années plus tard, il ne faut pas utiliser mysqlhotcopy.

Déroulement du script :

  1. création d'un dossier temporaire /tmp/mysql
  2. pour chaque base de données, création d'un dump ou d'une "hotcopy"
  3. archivage et compression de chaque dump/hotcopy (en .tgz)
  4. suppression de la version non-compressée
  5. déplacement de la version compressée vers le dossier de sauvegarde
  6. suppression du dossier temporaire /tmp/mysql
#!/bin/sh
mysqlroot=/var/db/mysql
monbkp=/backup/MYSQL
hotcopy=/usr/local/bin/mysqlhotcopy
mydump=/usr/local/bin/mysqldump

madate=`date "+%Y-%m-%d"`
monjour=`date "+%w"`

echo "lancement du backup des bases de donnees MySQL..."
echo

mkdir -m 0777 /tmp/mysql

cd $mysqlroot
for directory in *
do
if [ $directory != "" ]; then
if [ -d "$mysqlroot/$directory" ]; then
  echo -n "backup de $directory : "
  case $* in
    dump)
    $mydump -u root -pLE_PASS_MYSQL --opt $directory > "/tmp/mysql/$directory"
    ;;
    *)
    $hotcopy -u root -p LE_PASS_MYSQL -q "$directory" /tmp/mysql
    ;;
  esac
  if [ $? = 0 ]; then
    tar -czf "$monbkp/$madate$directory.tgz" -C /tmp/mysql/ "$directory"
    if [ $? = 0 ]; then
      rm -f "$monbkp/$directory.${monjour}.tgz"
      rm -r "/tmp/mysql/$directory"
      mv "$monbkp/$madate$directory.tgz" "$monbkp/$directory.${monjour}.tgz"
      echo "ok"
    else
      echo "Erreur targz".
    fi
  else
    echo "Erreur export".
  fi
fi
fi
done

rm -fR /tmp/mysql/

 

Pour lancer ce script toutes les nuits, j'utilise une crontab (car mon mysqld est installé sur un serveur FreeBSD). Le script est enregistré dans /usr/local/bin/ sous le nom BKP_SQL.sh. Voilà la ligne en question :

30 5 * * * /usr/local/bin/BKP_SQL.sh

Et si je souhaite faire des dumps plutôt que des "hotcopy" :

30 5 * * * /usr/local/bin/BKP_SQL.sh dump

 
Note : ce script n'est pas du tout une référence de fiabilité et encore moins d'élégance, néanmoins, je l'ai créé en 2003 et depuis il tourne tous les jours. Je n'ai jamais eu de problème avec.

Note 2 : selon le système, votre environnement, ... il vous faudra peut être indiquer le chemin complet pour l'application tar.

Related posts

MySQL 5 : le checklist en cas de pépin

Comme les commentaires le montrent, si l'installation de MySQL peut prendre 5 minutes et se dérouler comme un charme, le moindre problème peut vite bloquer le débutant pendant des jours. Et plus le débutant se débat, plus il fait des dégâts sur son système.
Je vous propose donc ici une petite checklist des choses à vérifier si votre installation de MySQL sur Mac OS X tourne mal.

1) Si vous avez installé une ou plusieurs autres versions de MySQL et que vous souhaitez repartir de zéro, le plus simple est de localiser tous les éléments liés à MySQL et de les supprimer. On utilise pour cela la base locate, qu'il convient de mettre à jour au préalable :

sudo /usr/libexec/locate.updatedb 
locate -i mysql

ensuite faites le tri dans ce que vous voyez, et supprimez les éléments appartenant aux anciennes installation de MySQL (sans doute dans /usr/local/, /Library/LaunchDaemon/, /Library/StartupItems/, ...)

2) Vérifiez votre PATH : les binaires de MySQL doivent se trouver dans votre PATH pour être exécutables sans indiquer leur chemin complet. Si la commande which mysql ne renvoie rien, ajoutez /usr/local/mysql/bin/ à votre PATH.

3) Vérifiez que le serveur mysqld est lancé (ps auxwww | grep mysqld) ou se lance bien (sudo /usr/local/mysql/bin/mysqld_safe).

4) Vérifiez que le socket du serveur existe quand il est lancé :

netstat -f unix | grep mysql 
ls -l /tmp/mysql.sock

Si l'une de ces deux commandes ne retourne pas le chemin du socket, alors soit le socket est ouvert par le serveur mais supprimé par un autre process, soit le socket n'est pas ouvert par le serveur car il existe déjà.

5) Vérifiez que vous essayez bien d'accéder au serveur MySQL à partir d'un logiciel qui saura s'y connecter (php doit connaître le chemin du socket, le client mysql aussi). Si vous tentez une connexion réseau, vérifier aussi que mysqld ouvre un port réseau (netstat -alnf inet | grep 3306).

6) Jetez un œil aux fichiers de log de MySQL. Si le serveur ne se lance pas du tout, cela ne vous aidera probablement pas, mais si il se lance et quitte inopinément, ou si il se lance dans un état inutilisable, vous trouverez probablement des informations intéressantes dans ces fichiers. Pour l'installation de MySQL via le package officiel, les fichiers de log se trouvent normalement dans /usr/local/mysql/data/, sous le nom de localhost.err ou de votre-machine.err.

Je compléterai cette liste au fil du temps... N'hésitez pas à faire des suggestions !

Related posts

MySQL 5 : le plist de démarrage

Dans un précédent article j'ai exposé l'installation triviale d'un MySQL 5 sur une base de Mac OS X 10.5 propre. J'ai aussi mentionné le StartupItem fourni de base avec le package MySQL. Ce StartupItem étant conçu pour Mac OS X 10.4, il est intéressant de voir comment on doit maintenant lancer un serveur MySQL sur Leopard.

Si vous aviez installé le script de démarrage de MySQL 5 mentionné dans le précédent article, il faudra le désactiver ou le supprimer. Pour le supprimer, vous pouvez exécuter les commandes suivantes dans le terminal :

sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop 
sudo rm -r /Library/StartupItems/MySQLCOM 
sudo rm /tmp/mysql.sock

Ensuite, vous pouvez créer le fichier /Library/LaunchDaemons/org.mysql.mysqld.plist avec votre éditeur favori, et coller dedans :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>org.mysql.mysqld</string>
	<key>OnDemand</key>
	<false/>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/mysql/bin/mysqld</string>
		<string>--socket=/tmp/mysql.sock</string>
		<string>--user=mysql</string>
		<string>--port=3306</string>
		<string>--datadir=/usr/local/mysql/data</string>
		<string>--pid-file=/usr/local/mysql/data/localhost.pid</string>
		<string>--bind-address=127.0.0.1</string>
	</array>
	<key>ServiceIPC</key>
	<false/>
</dict>
</plist>

Une fois que ce fichier est sauvé, il faut s'assurer qu'il appartient bien à root, sinon launchctl vous envoie sur les roses (cf. les commentaires de Pierre29). Dans le doute, exécutez la commande

sudo chown root /Library/LaunchDaemons/org.mysql.mysqld.plist

Vous pouvez ensuite activer ce plist par la commande

sudo launchctl load /Library/LaunchDaemons/org.mysql.mysqld.plist

MySQL devrait être alors lancé automatiquement pour vous. Il placera son socket dans /tmp/ et autorisera aussi les connexions TCP sur l'interface 127.0.0.1.

Je vous renvoie à la documentation de launchctl pour le reste des options et commandes disponibles et pour les détails sur l'utilisation de launchd. Votre serveur MySQL est désormais géré proprement par launchd, exactement comme sur un Mac OS X Serveur.

edit : ajout du chown root sur le fichier

Related posts

MySQL 5 sur Mac OS X 10.5 en 5 minutes

Ça arrive toujours par vague, il suffit de suivre un peu des newsgroups comme fr.comp.mac-os.x pour s'en apercevoir. Un type un peu désespéré se pointe avec plein de questions sur comment installer MySQL sur son nouvel OS, puis c'est s'escalade, la surenchère à qui proposera la solution la plus compliquée ou l'idée la plus saugrenue. Bien sûr au départ c'est toujours la faute du système, ou celle de MySQL. C'est rarement celle de tous ces tutoriels ou de ces conseils mal avisés glanés sur les forums les plus inattendus. Et non, bien sûr ce n'est jamais la faute du pauvre bougre qui va copier-coller dans son terminal, sans les comprendre, les commandes dictées par des inconnus.
Pourtant, installer un MySQL 5 sur Mac OS X est d'une simplicité enfantine. C'est comme à l'école des fans : même les moins doués gagnent à la fin. Je ne vais pas détailler toutes les contortions cérébrales qu'il faut faire pour rater cette installation, on trouve suffisamment d'exemples sur les forums, et ce ne serait pas chic de ma part de moquer la paresse intellectuelle de certains.

La première étape pour une installation réussie, c'est de télécharger le package officiel fourni par MySQL. Ne cédez pas à la tentation de compiler vous même MySQL, si vous avez besoin d'aide pour installer un pkg, faites preuve de bon sens et oubliez immédiatement la compilation. On trouve le précieux paquet dans la zone "Developer" du site mysql.com. Cliquez sur "MySQL Community Server" dans la marge de gauche, et dans la nouvelle page qui se charge, trouvez le lien intitulé "Mac OS X (package format)". Je ne donne pas les liens directs, car ils sont susceptibles de changer au fil des versions de MySQL.
Vous voilà en face d'une liste de packages pour Mac OS X : Mac OS X (package format) downloads. Choisissez celui qui correspond le plus à votre version du système. Actuellement pour un G5 en Mac OS X 10.4 ou 10.5 ce sera "Mac OS X 10.4 (PowerPC, 64-bit)" par exemple.

Une fois l'image disque téléchargée et montée vous voici en face de deux packages, d'un "PrefPane", et d'un readme :

  • mysql-5.0.45-osx10.4-powerpc-64bit.pkg (dans mon cas)
  • MySQLStartupItem.pkg
  • MySQL.prefPane
  • ReadMe.txt

Le premier package installe tout MySQL sur votre machine. Le second installe un StartupItem à l'ancienne (comprendre : pré-launchd). Pour un lanceur à la mode de launchd : moderne et qui marche bien, voyez cet article. Le PrefPane permet d'installer un tableau de bord MySQL dans les préférences système.
Muni d'un log/pass d'administrateur vous pouvez maintenant installer les packages par simple double-click. Jusque là, pas besoin de comprendre la théorie de la relativité. Si vous avez su taper votre mot de passe, vous avez maintenant installé MySQL.
De la même manière, double-cliquez sur le PrefPane pour l'installer. Vous pouvez l'installer pour vous uniquement, ou pour tous les utilisateurs de la machine. C'est sans incidence sur le résultat, faites comme vous préférez. Ce tableau de bord est de toute manière partiellement non-fonctionnel sous Leopard (je ne l'ai pas testé sous Tiger). Il ne permet pas de lancer ou d'arrêter MySQL via le bouton de son interface. Par contre, il permet d'activer ou non le lancement automatique du serveur MySQL au démarrage de la machine.
À partir de là, votre serveur MySQL est complètement fonctionnel. Si vous avez opté pour un lancement automatique au démarrage, vous pouvez maintenant rebooter pour vérifier que cela fonctionne, tout en vous félicitant d'avoir installé MySQL 5 en moins de 5 minutes, sans taper une seule ligne de commande dans votre terminal. Si vous souhaitez lancer le serveur sans redémarrer et que, comme dans mon cas, le bouton ad hoc du tableau de bord de fonctionne pas, vous pouvez le faire via le terminal :

  • cochez la case pour lancer MySQL automatiquement au démarrage (cela édite pour vous un fichier de configuration qui autorise aussi le lancement manuel)
  • tapez dans une fenêtre de terminal la commande
    sudo /Library/StartupItems/MySQLCOM/MySQLCOM start

Normalement, le tableau de bord doit maintenant refléter l'état du serveur, et indiquer que le serveur est fonctionnel. Si ce n'est pas le cas, c'est que vous êtes parvenu à rater une des étapes précédentes.

Désormais, il est judicieux de tester la connexion au serveur. Ouvrez une fenêtre de terminal, et taper la commande suivante :

/usr/local/mysql/bin/mysql -u root

Cela doit vous donner le résultat suivant :

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 200
Server version: 5.0.45 MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> 

Vous êtes alors connecté à votre serveur mysql local. Il est important de noter que les packages officiels de MySQL sont compilés pour stocker le socket de connexion dans /tmp/mysql.sock, et non pas dans /var/mysql/mysql.sock. Le PHP fourni par Apple quant à lui, attend ce socket dans /var/mysql/mysql.sock. Si vous souhaitez faire fonctionner des scripts PHP, vous devrez indiquer à ce dernier le chemin réel de votre socket MySQL. On fait cela en éditant le fichier /private/etc/php.ini. Ouvrez ce fichier (probablement inexistant) avec votre éditeur de texte favori, et insérez la ligne mysql.default_socket = /tmp/mysql.sock. Maintenant, PHP doit trouver tout seul le socket de MySQL. C'est facile à vérifier dans le terminal :

php -r 'mysql_connect(localhost, root, ""); echo mysql_result(mysql_query("SELECT 2+2;"),0)." ";'

Si tout fonctionne, le résultat affiché sera "4". Si cela ne fonctionne pas, c'est probablement que vous êtes incapable d'utiliser MySQL de toute manière :).

edit : en cas de pépin, faites un tour vers la checklist.

Related posts