Problema de los índices de Magento-No se puede reindexar
indexing magento-1.6 (5)
Tengo un problema con la administración de índices dentro de mi tienda Magento 1.6.2.0. Básicamente no puedo conseguir que se actualicen. El estado dice Processing
pero dice así durante más de 3 semanas.
Y cuando intento volver a indexar, recibo este mensaje. Stock Status Index process is working now. Please try run this process later
Stock Status Index process is working now. Please try run this process later
pero más tarde son 3 semanas. Parece que el proceso está congelado pero no sé cómo reiniciar.
¿Algunas ideas?
aclamaciones
Cuando inicia un proceso de indexación, Magento escribe un archivo de bloqueo en la carpeta var/locks
.
$ cd /path/to/magento
$ ls var/locks
index_process_1.lock index_process_4.lock index_process_7.lock
index_process_2.lock index_process_5.lock index_process_8.lock
index_process_3.lock index_process_6.lock index_process_9.lock
El archivo de bloqueo impide que otro usuario inicie un proceso de indexación. Sin embargo, si la solicitud de indexación se agota o falla antes de que pueda completarse, el archivo de bloqueo quedará en estado de bloqueo. Eso es probablemente lo que te pasó. Le recomendaría que compruebe las últimas fechas modificadas en los archivos de bloqueo para asegurarse de que otra persona no esté ejecutando el re-indexador en este momento, y luego elimine los archivos de bloqueo. Esto aclarará su
El proceso del índice de estado de stock está funcionando ahora. Por favor, intente ejecutar este proceso más tarde
error. Después de eso, ejecute los indexadores uno a la vez para asegurarse de que cada uno se complete.
Cuando inicia un proceso de indexación, Magento escribe un archivo de bloqueo en la carpeta var / locks. Así que necesitas hacer dos pasos:
- Otorgar 777 permisos a las carpetas var / locks
- Borrar todos los archivos de la carpeta var / locks.
Ahora actualice la página de gestión de índice en el panel de administración. ¡¡Disfrutar!!
Hola: ¿Llamó al script manualmente o, si no, creó un archivo en su carpeta raíz y escribió este código en él?
require_once ''app/Mage.php'';
umask( 0 );
Mage :: app( "default" );
$process = Mage::getSingleton(''index/indexer'')->getProcessByCode(''catalog_product_flat'');
$process->reindexAll();
este código hace la indexación de su magento manualmente algunas veces sucede que si su tienda magento contiene una gran cantidad de productos, se necesitará mucho tiempo para reindexar los productos, de modo que cuando pueda acceder a la administración de índices desde el administrador, se mostrará cierta indexación en La etapa de procesamiento puede ser que este código lo ayude a eliminar la etapa de procesamiento para preparar la etapa de sus índices.
o también puede hacer indexación con SSH si tiene derechos sobre ella. también es más rápido para la indexación
Necesitas hacer dos pasos:
- dar permiso 777 a las carpetas var / locks
- borrar todos los archivos de la carpeta var / locks
Para las versiones más recientes de magento, es decir, 2.1.3 tuve que usar esta solución: http://www.elevateweb.co.uk/magento-ecommerce/magento-error-sqlstatehy000-general-error-1205-lock-wait-timeout-exceeded
Esto puede suceder si está ejecutando muchos scripts personalizados y eliminando los scripts antes de que la conexión de la base de datos tenga la oportunidad de cerrarse
Si inicia sesión en MySQL desde CLI y ejecuta el comando
MOSTRAR LA LISTA DE PROCESOS;
obtendrás la siguiente salida
+ ——— + —————– + +——————- + —————– + ——— + —— + ——- + —————— + ———– + ————— + ———– +
| Id | Usuario | Host | db | Comando | Tiempo | Estado | Info | Filas_sent | Filas_examinadas | Rows_read |
+ ——— + —————– + +——————- + —————– + ——— + —— + ——- + —————— + ———– + ————— + ———– +
| | 6794372 | db_user | 111.11.0.65:21532 | nombre_bd | Dormir 3800 | | NULL | 0 | 0 | 0
| | 6794475 | db_user | 111.11.0.65:27488 | nombre_bd | Dormir 3757 | | NULL | 0 | 0 | 0
| | 6794550 | db_user | 111.11.0.65:32670 | nombre_bd | Dormir 3731 | | NULL | 0 | 0 | 0
| | 6794797 | db_user | 111.11.0.65:47424 | nombre_bd | Dormir 3639 | | NULL | 0 | 0 | 0
| | 6794909 | db_user | 111.11.0.65:56029 | nombre_bd | Dormir 3591 | | NULL | 0 | 0 | 0
| | 6794981 | db_user | 111.11.0.65:59201 | nombre_bd | Dormir 3567 | | NULL | 0 | 0 | 0
| | 6795096 | db_user | 111.11.0.65:2390 | nombre_bd | Dormir 3529 | | NULL | 0 | 0 | 0
| | 6795270 | db_user | 111.11.0.65:10125 | nombre_bd | Dormir 3473 | | NULL | 0 | 0 | 0
| | 6795402 | db_user | 111.11.0.65:18407 | nombre_bd | Dormir 3424 | | NULL | 0 | 0 | 0
| | 6795701 | db_user | 111.11.0.65:35679 | nombre_bd | Dormir 3330 | | NULL | 0 | 0 | 0
| | 6800436 | db_user | 111.11.0.65:57815 | nombre_bd | Dormir 1860 | | NULL | 0 | 0 | 0
| | 6806227 | db_user | 111.11.0.67:20650 | nombre_bd | Dormir 188 | | NULL | 1 | 0 | 0
+ ——— + —————– + +——————- + —————– + ——— + —— + ——- + —————— + ———– + ————— + ———– +
15 filas en conjunto (0,00 seg)
Puede ver como ejemplo 6794372 que el comando está en espera y el tiempo es 3800. Esto está impidiendo otras operaciones. Estos procesos deben eliminarse 1 a 1 utilizando el comando.
KILL 6794372; Una vez que haya eliminado todas las conexiones para dormir, las cosas deberían comenzar a funcionar normalmente.