5.4. El proceso de cierre del servidor MySQL

Comienza el proceso de apagado

El servidor crea un subproceso de apagado si es necesario

El servidor deja de aceptar nuevas conexiones

El servidor acaba con su tarea actual

Se apagan o cierran los motores de almacenamiento

El servidor se cierra

Comienza el proceso de apagado.

El apagado del servidor puede iniciarse de diferentes maneras. Por ejemplo, un usuario con el privilegio SHUTDOWN puede ejecutar la orden mysqladmin shutdown. mysqladmin puede ser utilizado en cualquier plataforma soportada por MySQL. También son posibles otros métodos de encendido y apagado específicos de cada sistema operativo: El servidor se apaga en Unix cuando recibe una señal SIGTERM. Un servidor ejecutándose como servicio en Windows se apaga cuando el administrador de servicios se lo indica.

El servidor crea un subproceso de apagado si es necesario.

Dependiendo de como se ha iniciado el apagado, el servidor puede crear un subproceso para llevar a cabo el proceso de apagado. Si el apagado fue demandado por un cliente, se crea un subproceso de apagado. Si el apagado es debido a la recepción de una señal SIGTERM, el subproceso de la señal podría llevar a cabo el apagado él mismo, o podría crear un subproceso separado para hacerlo. Si el servidor intenta crear un subproceso de apagado y no puede hacerlo (por ejemplo, porque no hay memoria suficiente disponible), crea un mensaje de diagnóstico que aparece en el registro de errores:

Error: Can't create thread to kill server

El servidor deja de aceptar nuevas conexiones.

Para prevenir que comiencen nuevas actividades durante el apagado, el servidor deja de aceptar nuevas conexiones de clientes. Esto lo consigue cerrando las conexiones de red a las que normalmente escucha: el puerto TCP/IP, el archivo socket Unix, la "named pipe" de Windows, y la memoria compartida de Windows.

El servidor acaba con su tarea actual.

En cada subproceso asociado a una conexión de un cliente, se rompe la conexión al cliente, y dicho subproceso es marcado como muerto. Los subprocesos mueren cuando se dan cuenta de que han sido marcados de esa manera. Los subprocesos de conexiones inactivas mueren rápidamente. Los que están actualmente procesando sentencias, consultan periodicamente su estado y tardan un poco más en morir. Para encontrar información adicional sobre la terminación de subprocesos, consulte Sección 13.5.5.3, “Sintaxis de KILL”, en particular las instrucciones sobre las operaciones REPAIR TABLE o OPTIMIZE TABLE que han sido matadas en tablas MyISAM.

En los subprocesos que tienen abierta una transacción, la transacción se cancela. Nótese qeu si un subproceso está actualizando una tabla no transaccional, una operación como un UPDATE o INSERT de múltiples registros podría dejar la tabla parcialmente actualizada, porque la operación puede terminar antes de ser completada.

Si el servidor es un servidor maestro de replicación, los subprocesos asociados a esclavos todavía conectados son tratados como subprocesos de cualquier otro cliente. Es decir, cada uno es marcado como muerto y se cierra la próxima vez que éste comprueba su estado.

Si el servidor es un servidor esclavo de replicación, los subprocesos de Entrada/Salida y SQL se paran, si están activos, antes de que los subprocesos de cliente sean marcados como muertos. Se permite al subproceso SQL finalizar su sentencia actual (para evitar causar problemas de replicación), y entonces se para. Si el subproceso SQL estaba en medio de una transacción en ese momento, la transacción se cancela.

Se apagan o cierran los motores de almacenamiento.

En este punto, la cache de tabla se escribe a disco y se cierran todas las tablas abiertas.

Cada motor de almacenamiento realiza todas las acciones necesarias para las tablas que controla. Por ejemplo, MyISAM realiza cualquier escritura de índices pendiente de una tabla. InnoDB escribe sus buffers a disco (desde la versión 5.0.5: a menos que innodb_fast_shutdown valga 2), escribe el número de secuencia de registro (LSN - Log Sequence Number) en el espacio de tablas, y cierra sus propios subprocesos internos.

El servidor se cierra.