ApsaraDB RDS:Qué hacer si una instancia de ApsaraDB RDS for MySQL está en estado Locked porque los archivos temporales agotaron su capacidad de almacenamiento

Opción 1: amplíe la capacidad de almacenamiento

Amplíe la capacidad de almacenamiento de la instancia. Después de la ampliación, el sistema desbloquea automáticamente la instancia en aproximadamente 5 minutos. Para más detalles, consulte Change the specifications of an ApsaraDB RDS for MySQL instance.

Opción 2: reinicie la instancia para liberar los archivos temporales

Si no es posible ampliar el almacenamiento, utilice uno de los métodos siguientes según la versión principal de MySQL de la instancia:

• MySQL 5.6: el tablespace temporal reside en el tablespace del sistema ibdata1. Restarting the instance no libera los archivos temporales. Compare el tamaño de ibdata1 entre el nodo primario y el secundario. Si el nodo secundario tiene un archivo ibdata1 más pequeño, ejecute un failover de alta disponibilidad (HA) y luego reconstruya el nodo secundario original para liberar el espacio. Si ambos nodos tienen un archivo ibdata1 grande, cree una nueva instancia y use DTS para migrar los datos.

• MySQL 5.7: el tablespace temporal reside en el archivo independiente ibtmp1. Restarting the instance libera los archivos temporales. En instancias de alta disponibilidad, compare el tamaño de ibtmp1 entre el nodo primario y el secundario. Si el nodo secundario tiene un archivo ibtmp1 más pequeño, ejecute un failover de HA y luego reinicie el nodo secundario original para liberar el espacio. Establezca el parámetro innodb_temp_data_file_path en ibtmp1:12M:autoextend:max:10G para limitar ibtmp1 a 10G. Este cambio requiere reiniciar la instancia para surtir efecto.

• MySQL 8.0 y 8.4: cuando la instancia se bloquea, todas las sesiones de usuario finalizan. Estas comienzan automáticamente a revertirse después de terminar. La duración de la reversión depende de las consultas que se estaban ejecutando. El almacenamiento de la instancia se libera una vez que finaliza la reversión de la transacción.

Si el botón Restart Instance de la página Basic Information aparece atenuado, aplique esta solución alternativa:

1. Vaya a la página Instances. En la barra de navegación superior, seleccione la región donde reside la instancia y haga clic en el ID de la instancia.

2. En el panel de navegación izquierdo, haga clic en Parameters.

3. En la pestaña Editable Parameters, busque cualquier parámetro que muestre Yes en la columna Force Restart y cambie su valor.

Opción 3: identifique y finalice la sesión problemática

Si la instancia sigue bloqueada después de reiniciarla, identifique la sesión que genera los archivos temporales y termínela.

1. Conéctese a la instancia mediante Data Management (DMS).

2. Ejecute la siguiente sentencia para listar las sesiones activas:

   show processlist

3. Ordene los resultados por la columna State. Busque sesiones donde State muestre Copy to tmp table o Sending data, ya que indican un uso intensivo de archivos temporales. Anote el ID de la sesión problemática.

4. Finalice la sesión:

   kill [$ID];

   Reemplace [$ID] con el ID de sesión obtenido en el paso anterior.

   Importante

   Antes de finalizar una sesión, compruebe que hacerlo no afectará los servicios en ejecución.

Habilite la ampliación automática de almacenamiento

Configure la ampliación automática de almacenamiento para que el sistema lo amplíe automáticamente cuando el uso se acerque al umbral. Para más detalles, consulte Configure automatic storage expansion for an ApsaraDB RDS for MySQL instance.

Optimice las sentencias SQL que generan archivos temporales

Para comprobar si una sentencia SQL específica usa una tabla temporal, ejecute EXPLAIN y revise la columna Extra. Si aparece Using temporary, la sentencia genera una tabla temporal.

explain select * from alarm group by created_on order by default;

Para reducir el uso de archivos temporales:

• Reescriba las consultas para evitar el uso frecuente de ORDER BY y GROUP BY sobre conjuntos de resultados grandes.

• Agregue índices adecuados para evitar ordenamientos de tablas completas.

• Puede aumentar los valores de tmp_table_size y max_heap_table_size según sus necesidades de negocio. Sin embargo, no se recomienda este método, ya que los recursos de memoria son más importantes que los de disco.

Reduzca el almacenamiento temporal de las transacciones grandes

Las transacciones grandes escriben archivos de caché de binlog en el disco mientras están en curso. Para reducir este consumo:

• Divida las operaciones por lotes grandes en transacciones más pequeñas.

• Evite ejecutar varias transacciones grandes en paralelo a través de múltiples conexiones.

• Use conexiones de corta duración para las transacciones grandes y así reducir el almacenamiento que ocupan los archivos temporales.

• Puede aumentar el valor de binlog_cache_size según sus necesidades de negocio. No obstante, se recomienda no usar este método.

Supervise el uso del disco

Mantenga el uso del disco por debajo del 80 %. Configure alertas de monitoreo para poder eliminar datos innecesarios o dividir conjuntos de datos grandes antes de que se agote el almacenamiento.