El espacio en disco de MySQL es bajo en Adobe Commerce en la infraestructura en la nube

Este artículo proporciona soluciones para cuando está experimentando un espacio muy bajo o ningún espacio para MySQL en Adobe Commerce en la infraestructura en la nube. Los síntomas pueden incluir interrupciones del sitio, clientes que no pueden añadir productos al carro de compras, que no pueden conectarse a la base de datos, que no pueden acceder a la base de datos de forma remota, que no pueden SSH en el nodo. Los síntomas también incluyen errores de Galera, sincronización del entorno, PHP, base de datos e implementación, como se indica a continuación. Haga clic en Solución para saltar directamente a la sección de la solución.

Productos y versiones afectados

Adobe Commerce en infraestructura en la nube 2.3.0-2.3.6-p1, 2.4.0-2.4.2

Problema

La base de datos es demasiado grande. Los síntomas pueden incluir la pérdida de la conexión a la base de datos, un error de carga de la base de datos y una serie de otros problemas.

Errores que pueden producirse:

Galera:

  • SQLSTATE[08S01]: error de vínculo de comunicación: WSREP 1047 aún no ha preparado el nodo para el uso de la aplicación Errores de importación:
  • SQLSTATE[HY000]: Error general: 1180 Se obtuvo el error 5 "Error de entrada/salida"
  • SQLSTATE[08S01]: error de vínculo de comunicación: WSREP 1047 aún no ha preparado el nodo para el uso de la aplicación

Errores de sincronización de entorno:

  • SQLSTATE: Error general: 1180 Se obtuvo el error 5 "Error de entrada/salida" durante la confirmación

Errores de PHP:

  • php: PDO::__builds(): El servidor MySQL ha desaparecido.
  • errores php: PDO::__builds(): Error al leer el paquete de saludo. PID=NNNN.
  • ERROR 2013 (HY000): Se perdió la conexión con el servidor MySQL al 'leer el paquete de comunicación inicial', error del sistema: 0 "Error interno/comprobación (no error del sistema)".

Errores de base de datos:

  • Error_code: 1114
  • InnoDB: error (espacio en disco insuficiente) al escribir el nodo de Word en la tabla de índice auxiliar de FTS.
  • SQLSTATE[HY000]: Error general: 2006 El servidor MySQL ha desaparecido
  • [ERROR] SQL esclavo: Error 'La tabla <table\_name> está llena' en la consulta.
  • El mysql.service de la unidad entró en estado de error.
  • error: 'No se puede conectar al servidor MySQL local a través del socket '/var/run/mysqld/mysqld.sock' (111 "Conexión rechazada")'
  • 1205 Se superó el tiempo de espera de bloqueo; intente reiniciar la transacción. La consulta era: INSERT INTO `cron_schedule` (`job_code`, `status`, `created_at`, `scheduled_at`) VALUES (?, ?, YYYY-02-07 HH:MM:SS, YYYY-MM-DD HH:MM:SS)

Errores de implementación:

  • E: el comando '['sudo', '-u', <environment name>, 'bash', '-c', '/etc/platform/<environment name>/post_deploy.sh']' devolvió un estado de salida distinto de cero 255
  • E: el comando '['ssh', u<node IP address>, 'sudo /usr/bin/sv -w 30 sitio de reinicio-<environment name>g-nginx']' devolvió un valor distinto de cero
  • Actualizando esquema… SQLSTATE[HY000]: Error general: 1114 La tabla <table\_name> está llena
  • SQLSTATE[HY000]: Error general: 3 Error al escribir el archivo ./<environment name>/#
  • W: <filename> (código de error: 28 "No queda espacio en el dispositivo") Errores de indexación (junto con archivos temporales .ibd huérfanos en /tmp):
  • El indizador de reglas de catálogo genera una excepción. Las tablas temporales no se limpian después y luego llenan el disco en el nodo maestro MySQL actual

Pasos a seguir:

Una de las formas en que puede comprobar si el /data/mysql (o donde quiera que esté configurado el almacenamiento de datos MySQL) está lleno es ejecutando el siguiente comando en la CLI:

df -h

Menos del 10% de la memoria libre en el disco MySQL es un indicador principal de una interrupción.

Causa

