Migración de datos de Elasticsearch y recuperación ante desastres de clústeres
Este artículo analiza cómo migrar datos de ES entre clústeres y cómo implementar la recuperación ante desastres entre salas de máquinas y dentro de la ciudad y la recuperación ante desastres remota de ES.
En la práctica de producción de ES, a menudo se encuentran los siguientes problemas:
Según las necesidades comerciales, existen los siguientes escenarios:
Si es el primero En este escenario, la escritura se puede detener durante el proceso de migración de datos y se pueden utilizar métodos como elasticsearch-dump, logstash, reindex e snapshot para la migración de datos. De hecho, estas herramientas se pueden dividir aproximadamente en dos categorías:
Si es el segundo escenario, el clúster antiguo no puede dejar de escribir durante el proceso de migración de datos y la coherencia de los datos debe resolverse de acuerdo con el Escenario empresarial real. Pregunta:
A continuación se describe el uso de varias herramientas para la migración de datos cuando el clúster antiguo puede dejar de escribir.
elasticsearch-dump es una herramienta de migración de datos ES de código abierto, dirección de github: /taskrabbit/elasticsearch-dump
Las siguientes operaciones utilizan el comando elasticdump para migrar el índice de la base de datos de la empresa en el clúster x.x.x. 1 al grupo x.x.x.2. Tenga en cuenta que el primer comando primero migra la configuración del índice. Si migra directamente la asignación o los datos, perderá la información de configuración del índice en el clúster original, como la cantidad de fragmentos y la cantidad de copias. , también puede crear el índice directamente en el clúster de destino y luego sincronizar la asignación y los datos.
Logstash admite la lectura de datos de un clúster de ES y luego los escribe en otro clúster de ES, por lo que logstash se puede utilizar para la migración de datos. El archivo de configuración específico es el siguiente:
El archivo de configuración anterior sincroniza todos los índices del clúster ES de origen con el clúster de destino. Por supuesto, puede configurarlo para sincronizar solo los índices específicos. logstash, consulte la documentación oficial de logstash. Documentación oficial de logstash.
reindex Es una interfaz API proporcionada por Elasticsearch, que puede migrar datos de un clúster a otro.
La API de instantáneas es un conjunto de interfaces de API utilizadas por Elasticsearch para realizar copias de seguridad y restaurar datos. La migración de datos entre clústeres se puede realizar a través de la API de instantáneas. El principio es crear una instantánea de datos desde la fuente. Clúster de ES y luego migrelo al ES de destino en el clúster. Debe prestar atención al problema de la versión ES:
Si el clúster antiguo no puede dejar de escribir y se realiza la migración de datos en línea en este momento, se debe garantizar la coherencia de los datos de los clústeres nuevos y antiguos. En la actualidad, parece que, a excepción de la función CCR proporcionada oficialmente, no existe un método maduro de migración de datos en línea que pueda garantizar estrictamente la coherencia de los datos. En este momento, puede partir del escenario empresarial y elegir una solución de migración de datos adecuada en función de las características de los datos comerciales escritos.
En términos generales, las características de los datos escritos comerciales son las siguientes:
Analicemos en detalle cómo elegir el método de migración de datos adecuado según las diferentes características de los datos escritos.
En escenarios de registro o APM, los datos son datos de series de tiempo y, generalmente, los índices se crean diariamente. Los datos de ese día solo se escribirán en el índice actual. En este momento, primero puede sincronizar los datos del índice existente que ya no se escriben en el nuevo clúster a la vez y luego usar logstash u otras herramientas para sincronizar incrementalmente el índice de ese día. Después de que se ecualicen los datos, cambie el negocio. acceso a ES en el nuevo clúster.
El plan de implementación específico es:
El método de escritura de datos de solo agregar se puede ordenar según el orden de escritura de los datos (ordenado según _doc, si hay un campo de marca de tiempo, también se puede ordenar según la clasificación de marca de tiempo) extrae datos en lotes del clúster anterior y luego los escribe en lotes en el nuevo clúster; puede escribir un programa y usar la API de desplazamiento o el parámetro search_after para extraer datos incrementales en lotes; luego use la API masiva para escribirlos en lotes.
Utilice el desplazamiento para extraer datos incrementales:
La operación anterior se puede realizar una vez por minuto, extrayendo los datos recién generados en el minuto anterior, de modo que los datos se sincronicen entre los datos antiguos. cluster y el nuevo cluster El retraso es de un minuto.
Utilice search_after para extraer datos incrementales en lotes:
Las operaciones anteriores se pueden ejecutar en intervalos de eventos personalizados según sea necesario. Modifique el valor del parámetro search_after cada vez que se ejecute para obtenerlos. los datos múltiples después del valor especificado search_after son en realidad equivalentes a un cursor, que avanza cada vez que se ejecuta para obtener los datos más recientes.
La diferencia entre usar scroll y search_after es:
Además, si no desea migrar los datos incrementales del clúster antiguo al nuevo clúster escribiendo un programa, puede Puede usar logstash combinado con desplazamiento para realizar datos incrementales. Para la migración, los archivos de configuración a los que puede consultar son los siguientes:
Durante el uso, puede ajustar los parámetros de la tarea programada y los parámetros relacionados con el desplazamiento de acuerdo con el tiempo real. necesidades del negocio.
Si el escenario empresarial implica agregar y actualizar datos existentes al escribir en ES, lo más importante en este momento es cómo resolver el problema de sincronización de datos de la operación de actualización. Para datos nuevos, puede utilizar el método de índice activo de migración incremental descrito anteriormente para sincronizarlos con el nuevo clúster. Para datos actualizados, si el índice tiene un campo similar a updateTime para marcar el momento de la actualización de los datos, puede escribir un programa o logstash y usar la API de desplazamiento para extraer los datos incrementales actualizados en lotes según el campo updateTime y luego escribir a un nuevo clúster.
Los archivos de configuración de logstash a los que se puede hacer referencia son los siguientes:
En varias aplicaciones prácticas, la sincronización de los datos recién agregados y los datos actualizados se puede realizar al mismo tiempo. Sin embargo, si no hay ningún campo como updateTime en el índice que pueda identificar qué datos se han actualizado, actualmente no parece haber un mejor método de sincronización que pueda usarse para garantizar la coherencia de los datos entre el clúster antiguo y el nuevo.
Si la empresa escribe en ES tanto datos nuevos (agregar) como datos actualizados (actualizar) y eliminados (eliminar), puede usar la función CCR en la versión comercial del complemento X-pack posterior a 6.5 Migración de datos. Sin embargo, existen algunas restricciones en el uso de CCR, a las que se debe prestar atención:
El método de uso específico es el siguiente:
Si el negocio es escribir datos en ES a través de middleware como kafka, puede usar lo siguiente. Como se muestra en la figura, logstash se usa para consumir datos de Kafka en el nuevo clúster. Después de que los datos del clúster antiguo y el nuevo sean completamente iguales, puede cambiar al nuevo. clúster para consultas comerciales y luego desconecte el clúster anterior para procesarlo.
Las ventajas de utilizar middleware para la doble escritura sincrónica son:
Por supuesto, la doble escritura también se puede resolver de otras maneras, como construir un proxy autoconstruido y escribir en el proxy al escribir negocios, el proxy reenvía la solicitud a uno o más clústeres, pero este método tiene los siguientes problemas:
A medida que crece la escala comercial, la parte comercial se preocupa por la confiabilidad de los datos y la estabilidad del clúster de Los requisitos del clúster ES utilizado para tales aspectos son cada vez mayores, por lo que se necesita una mejor solución de recuperación ante desastres del clúster para satisfacer las necesidades del lado empresarial.
Si la empresa construye su propio clúster ES a través de máquinas físicas en su propia sala de computadoras IDC, al resolver la recuperación ante desastres entre salas de máquinas, a menudo implementa dos clústeres ES en dos salas de computadoras, una maestra y otra maestra. Prepare y luego resuelva el problema de la sincronización de datos; generalmente hay dos formas de sincronización de datos. Una es la escritura doble, que es implementada por el lado comercial para garantizar la coherencia de los datos. Y es necesario garantizar que los datos se almacenen en ambos lados. Solo se puede considerar que todos los grupos se escriben correctamente. Otro método es la replicación asincrónica. La parte comercial solo escribe en el clúster principal y luego sincroniza los datos con el clúster de respaldo en segundo plano. Sin embargo, es más difícil garantizar la coherencia de los datos. El tercer método consiste en conectar las dos salas de computadoras a través de una línea dedicada para lograr la implementación entre salas de computadoras, pero el costo es mayor.
Debido a la complejidad de la sincronización de datos, cuando los proveedores de la nube implementan la recuperación ante desastres entre salas de computadoras para los clústeres de ES, a menudo implementan solo un clúster y utilizan las capacidades propias de ES para sincronizar los datos.
La primera característica de la implementación de clústeres ES entre salas de computadoras de un proveedor de nube extranjero es que no obliga al uso de nodos maestros dedicados. Como se muestra en la figura anterior, un clúster tiene solo dos nodos, que sirven como nodos de datos y candidatos. nodos maestros; fragmentos primarios y fragmentos de réplica Distribuidos en dos zonas de disponibilidad, debido a la existencia de fragmentos de réplica, el clúster aún está disponible después de que falla la zona de disponibilidad 1. Sin embargo, si la red entre las dos zonas de disponibilidad se interrumpe, se producirá un cerebro dividido. ocurrirá el problema. Como se muestra en la figura siguiente, el uso de tres nodos maestros dedicados eliminará el problema del cerebro dividido.
Pero, ¿qué pasa si una región no tiene tres zonas de disponibilidad? Entonces, dos nodos maestros dedicados solo se pueden colocar en una de las zonas de disponibilidad, como la solución de un proveedor de nube nacional:
Sin embargo, todavía hay problemas en el proceso de reconstrucción de nodos. Como se muestra en la figura anterior, el quórum del clúster en sí debe ser 2. Después de que la zona de disponibilidad 1 cuelga, solo queda un nodo maestro dedicado en el clúster. Debe cambiar el parámetro de quórum (discovery.zen.minimum_master_nodes) a 1 antes de que el clúster pueda seleccionar normalmente el maestro. Después de restaurar los dos nodos maestros dedicados que murieron, se necesita el parámetro de quórum (discovery.zen.minimum_master_nodes). debe ajustarse a 2 para evitar la aparición de cerebro dividido.
Por supuesto, todavía existen soluciones que pueden evitar los dos posibles problemas de no poder elegir el cerebro maestro y el cerebro dividido, como se muestra a continuación, la idea de solución de un proveedor de nube nacional:
Crear Cuando utilice un clúster de zona de disponibilidad dual, debe seleccionar 3 o 5 nodos maestros dedicados. El backend implementará solo nodos maestros dedicados en una zona de disponibilidad oculta. La ventaja 1 de la solución es que si hay una zona de disponibilidad. falla, el clúster aún puede seleccionar el nodo maestro normalmente, evitando la situación en la que no se puede seleccionar el maestro porque no se cumplen los votos legales del quórum; 2, porque se deben seleccionar tres o cinco nodos maestros dedicados, lo que también evita la división del cerebro.
Quiero comparar el método de uso de dos clústeres, uno activo y otro en espera, para la recuperación ante desastres entre salas de computadoras. Los proveedores de la nube han resuelto el problema originalmente complicado de sincronización de datos primarios y en espera mediante la implementación de clústeres en todas las computadoras. Sin embargo, lo más preocupante es si el retraso de la red entre las salas de computadoras o las zonas de disponibilidad hará que el rendimiento del clúster disminuya. Aquí, para el clúster de zona de disponibilidad dual de Tencent Cloud, utilizamos herramientas de referencia estándar para realizar una prueba de esfuerzo en dos clústeres de zona de disponibilidad única y de zona de disponibilidad dual de las mismas especificaciones. Los resultados de la prueba de estrés se muestran en la siguiente figura:
A juzgar por los indicadores de latencia de consulta y latencia de escritura de los resultados de la prueba de estrés, no existe una diferencia obvia entre los dos tipos de clústeres. Esto se debe principalmente a la mejora de la infraestructura de red subyacente en la nube. y la latencia de la red entre zonas de disponibilidad es muy baja.
De manera similar a la recuperación ante desastres entre salas de computadoras en la misma ciudad, la solución general para la recuperación ante desastres remota es implementar dos clústeres, uno maestro y otro en espera, en dos salas de computadoras remotas. Al escribir negocios, solo se escribe en el clúster primario y luego los datos se sincronizan de forma asincrónica con el clúster de respaldo. Sin embargo, la implementación será más complicada porque es necesario resolver el problema de la coherencia de los datos entre los clústeres primario y de respaldo. si cruza regiones, el retraso de la red será relativamente alto. Además, cuando el clúster primario falla y el clúster de respaldo se cambia al clúster de respaldo, es posible que los datos en ambos lados aún no sean iguales, lo que resulta en inconsistencias y daños al negocio; . Por supuesto, la doble escritura se puede lograr con la ayuda de middleware como Kafka, pero a medida que aumentan los enlaces de datos, los retrasos en la escritura también aumentan y, si hay un problema con Kafka, la falla puede ser catastrófica.
Un método de replicación asincrónica más común es utilizar la función de copia de seguridad instantánea para realizar una copia de seguridad en el clúster principal con regularidad, por ejemplo cada hora, y luego restaurarla en el clúster de copia de seguridad, pero habrá una en los clusters principal y de respaldo. Horas de latencia de datos. Tomando Tencent Cloud como ejemplo, el clúster ES de Tencent Cloud admite la copia de seguridad de datos en el COS de almacenamiento de objetos, porque se puede utilizar para lograr la sincronización de datos entre los clústeres activo y en espera. Para conocer los pasos de operación específicos, consulte /document/product/845/. 19549.
Tras el lanzamiento oficial de la función CCR en la versión 6.5, se ha solucionado el problema de sincronización de datos entre clusters.
CCR se puede utilizar para implementar recuperación ante desastres fuera del sitio para clústeres ES:
CCR es similar a un método de suscripción de datos: el clúster principal es el líder, el clúster de respaldo es el seguidor y el clúster de respaldo extrae. datos del clúster principal de forma extraíble y solicitudes de escritura; cuando se define el índice de seguidores, el índice de seguidores se inicializará y todos los archivos del segmento subyacente se sincronizarán desde el líder en forma de instantáneas. Una vez completada la solicitud de escritura, se extraerá la solicitud de escritura y se realizará la reproducción en el lado del seguidor para completar la sincronización de datos. La ventaja de CCR es, por supuesto, que puede sincronizar las operaciones ACTUALIZAR/ELIMINAR, resolver el problema de coherencia de los datos y reducir el retraso de sincronización.
Además, basado en CCR, se puede combinar con el clúster de recuperación de desastres entre salas de computadoras mencionado anteriormente para realizar un clúster ES multicéntrico en dos lugares. En la región de Shanghai, se implementa un clúster de zona de disponibilidad múltiple para lograr una alta disponibilidad en todas las salas de computadoras. Al mismo tiempo, se implementa un clúster en espera en la región de Beijing como seguidor para sincronizar datos usando CCR, dando así un paso más en. disponibilidad de clústeres y capacidad de salas de computadoras en la misma ciudad ante desastres, y logró recuperación ante desastres entre regiones.
Sin embargo, cuando ocurre una falla y es necesario cambiar el acceso al clúster de Shanghai a Beijing, habrá algunas restricciones, porque el índice de seguidores en CCR es de solo lectura y no se puede escribir, y debe Se puede cambiar a un índice normal y el proceso es irreversible. Sin embargo, se debe evitar desde el lado comercial, como usar un nuevo índice normal al escribir y el negocio usar alias para la consulta. Cuando se restablezca la región de Shanghai, los datos se sincronizarán nuevamente a la inversa.
El problema actual es garantizar la integridad de los datos del clúster en la región de Shanghai. Una vez restaurada la región de Shanghai, puede crear un nuevo índice de seguidores en la región de Shanghai y sincronizar los datos con el índice. escrito en la región de Beijing como Líder Una vez que se completan los datos Después de vincular el nivel, cambie a la región de Shanghai para leer y escribir. Tenga en cuenta que debe crear un nuevo índice de Líder para escribir datos al cambiar.
El proceso de sincronización de datos es el siguiente:
1. El clúster principal de Shanghai proporciona servicios normalmente y el clúster de respaldo de Beijing sigue los datos del clúster principal
2. El clúster principal de Shanghai En caso de falla, la empresa cambia al clúster de respaldo de Beijing para lectura y escritura. Después de restaurar el clúster principal de Shanghai, los datos se siguen desde el clúster de Beijing.