Configuración persistente AOF
# Ya sea para abrir un
anexo solo sí
# Nombre de archivo
appendfilename "appendonly.aof"
# Modo de sincronización
appendfsync everysec
# aof Si sincronizar durante la reescritura
no-appendfsync-on-rewrite no
# Configuración del disparador
de reescritura auto-aof-rewrite-percent 100
auto-aof-rewrite-min-size 64mb
# Qué hacer si hay un error al cargar aof
-load-truncated yes # yes significa que si hay un problema con el archivo de cola aof, escriba un registro y continúe la ejecución. no significa que se le solicite escribir y escribir después de esperar la reparación
# Estrategia de reescritura de archivos
aof-rewrite-incremental-fsync yes
-
Hay tres modos de sincronización appendfsync: en general, se adopta la configuración everysec , se hace una elección equilibrada en cuanto a datos y seguridad, y la pérdida de datos es de hasta 1 s.
-
always: sincroniza cada comando de escritura con aof inmediatamente, lo cual es lento pero seguro
-
everysec: sincroniza cada segundo, lo cual es un compromiso
-
no: Redis no maneja el procesamiento, es muy rápido, pero también es el menos seguro
-
-
La vista AOF de todo el proceso se puede dividir aproximadamente en dos pasos, el paso es escribir un comando en tiempo real (si está
appendfsync everysecconfigurado, hay una pérdida), el segundo paso es una reescritura del archivo aof.-
paso:
-
Comando write = "Append to aof_buf =" Sincronizar con un disco aof llamando a la función flushAppendOnlyFile a través del evento de tiempo
-
-
la razón:
-
La escritura en tiempo real en el disco traerá una E / S de disco muy alta, lo que afectará el rendimiento general
-
-
-
Análisis de la eficiencia y seguridad de la persistencia AOF
siempre: Cada ciclo de eventos escribe todo el contenido del búfer AOF_BUF en el archivo AOF y sincroniza el archivo AOF. Esta es la forma más segura, pero la operación del disco y el retraso de bloqueo son los gastos de IO.
everysec: sincroniza una vez por segundo, el rendimiento y la seguridad son relativamente moderados, y también es el método recomendado por redis. Si encuentra una falla en el servidor físico, puede hacer que el registro AOF se pierda en el último segundo (puede ser una pérdida parcial).
no: Redis no llama directamente a la sincronización de archivos, sino que la entrega al sistema operativo para su procesamiento. El sistema operativo puede activar la sincronización de acuerdo con las condiciones de llenado del búfer / tiempo de inactividad del canal, etc .; este es un método común de operación de archivos. El rendimiento es mejor Cuando el servidor físico falla, la cantidad de datos perdidos estará relacionada con la configuración del sistema operativo. La llamada flushAppendOnlyFile en ningún modo no necesita realizar operaciones de sincronización