Es posible que el montaje de /data/mysql se llene debido a una serie de problemas, como no tener suficientes nodos, espacio de almacenamiento disponible y consultas incorrectas que generan tablas temporales.

Solución

Hay un paso inmediato que podría tomar para volver a poner MySQL en marcha (o evitar que se atasque): libere algo de espacio vaciando las tablas grandes.

Sin embargo, una solución a largo plazo sería asignar más espacio y seguir las prácticas recomendadas de la base de datos, incluida la habilitación de la funcionalidad Archivo de pedidos/facturas/envíos.

A continuación se ofrecen detalles sobre soluciones rápidas y a largo plazo.

Comprobación y liberación de inodes

Asegúrese de que haya suficientes nodos disponibles. Para ello, ejecute el siguiente comando:

df -i

El resultado sería similar al siguiente:

Filesystem Inodes   Used   Free Use% Mounted on
/dev/nvme2n1 655360    1695  653665    1% /data/mysql

Compruebe que % de uso es <70 %. Los nodos se correlacionan con los archivos. Si elimina archivos de la partición, liberará inodes.

Compruebe y libere espacio de almacenamiento

Compruebe el espacio de almacenamiento disponible. Para ello, ejecute:

df -k

El resultado sería similar al siguiente:

Size Used Avail Use% Mounted on·
       50G 49G 95M 100% /data/mysql

Si el porcentaje de uso es >70 %, debe realizar alguna acción para liberar o agregar espacio.

Buscar ibtmp1 archivos grandes

Compruebe el archivo ibtmp1 grande en /data/mysql de cada nodo: este archivo es el tablespace para las tablas temporales. Si hay consultas erróneas que generan tablas temporales, se encuentran en el archivo ibtmp1. Este archivo sólo se quita cuando se reinicia la base de datos. Si ocupa todo el espacio disponible, debe reiniciarse la base de datos. Si hay consultas incorrectas, se volverá a crear.

Vaciar las mesas grandes

WARNING
Se recomienda encarecidamente crear una copia de seguridad de la base de datos antes de realizar cualquier manipulación y evitarlas durante períodos de carga alta del sitio. Consulte Volcar la base de datos en nuestra documentación para desarrolladores.

Compruebe si hay tablas grandes y considere si alguna de ellas se puede vaciar. Haga esto en el nodo principal (origen).

Por ejemplo, las tablas con informes suelen vaciarse. Para obtener más información sobre cómo buscar tablas grandes, consulte el artículo Buscar tablas MySQL grandes.

Si no hay tablas de informes enormes, considere la posibilidad de vaciar _index tablas, solo para volver a encarrilar la aplicación de Adobe Commerce. index_price tablas serían los mejores candidatos. Por ejemplo, catalog_category_product_index_storeX tablas, donde X puede tener valores desde "1" hasta el número máximo de tiendas. Tenga en cuenta que deberá reindexar para restaurar los datos de estas tablas y, en el caso de catálogos grandes, este reindexado puede llevar mucho tiempo.

Una vez vaciados, espere a que finalice la sincronización de wsrep. Ahora puede crear copias de seguridad y realizar pasos más significativos para agregar más espacio, como asignar o comprar más espacio y habilitar la funcionalidad Archivo de pedidos/facturas/envíos.

Comprobar configuración de registro binario

Compruebe la configuración del registro binario del servidor MySQL: log_bin y log_bin_index. Si la configuración está habilitada, los archivos de registro pueden llegar a ser enormes. Crear un ticket de soporte solicitando purgar archivos de registro binarios grandes. Además, solicite comprobar que el registro binario se está configurando correctamente para que los registros se purguen periódicamente y no ocupen demasiado espacio.

Si no tiene acceso a la configuración del servidor MySQL, solicite asistencia técnica para comprobarlo.

Asignar/comprar más espacio

Asigne más espacio en disco para MySQL si tiene algo sin usar. Consulte el artículo Comprobar el límite de espacio en disco para saber cómo comprobar si tiene espacio libre en disco.

Si ha alcanzado el límite de espacio y sigue experimentando problemas de poco espacio, considere la posibilidad de comprar más espacio en disco, póngase en contacto con el equipo de cuenta de Adobe para obtener más información.

recommendation-more-help
8bd06ef0-b3d5-4137-b74e-d7b00485808a