Descripción del problema
- Cuando se consultan datos basados en palabras clave, se pueden encontrar la vez anterior, pero es posible que no se encuentren al volver a consultar (aparece cuando se acaban de escribir los datos)
- Cuando se utiliza la interfaz de consulta general, la cantidad de consultas es inestable (aparece cuando los datos se escriben)
Resumen: Después de escribir el consumo de datos en ES, después de un ciclo de actualización (generalmente 30 o 60 segundos para grandes cantidades de datos), los datos se procesan en lotes para generar segmentos y prefijos de índice, que se pueden consultar externamente, pero la consulta no Condiciones estables, generalmente no exceden de 1 minuto para estabilizarse.
Análisis de causa
Los fragmentos de índice de Elasticsearch tienen dos atributos: fragmento principal y réplica. La función de la réplica es la conmutación por error y el equilibrio de carga.
Conmutación por error: cuando falla el host o nodo donde se encuentra el fragmento principal, la réplica se actualiza automáticamente al fragmento principal.
Equilibrio de carga: tanto el fragmento principal como la réplica proporcionan la misma capacidad de consulta externamente.
Cuando se escriben datos, primero se escriben en el fragmento principal y luego se sincronizan con el fragmento de índice correspondiente del fragmento principal. Si se realizan varias consultas durante este período, es realizará un equilibrio de carga y seleccionará aleatoriamente el fragmento principal o la réplica para realizar la tarea de consulta. En este momento, no hay datos en la réplica y se producirá inestabilidad de la consulta.
solución
ES proporciona una preferencia de modo de consulta de preferencias, que tiene los siguientes parámetros en la versión 5.5:
- _primary solo se consulta en el fragmento primario
- _primary_first Consulta primero en el fragmento principal, si el fragmento principal no está disponible o la consulta falla, consulta en la réplica
- _replica solo consultas en la réplica
- _replica_first Consulta primero en la réplica, si la réplica no está disponible o la consulta falla, consulta en el fragmento principal
- _local Si el fragmento local está disponible, la consulta se ejecutará primero en el fragmento local
- _prefer_nodes: abc, xyz consulta preferentemente en el nodo con la identificación especificada
- _shards: 2, 3 prioridad para consultar en el fragmento con el ID especificado
- _only_nodes está limitado para realizar operaciones en nodos específicos
- Valor personalizado (cadena)
La mayoría de las veces no es necesario utilizar la función de preferencia deliberadamente.
Según el escenario de datos actual, primary_first o replica_first se pueden usar para resolver la inestabilidad de la consulta, pero aumentará la presión de consulta del clúster y no puede usar la función de equilibrio de carga.