Persistencia en Redis

Problema

Al ser Redis un almacén de datos en memoria RAM, y ésta no es persistente, podemos perder datos en el caso de que haya un fallo. Si usamos Redis como cache, no debería ser un problema gigante ya que podemos recalentar la cache de nuevo y listos.

Casi seguro que tenga un impacto en rendimiento, los usuarios se tendrán que volver a loguear pero aparte de esto no habrá mas impacto.

Pero ¿y si queremos usar Redis de almacén persistente? ¿Es posible?

Sistemas de persistencia

Redis tiene varios modelos de persistencia, mediante los cuales guarda todo el contenido que tiene en memoria a disco. En el caso de error o reinicio de Redis, se leerían dichos ficheros para volver a dejar el nodo en el estado correcto. Tiene dos modos de operativa RDB y AOF.

RDB — Redis Database Backup

RDB va sacando fotos de los datos cada un intervalo de tiempo determinado y por lo que representa la información en un punto en el tiempo concreto. Las ventas es que es muy bueno para hacer backups digamos, cada hora. Al ser un formato muy compacto es muy fácil de guardar a otro centro de datos, o a Amazon S3 por ejemplo. Las restauraciones también son muy rápidas, sobretodo si el backup es muy grande.

La desventaja principal, es que al hacer fotos cada 5 minutos, por ejemplo, nos exponemos a perder 5 minutos de datos en caso de que Redis se pare abruptamente.

AOF — Append Only File

AOF replica todas las escrituras en el cluster de Redis y las guarda en un fichero en disco. Entonces no hay seeks (movimiento de los cabezales de los discos duros tradicionales) y el rendimiento es alto.

Al estar escribiendo en disco cada orden recibida, los datos son mucho mas durables. Como ya sabemos, por temas de performance cualquier programa que escribe en disco realmente no escribe en disco físicamente hasta que no se hace un fsync. Esto lo hace automáticamente el kernel de linux cada poco tiempo para asegurar que los datos se persisten, pero acumular una serie de cambios para aplicarlos todos juntos mejora el rendimiento.

Esto, cómo puedes imaginar, puede suponer un problema ya que podríamos haber escrito cambios sin hacer fsync y si el servidor se queda sin corriente perderemos éstos cambios. Para ello Redis permite ajustar cada cuando queremos hacer fsync:

  • No fsync: se encarga el sistema operativo de gestionarlo
  • Fsync cada segundo
  • Fsync en cada escritura

Con fsync cada segundo podemos perder realmente un segundo de datos.

El principal inconveniente es que los ficheros son bastante más grandes — pensemos que todos los comandos que provocan una escritura tienen que guardarse. Si guardamos 100 veces una misma clave, se guardan los 100 estados que ha tenido ésta clave. Cuando restauramos la copia lo que hacemos es volver a ejecutar los comandos uno a uno hasta el final. Éste proceso es más lento que el RDB.

¿Qué sistema de persistencia debería usar?

Depende de las necesidades que tengas, pero está bien tener ambos sistemas. Vas sacando fotos con RDB cada hora, y tienes backups completos y fácilmente restaurables, y AOF son fsync cada segundo, que tiene un impacto en performance muy pequeño, y nos permite tener datos pudiendo perder sólo 1 segundo.

¿Cómo lo hace MySQL?

Si miramos el parámetro innodb_fsync_threshold, éste ajusta cada cuantos bytes haremos fsync en disco. Por defecto el valor está a 0, y significa que esperará a hacer el fsync que se haya escrito todo en la cache del sistema operativo. Podemos imaginar que si hemos escrito en la cache sin hacer fsync, también podemos perder datos en MySQL (aunque la consistencia de datos está asegurada, como en Redis!)

Para más información, leer la información sobre la persistencia en la documentación oficial de Redis.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *