magento indexing magento-1.6

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:

  1. Otorgar 777 permisos a las carpetas var / locks
  2. 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:

  1. dar permiso 777 a las carpetas var / locks
  2. 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.