Persistencia de Redis

Redis admite dos mecanismos de persistencia: RDB y AOF. La función de persistencia evita eficazmente la pérdida de datos causada por la salida del proceso. La recuperación de datos se puede lograr utilizando archivos previamente persistidos cuando se produce el siguiente reinicio. Comprender y dominar el mecanismo de persistencia es muy importante para la operación y el mantenimiento de Redis. El contenido de este capítulo es el siguiente:

·Primero presente el proceso de configuración y operación de RDB y AOF, así como los comandos relacionados para controlar la persistencia, como bgsave y bgrewriteaof.

·En segundo lugar, analizar, localizar y optimizar los problemas de persistencia comunes.

·Finalmente, está optimizado en base al escenario de implementación común de múltiples instancias en una sola máquina de Redis.

5.1 RDB

La persistencia de RDB es el proceso de generar una instantánea de los datos del proceso actual y guardarla en el disco duro. El proceso de activación de la persistencia de RDB se divide en activación manual y. disparo automático.

5.1.1 Mecanismo de activación

La activación manual corresponde a los comandos save y bgsave respectivamente:

·comando save: bloquea el servidor Redis actual hasta que finalice el proceso RDB Una vez completado, las instancias con memoria relativamente grande provocarán un bloqueo a largo plazo y no se recomienda su uso en entornos en línea. El registro de Redis correspondiente a la ejecución del comando guardar

es el siguiente:

* Base de datos guardada en el disco

· comando bgsave: el proceso de Redis realiza una operación de bifurcación para crear un proceso hijo y el RDB persiste. El subproceso es responsable del proceso de transformación y finaliza automáticamente una vez completado. El bloqueo sólo ocurre durante la fase de bifurcación y generalmente es de muy corta duración. El registro de Redis correspondiente a la ejecución del comando bgsave es el siguiente:

* Guardado en segundo plano iniciado por el pid 3151

* Base de datos guardada en el disco

* RDB: 0 MB de memoria utilizada por copia en escritura

* El guardado en segundo plano finalizó con éxito

Obviamente, el comando bgsave está optimizado para el problema de bloqueo de guardado. Por lo tanto, todas las operaciones que involucran RDB dentro de Redis usan bgsave y el comando guardar se abandonó.

Además de la activación manual mediante la ejecución de comandos, también existe un mecanismo de persistencia dentro de Redis que activa automáticamente RDB, como los siguientes escenarios:

1) Utilice configuraciones relacionadas con guardar, como "guardar m n". Indica que bgsave se activa automáticamente cuando el conjunto de datos se modifica n veces en m segundos.

2) Si el nodo esclavo realiza una operación de copia completa, el nodo maestro ejecuta automáticamente bgsave para generar un archivo RDB y lo envía al nodo esclavo. Para obtener más detalles, consulte el principio de replicación presentado en la Sección 6.3. .

3) Al ejecutar el comando debug reload para recargar Redis, la operación de guardar también se activará automáticamente.

4) De forma predeterminada, al ejecutar el comando de apagado, si la función de persistencia AOF no está habilitada, bgsave se ejecutará automáticamente.

5.1.2 Descripción del proceso

bgsave es la forma principal de activar la persistencia de RDB. Entendamos su proceso de operación de acuerdo con la Figura 5-1.

1) Ejecute el comando bgsave. El proceso principal de Redis determina si actualmente hay un proceso secundario en ejecución, como un proceso secundario RDB/AOF. Si hay un comando bgsave, regresa directamente.

2) El proceso principal realiza una operación de bifurcación para crear un proceso secundario. El proceso principal se bloqueará durante la operación de bifurcación. Marque la opción last_fork_usec a través del comando info stats para obtener el tiempo necesario para la última. operación de horquilla, en microsegundos.

3) Una vez completada la bifurcación del proceso principal, el comando bgsave devuelve el mensaje "Se inició el guardado en segundo plano" y ya no bloquea el proceso principal y puede continuar respondiendo a otros comandos.

