☰

Percona MySQL 8.0.25-15 llenando el registro lento solo con encabezados

tag-icon • tag-icon mysql logging percona
Percona MySQL 8.0.25-15 llenando el registro lento solo con encabezados

¿Alguien ha experimentado un problema cuando el registro lento está habilitado con las siguientes opciones?

root@(none)> show global variables like "%slow_query%";
+-----------------------------------+-------------------------------+
| Variable_name                     | Value                         |
+-----------------------------------+-------------------------------+
| slow_query_log                    | ON                            |
| slow_query_log_always_write_time  | 10.000000                     |
| slow_query_log_file               | /var/log/mysql/mysql-slow.log |
| slow_query_log_use_global_control |                               |
+-----------------------------------+-------------------------------+
4 rows in set (0.00 sec)

Recibo un problema extraño en el que el archivo de registro lento recibe spam con lo mismo una y otra vez, sin una sola consulta de registro lento:

Time                 Id Command    Argument
/usr/sbin/mysqld, Version: 8.0.25-15 (Percona Server (GPL), Release '15', Revision 'a558ec2'). started with:
Tcp port: 3306  Unix socket: /var/run/mysqld/mysqld.sock

Estas tres líneas reciben spam constantemente, a unos 100 kilobytes por segundo. No solo eso, debido a esto la replicación estaba retrasada, los segundos detrás del maestro aumentaban constantemente. Me di cuenta de un uso extraño de los discos del sistema operativo (el directorio de datos de MySQL está en una matriz diferente) donde reside el directorio /var/log/mysql, supongo que se estaban descargando al disco todos y cada uno de estos mensajes inútiles. Una vez que desactivé slow_query_log, el SBM comenzó a caer muy rápido y no tiene problemas para mantener el ritmo.

¿Estoy teniendo un error con Percona MySQL? ¿No puedo encontrar ninguna referencia sobre esto?

Respuesta1

Considere agregar a my.cnf o my.ini lo siguiente

min_examined_row_limit=1

para evitar conversaciones inútiles en el registro de consultas lentas.

Respuesta2

¿Quizás no tiene ninguna consulta que demore más de 10 segundos?

Probablemente long_query_timetodavía esté en el valor predeterminado de 10 (segundos). En la mayoría de los casos se trata de un valor inútilmente elevado; bájelo a, digamos, 1.

¿Está haciendo algo FLUSH LOGS? Compruebe si hay trabajos cron. ¿Esto está en su propio sitio o en alguna nube? Puede que ellos lo estén provocando.

información relacionada