architecture - Solr dataimport seguro y cambio de núcleo en el sitio web de alto tráfico
high-availability dataimporthandler (2)
Hola compañeros técnicos,
Supongamos que tenemos un sitio web (PHP) con millones de visitantes al mes y que ejecutamos un índice SolR en el sitio web con 4 millones de documentos alojados. Solr se ejecuta en 4 servidores separados donde un servidor es el maestro y otros 3 servidores se replican.
Se pueden insertar miles de documentos en Solr cada 5 minutos. Y además de eso, el usuario puede actualizar su cuenta, que también debe desencadenar una actualización de Solr.
Estoy buscando una estrategia segura para reconstruir el índice rápido y seguro sin perder ningún documento. Y tener una estrategia de delta / actualización segura . He pensado en una estrategia y quiero compartirla con expertos aquí para escuchar su opinión sobre si debería recurrir a este enfoque o si pueden aconsejar algo (totalmente) diferente.
Solr DataImport
Para todas las operaciones, quiero usar un manejador de importación de datos. Quiero mezclar datos e importación delta en un archivo de configuración como DataImportHandlerDeltaQueryViaFullImport . Estamos utilizando una base de datos MySQL como fuente de datos.
Índice de reconstrucción
Para reconstruir el índice tengo en mente lo siguiente; creamos un nuevo núcleo llamado ''reindex'' cerca del núcleo ''en vivo''. Con dataimporthandler, reconstruimos por completo el conjunto de documentos completo (4 millones de documentos), lo que demora entre 1 y 2 horas en total. En el índice en vivo todavía hay cada minuto algunas actualizaciones, inserciones y eliminaciones.
Después de la reconstrucción, que duró alrededor de 1-2 horas, el nuevo índice aún no está actualizado. Para reducir la demora, realizamos una importación ''delta'' contra el nuevo núcleo para confirmar todos los cambios de las últimas 1-2 horas. Cuando esto se hace, hacer un core-swap. El controlador de importación "delta" normal que se ejecuta cada minuto seleccionará este nuevo núcleo.
Confirmando actualizaciones para el núcleo en vivo
Para mantener nuestro núcleo en vivo en la pista, ejecutamos la importación delta cada minuto. Debido al intercambio de núcleo, el núcleo de reindex (que ahora es el núcleo en vivo) se rastreará y se mantendrá actualizado. Supongo que realmente no debería ser un problema si este índice se retrasa por algunos minutos porque también se intercambiarán dataimport.properties. La importación delta ha superado estos minutos de retraso, pero debería ser posible.
Espero que entiendas mi situación y mi estrategia, y que podrían aconsejarte si lo hago de la manera correcta en tus ojos. Además, me gustaría saber si hay algún cuello de botella en el que no haya pensado. Estamos ejecutando Solr versión 1.4.
Alguna pregunta que tengo es, ¿qué hay de la replicación? Si el servidor maestro intercambia el núcleo, ¿cómo lo manejan los ungüentos?
¿Y hay riesgos de perder documentos al intercambiar, etc.?
¡Gracias por adelantado!
Buena (y difícil) pregunta!
La importación total es una operación muy pesada, en general es mejor ejecutar consultas delta para actualizar solo su índice a los últimos cambios en su RDMS. Obtuve por qué intercambias el maestro cuando necesitas realizar una importación completa: mantienes al día el núcleo activo al usar importación delta mientras que la importación total se ejecuta en el nuevo núcleo, ya que demora dos horas. Suena bien, siempre que la importación total no se use con tanta frecuencia.
Con respecto a la replicación, me aseguraría de que no haya ninguna replicación en progreso antes de intercambiar el núcleo maestro. Para obtener más detalles sobre cómo funciona la replicación, puede echar un vistazo a la wiki de Solr si aún no lo ha hecho.
Además, me aseguraría de que no haya ninguna importación delta ejecutándose en el núcleo activo antes de intercambiar el núcleo maestro.
Tenemos una situación ligeramente modificada en nuestro extremo. Hay dos DataImportHandlers: uno para la importación completa, otro para la importación delta. La importación delta se desencadena por un cron cada 3 horas y tarda minutos en completarse. La importación total de unos 10 millones de documentos tarda ~ 48 horas (¡loco!). Una gran parte de esto involucra la latencia de la red, ya que se obtiene una gran cantidad de datos de una tabla MySQL para cada documento. Estas dos tablas residen en dos servidores MySQL diferentes y no se pueden unir.
Tenemos un núcleo ''en vivo'', que es el que tiene importaciones delta. Presentamos otro núcleo de ''reconstrucción'' y realizamos un índice completo que tarda ~ 48 horas en completarse. En este momento, llevamos un registro de todos los documentos que se han actualizado / eliminado del núcleo ''en vivo'', y luego hacemos una importación del delta en el núcleo ''reconstruir'', para obtener los dos en el mismo estado. En un día normal, una vez que ambos núcleos estén en el mismo estado, los intercambiaremos y serviremos desde el núcleo de reconstrucción. (¿Quién controlará que el núcleo de reconstrucción esté completo de indexación y también haya aplicado parches delta?)
A veces, nos gustaría tener tanto el núcleo ''en vivo'' como ''reconstruido'' al mismo tiempo para ''pruebas ab''. En aquellos tiempos, tanto el núcleo ''en vivo'' como el de ''reconstrucción'' tendrían importaciones delta para mantener la coherencia, y ambos estarían sirviendo. En función del resultado, nos gustaría conservar uno y eliminar el otro mediante el intercambio.
Para que toda esta configuración sea operacionalmente estable, planeamos introducir un proceso de monitoreo que verifique si el núcleo de ''reconstrucción'' está indexando o hecho con eso. Si se ha indexado, el proceso del monitor lo actualizará con los documentos delta y activará el cron de indexación delta para ambos núcleos. Una vez completada la fase ab, uno de los núcleos se descargaría y el otro núcleo se intercambiaría. Los crons adicionales serían deshabilitados.
Hay algunas piezas más móviles en este diseño y la confiabilidad del proceso del monitor es crítica para la operación sin problemas. Alguna sugerencia / alternativa?