Asumir un servidor web Debian Etch con MySQL en ejecución.
Normalmente inicio, detengo y reinicio msyql usando:
/etc/init.d/mysql restart
Por alguna razón en esta configuración obtengo lo siguiente:
: ~ # /etc/init.d/mysql stop
Detención del servidor de bases de datos MySQL: ¡falló mysqld!
El proceso mysql está funcionando bien:
:~# ps aux | grep mysql
root 2045 0.0 0.1 2676 1332 ? S Jun25 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 2082 0.6 10.7 752544 111188 ? Sl Jun25 18:49 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
root 2083 0.0 0.0 1568 504 ? S Jun25 0:00 logger -p daemon.err -t mysqld_safe -i -t mysqld
root 11063 0.0 0.0 2856 716 pts/0 S+ 17:29 0:00 grep mysql
Estoy seguro de que hay una forma realmente fácil de hacerlo, pero también quiero entender lo que está sucediendo. ¿Por qué la forma típica no funciona para mí?
EDITAR ACTUALIZACIÓN como una actualización:
JBRLSVR001:/var/log/mysql# mysqladmin shutdown
JBRLSVR001:/var/log/mysql# dpkg --list mysql\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-============================================-============================================-========================================================================================================
un mysql-client <none> (no description available)
un mysql-client-4.1 <none> (no description available)
ii mysql-client-5.0 5.0.32-7etch8 mysql database client binaries
ii mysql-common 5.0.32-7etch8 mysql database common files (e.g. /etc/mysql /my.cnf)
un mysql-common-4.1 <none> (no description available)
ii mysql-server 5.0.32-7etch8 mysql database server (meta package depending on the latest version)
un mysql-server-4.1 <none> (no description available)
ii mysql-server-5.0 5.0.32-7etch8 mysql database server binaries
mysqladmin shutdown funciona pero todavía tengo curiosidad por qué los comandos /etc/init.d/mysql no funcionan.
/tmp/mysql.sock
lugar de/var/run/mysqld/mysqld.sock
. Entonces, el script de los mantenedores de Debian emitía un error, en silencio. Sólo tienes que fijarsocket=
en el/etc/mysql/debian.cnf
Respuestas:
debería funcionar para apagar el servidor.
Veo dos posibilidades probables:
Que
dpkg --list mysql\*
dice¿Qué dice /var/log/mysql.err? ¿O los otros registros de mysql?
EDITAR:
Así
mysqladmin shutdown
trabajado?De acuerdo con eso, el paquete mysql-server está instalado (mysql-server-5.0; el paquete mysql-server es probablemente solo un trozo). Entonces, ¿pueden haberse instalado sobre él? Correr
debsums mysql-server-5.0
podría decirte más.dpkg --listfiles mysql-server-5.0
también podría ayudar ...¿Qué hay realmente en /etc/init.d/mysql? No he comprobado esa versión específica del paquete, pero debería intentar usar
mysqladmin shutdown
... Tal vez tengas suerte y solo rompieron eso ...fuente
¿Por qué está pasando esto?
Este es un problema común si realiza una importación de mysql y sobrescribe la base de datos mysql, como cuando podría estar restaurando desde una copia de seguridad mysqldump -A.
Esto es algo bueno: probablemente desee hacer una copia de seguridad de todos sus usuarios, permisos, etc. de mysql, pero puede causar estragos en cosas como el usuario debian-sys-maint utilizado para cerrar mysql limpiamente.
Aunque esta nueva base de datos posiblemente cambiará tanto la contraseña de root como la contraseña de debian-sys-maint, por supuesto, no cambiará automáticamente la contraseña esperada de debian-sys-maint en /etc/mysql/debian.cnf. De hecho, a menos que también haya hecho una copia de seguridad de ese archivo, ¡probablemente ya ni siquiera sepa cuál es esa contraseña!
Restablecer la contraseña de root de mysql (opcional)
Lo primero es lo primero. Si la contraseña de root de mysql era diferente entre los servidores antiguos y nuevos, puede usar mysqladmin para solucionarlo:
Sin embargo, cuando instala mysql-server, es probable que le solicite la nueva contraseña de root de mysql y probablemente haya utilizado la misma que usaba anteriormente.
Arregle la contraseña de mantenimiento del sistema Debian.
Así que ahora busque la contraseña de debian sys maint que debian creó para usted cuando la instaló en el nuevo servidor. (Necesita sudo porque este debería ser un archivo altamente protegido).
Ahora, inicie sesión en mysql usando la contraseña de root que configuró anteriormente:
Restablezca la contraseña para el usuario debian-sys-maint y no olvide eliminar los privilegios:
Prueba para asegurarte de que funciona:
fuente
2 pistas más:
Esto le mostrará los comandos ejecutados por el guión de inicio.
instale los debsums de paquetes y puede probar qué paquetes se modificaron (verificar también está disponible para RPM, pero en mi humilde opinión funciona mejor).
fuente
"Access denied for user 'debian-sys-maint'@'localhost'"
, lo cual era absolutamente correcto: mi base de datos mysql aún no había asignado ningún permiso, pormysql stop
lo que no tenía los permisos en la base de datos para cerrar. Un manualmysqladmin shutdown
funcionó perfectamente.definitivamente funcionará
fuente
Asumiendo que el paquete es algo extraño, el problema podría ser el archivo pid. Sospecho que los nuevos paquetes o la instalación compilada no crearon / var / run / mysql / o lo que sea estándar en Debian para que se escriba el archivo pid o el script de inicio busque el archivo mysqld.pid en otro lugar. Si puede solucionar el desajuste del archivo init / pid, las cosas probablemente deberían funcionar.
fuente
El script de cierre de mysql utiliza el usuario debian-sys-maint para ejecutar 'cierre de mysqladmin', leyendo la contraseña para el usuario en /etc/mysql/debian.cnf. Debe verificar que este archivo existe y que puede ejecutar el apagado de mysqladmin como este usuario.
fuente
Técnicamente podría terminar con:
¿Pero podrías perder datos?
Puede que sea mejor preguntarle a alguien en http://www.serverfault.com
fuente
El uso de "pkill mysql" también probablemente perderá sus datos, particularmente si se invoca como "pkill -9" :(
También recomendaría usar 'sh -x' para ver cuál podría ser el problema con el script de inicio, y también puede echar un vistazo a los registros de errores de MySQL (/ var / log / mysql o / var / lib / mysql, dependiendo de la configuración) para ver si está atascado en una consulta de ejecución muy larga o algo y, por lo tanto, no está dispuesto a abandonar con gracia todavía.
fuente
Para seguir el comentario sobre su pregunta, escribiré una respuesta completa:
El problema es que el socket predeterminado es
/tmp/mysql.sock
con la fuente MySQL y/var/run/mysqld/mysqld.sock
con los binarios de Debian.La solución es fijar la trayectoria de socket en
/etc/mysql/debian.cnf
, proporcionando el biensocket=
. O manteniéndolo, pero luego cambia el que está adentro/etc/mysql/my.cnf
.Así es como descubrí esto:
/etc/init.d/mysql
cuando aparece el mensaje "fallido", tiene esta línea llamada:echo -e "$ps_alive processes alive and '$MYADMIN ping' resulted in\n$ping_output\n" | $ERR_LOGGER -p daemon.debug
Esto me señaló
$MYADMIN ping
, que esmysqladmin --defaults-file=/etc/mysql/debian.cnf ping
. Ejecutar este mismo comando termina en:Así que eché un vistazo
/etc/mysql/debian.cnf
y descubrí que ese era el enchufe defectuoso.fuente
usa el siguiente comando:
$ mysqladmin apagado
esto debería estar disponible en el directorio / usr / bin en su caso.
fuente
necesita ser un súper usuario para comenzar a detener mysql (y la mayoría de los otros servicios) en debian.
No estoy seguro si ya lo estás o no ... si no, debes hacer uno de
fuente