Cuando una instancia de ApsaraDB RDS for MySQL se queda sin almacenamiento, se bloquea automáticamente en modo de solo lectura para evitar la pérdida de datos. Este tema explica cómo identificar qué tipo de archivo consume espacio y cómo resolver cada causa.
Respuesta de emergencia
Si la instancia ya está bloqueada (en modo de solo lectura), amplíe el disco de inmediato para restaurar el acceso de escritura. Ejecute todas las tareas de limpieza y las correcciones de la causa raíz después de que se restaure el servicio.
En la consola de RDS, haga clic en el ID de la instancia.
Manually resize the disk para desbloquear la instancia.
La instancia se desbloquea aproximadamente 5 minutos después de que finaliza el cambio de tamaño. Puede monitorear el progreso en Task Center.
Cambiar el tamaño del disco es una solución temporal. El almacenamiento se volverá a llenar si no atiende también la causa raíz que se describe a continuación.
Consulta del uso de almacenamiento
El espacio de almacenamiento de una instancia de RDS for MySQL incluye los datos de usuario, los datos del sistema, los registros y los archivos temporales.
En la consola de RDS, haga clic en el ID de la instancia.
En el panel de navegación izquierdo, elija Monitoring and Alerts > Standard Monitoring.
Busque la vista MySQL Storage Space Used. Haga clic en el ícono junto al título de la vista para consultar la descripción de cada parámetro.
Para conocer los pasos detallados de monitoreo, consulte Consulta de la información de monitoreo.
Identificación de la causa
Revise la vista MySQL Storage Space Used y asocie el parámetro con mayor consumo al tipo de archivo y la solución correspondientes que se muestran a continuación.
|
Tipo de archivo |
Parámetro en Standard Monitoring |
Parámetro en Space Analysis |
Solución |
|
Archivo temporal |
|
|
|
|
Archivo binlog |
|
|
|
|
Archivo de registro undo |
|
|
|
|
Archivo de registro general |
|
|
|
|
Archivo de datos de usuario |
|
|
Compruebe también la fragmentación y el crecimiento excesivo de índices. Estos elementos no aparecen como parámetros independientes, pero pueden consumir un espacio considerable:
Fragmentación: consulte Fragmentation accumulation
Crecimiento excesivo de índices: consulte Acumulación de archivos de índice
Acumulación de archivos temporales
Los archivos temporales se crean cuando MySQL ejecuta sentencias SQL que ordenan, agrupan o combinan grandes volúmenes de datos. Los registros binarios de transacciones grandes también se almacenan temporalmente en caché hasta que la transacción se confirma. Si estos archivos se acumulan, la instancia se bloquea.
Resolución del bloqueo inmediato:
MySQL 5.7 o anterior: Restart the instance. El sistema elimina automáticamente los archivos temporales al reiniciar.
MySQL 8.0: La instancia finaliza todas las sesiones de usuario e inicia una reversión automática. Los archivos temporales se liberan cuando termina la reversión.
Si la instancia no se desbloquea automáticamente, ejecute show processlist para identificar las sesiones con estado Copy to tmp table o Sending data. Después, termínelas con el comando kill.
Para obtener más información, consulte Solutions for temporary file accumulation in RDS for MySQL.
Acumulación de archivos de registro binario
Las transacciones grandes generan muchos archivos de registro binario en poco tiempo. Si los registros se acumulan más rápido de lo que se limpian, el almacenamiento se agota y la instancia se bloquea.
Resolución mediante la carga de los registros existentes:
Use la función One-click binary log upload para cargar los archivos de registro binario de la instancia de RDS a OSS. RDS elimina automáticamente los archivos cargados. Consulte Consulta y eliminación de archivos de registro binario.
Prevención mediante el ajuste de la política de retención:
En la consola de RDS, vaya a la página Backup and Restoration.
Haga clic en la pestaña Backup Strategy.
Junto a Local Log Retention Policy, haga clic en Edit.
Ajuste el periodo de retención, el uso máximo de almacenamiento y el espacio de almacenamiento disponible. Cuando el almacenamiento local de registros alcanza el umbral, el sistema elimina automáticamente los registros más antiguos.
Para obtener más información, consulte Solutions for MySQL binlog file accumulation.
Acumulación de fragmentación
InnoDB gestiona los espacios de tablas por página. Cuando elimina o actualiza filas con delete o update, MySQL marca el espacio como reutilizable, pero no reduce el tamaño del archivo en disco. Si las páginas liberadas no se pueden reutilizar, la fragmentación se acumula y consume almacenamiento.
Resuelva la fragmentación con uno de los métodos siguientes:
Línea de comandos: Ejecute
optimize table <table_name>para reconstruir la tabla y recuperar el espacio fragmentado.Consola de DMS: Inicie sesión en la instancia de RDS desde DMS. Haga clic derecho sobre el nombre de una tabla y elija Batch operation table. Seleccione las tablas que desea desfragmentar y luego elija Table Maintenance > Optimize Table.
Automatic reclamation: En la consola de RDS, vaya a Autonomy Services > Diagnostics > Autonomy Center. Haga clic en Autonomy Service Settings y habilite Automatic Fragment Reclamation en la pestaña Optimization and Throttling. Para más detalles, consulte Uso de la función de recuperación automática de fragmentos.
Para obtener más información, consulte Solutions for MySQL space fragmentation.
Acumulación de archivos del sistema
Los archivos del sistema de gran tamaño casi siempre se deben al crecimiento del registro undo. Cuando consultas largas de InnoDB se ejecutan de forma simultánea con actualizaciones masivas de datos, MySQL genera grandes cantidades de datos undo. Esta información llena el espacio de tablas del sistema y puede agotar el almacenamiento.
La solución depende de su versión de MySQL y de la configuración del espacio de tablas undo.
MySQL 8.0
El sistema limpia automáticamente los archivos undo. No se requiere ninguna acción manual.
**MySQL 5.7 con innodb_undo_tablespaces = 2**
La instancia usa espacios de tablas undo independientes. Cuando el tamaño del archivo undo supera innodb_max_undo_log_size y ninguna transacción activa necesita esos datos, el sistema ejecuta una operación truncate para liberar el espacio.
**MySQL 5.7 con innodb_undo_tablespaces = 0**
Los datos undo se almacenan en el espacio de tablas del sistema ibdata1 y no se pueden recuperar. Use uno de los métodos siguientes para resolver el problema:
Método 1: Cree una nueva instancia y migre los datos con DTS. Consulte Data migration through the RDS MySQL console.
Método 2: Actualice a MySQL 8.0. Consulte Upgrade the database version.
MySQL 5.5 y 5.6
No se admite la limpieza de archivos undo. Actualice a MySQL 5.7 High-availability Edition o a MySQL 8.0. Después de actualizar a MySQL 5.7, habilite los espacios de tablas undo independientes para permitir la limpieza automática. MySQL 8.0 limpia los archivos undo de forma automática.
En instancias de MySQL 5.7 o anteriores donde innodb_undo_tablespaces = 0, el espacio que ocupa el archivo ibdata1 original no se puede recuperar, incluso después de una actualización de versión principal. Tras la actualización, solo los registros undo nuevos se escriben en espacios de tablas independientes y admiten la limpieza automática.
Para obtener más información, consulte Solutions for MySQL system file accumulation.
Acumulación de archivos de registro general
Cuando el registro general de consultas está habilitado, RDS registra cada sentencia SQL que se ejecuta, incluidas SELECT, INSERT, UPDATE y DELETE. Con tráfico alto, el archivo de registro crece rápidamente. Si no se limpia de forma periódica, puede agotar el almacenamiento.
Resolución inmediata:
Ejecute el siguiente comando para eliminar todos los registros generales existentes:
TRUNCATE TABLE mysql.general_log;Detención del crecimiento de nuevos registros:
Deshabilite la recopilación del registro general. Para ello, establezca el parámetro de ejecución general_log en OFF. Consulte Configuración de parámetros de la instancia.
Práctica recomendada: Mantenga el registro general deshabilitado en producción. Habilítelo de forma temporal solo para depurar o solucionar problemas. Después, deshabilítelo y limpie los datos de inmediato.
Para obtener más información, consulte Solutions for MySQL general log file accumulation.
Acumulación de archivos de datos de usuario
Los archivos de datos de usuario crecen con el tiempo y pueden llenar el almacenamiento si no se gestionan. Las columnas con tipos blob, text o varchar largos contribuyen de manera frecuente al gran tamaño de los archivos de datos. Cuando el almacenamiento se llena, RDS bloquea la instancia para evitar la pérdida de datos.
Resolución mediante la limpieza de datos no utilizados:
Use
dropotruncatepara eliminar las tablas o los datos que ya no necesite.En el caso de datos de objetos grandes, comprima la información antes de almacenarla para reducir el uso de espacio.
Para obtener más información, consulte Solutions for RDS for MySQL data file accumulation.
Acumulación de archivos de índice
Los índices de la base de datos se almacenan como archivos en disco. Una estrategia de indexación ineficiente o una gran cantidad de índices secundarios pueden hacer que los archivos de índice crezcan y agoten el almacenamiento.
Optimice su estrategia de indexación:
Cree índices en los campos adecuados: Genere índices en los campos que se consultan, ordenan o usan en combinaciones de tablas con frecuencia. Utilice índices compuestos en lugar de índices de una sola columna siempre que sea posible para reducir el tamaño total de los archivos de índice.
Elimine los índices no utilizados: Quite los índices redundantes o aquellos que ya no referencia ninguna consulta.
Eliminar un índice puede provocar bloqueos a nivel de tabla. Ejecute esta operación fuera del horario de mayor actividad o use la función lock-free schema evolution en DMS para reducir el impacto.