Le moyen le plus simple d'arrêter mysql quand il le fait est simplement d'exécuter
mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown
Voici pourquoi:
Le fichier de service mysql ( /etc/init.d/mysql) repose sur la présence du fichier socket. Historiquement, remontant à MySQL 4.0, le fichier socket disparaît parfois inexplicablement. Cela empêche une norme service mysql stopde fonctionner.
Il ne suffit pas de dire
mysqladmin -uroot -p -h127.0.0.1 shutdown
parce que mysqld acheminera un utilisateur entrant root@127.0.0.1vers root@localhostsi TCP / IP n'est pas explicitement activé. Par défaut, mysqld choisira le chemin le moins de résistance et de se connecter root@127.0.0.1à l' root@localhostaide du fichier socket. Pourtant, s'il n'y a pas de fichier socket, root@localhostne se connectera jamais.
Même la documentation MySQL sur mysqladmin dit ceci:
Si vous exécutez l'arrêt de mysqladmin lors de la connexion à un serveur local à l'aide d'un fichier socket Unix, mysqladmin attend que le fichier d'ID de processus du serveur soit supprimé pour s'assurer que le serveur s'est arrêté correctement.
C'est pourquoi il est impératif d'activer TCP / IP:
mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown
De retour le 30 septembre 2011, j'ai scripté ma propre version de mysqld_multicalled mysqlservice(Voir mon article: Exécuter plusieurs instances sur le même hôte ). Il sert de moteur virtuel pour se connecter à mysqld à partir de différents ports. Il vous suffit d'apporter le vôtre my.cnfavec des paramètres personnalisés. Dans ce script, j'émets des arrêts comme celui-ci:
stop() {
${ECHO} -n $"Stopping ${PROGNAME}"
${MYSQLD_STOP}
ATTEMPTS=0
STOPPING_MYSQLD=1
MINUTES_TO_TRY=10
(( TICKS_TO_TRY = MINUTES_TO_TRY*240 ))
while [ ${STOPPING_MYSQLD} -eq 1 ]
do
${ECHO} -n "."
${SLEEP} 0.25
MYSQLD_HAS_BEEN_SHUTDOWN=`${TAIL} ${MYSQL_ERROR_LOG} | ${GREP} -c "Shutdown complete$"`
(( ATTEMPTS++ ))
if [ ${ATTEMPTS} -eq ${TICKS_TO_TRY} ] ; then STOPPING_MYSQLD=0 ; fi
if [ ${MYSQLD_HAS_BEEN_SHUTDOWN} -eq 1 ] ; then STOPPING_MYSQLD=2 ; fi
done
${ECHO}
if [ ${STOPPING_MYSQLD} -eq 2 ]
then
${ECHO} "Stopped ${PROGNAME}"
else
${TAIL} -30 ${MYSQL_ERROR_LOG}
fi
}
Mais c'est quoi ${MYSQLD_STOP}?
MYSQL_CONN="-uroot -p<rootpassword> -P${MYSQLD_PORT} -h127.0.0.1 --protocol=tcp"
MYSQLD_STOP="${MYSQLADMIN} ${MYSQL_CONN} shutdown"
Veuillez noter que j'utilise 127.0.0.1un port explicite. De cette façon, je ne compte pas sur un fichier socket.
J'ai toujours utilisé mysqladmin --protocol=tcp shtudowncomme alternative appropriée aux arrêts de mysql en cas de service mysql stopblocage. Faire kill -9sur mysqldet mysqld_safedevrait le dernier du dernier des derniers recours. (Oui, je l'ai dit trois fois).
Plusieurs fois, mysqld a supprimé mysql.sock sans avertissement. D'autres personnes ont également eu ce problème au fil des ans:
ÉPILOGUE
Le secret est comme je l'ai dit: connectez-vous à mysql en utilisant mysqladmin via TCP / IP ( --protocol=tcp) et lancezshutdown . Cela doit fonctionner car le privilège d'arrêt est mysql.userréservé à des fins d'arrêt authentifiés. Cela a sauvé ma journée de travail à quelques reprises lorsque j'ai pu émettre un arrêt à distance depuis ma machine Windows lors de l'arrêt de mysqld sur un serveur Linux.
MISE À JOUR 2013-03-06 22:48 EST
Si vous vous inquiétez de ce qui se passe pendant l'arrêt, il existe un moyen de manipuler le temps d'arrêt et la façon dont les données sont vidées sur le disque, surtout si vous avez beaucoup de données InnoDB dans le pool de tampons
SUGGESTION # 1
Si vous avez beaucoup de pages sales, vous pouvez réduire le innodb_max_dirty_pages_pct à 0:
SET GLOBAL innodb_max_dirty_pages_pct = 0;
Réglez-le environ 15 à 30 minutes avant l'arrêt. Cela donnera à mysqld le moins de pages sales à écrire sur le disque.
SUGGESTION # 2
Par défaut, innodb_fast_shutdown vaut 1. Il y a trois valeurs pour cette option
- 0: InnoDB effectue un arrêt lent, une purge complète et une fusion de tampon d'insertion avant l'arrêt.
- 1: InnoDB ignore ces opérations à l'arrêt, un processus appelé arrêt rapide.
- 2: InnoDB vide ses journaux et s'arrête à froid, comme si MySQL s'était écrasé; aucune transaction validée n'est perdue, mais l'opération de récupération après incident rend le démarrage suivant plus long.
La documentation dit en outre ceci:
L'arrêt lent peut prendre des minutes, voire des heures dans les cas extrêmes où des quantités importantes de données sont toujours mises en mémoire tampon. Utilisez la technique d'arrêt lent avant la mise à niveau ou la rétrogradation entre les versions majeures de MySQL, afin que tous les fichiers de données soient entièrement préparés au cas où le processus de mise à niveau met à jour le format de fichier.
Utilisez innodb_fast_shutdown = 2 en cas d'urgence ou de dépannage, pour obtenir l'arrêt absolu le plus rapide si les données risquent d'être corrompues.
Les valeurs par défaut pour innodb_max_dirty_pages_pct et innodb_fast_shutdown devraient être très bien dans la plupart des cas.
tmpwatchil le supprime, ainsi que tout le reste/tmpqui a un atime plus ancien que son seuil configuré.