ApsaraDB RDS:Preguntas frecuentes sobre la función de registro general de consultas de ApsaraDB RDS for MySQL

¿Por qué RDS almacena los registros generales de consultas en una tabla?

De forma predeterminada, ApsaraDB RDS for MySQL almacena los registros generales de consultas en una tabla de base de datos en lugar de un archivo por dos razones:

• Los usuarios no pueden acceder directamente a los archivos en una instancia RDS, por lo que no es posible consultar ni descargar los registros basados en archivos.

• El parámetro log_output controla el formato de salida tanto para los registros generales de consultas como para los de consultas lentas. Dado que RDS rota los registros de consultas lentas y exige su almacenamiento en tablas, los registros generales de consultas también deben almacenarse en tablas.

¿Por qué el registro general de consultas agota el almacenamiento?

Cada instrucción SQL ejecutada en la instancia genera una entrada de registro. Cuando el registro general de consultas permanece habilitado durante un periodo prolongado o la instancia procesa un alto volumen de consultas, la tabla mysql.general_log crece de forma continua. Si no limpia la tabla periódicamente, esta saturará el almacenamiento de la instancia.

Para confirmar que el registro general de consultas causa el problema de almacenamiento:

1. Revise el uso de almacenamiento en la página de monitoreo de la instancia. Si sys_data_size es inusualmente grande, los datos de la tabla consumen almacenamiento. Para más detalles, consulte View the monitoring information.

2. Consulte View the instance parameters. Si general_log está configurado en ON, la función está activa.

¿Por qué el registro general de consultas causa problemas de rendimiento?

Cuando el registro general de consultas está habilitado, cada hilo que ejecuta una instrucción SQL debe escribir una fila en la tabla mysql.general_log. Esta operación de escritura requiere bloqueos de metadatos (MDL) y de tabla, por lo que los hilos escriben en la tabla de forma secuencial en lugar de paralela.

Ante un alto volumen de conexiones, muchos hilos compiten por estos bloqueos simultáneamente, lo que deja las conexiones en el estado Waiting for table level lock. A medida que aumenta el número de conexiones, también se incrementa el uso de la CPU.

Para confirmarlo, ejecute SHOW PROCESSLIST o consulte la tabla innodb_trx. Si muchas conexiones muestran Waiting for table level lock, el registro general de consultas contribuye a la contención de bloqueos.

¿Por qué el registro general de consultas aumenta el tiempo de recuperación?

Si una instancia RDS se apaga inesperadamente, el marcador de falla del registro general de consultas se establece en true. Al reiniciarse, la instancia inicia un proceso de recuperación automática. Si las tablas de la instancia RDS son grandes, restaurarlas toma mucho tiempo, durante el cual la instancia permanece no disponible. Esto extiende directamente su objetivo de tiempo de recuperación (RTO).

Solución

1. Establezca general_log en OFF para detener la escritura de nuevas entradas de registro. Consulte Modify instance parameters.

2. Conéctese a la instancia mediante una cuenta con privilegios. Consulte Connect to an ApsaraDB RDS for MySQL instance.

3. Limpie la tabla de registros:

   La instrucción TRUNCATE no es compatible con instancias que ejecutan MySQL 5.6. Para esas instancias, póngase en contacto con technical support para limpiar el registro. Para ver la lista completa de funciones compatibles según la versión, consulte Features . Para ejecutar la instrucción TRUNCATE con una cuenta con privilegios , la instancia debe ejecutar una versión menor del motor compatible: 20210630 o posterior para ApsaraDB RDS for MySQL 5.7, y 20210930 o posterior para ApsaraDB RDS for MySQL 8.0. En instancias con una versión menor del motor anterior, la instrucción TRUNCATE falla incluso con una cuenta con privilegios . En ese caso, envíe un ticket para que el soporte técnico limpie el registro por usted.

   TRUNCATE TABLE mysql.general_log;

Después de limpiar el registro, revise la página de monitoreo de la instancia para confirmar que el uso de almacenamiento ha disminuido.

Alternativas para el análisis de SQL

Mantenga el registro general de consultas deshabilitado durante las operaciones normales. Habilítelo solo para sesiones cortas de depuración; después, deshabilítelo y limpie la tabla de inmediato.

Para el análisis continuo de SQL, utilice uno de los siguientes enfoques:

• SQL Explorer and Audit (recomendado): Habilite esta función para registrar y analizar automáticamente las instrucciones SQL. Los datos se almacenan en Database Autonomy Service (DAS) y no consumen el almacenamiento de su instancia RDS, por lo que no afectan el rendimiento de la instancia. Consulte Use the SQL Explorer and Audit feature.

• Registro general de consultas temporal: Si necesita depurar un problema específico, habilite el registro general de consultas y luego consulte la tabla de registros para inspeccionar la actividad SQL:

  SELECT * FROM mysql.general_log;

  Deshabilite la función y limpie la tabla tan pronto como finalice la depuración.

Qué hacer si el almacenamiento ya está agotado

Si la instancia se quedó sin almacenamiento antes de que pudiera limpiar el registro, amplíe la capacidad de almacenamiento:

• Expansión manual: Modifique las especificaciones de la instancia para aumentar el almacenamiento. Consulte Change instance specifications.

• Expansión automática: Configure la expansión automática de almacenamiento para que el sistema amplíe la capacidad cuando el uso alcance un umbral especificado. Consulte Configure automatic storage expansion.