Presentando Rump: sincronizar en caliente dos bases de datos Redis usando volcados
Publicado por Marco Lisci el
Estamos encantados de anunciar nuestro primer proyecto de código abierto: ¡Rump!
Rump es una pequeña herramienta enfocada en una cosa simple: obtener datos en vivo de un cluster ElastiCache Redis de AWS.
Nos enfrentamos a este problema cuando tratamos de sincronizar nuestros contenedores de Redis en nuestro cluster de producción. En Sticker Mule usamos Docker y CoreOS, confiando en un cluster de ElastiCache para nuestras necesidades de Redis en producción.
Últimamente quisimos hacer nuestro ambiente de montaje lo más cercano posible a nuestro ambiente de producción, y Redis es parte de él. Este es el viaje que finalmente nos llevó a Rump.
No bloquees
Teníamos un simple requisito: no bloquear la producción mientras se obtienen los datos. La unicidad de Redis es un aspecto importante a tener en cuenta.
Sorprendentemente descubrimos que ElastiCache funciona con algunos comandos desactivados. Básicamente todos los comandos que puedes usar para transferir datos de forma segura.
BGSAVE
La forma estándar de lanzar manualmente una copia de seguridad de una base de datos Redis es emitir un BGSAVE, y esperar a que termine en el fondo, una operación no bloqueante. Desafortunadamente esto está deshabilitado, a menos que vaya con la implementación interna de AWS de la característica instantánea.
SLAVEOF
La colocación de esclavos es otra opción interesante que ofrece Redis, y habría sido la elección perfecta para nosotros.
El plan era establecer temporalmente los contenedores de Redis como esclavos de nuestro cluster de producción, obteniendo datos en vivo. Desafortunadamente SLAVEOF también está deshabilitado, no hay forma de agregar slaves a una instancia de ElastiCache.
Herramientas existentes
Hay muchas herramientas increíbles de Redis que tratan de simplificar la administración de los servidores de Redis, el volcado a JSON, etc.
El problema es que la mayoría de las herramientas estables y mantenidas, usan el comando KEYS para obtener las claves, y luego operan en las claves. El comando KEYS tiene una complejidad de O(N), bloqueando fuertemente a Redis cuando N es alto, hasta que todas las claves sean devueltas. Los contenedores de almacenamiento se crean y se destruyen con frecuencia y tenemos un buen número de claves, no queremos hacer el DoS en nuestro propio servidor.
Estaba claro que necesitábamos una herramienta sencilla para hacer la sincronización. Empezamos a jugar con SCAN para obtener las claves, y con DUMP/RESTORE para obtener/establecer los valores.
SCAN es un comando O(1), seguro para ejecutarse en un servidor de producción para obtener todas las claves, y por eso su implementación tiene que ser diferente a la de KEYS. El comando SCAN devuelve un grupo de claves que se encuentran actualmente en la BD, y un cursor al siguiente grupo.
La función DUMP/RESTORE hace que el trabajo de lectura/escritura de valores sea independiente del tipo de clave.
Teniendo esto en cuenta, esto es lo que Rump aporta a la mesa:
- Lectura de teclas progresivas sin bloqueo a través de
SCAN. - Operaciones de valores independientes de
TYPEa través deDUMP/RESTORE. - Operaciones de
SCANyDUMP/RESTORE. - La lectura del servidor fuente y la escritura en el servidor de destino son concurrentes. Rump no almacena todas las claves antes de escribir en el servidor de destino.
- Un solo binario multiplataforma, sin dependencias.
- Huella mínima, filosofía de UNIX, hace una sola cosa con dos banderas.
Esperamos que la herramienta sea útil para aquellos que experimentan los mismos problemas que nosotros, ¡y muchas, muchas gracias a Redis por soportar una gama tan amplia de comandos!
P.D. Si esto es de tu interés, y estás buscando una organización donde la gente con talento disfrute trabajando, estamos contratando.