4) El proceso hijo crea un archivo RDB, genera un archivo de instantánea temporal basado en la memoria del proceso padre y reemplaza atómicamente el archivo original una vez completado. La ejecución del comando lastsave puede obtener la hora en que se generó por última vez el RDB, correspondiente a la opción rdb_last_save_time de las estadísticas de información.

5) El proceso envía una señal al proceso principal para indicar la finalización y el proceso principal actualiza la información estadística. Para obtener más detalles, consulte las opciones relacionadas con rdb_* en información Persistencia.

5.1.3 Procesamiento de archivos RDB

Guardar: los archivos RDB se guardan en el directorio especificado por la configuración del directorio y el nombre del archivo se especifica mediante la configuración del nombre del archivo db. Se puede ejecutar dinámicamente durante el tiempo de ejecución ejecutando config set dir{newDir} y config setdbfilename{newFileName}. El archivo RDB se guardará en el nuevo directorio la próxima vez que se ejecute.

Consejos de operación y mantenimiento

Cuando encuentre un disco defectuoso o un disco lleno, puede modificar la ruta del archivo en línea a una ruta de disco disponible a través de config set dir{newDir} y luego ejecutar bgsave realiza cambio de disco y también es aplicable a archivos persistentes AOF.

Compresión: Redis utiliza el algoritmo LZF de forma predeterminada para comprimir los archivos RDB generados. Los archivos comprimidos son mucho más pequeños que el tamaño de la memoria. Está habilitado de forma predeterminada y se puede modificar dinámicamente a través del conjunto de configuración de parámetros rdbcompression. {sí|no}.

Consejos de operación y mantenimiento

Aunque comprimir RDB consumirá CPU, puede reducir en gran medida el tamaño del archivo, lo cual es conveniente para guardarlo en el disco duro o enviarlo al nodo esclavo. a través de la red, por lo que se recomienda encenderlo en línea.

Verificación: si Redis se niega a iniciarse al cargar un archivo RDB dañado e imprime el siguiente registro:

# Lectura corta o error irrecuperable al cargar OOM, abortando ahora.

p >

En este momento, puede utilizar la herramienta redis-check-dump proporcionada por Redis para detectar el archivo RDB y obtener el informe de error correspondiente.

5.1.4 Ventajas y Desventajas de RDB

Ventajas de RDB:

·RDB es un archivo binario compacto y comprimido que representa a Redis en un determinado punto de instantánea de datos. Es muy adecuado para copias de seguridad, copias completas y otros escenarios. Por ejemplo, realice una copia de seguridad de bgsave cada 6 horas y copie el archivo RDB a una máquina o sistema de archivos remoto (como HDFS) para la recuperación ante desastres.

·Redis carga RDB para restaurar datos mucho más rápido que AOF.

Desventajas de RDB:

·Los datos RDB no pueden lograr persistencia en tiempo real/persistencia de segundo nivel. Porque cada vez que se ejecuta bgsave, debe realizar una operación de bifurcación para crear un proceso hijo, lo cual es una operación pesada y el costo de ejecución frecuente es demasiado alto.

·Los archivos RDB se guardan en un formato binario específico. Durante la evolución de la versión de Redis, existen múltiples formatos de versiones de RDB. Existe el problema de que la versión anterior del servicio Redis no es compatible con. Nueva versión del formato RDB. Para resolver el problema de que RDB no es adecuado para la persistencia en tiempo real, Redis proporciona el método de persistencia AOF.

5.2 AOF

Persistencia de AOF (solo agregar archivo): registre cada comando escrito en un registro independiente y luego vuelva a ejecutar el comando en el archivo AOF durante el reinicio para lograr la recuperación de datos. . Objetivo.

La función principal de AOF es resolver el problema de la persistencia de datos en tiempo real y actualmente es el método principal de persistencia de Redis. Comprender y dominar el mecanismo de persistencia de AOF nos resulta muy útil para tener en cuenta la seguridad y el rendimiento de los datos.

5.2.1 Uso de AOF

Para habilitar la función AOF, debe establecer la configuración: appendonly sí, que no está habilitada de forma predeterminada. El nombre del archivo AOF se establece mediante la configuración appendfilename. El nombre de archivo predeterminado es appendonly.aof. La ruta para guardar es coherente con el método de persistencia RDB y se especifica mediante la configuración del directorio. Las operaciones de flujo de trabajo de AOF: escritura de comandos (agregar), sincronización de archivos (sincronización), reescritura de archivos (reescritura) y reinicio de carga (cargar), como se muestra en la Figura 5-2.

1) Todos los comandos de escritura se agregarán a aof_buf (búfer).

2) El búfer AOF realiza operaciones de sincronización con el disco duro de acuerdo con la política correspondiente.

3) A medida que los archivos AOF se vuelven cada vez más grandes, los archivos AOF deben reescribirse periódicamente para lograr la compresión.

4) Cuando se reinicia el servidor Redis, el archivo AOF se puede cargar para la recuperación de datos. Después de comprender el flujo de trabajo de AOF, cada paso se presentará en detalle a continuación.

5.2.2 Escritura de comandos

El contenido escrito por el comando AOF está directamente en formato de protocolo de texto. Por ejemplo, el comando set hello world agregará el siguiente texto al búfer AOF: *3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\ n

Consulte la sección 4.1 Protocolo de cliente para obtener una descripción detallada del formato del protocolo Redis. No entraré en detalles aquí

dos dudas sobre AOF:

1) ¿Por qué AOF utiliza directamente el formato de protocolo de texto? Las posibles razones son las siguientes:

·El protocolo de texto tiene buena compatibilidad.

·Después de activar AOF, todos los comandos de escritura incluyen operaciones de adición y utilizan directamente el formato de protocolo para evitar la sobrecarga del procesamiento secundario.

·El protocolo de texto es legible y fácil de modificar y procesar directamente.

2) ¿Por qué AOF agrega comandos a aof_buf? Redis usa un solo hilo para responder a los comandos. Si cada comando para escribir un archivo AOF se agrega directamente al disco duro, entonces el rendimiento depende completamente de la carga actual del disco duro. Escribir primero en el búfer aof_buf tiene otra ventaja. Redis puede proporcionar una variedad de estrategias de sincronización del búfer al disco duro para equilibrar el rendimiento y la seguridad.

5.2.3 Sincronización de archivos

Redis proporciona una variedad de estrategias de archivos de sincronización de búfer AOF, que están controladas por el parámetro appendfsync. Los significados de los diferentes valores se muestran en la Tabla 5. -1.

Tabla 5-1 Estrategia de archivo de sincronización del buffer AOF

Descripción de las llamadas al sistema write y fsync:

·La operación de escritura activará el mecanismo de escritura retrasada. Linux proporciona un búfer de páginas en el kernel para mejorar el rendimiento de E/S del disco duro. La operación de escritura regresa directamente después de escribir en el búfer del sistema. Las operaciones de disco síncronas dependen de mecanismos de programación del sistema, como el llenado del espacio de la página del búfer o el alcance de un período de tiempo específico. Antes de sincronizar archivos, si el sistema falla en este momento, los datos en el búfer se perderán.

·fsync realiza una sincronización forzada del disco duro para operaciones de un solo archivo (como archivos AOF) fsync se bloqueará hasta que se complete la escritura en el disco duro y regrese, asegurando la persistencia de los datos.

Además de escribir y fsync, Linux también proporciona operaciones de sincronización y fdatasync. Para obtener descripciones de API específicas, consulte: completo, esto puede ralentizar Redis

2) Cada vez que ocurre un evento de bloqueo de anexos AOF Cuando esto ocurre, el El indicador aof_delayed_fsync se acumulará en las estadísticas de persistencia de información. Marque este indicador para facilitar la localización del problema de bloqueo de AOF.

3) La sincronización de AOF permite hasta 2 segundos de retraso. Cuando ocurre el retraso, significa que el disco duro tiene un problema de carga alta. Puede utilizar herramientas de monitoreo como iotop para localizar el proceso que consume. los recursos de E/S del disco duro. La optimización del problema de bloqueo de anexos de AOF implica principalmente optimizar la carga del disco duro del sistema. Consulte la sección anterior para conocer el método de optimización.

