Reiniciar MySQL es una operación que combina detener el servidor y volver a iniciarlo en un solo paso. Aunque suena trivial, en un entorno de producción un reinicio implica interrumpir todas las conexiones activas, lo que puede afectar a las aplicaciones que dependen del servidor. Por eso, es fundamental entender cuándo un reinicio es realmente necesario, cuándo se puede evitar y cómo minimizar su impacto cuando no hay alternativa.

Reiniciar MySQL con systemd

En sistemas Linux con systemd, el comando para reiniciar MySQL es directo:

sudo systemctl restart mysql

En distribuciones basadas en Red Hat:

sudo systemctl restart mysqld

Puedes confirmar que el reinicio fue exitoso revisando el estado y el uptime:

sudo systemctl status mysql

● mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled)
     Active: active (running) since Tue 2025-03-18 16:45:08 UTC; 4s ago
    Process: 5891 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre
             (code=exited, status=0/SUCCESS)
   Main PID: 5934 (mysqld)
     Status: "Server is operational"
     Memory: 378.2M

Fíjate en el timestamp: si es reciente (hace pocos segundos), el reinicio fue exitoso. También puedes verificar desde dentro de MySQL:

SHOW STATUS LIKE 'Uptime';

Un uptime de 12 segundos confirma que el servidor acaba de reiniciarse.

Cuándo es necesario reiniciar

No todos los cambios de configuración requieren un reinicio. MySQL distingue entre variables dinámicas (que se pueden cambiar en caliente) y variables estáticas (que solo surten efecto al reiniciar el servidor). Esta distinción es crucial para minimizar el tiempo de inactividad.

Las variables que sí requieren reinicio incluyen:

-- Cambiar el puerto de escucha
-- port
 
-- Cambiar el directorio de datos
-- datadir
 
-- Cambiar el tamaño del redo log (requiere reinicio en MySQL 5.7,
-- dinámico en 8.0.30+)
-- innodb_log_file_size
 
-- Cambiar la ruta del archivo de log general
-- general_log_file

Puedes verificar si una variable es dinámica consultando:

SELECT VARIABLE_NAME, VARIABLE_SOURCE
FROM performance_schema.variables_info
WHERE VARIABLE_NAME = 'innodb_buffer_pool_size';

Las variables que no requieren reinicio pueden cambiarse con SET GLOBAL y surten efecto inmediatamente:

-- Cambiar el tiempo máximo de espera por conexiones inactivas
SET GLOBAL wait_timeout = 300;
 
-- Cambiar el modo SQL
SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION';
 
-- Ajustar el número máximo de conexiones
SET GLOBAL max_connections = 300;
 
-- Habilitar el slow query log
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 2;

Diferencia entre restart y reload

Systemd ofrece dos opciones: restart y reload. Es importante entender la diferencia.

El comando restart detiene completamente el servidor y lo vuelve a iniciar. Todas las conexiones se pierden, todas las transacciones se interrumpen, y el buffer pool se vacía (a menos que tengas configurado innodb_buffer_pool_dump_at_shutdown).

sudo systemctl restart mysql

El comando reload envía una señal al proceso para que relea ciertos archivos de configuración sin detenerse. En MySQL, reload tiene un efecto limitado: recarga las tablas de permisos y cierra y reabre los archivos de log:

sudo systemctl reload mysql

Para la mayoría de los cambios de configuración, reload no es suficiente y necesitarás un restart completo. Sin embargo, reload es útil cuando acabas de ejecutar sentencias GRANT/REVOKE y quieres asegurarte de que los cambios de permisos se apliquen a todas las conexiones.

Caso práctico: reinicio con mínimo impacto en producción

Imagina un servidor de producción que gestiona la base de datos de un e-commerce con tráfico constante. Necesitas reiniciar porque cambiaste innodb_log_file_size en el archivo my.cnf y el cambio requiere reinicio en tu versión de MySQL (anterior a 8.0.30).

El procedimiento para minimizar el impacto sería:

-- 1. Verificar que no hay consultas pesadas ejecutándose
SELECT id, user, host, db, time,
       SUBSTRING(info, 1, 100) AS query
FROM information_schema.PROCESSLIST
WHERE command != 'Sleep'
  AND info IS NOT NULL
  AND time > 5
ORDER BY time DESC;

-- 2. Guardar el contenido del buffer pool para restaurarlo rápido
SET GLOBAL innodb_buffer_pool_dump_at_shutdown = ON;
SET GLOBAL innodb_buffer_pool_load_at_startup = ON;

Estas dos variables hacen que MySQL guarde una lista de las páginas que están en el buffer pool antes de cerrarse, y las recargue al arrancar. Esto acelera enormemente el "calentamiento" del servidor, porque no tiene que esperar a que las consultas de los usuarios vuelvan a traer las páginas populares a memoria.

-- 3. Verificar la configuración
SHOW VARIABLES LIKE 'innodb_buffer_pool_dump%';
SHOW VARIABLES LIKE 'innodb_buffer_pool_load%';

Luego, desde la terminal, realiza el reinicio:

sudo systemctl restart mysql

Después del reinicio, verifica que el buffer pool se está recargando:

SHOW STATUS LIKE 'Innodb_buffer_pool_load_status';

Caso práctico: reinicio programado con notificación

En equipos organizados, los reinicios de producción se planifican y comunican con anticipación. Puedes usar MySQL para preparar el terreno:

-- Ver cuántas conexiones hay activas antes de proceder
SELECT
  COUNT(*) AS total_conexiones,
  SUM(CASE WHEN command = 'Sleep' THEN 1 ELSE 0 END) AS inactivas,
  SUM(CASE WHEN command != 'Sleep' THEN 1 ELSE 0 END) AS activas
FROM information_schema.PROCESSLIST
WHERE user NOT IN ('system user', 'event_scheduler');

Con 9 conexiones ejecutando consultas activamente, conviene esperar a que el número baje o coordinar con los equipos de desarrollo. En muchas arquitecturas modernas, las aplicaciones tienen mecanismos de reconexión automática, pero un reinicio durante una transacción de pago o una migración de datos podría causar problemas.

Para ventanas de mantenimiento programadas, también puedes bloquear nuevas conexiones antes del reinicio:

-- Evitar nuevas conexiones (excepto SUPER)
SET GLOBAL max_connections = 1;

Esto hará que las nuevas conexiones reciban un error Too many connections, mientras que las existentes siguen funcionando hasta que terminen. Una vez que el número de conexiones activas baje a niveles seguros, procedes con el reinicio.

No olvides restaurar el valor original después del reinicio (o asegurarte de que my.cnf tiene el valor correcto para que se aplique automáticamente).

Reiniciar MySQL es una herramienta necesaria en la caja de herramientas del administrador, pero debe usarse con criterio. Siempre que sea posible, prefiere cambios dinámicos con SET GLOBAL sobre reinicios completos. En el siguiente artículo profundizaremos en el archivo de configuración my.cnf, que es donde se definen todos estos parámetros de forma persistente.