Los datos de Redis están todos en la memoria. Si hay un tiempo de inactividad repentino, se perderán todos los datos. Por lo tanto, debe haber un mecanismo para garantizar que los datos de Redis no se pierdan debido a fallas. Este mecanismo es el mecanismo de persistencia de Redis. El estado de la base de datos se guarda en el disco.
Redis tiene dos métodos de persistencia: instantáneas (archivos RDB) y archivos adjuntos (archivos AOF)
RDB (Redis DataBase)
¿Qué es?
Todas las instantáneas de conjuntos de datos en la memoria se escriben en el disco dentro de un intervalo de tiempo específico, que también se denomina Instantánea en la jerga. Realiza instantáneas completas. Cuando se restaura, lee los archivos de instantáneas directamente en la memoria.
Esto es similar a una foto. Cuando tomas una foto, una foto puede recordar completamente la imagen en el momento de la foto.
Redis creará (bifurcará) un proceso secundario para la persistencia. Primero escribirá los datos en un archivo temporal. Una vez finalizado el proceso de persistencia, el archivo temporal se utilizará para reemplazar el último archivo persistente. Durante todo el proceso, el proceso principal no realiza ninguna operación de E / S, lo que garantiza un rendimiento extremadamente alto. Si se requiere una recuperación de datos a gran escala y la integridad de la recuperación de datos no es muy sensible, el método RDB es más eficiente.
La desventaja de RDB es que los datos posteriores a la última persistencia pueden perderse.
¿No es Redis un solo proceso?
Redis utiliza el mecanismo COW (Copy On Write) multiproceso del sistema operativo para lograr la persistencia de instantáneas (las operaciones de escritura se procesan normalmente mientras se realizan instantáneas), la bifurcación se crea en sistemas operativos similares a Unix. método principal del proceso. COW (Copy On Write) es una estrategia de optimización utilizada en programación de computadoras.
La función de la bifurcación es copiar un proceso que es el mismo que el proceso actual. Los valores de todos los datos (variables, variables de entorno, contadores de programa, etc.) del nuevo proceso son los mismos que los del proceso original, pero es un proceso completamente nuevo y es un proceso hijo del proceso original. El proceso hijo lee los datos y luego los serializa en el disco.
Configuración
Ubicación de configuración: SNAPSHOTTING
redis-snapshotting
rdb guarda el archivo dump.rdb de forma predeterminada, de la siguiente manera (ilegible)
redis-rdb-file
Puede configurar Redis para que guarde automáticamente el conjunto de datos una vez que se cumpla la condición de "al menos M cambios en el conjunto de datos en N segundos".
Por ejemplo, las siguientes configuraciones permitirán a Redis guardar automáticamente el conjunto de datos una vez cuando se cumpla la condición "al menos 1000 claves han sido cambiadas en 60 segundos":
guardar 60 1000
activa instantáneas RDB
además del archivo de configuración, activa automáticamente la Generación instantánea, también puede usar el comando para activar manualmente el
guardado: solo guarde cuando guarde. La ejecución en el hilo principal causará bloqueo, así que utilícelo con precaución;
bgsave: se puede entender como guardado en segundo plano. Cuando el comando bgsave se ejecuta, redis sacará un hijo El proceso se usa especialmente para escribir archivos RDB para evitar el bloqueo del hilo principal Esta es también la configuración predeterminada generada por los archivos RDB de Redis. Puede usar el comando lastsave para obtener la hora de la última ejecución exitosa de la instantánea. La
ejecución del comando fluxhall también generará el archivo dump.rdb, pero está vacío y sin sentido. Cuando el
cliente ejecuta shutdown y cierra redis, la instantánea En
resumen, bgsave sub El proceso es generado por la bifurcación del hilo principal y puede compartir todos los datos de la memoria del hilo principal. Después de que se ejecuta el proceso hijo de bgsave, comienza a leer los datos de la memoria del hilo principal y los escribe en el archivo RDB. En este momento, si el hilo principal también lee estos datos (por ejemplo, el par clave-valor K1 en la figura), entonces el hilo principal y el proceso hijo bgsave no se afectan entre sí. Sin embargo, si el hilo principal desea modificar un dato (por ejemplo, el par clave-valor K3 en la figura), este dato se copiará para generar una copia de los datos. Luego, el proceso hijo de bgsave escribirá esta copia de los datos en el archivo RDB y, en este proceso, el hilo principal aún puede modificar directamente los datos originales.
Cómo funciona la
instantánea redis-bgsave
Cuando Redis necesita guardar el archivo dump.rdb, el servidor realiza las siguientes operaciones:
Redis llama a fork () para generar un proceso secundario, y en este momento tiene un proceso principal y un proceso secundario .
El proceso padre continúa procesando las solicitudes del cliente y el proceso hijo es responsable de escribir el contenido de la memoria en un archivo temporal. Debido al mecanismo de copia en escritura del sistema operativo, los procesos padre e hijo compartirán la misma página física. Cuando el proceso padre procesa una solicitud de escritura, el sistema operativo creará una copia de la página para ser modificada por el proceso padre en lugar de escribir la página compartida. Por lo tanto, los datos en el espacio de direcciones del proceso hijo son una instantánea de toda la base de datos en el momento de la bifurcación.
Cuando el proceso secundario termina de escribir el nuevo archivo RDB, Redis reemplaza el archivo RDB original con el nuevo archivo RDB y elimina el archivo RDB anterior.
Esta forma de trabajo permite a Redis beneficiarse del mecanismo de copia en escritura.
Cómo restaurar:
Mueva el archivo de respaldo (dump.rdb) al directorio de instalación de Redis e inicie el servicio (CONFIG GET dir obtiene el directorio)
Ventajas de redis-rdb-bak
Una vez que se adopte este método, toda su base de datos de Redis solo contendrá un archivo, que es perfecto para la copia de seguridad de archivos. Por ejemplo, puede planear archivar las últimas 24 horas de datos una vez cada hora, y también desea archivar los últimos 30 días de datos una vez al día. A través de una estrategia de respaldo de este tipo, una vez que el sistema tiene una falla catastrófica, podemos recuperarnos muy fácilmente. Adecuado para la recuperación de datos a gran escala
Para la recuperación de desastres, RDB es una muy buena opción. Porque podemos comprimir fácilmente un solo archivo y luego transferirlo a otros medios de almacenamiento.
Maximice el rendimiento. Para el proceso de servicio de Redis, cuando comienza a persistir, lo único que debe hacer es bifurcar el proceso hijo, y luego el proceso hijo completará el trabajo de persistencia, lo que puede evitar en gran medida que el proceso de servicio realice operaciones IO.
Desventajas
Si desea garantizar una alta disponibilidad de datos, es decir, evitar la pérdida de datos al máximo, RDB no es una buena opción. Porque una vez que el sistema está inactivo antes de la persistencia temporizada, los datos que no han tenido tiempo de escribir en el disco antes se perderán (se perderán todos los cambios posteriores a la última instantánea).
Dado que RDB ayuda a completar la persistencia de datos a través del subproceso de la bifurcación, los datos en la memoria se clonan y se debe considerar aproximadamente 2 veces la expansión. Por lo tanto, si el conjunto de datos es grande, puede causar que todo el servidor Detenga el servicio durante unos cientos de milisegundos o incluso 1 segundo.
Quizás tengas la misma pregunta que yo. De todos modos, no se bloquea. Si tomo una instantánea cada segundo, ¿no puedo evitar la pérdida de datos en la mayor medida posible?
Por un lado, escribir con frecuencia la cantidad total de datos en el disco ejercerá mucha presión sobre el disco. Varias instantáneas compiten por un ancho de banda limitado del disco. La instantánea anterior no se ha completado y la última se inicia de nuevo, lo que puede causar fácilmente un círculo vicioso.
Por otro lado, el proceso hijo bgsave debe crearse a partir del subproceso principal mediante una operación de bifurcación. Aunque el proceso hijo no bloqueará el subproceso principal después de su creación, el proceso de creación de la bifurcación bloqueará el subproceso principal y cuanto mayor sea la memoria del subproceso principal, mayor será el tiempo de bloqueo. Si desembolsa con frecuencia el proceso secundario de bgsave, esto bloqueará con frecuencia el hilo principal.
Cómo detener
El método para detener dinámicamente las reglas de guardado de RDB: redis-cli config set save "", o modifique el archivo de configuración y reinicie.
Pequeño resumen
redis-rdb-summary
RDB es un archivo
RDB muy compacto . Lo único que debe hacer el proceso padre al guardar el archivo RDB es bifurcar un proceso hijo. El siguiente trabajo lo realiza el proceso hijo, y el proceso padre no necesita realizar otras operaciones de E / S. Por lo tanto, el método de persistencia RDB puede maximizar el rendimiento de Redis. El
riesgo de pérdida de datos es alto.
RDB necesita bifurcar el subproceso para guardar el conjunto de datos en el disco duro. Cuando el conjunto de datos es relativamente grande, el proceso de bifurcación consume mucho tiempo y puede hacer que Redis no pueda responder a la solicitud del cliente
AOF (Append Only File) en algunos milisegundos
¿Qué es
registrar cada operación de escritura en forma de registro? Registre todas las instrucciones de escritura que Redis ha realizado (las operaciones de lectura no se registran), solo agregue archivos pero no reescriba archivos. Redis leerá los archivos al comienzo de la La construcción de los datos, es decir, la "reproducción". En otras palabras, cuando Redis se reinicia, ejecutará el comando de escritura de adelante hacia atrás de acuerdo con el contenido del archivo de registro para completar el trabajo de recuperación de datos.
Configurar
AOF El archivo predeterminado para guardar es ** appendonly.aof **
Ubicación de configuración del archivo : APPEND ONLY MODE
redis-aof-conf
Inicio / reparación / recuperación de AOF Recuperación
normal
Inicio: modifique el anexo predeterminado solo no, cámbielo a sí,
copie y guarde el archivo aof con los datos en el directorio correspondiente (config get dir)
Recuperación: reinicie redis y luego vuelva a cargar la
excepción
Inicio de recuperación : modifique el adjunto predeterminado solo no, cámbielo a sí para hacer una
copia de seguridad del archivo AOF incorrecto.
Reparación: redis-check-aof --fix para reparar + archivo AOF.
Recuperación: reinicie redis y luego vuelva a cargar el
registro AOF. ¿Cómo se logra?
Hablando de registros, con lo que estamos más familiarizados es con el Write Ahead Log (WAL) de la base de datos, es decir, antes de escribir los datos, los datos modificados se registran en el archivo de registro para su recuperación en caso de falla (DBA We diga "iniciar sesión primero").
Sin embargo, el registro AOF es todo lo contrario. Es un registro posterior a la escritura. "Posterior a la escritura" significa que Redis ejecuta el comando primero, escribe los datos en la memoria y luego registra el registro, como se muestra en la siguiente figura :
redis-aof-write-log
Consejo: La primera forma de registro, si la máquina deja de funcionar , también puede restaurar el estado de datos anterior a través del registro previamente guardado. Sin embargo, si el registro se escribe después de AOF, ¿se perderán los datos escritos en la memoria si la máquina deja de funcionar?
Entonces, ¿por qué AOF necesita ejecutar el comando primero y luego iniciar sesión? Para responder a esta pregunta, primero debemos saber qué está registrado en el AOF.
Los registros de bases de datos tradicionales, como el registro de rehacer (registro de rehacer), registran los datos modificados, mientras que AOF registra cada comando recibido por Redis, que se guarda en forma de texto.
Tomemos el registro registrado después de que Redis recibió el comando "set k1 v1" como ejemplo para ver el contenido del registro AOF. Entre ellos, "* 2" significa que el comando actual tiene dos partes, cada parte comienza con "$ + número", seguido de un comando, clave o valor específico. Aquí, "número" indica cuántos bytes hay en el comando, clave o valor en esta parte.
Por ejemplo, * 2 significa que hay dos partes, $ 6 significa 6 bytes, que es el comando "SELECT" a continuación, y $ 1 significa 1 byte, que es el comando "0" a continuación, que en conjunto es SELECT 0, seleccione 0 Library. Las instrucciones a continuación son las mismas, por lo que puede comprender muy bien SET K1 V1.
redis-aof-file
Sin embargo, para evitar una sobrecarga de verificación adicional, Redis no verificará primero la sintaxis de estos comandos cuando inicie sesión en AOF. Por lo tanto, si inicia sesión primero y luego ejecuta el comando, es posible que se registre el comando incorrecto en el registro y Redis puede cometer un error al usar el registro para restaurar datos. El método de registro posterior a la escritura es dejar que el sistema ejecute el comando primero. Solo cuando el comando se pueda ejecutar correctamente, se registrará en el registro. De lo contrario, el sistema informará un error directamente al cliente. Por lo tanto, una de las principales ventajas de Redis al utilizar el método de registro posterior a la escritura es que puede evitar la situación de registrar comandos incorrectos. Además, AOF tiene otra ventaja: registra el registro después de que se ejecuta el comando, por lo que no bloqueará la operación de escritura actual.
Sin embargo, AOF también tiene dos riesgos potenciales.
En primer lugar, si se acaba de ejecutar un comando y se bloquea antes de que tenga tiempo de registrarse, entonces este comando y los datos correspondientes corren el riesgo de perderse. Si Redis se usa como caché en este momento, también puede volver a leer los datos de la base de datos back-end para la recuperación. Sin embargo, si Redis se usa directamente como una base de datos, en este momento, porque el comando no está registrado en el log, el registro no se puede utilizar para la recuperación.
En segundo lugar, aunque AOF evita el bloqueo del comando actual, puede traer el riesgo de bloqueo a la siguiente operación. Esto se debe a que el registro AOF también se ejecuta en el subproceso principal. Si la presión de escritura del disco es alta cuando el archivo de registro se escribe en el disco, la escritura en el disco será lenta y las operaciones posteriores no se pueden ejecutar.
Si analiza detenidamente, encontrará que estos dos riesgos están relacionados con el momento en que AOF vuelve a escribir en el disco. Esto también significa que si podemos controlar el momento en que el registro AOF se vuelve a escribir en el disco después de que se ejecuta un comando de escritura, estos dos riesgos se eliminarán.
A continuación, veamos la estrategia de reescritura proporcionada por Redis o la durabilidad de AOF.
Tres estrategias de escritura diferida | Durabilidad de AOF
Puede configurar la frecuencia con la que Redis sincronizará los datos en el disco. El mecanismo AOF nos brinda tres opciones:
appendfsync siempre, escritura sincrónica: después de que se ejecuta cada comando de escritura, el registro se vuelve a escribir en el disco sincrónicamente;
appendfsync everysec, se escribe cada segundo: después de que se ejecuta cada comando de escritura, el registro se escribe en el búfer de memoria del archivo AOF primero, el contenido del búfer se escribe en el disco cada segundo,
pero cuando la llamada fsync dura más de 1 segundo. Redis adoptará una estrategia para retrasar fsync y esperar otro segundo. Es decir, fsync se realizará después de dos segundos, esta vez fsync se realizará sin importar cuánto tiempo se ejecute. En este momento, debido a que el descriptor de archivo se bloqueará durante fsync, se bloqueará la operación de escritura actual.
appendfsync no, escritura controlada por el sistema operativo: después de que se ejecuta cada comando de escritura, el registro se escribe primero en el búfer de memoria del archivo AOF y el sistema operativo decide cuándo volver a escribir el contenido del búfer en el disco. Para la mayoría de los sistemas operativos Linux, fsync se realiza cada 30 segundos para escribir los datos del búfer en el disco.
Para evitar el bloqueo del hilo principal y reducir la pérdida de datos, estas tres estrategias de escritura diferida no pueden lograr lo mejor de ambos mundos. Analicemos las razones.
"Escritura sincrónica" básicamente no puede perder datos, pero tiene una operación de caída de disco lenta después de cada comando de escritura, lo que inevitablemente afectará el rendimiento del subproceso principal;
aunque "escritura controlada por el sistema operativo" Después de escribir el búfer, usted puede continuar ejecutando comandos posteriores, pero el tiempo de caída del disco ya no está en manos de Redis. Mientras el registro AOF no se vuelva a escribir en el disco, los datos correspondientes al tiempo de inactividad se perderán;
"Reescribir cada segundo ". La frecuencia de reescritura una vez por segundo evita la sobrecarga de rendimiento de la" reescritura sincrónica ". Aunque reduce el impacto en el rendimiento del sistema, si se produce un tiempo de inactividad, las operaciones de comando que no se han colocado en el último el segundo todavía se perderá. Por lo tanto, esto solo puede considerarse como un compromiso entre evitar el rendimiento del hilo principal y evitar la pérdida de datos.
Ventajas y desventajas del tiempo de escritura diferida de elementos de configuración
La escritura diferida siempre sincronizada tiene una alta fiabilidad, básicamente sin pérdida de datos. Cada comando de escritura debe
colocarse en el disco. El impacto en el rendimiento es mayor, pero es lento pero seguro. Everysec escribe cada segundo con un rendimiento moderado. Los datos se pierden en 1 segundo cuando hay tiempo de inactividad
Sin control del sistema operativo El rendimiento de escritura diferida es bueno y hay más pérdida de datos cuando hay tiempo de inactividad
Aquí, podemos elegir qué estrategia de escritura diferida usar de acuerdo con los requisitos del sistema para un alto rendimiento y alta confiabilidad.
En resumen: si desea un alto rendimiento, elija la estrategia No; si desea una garantía de alta confiabilidad, elija la estrategia Siempre; si permite una pequeña pérdida de datos y espera que el rendimiento no se vea demasiado afectado, elija Everysec Estrategia.
Sugerencia: Imagínese, si activamos AOF y lo ejecutamos durante un año o medio, el archivo AOF se hará cada vez más grande, y mucho menos el problema de ocupación de recursos, si la máquina se reinicia, debe ser especial rehacer los datos. con el archivo AOF. Un proceso largo, por lo que Redis proporciona un mecanismo de "adelgazamiento" para los archivos AOF.
Qué es la reescritura (reescritura de AOF)
: AOF adopta el método de adición de archivos, y el archivo se agrandará cada vez más. Para evitar esta situación, se ha agregado un nuevo mecanismo de reescritura. Cuando el tamaño del archivo AOF excede el umbral establecido, Redis Se iniciará la compresión de contenido del archivo AOF, y solo se conservará el conjunto mínimo de instrucciones que pueden restaurar los datos. Se puede usar el comando bgrewriteaof. Esta operación es equivalente a "adelgazar" el archivo AOF. Al reescribir, se genera el comando de escritura correspondiente de acuerdo con el último estado actual de este par clave-valor. De esta manera, un par clave-valor se puede escribir con un solo comando en el registro de reescritura Además, cuando se restaura el registro, el par clave-valor se puede escribir directamente ejecutando este comando solamente.
El
principio de reescritura de pérdida de peso : cuando el archivo AOF continúa creciendo y se vuelve demasiado grande, un nuevo proceso se bifurcará para reescribir el archivo (también escriba el archivo temporal primero y luego cambie el nombre), recorra los datos en la memoria del nuevo proceso y convertirlo en una instrucción de operación y luego serializarlo en un nuevo archivo AOF.
PD: La operación de reescritura del archivo AOF no lee el archivo AOF antiguo, sino que reescribe un nuevo archivo AOF con comandos del contenido de la base de datos en toda la memoria, que es similar a una instantánea.
Mecanismo de activación: Redis registrará el tamaño de AOF durante la última reescritura. La configuración predeterminada se activa cuando el tamaño del archivo AOF es el doble del tamaño después de la última reescritura y el archivo es mayor de 64 M. Ingresamos
set k1 v1 dos veces en el cliente y luego compare el archivo appendonly.aof antes y después de bgrewriteaof (primero desactive la persistencia híbrida)
bgrewriteaof
¿Qué debo hacer si hay un error en el archivo AOF?
Es posible que el servidor se apague mientras el programa escribe en el archivo AOF. Si el apagado provoca la corrupción de un archivo AOF, Redis se negará a cargar el archivo AOF cuando se reinicie, a fin de garantizar que la coherencia de los datos no se dañe. .
Cuando esto sucede, puede utilizar los siguientes métodos para reparar el archivo AOF incorrecto:
Cree una copia de seguridad del archivo AOF existente.
Utilice el programa redis-check-aof adjunto a Redis para reparar el archivo AOF original.
$ redis-check-aof --fix
(opcional) Utilice diff -u para comparar la copia de seguridad del archivo AOF reparado y el archivo AOF original para ver las diferencias entre los dos archivos.
Reinicie el servidor Redis, espere a que el servidor cargue el archivo AOF reparado y realice la recuperación de datos.
Cómo funciona AOF | Reescritura en segundo plano La reescritura de
AOF es lo mismo que RDB creando una instantánea, ambos usando ingeniosamente el mecanismo de copia sobre escritura.
Sin embargo, hay un problema que debe resolverse cuando se utilizan subprocesos: debido a que el subproceso está realizando la reescritura AOF, el proceso principal aún necesita continuar procesando comandos, y los nuevos comandos pueden modificar los datos existentes, lo que hará que los datos de la base de datos actual y Los datos del archivo AOF reescrito son incoherentes.
Para resolver este problema, Redis ha agregado un caché de reescritura AOF. Este caché se habilita después de que el proceso secundario se bifurca. Después de recibir un nuevo comando de escritura, el proceso principal de Redis agregará el contenido del protocolo del comando de escritura al existente. al archivo AOF, también se agregará a este caché: los
siguientes son los pasos de ejecución de la reescritura de AOF:
Redis ejecuta fork () y ahora tiene un proceso padre y un proceso hijo.
El proceso hijo comienza a escribir el contenido del nuevo archivo AOF en un archivo temporal.
Para todos los comandos de escritura recién ejecutados, el proceso principal los acumula en una memoria caché mientras agrega estos cambios al final del archivo AOF existente: de modo que incluso si hay un tiempo de inactividad en el medio de la reescritura, el archivo AOF existente sigue siendo Aún a salvo.
Cuando el proceso hijo completa el trabajo de reescritura, envía una señal al proceso padre. Después de recibir la señal, el proceso padre agrega todos los datos en la memoria caché al final del nuevo archivo AOF.
¡Hazlo! Ahora Redis reemplaza atómicamente el archivo antiguo con el nuevo archivo, y todos los comandos posteriores se añaden directamente al final del nuevo archivo AOF.
Redis-AOF-reescritura trabajo
ventaja
Este mecanismo puede aportar mayor seguridad de los datos, es decir, la persistencia de datos. En Redis se proporcionan tres estrategias de sincronización, a saber, sincronización por segundo, sincronización por modificación y no sincronización. De hecho, la sincronización por segundo también se completa de forma asincrónica, y su eficiencia también es muy alta, la diferencia es que una vez que el sistema deja de funcionar, los datos modificados en un segundo se perderán. Y cada vez que se modifica la sincronización, podemos considerarla como persistencia de sincronización, es decir, cada cambio de datos que se produzca se grabará inmediatamente en el disco. Se puede predecir que este método es el más bajo en eficiencia. En cuanto a la falta de sincronización, no es necesario decir más, creo que todos pueden entenderlo correctamente.
Debido a que este mecanismo utiliza el modo de adición para la operación de escritura del archivo de registro, incluso si hay un tiempo de inactividad durante el proceso de escritura, no dañará el contenido existente en el archivo de registro. Sin embargo, si solo escribimos la mitad de los datos en esta operación, el sistema se bloquea, no se preocupe, podemos usar la herramienta redis-check-aof para ayudarnos a resolver el problema de la coherencia de los datos antes de que se inicie Redis la próxima vez.
Si el registro es demasiado grande, Redis puede habilitar automáticamente el mecanismo de reescritura. Es decir, Redis escribe continuamente los datos modificados en el archivo de disco antiguo en el modo anexar y, al mismo tiempo, Redis también creará un nuevo archivo para registrar qué comandos de modificación se han ejecutado durante este período. Por lo tanto, la seguridad de los datos se puede garantizar mejor durante la conmutación de reescritura.
AOF contiene un archivo de registro claramente formateado y fácil de entender para registrar todas las operaciones de modificación. De hecho, también podemos completar la reconstrucción de datos a través de este archivo. Por lo tanto, el contenido del archivo AOF es muy fácil de entender por las personas y es fácil analizar el archivo (parse). Exportar archivos AOF también es muy simple: por ejemplo, si ejecuta accidentalmente el comando FLUSHALL, pero siempre que el archivo AOF no se vuelva a escribir, simplemente detenga el servidor, elimine el comando FLUSHALL al final del archivo AOF y reinicie Redis , Puede restaurar el conjunto de datos al estado anterior a la ejecución de FLUSHALL.
Desventaja
Para el mismo número de conjuntos de datos, el archivo AOF suele ser más grande que el archivo RDB. La velocidad de recuperación es más lenta que rdb.
Según diferentes estrategias de sincronización, AOF tiende a ser más lento que RDB en términos de eficiencia operativa. En resumen, la eficiencia de la estrategia de sincronización por segundo es relativamente alta y la eficiencia de la estrategia de desactivación de la sincronización es tan eficiente como RDB.
para resumir
El archivo AOF redis-aof-summary
es un archivo de registro que solo debe adjuntarse.
Redis puede reescribir automáticamente
AOF en segundo plano cuando el tamaño del archivo AOF es demasiado grande. El archivo AOF guarda todas las operaciones de escritura en la base de datos de forma ordenada Estas operaciones de escritura se guardan en el formato del protocolo Redis, por lo que el contenido del archivo AOF es muy fácil de leer por las personas y es fácil analizar el archivo.
Para el mismo conjunto de datos, el volumen del El archivo AOF generalmente debe ser mayor que el volumen del archivo RDB
Según la estrategia fsync utilizada, la velocidad de AOF puede ser más lenta que la de RDB.
Cómo cambiar de persistencia RDB a persistencia AOF
En Redis 2.2 o superior, puede cambiar de RDB a AOF sin reiniciar:
el último volcado Cree una copia de seguridad del archivo .rdb.
Guarde la copia de seguridad en un lugar seguro.
Ejecute los siguientes dos comandos:
redis-cli> CONFIG SET appendonly yes
redis-cli> CONFIG SET save "" para
garantizar que el número de claves en la base de datos no haya cambiado después de que se ejecute el comando.
Asegúrese de que el comando de escritura se adjunte correctamente al final del archivo AOF.
El primer comando ejecutado en el paso 3 activa la función AOF: Redis se bloqueará hasta que se complete la creación del archivo AOF inicial, y luego Redis continuará procesando la solicitud del comando y comenzará a agregar el comando de escritura al final del archivo AOF. .
El segundo comando ejecutado en el paso 3 se utiliza para desactivar la función RDB. Este paso es opcional. Si lo desea, también puede utilizar las funciones de persistencia RDB y AOF al mismo tiempo.
¡No olvide habilitar la función AOF en redis.conf! De lo contrario, después de reiniciar el servidor, se olvidará la configuración establecida previamente por CONFIG SET y el programa iniciará el servidor de acuerdo con la configuración original.
Cuál
El método de persistencia RDB puede tomar instantáneas de sus datos en un intervalo de tiempo específico. La
persistencia AOF registra cada operación de escritura en el servidor. Cuando el servidor se reinicia, estos comandos se ejecutarán nuevamente para restaurar los datos originales. El comando AOF es El protocolo Redis agrega y guarda cada operación de escritura al final del archivo. Redis también puede reescribir el archivo AOF en segundo plano (bgrewriteaof), de modo que el volumen del archivo AOF no sea demasiado grande,
solo para el almacenamiento en caché: si solo desea que sus datos existan cuando el servidor se está ejecutando, tampoco puede usar cualquier método de persistencia.
Active ambos métodos de persistencia
al mismo tiempo. En este caso, cuando Redis se reinicia, el archivo AOF se cargará primero para restaurar los datos originales, porque en circunstancias normales el conjunto de datos guardado por el archivo AOF es mayor que el conjunto de datos guardado por el archivo RDB completo.
Los datos de RDB no son en tiempo real y el servidor se reinicia solo para encontrar el archivo AOF cuando se usan ambos al mismo tiempo. ¿Debería usar AOF? No se recomienda, porque RDB es más adecuado para realizar copias de seguridad de la base de datos (AOF no es bueno para realizar copias de seguridad cuando se cambia constantemente), reinicio rápido y no habrá errores potenciales de AOF, manténgalo por si acaso.
Recomendaciones de rendimiento
Debido a que los archivos RDB solo se utilizan con fines de copia de seguridad, se recomienda conservar solo los archivos RDB en el esclavo y solo necesita una copia de seguridad de 15 minutos. La regla es guardar solo 900 1.
Si Enalbe AOF, la ventaja es que en el peor de los casos, solo perderá no más de dos segundos de datos.El script de inicio es más simple y solo carga su propio archivo AOF. El primer costo es el IO continuo, y el segundo es que el bloqueo causado por los nuevos datos generados en el proceso de reescritura se escribe en el nuevo archivo al final de la reescritura AOF es casi inevitable. Siempre que el disco duro tenga licencia, la frecuencia de reescritura de AOF debe minimizarse. El valor predeterminado de 64M para la reescritura de AOF es demasiado pequeño y se puede establecer en más de 5G. El tamaño predeterminado es un 100% más grande que el tamaño original. La reescritura se puede cambiar a un valor apropiado.
Si no habilita AOF, puede confiar en la replicación maestro-esclavo para lograr una alta disponibilidad. Se puede ahorrar una gran cantidad de E / S y también se reducen las fluctuaciones del sistema causadas por la reescritura. El precio es que si el Master / Slave se cae al mismo tiempo, se perderán más de diez minutos de datos. El script de inicio también debe comparar los archivos RDB en los dos Master / Slave y cargar el más nuevo.
Redis 4.0 Hybrid Persistence
Redis 4.0 propone un método para mezclar registros AOF e instantáneas de memoria. En pocas palabras, las instantáneas de la memoria se ejecutan con una frecuencia determinada. Entre dos instantáneas, los registros AOF se utilizan para registrar todas las operaciones de comando durante este período. Es decir, el contenido del archivo RDB y el archivo de registro AOF incremental se almacenan juntos. El registro AOF aquí ya no es un registro completo, sino un registro AOF incremental que se produjo durante el período desde el comienzo de la persistencia hasta el final de la persistencia.
De manera similar, ejecutamos set k1 v1 3 veces, y luego reducimos manualmente bgrewriteaof, y luego verificamos el archivo appendonly.aof:
La ventaja de redis-mix-persistence-file es
que puede combinar las ventajas de rdb y aof, carga rápida y evitar perder demasiados datos. La desventaja es que la parte rdb en aof es que el formato comprimido ya no es aof. y la legibilidad es deficiente.
De esta forma, las instantáneas no se ejecutan con mucha frecuencia, lo que evita el impacto de bifurcaciones frecuentes en el hilo principal. Además, el log AOF solo registra las operaciones entre dos instantáneas, es decir, no es necesario registrar todas las operaciones, por lo que el tamaño del archivo no será demasiado grande y se evitará la sobrecarga de reescritura.
La función de persistencia híbrida de la versión 4.0 está desactivada por defecto, y podemos controlar la habilitación de esta función a través del parámetro de configuración aof-use-rdb-preámbulo. Está activado de forma predeterminada después de la versión 5.0.
Como se muestra en la figura siguiente, la modificación en el medio de las dos instantáneas se registra con el registro AOF. Cuando se toma la instantánea completa por segunda vez, el registro AOF se puede borrar, porque la modificación en este momento se ha registrado en la instantánea y no se restaurará cuando se recupere.
imagen
El método redis-mix-persistence
no solo puede disfrutar de los beneficios de la recuperación rápida de archivos RDB, sino que también disfruta de la ventaja simple de AOF que solo registra los comandos de operación, lo que significa que "puede tener tanto peces como patas de oso".