La forma más ingeniosa de cerrar mysql cuando lo hace es simplemente ejecutar
mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown
Aquí es por qué:
El archivo de servicio mysql ( /etc/init.d/mysql) se basa en la presencia del archivo socket. Hablando históricamente, volviendo a MySQL 4.0, el archivo de socket a veces desaparece inexplicablemente. Esto dificulta un estándar service mysql stopde trabajo.
No es suficiente decir
mysqladmin -uroot -p -h127.0.0.1 shutdown
porque ruta mysqld un usuario entrando como root@127.0.0.1a root@localhostsi TCP / IP no está habilitado de forma explícita. De forma predeterminada, mysqld elegirá la menor ruta de resistencia y se conectará root@127.0.0.1a root@localhosttravés del archivo socket. Sin embargo, si no hay un archivo de socket, root@localhostnunca se conectará.
Incluso la documentación de MySQL en mysqladmin dice esto:
Si ejecuta el apagado de mysqladmin cuando se conecta a un servidor local utilizando un archivo de socket Unix, mysqladmin espera hasta que se haya eliminado el archivo de ID de proceso del servidor, para asegurarse de que el servidor se haya detenido correctamente.
Por eso es imprescindible habilitar TCP / IP:
mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown
El 30 de septiembre de 2011, escribí mi propia versión de mysqld_multillamada mysqlservice(consulte mi publicación: Ejecución de varias instancias en el mismo host ). Sirve como un motor virtual para conectarse a mysqld desde diferentes puertos. Solo tiene que traer los suyos my.cnfcon parámetros personalizados. En ese guión, publico paradas como esta:
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
}
Pero que es ${MYSQLD_STOP}?
MYSQL_CONN="-uroot -p<rootpassword> -P${MYSQLD_PORT} -h127.0.0.1 --protocol=tcp"
MYSQLD_STOP="${MYSQLADMIN} ${MYSQL_CONN} shutdown"
Tenga en cuenta que uso 127.0.0.1y un puerto explícito. De esa manera, no estoy confiando en un archivo de socket.
Siempre he usado mysqladmin --protocol=tcp shtudowncomo la alternativa adecuada a los cierres de mysql si se service mysql stopbloquea. Si lo hace kill -9en mysqldy mysqld_safesi el último de los últimos de los últimos recursos. (Sí, dije las últimas tres veces).
Muchas veces, mysqld ha eliminado mysql.sock sin previo aviso. Otras personas también han tenido este problema a lo largo de los años:
EPÍLOGO
El secreto es tal como dije: conéctese a mysql usando mysqladmin a través de TCP / IP ( --protocol=tcp) y emita shutdown. Esto tiene que funcionar porque el privilegio de apagado se realiza mysql.usercon el exclusivo propósito de los cierres autenticados. Esto me salvó el día de trabajo varias veces cuando pude emitir un apagado remoto desde mi máquina Windows al apagar mysqld en un servidor Linux.
ACTUALIZACIÓN 2013-03-06 22:48 EST
Si le preocupa lo que está sucediendo durante el apagado, hay una forma de manipular el tiempo de apagado y la forma en que los datos se vuelcan al disco, especialmente si tiene muchos datos InnoDB en el Buffer Pool
SUGERENCIA # 1
Si tiene muchas páginas sucias, puede reducir innodb_max_dirty_pages_pct a 0:
SET GLOBAL innodb_max_dirty_pages_pct = 0;
Establezca esto unos 15-30 minutos antes del apagado. Esto le dará a mysqld la menor cantidad posible de páginas sucias para escribir en el disco.
SUGERENCIA # 2
Por defecto, innodb_fast_shutdown es 1. Hay tres valores para esta opción
- 0: InnoDB realiza un apagado lento, una purga completa y una fusión de búfer de inserción antes de apagarse.
- 1: InnoDB omite estas operaciones en el apagado, un proceso conocido como apagado rápido.
- 2: InnoDB vacía sus registros y se apaga, como si MySQL se hubiera bloqueado; no se pierden transacciones comprometidas, pero la operación de recuperación de fallos hace que el próximo inicio tarde más.
La documentación además dice esto:
El apagado lento puede llevar minutos o incluso horas en casos extremos donde aún se almacenan cantidades sustanciales de datos. Utilice la técnica de apagado lento antes de actualizar o degradar entre versiones principales de MySQL, de modo que todos los archivos de datos estén completamente preparados en caso de que el proceso de actualización actualice el formato del archivo.
Use innodb_fast_shutdown = 2 en situaciones de emergencia o solución de problemas, para obtener el apagado más rápido si los datos corren el riesgo de corrupción.
Los valores predeterminados para innodb_max_dirty_pages_pct e innodb_fast_shutdown deberían estar bien en la mayoría de los casos.
tmpwatchelimina, junto con todo lo demás/tmpque tiene un tiempo más antiguo que su umbral configurado.