Elasticsearch estrategias de copia de seguridad en caliente

Question

Sería interesante si alguien pudiera compartir sus mejores estrategias de "copia de seguridad en caliente" para ElasticSearch.

Además, puede compartir herramientas y bibliotecas relacionadas con este problema y puede ayudar.

Actualizado: Gracias @javanna por su respuesta, es bastante completo y proporciona una buena dirección para futuras acciones.

También hice una pequeña investigación y encontré algunos artículos/discusiones que pueden ayudar si alguien tiene un interés.

• Elasticsearch backup strategies
• Backup/restore Elasticsearch index y related snippet on github:gist
• Elastic Search Backup and Recovery discusión (ver el comentario de Paul Smith, también compartió un enlace útil a su tool for verifying indexes)

Actualización: Elasticsearch 1.0 tienen una solución de copia de seguridad "oficial": Snapshot/Restore API y esta es la única forma correcta de hacerlo ahora. ElasticSearch identificará los fragmentos maestros y se ocupará de la consistencia. La copia de seguridad se realizará de forma incremental, por lo que podrá hacerlo muy rápido y con la frecuencia que desee.

Answer 1

Las réplicas son una especie de copia de seguridad, y elasticsearch nunca asigna una en el mismo nodo donde se encuentra el fragmento primario original. Pero aún existe el riesgo de perder datos según la cantidad de fragmentos, réplicas y nodos que tenga en su clúster.

Me gustaría ver el módulo Gateway, a través del cual puede guardar el índice y los metadatos del clúster. Hay diferentes tipos de puerta de enlace. Me gustaría ver el Shared FS por ejemplo, que le permite copiar el índice y los metadatos a un sistema de archivos compartido entre todos sus nodos. También puede iniciar manualmente una instantánea a través del Gateway Snapshot API.

Además, puede hacer una copia del directorio de datos (en cada nodo) una vez que desactivó el lavado a través del index.translog.disable_flush index setting. De esta forma, se aseguraría de que no se emitirá ninguna confirmación de lucene mientras está copiando. Después de hacer la copia, debe habilitar el enjuague nuevamente.

ACTUALIZACIÓN

Todos los tipos de puerta de enlace a excepción de la local han quedado en desuso y se eliminará en una versión futura. Elasticsearch 1.0 se lanzará con una mejor solución de respaldo.

Answer 2

Esto va en contra de cómo ElasticSearch funciona, pero consideraría tener 2 instancias separadas de ElasticSearch que no se conocen entre sí. En su código de aplicación, cada comando se envía a ambas instancias. Si un comando falla durante 1 instancia, vuelva a intentarlo 1 minuto después y vuelva a intentarlo. Ahora puede mantener 1 de las instancias como una copia de seguridad en caliente, o incluso puede usarla para mejorar el rendimiento equilibrando la carga de las consultas entre las 2 instancias.

La razón por la que no me gusta configurar réplicas en ElasticSearch es que es complicado configurar qué nodo obtiene qué réplica, y si desea reorganizar la organización en el futuro, básicamente tiene que pasar por un montón de aros. ElasticSearch hace un montón de reequilibrio detrás de escena, e intenta hacer todo por ti. Que puede ser bueno ...si tiene servidores potentes y no le importa qué obtiene qué ... pero puede ser un dolor de lo contrario.