Gestión del ciclo de vida del índice

La acción de sustitución de ILM ahora es totalmente recuperable. Este es uno de los principales problemas y una gran victoria para la resistencia.

Copiamos el informe que publico la gente de Elastic en su sitio web oficial sobre este tema: 

Hemos extraído un nuevo paso como parte de ILM RolloverAction que esperará a que estén disponibles los fragmentos activos del índice recién creado, en lugar de posiblemente fallar todo el paso de rollover si esta espera se agota o no se puede satisfacer . También realizamos el paso ILM de la configuración de actualización recuperable y con esto, cerramos el problema de agregar reintentos automáticos a RolloverAction, ya que ahora todos los pasos son reintentables.

Instantánea de resistencia y BWC

En 7.6+ estamos cambiando la forma en que la información se almacena en un repositorio de instantáneas, de modo que seamos resistentes al hacer instantáneas en almacenes de blobs eventualmente consistentes como S3. En versiones anteriores, existía el riesgo de que los repositorios se corrompieran si un clúster realizaba múltiples operaciones de instantáneas en una sucesión rápida, ya que un repositorio consistente eventualmente no permitiría que el clúster vea el estado base correcto para actualizar (y anularía incorrectamente las cosas , corrompiendo instantáneas en el peor de los casos).

Todavía necesitamos admitir un escenario en el que un clúster se actualiza, por ejemplo, de 7.5 a 7.6, y si algo está mal con el clúster en 7.6, permitir que una instantánea que se tomó del clúster en 7.5 se restaure a un nuevo 7.5 clúster (es decir, volver a un estado anterior del clúster). Sin embargo, el nuevo formato del repositorio 7.6+ es fundamentalmente diferente, no permite que las versiones anteriores de Elasticsearch lean desde el repositorio. Como solución para este caso de uso, logramos que Elasticsearch 7.6+ solo escriba en el nuevo formato de repositorio 7.6+ si todas las instantáneas en el repositorio están en 7.6+. Esto significa que, mientras las instantáneas 7.5 estén en el repositorio, ES 7.6+ seguirá escribiendo en el repositorio de la manera anterior, lo que permitirá restaurar una instantánea 7.5 en un clúster 7.5+.

Esto, a su vez, significa nuevamente que más de 7.6 clústeres aún corren el riesgo de corromper las instantáneas en su repositorio si tienen instantáneas más antiguas en el repositorio ya que el nuevo formato flexible no se puede usar para escribir en el repositorio durante ese tiempo. Entonces, justo cuando pensábamos que teníamos las cosas bajo control, surgió un nuevo desafío. Se pueden convertir más de 7.6 clústeres para utilizar SLM, que no tiene un período de enfriamiento, y puede hacer instantáneas consecutivas. Un clúster 7.6+ ahora podría corromper un repositorio usando SLM si todavía tuviera instantáneas más antiguas en el repositorio. Después de evaluar varias soluciones, optamos por introducir un período de enfriamientoen ES propiamente dicho. Este período de enfriamiento solo se aplica a los repositorios basados ​​en S3 (otros almacenes de blobs proporcionan garantías de consistencia mucho más altas), y solo en el caso de que haya instantáneas más antiguas en el repositorio (es decir, donde tenemos que escribir en el repositorio en el pre 7.6 formato). Esto significa que las instantáneas S3 tardan un poco más debido al período de enfriamiento, pero los clústeres de ES 7.6+ deben evitar la corrupción del repositorio, independientemente del formato en el que escriben.

Este trabajo concluye los esfuerzos para hacer que las instantáneas sean resistentes y seguras en todos los blobstores que admitimos, y actualmente no quedan errores conocidos de resiliencia de instantáneas que sepamos. Durante la sincronización de la resistencia de la instantánea, confirmamos este hecho también con Cloud. El siguiente paso en este proyecto es mejorar los repositorios de instantáneas para permitir operaciones concurrentes. El primer paso en esto es simplificar la máquina de estado para la creación y eliminación de instantáneas de una manera compatible con las operaciones simultáneas de instantáneas.

TLS y ejemplos de autenticación para High Level Rest Client

En los días del cliente de transporte, proporcionamos una versión especial del cliente que incluía el complemento del lado del cliente para la seguridad de X-Pack. Esto significaba que los mismos tipos de configuración TLS que funcionaban en la seguridad de X-Pack en el servidor también estaban disponibles en el cliente. Con el cambio al High Rest Rest Client, intencionalmente no hemos copiado todo ese mismo soporte en el nuevo cliente, pero a veces los usuarios tuvieron dificultades para encontrar la forma de configurar los Rest Clients para conectarse a clústeres seguros. SSL en Java es versátil y robusto, pero puede ser difícil entender las API si no está familiarizado con ellas.

Tuvimos algunas discusiones sobre este último año, y decidimos que el mejor paso que podíamos tomar en este momento era expandir los documentos del resto de clientes con ejemplos más claros de configuración de los Clientes de descanso de alto y bajo nivel para conectarse a una variedad de configuraciones TLS diferentes, y También se agregaron ejemplos para la autenticación con tokens y claves API.

Los documentos mejorados llegarán a un sitio web cerca de usted.

Apache Lucene

Geo mejoras

Abrimos un RP para aumentar el límite de dimensión de datos para BKD para admitir la indexación de triángulos 3D. Ha habido un límite estricto de 8 dimensiones para los puntos de indexación desde que se introdujo por primera vez el árbol BKD, pero el trabajo desde entonces ha permitido que esta información se divida en dimensiones de 'indexación', utilizadas para construir el árbol y dimensiones de 'datos', se almacenan en las hojas. Esto nos permite cierta libertad para aumentar el número de dimensiones almacenadas mientras conservamos el tamaño y el rendimiento del índice. Esta mejora nos permitirá codificar datos de mayor dimensión dentro de un índice de menor dimensión (por ejemplo, triángulos teselados en 3D como un punto de 10 dimensiones utilizando solo las primeras 6 dimensiones para la construcción del índice).

También fusionamos algunos problemas abiertos de larga data en torno a la organización del código espacial dentro de Lucene, moviendo LatLongShape y XYShape desde el sandbox de lucene al núcleo y eliminando el módulo espacial largo y obsoleto (y en su mayoría vacío) .

Pruebas

Ahora que la construcción paralela de Gradle está en el maestro, ha habido una serie de cambios para mejorar el rendimiento del conjunto de pruebas lucene. En particular, agregar opciones de Java para desactivar la compilación de puntos de acceso en segundo plano ha reducido el tiempo de ejecución de forma masiva (en mi MBP que ejecuta el conjunto de pruebas de lucene completo ha pasado de 18 minutos a 6 minutos)

Búsqueda ANN

La comunidad continúa iterando sobre algunas implementaciones de búsqueda de vecino más cercano, en particular, Hierarchical Navigable Small-Worlds y IVFFlat . Estamos haciendo nuestras propias investigaciones para construir la búsqueda ANN sobre las estructuras de índice luceno existentes, y es fascinante seguirlo Estas diferentes líneas de investigación se retroalimentan mutuamente. ¡Desarrollo abierto en acción!