5.4 Implementación de múltiples instancias

La arquitectura de un solo subproceso de Redis hace que sea imposible utilizar completamente las funciones de múltiples núcleos de la CPU. La práctica común es implementar múltiples instancias de Redis. en una máquina. Cuando varias instancias permiten la reescritura de AOF, se producirá competencia entre ellas por CPU e IO. Esta sección presenta principalmente el análisis y la optimización para este escenario. La sección anterior presentó la sobrecarga del subproceso relacionada con la persistencia. Para la implementación de múltiples Redis en una sola máquina, si se ejecutan varios procesos secundarios al mismo tiempo, el impacto en el sistema actual será muy obvio, por lo que se deben tomar medidas para aislar el trabajo de los procesos secundarios. Redis nos proporciona métricas para monitorear el estado de ejecución de procesos secundarios en info Persistence, como se muestra en la Tabla 5-2.

Según los indicadores anteriores, podemos controlar la ejecución de la operación de reescritura de AOF a través del sondeo del programa externo. Todo el proceso se muestra en la Figura 5-6.

Descripción del proceso:

1) El programa externo sondea y monitorea periódicamente todas las instancias de Redis en la máquina.

2) Para instancias con AOF habilitado, marque (aof_current_size-aof_base_size)/aof_base_size para confirmar la tasa de crecimiento.

3) Cuando la tasa de crecimiento excede un umbral específico (como 100), ejecute el comando bgrewriteaof para activar manualmente la reescritura AOF de la instancia actual.

4) Verifique los indicadores aof_rewrite_in_progress y aof_current_rewrite_time_sec cíclicamente durante la operación hasta que se complete la reescritura de AOF.

5) Después de confirmar que se completó la reescritura de AOF de la instancia, verifique otras instancias y repita los pasos 2) ~ 4). Esto garantiza la ejecución serializada de la reescritura de AOF para cada instancia de Redis en la máquina.

5.5 Puntos clave de este capítulo

1) Redis proporciona dos métodos de persistencia: RDB y AOF.

2) RDB utiliza una generación única de instantáneas de memoria y los archivos generados tienen una relación de compresión compacta más alta, por lo que la velocidad de recuperación de la lectura de RDB es más rápida. Debido a la alta sobrecarga de generar RDB cada vez, no se puede lograr la persistencia en tiempo real. Generalmente se usa para la copia de seguridad en frío y la transmisión de replicación.

3) El comando guardar bloqueará el hilo principal y no se recomienda su uso. El comando bgsave utiliza la operación fork para crear un subproceso para generar RDB y evitar el bloqueo.

4) AOF logra la persistencia agregando comandos de escritura a los archivos, y la persistencia en tiempo real/de segundo nivel se puede controlar a través del parámetro appendfsync. Debido a que los comandos de escritura deben agregarse continuamente, el tamaño del archivo AOF aumenta gradualmente y es necesario realizar operaciones de reescritura con regularidad para reducir el tamaño del archivo.

5) La reescritura de AOF se puede activar automáticamente controlando los parámetros auto-aof-rewrite-min-size y auto-aof-rewrite-percentage, o se puede activar manualmente usando el comando bgrewriteaof.

6) Durante la ejecución del proceso hijo, utilice el mecanismo de copia en escritura para compartir memoria con el proceso padre para evitar duplicar el consumo de memoria.

Durante la reescritura de AOF, también es necesario mantener un búfer de reescritura para guardar nuevos comandos de escritura y evitar la pérdida de datos.

7) Los escenarios de subprocesos principales de bloqueo de persistencia incluyen: bloqueo de bifurcación y bloqueo de anexos AOF. El tiempo de bloqueo de la bifurcación está relacionado con la cantidad de memoria y el bloqueo adicional de AOF indica que los recursos del disco duro son escasos.

8) Al implementar varias instancias en una sola máquina, para evitar que varios procesos secundarios realicen operaciones de reescritura, se recomienda implementar un control de aislamiento para evitar la competencia por los recursos de CPU y IO.