1. Estrategia de configuración persistente de nivel empresarial
En la empresa, la estrategia de generación de RDB es casi la misma que la predeterminada
guardar 60 10000: si desea asegurarse de que el RDB pierda hasta 1 minuto de datos tanto como sea posible, intente generar una instantánea cada 1 minuto. Durante el período de pico bajo, la cantidad de datos es pequeña e innecesaria
10000-> Generar RDB, 1000-> RDB, de acuerdo con su propia aplicación y datos comerciales, usted decide por usted mismo
AOF debe estar encendido, fsync, cada segundo
auto-aof-rewrite-percent 100: el tamaño actual de AOF se ha incrementado a más del 100% de la última vez, el doble de la última vez
auto-aof-rewrite-min-size 64mb: según su volumen de datos, 16mb, 32mb
2. Solución de respaldo de datos a nivel empresarial
RDB es muy adecuado para copias de seguridad en frío, después de cada generación, no habrá modificaciones
Solución de respaldo de datos
(1) Escriba un script de programación programada crontab para hacer una copia de seguridad de datos
(2) Copie una copia de seguridad RDB cada hora, vaya a un directorio y solo guarde las últimas 48 horas de la copia de seguridad
(3) Mantenga una copia de la RDB del día todos los días Copia de seguridad, vaya a un directorio, solo guarde la copia de seguridad del mes más reciente
(4) Cada vez que copie la copia de seguridad, elimine la copia de seguridad anterior
(5) Haga una copia de seguridad y envíe todos los datos en el servidor actual todas las noches Ir a un servicio remoto en la nube
/ usr / local / redis
Copie cada hora para hacer una copia de seguridad, elimine los datos hace 48 horas
crontab -e
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
redis_rdb_copy_hourly.sh
#! / bin / sh cur_date = `date +% Y% m% d% k` rm -rf / usr / local / redis / snapshotting / $ cur_date mkdir / usr / local / redis / snapshotting / $ cur_date cp / var / redis / 6379 / dump.rdb / usr / local / redis / snapshotting / $ cur_date del_date = `date -d -48hour +% Y% m% d% k` rm -rf / usr / local / redis / snapshotting / $ del_date
Copia una vez al día
crontab -e
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh
redis_rdb_copy_daily.sh
#! / bin / sh cur_date = `date +% Y% m% d` rm -rf / usr / local / redis / snapshotting / $ cur_date mkdir / usr / local / redis / snapshotting / $ cur_date cp / var / redis / 6379 / dump.rdb / usr / local / redis / snapshotting / $ cur_date del_date = `date -d -1month +% Y% m% d` rm -rf / usr / local / redis / snapshotting / $ del_date
Cargue todos los datos en un servidor remoto en la nube una vez al día
3. Plan de recuperación de datos.
(1) Si el proceso de redis se bloquea, reinicie el proceso de redis, restaure directamente los datos en función del archivo de registro AOF
No más demostración, en la parte de recuperación de datos AOF, demostración, fsync everysec, como máximo se pierde un segundo
(2) Si la máquina donde se encuentra el proceso de redis se cuelga, luego de reiniciar la máquina, intente reiniciar el proceso de redis e intente realizar la recuperación de datos directamente en función del archivo de registro AOF
AOF no está dañado y también se puede recuperar directamente en función de AOF
AOF de solo agregado, escriba secuencialmente, si el archivo AOF está dañado, luego use la solución redis-check-aof
(3) Si los últimos archivos AOF y RDB en redis se pierden / corrompen, puede intentar restaurar los datos basándose en una copia de los últimos datos RDB actualmente en la máquina
Los últimos archivos AOF y RDB actuales se han perdido / dañado para que no se puedan recuperar, generalmente no se trata de un mal funcionamiento de la máquina, hecho por el hombre
Big data system, hadoop, algunas personas colocan accidentalmente el directorio correspondiente a una gran cantidad de archivos de datos almacenados en hadoop, rm -rf, una pequeña compañía de mis amigos, la operación y el mantenimiento no son confiables y los permisos no son muy buenos.
Los archivos bajo / var / redis / 6379 han sido eliminados
Encuentre la última copia de seguridad RDB. La copia de seguridad a nivel de hora está bien. La copia de seguridad a nivel de hora debe ser la última. Copie a redis y puede restaurar a una hora de datos
Simulacro de recuperación ante desastres
appendonly.aof + dump.rdb, prefiera appendonly.aof para recuperar datos, pero descubrimos que appendonly.aof generado automáticamente por redis no tiene datos
Entonces nuestro propio dump.rdb tiene datos, pero obviamente nuestros datos no se usan
Cuando se inicia redis, se vuelve a basar automáticamente en los datos en la memoria y genera una última instantánea de RDB, directamente usando los datos vacíos, sobrescribiendo los datos que tenemos, copiando el pasado dump.rdb
Después de detener redis, debería eliminar appendonly.aof, luego copiar nuestro dump.rdb y luego reiniciar redis
Es muy simple, incluso si elimina appendonly.aof, pero debido a que la persistencia AOF está activada, redis primero se restaurará en función de AOF, incluso si el archivo no está en él, luego creará un nuevo archivo AOF vacío.
Detenga redis, cierre temporalmente AOF en la configuración, luego copie una copia de RDB y luego reinicie redis, ¿pueden recuperarse los datos, pueden recuperarse?
Cuando el cerebro está caliente, apague redis, modifique manualmente el archivo de configuración, abra aof y reinicie redis, los datos se han ido, el archivo aof vacío, todos los datos se han ido
En el caso de pérdida de datos, cómo restaurar los datos perfectamente en función de la copia de seguridad en frío RDB, mientras se mantiene dual AOF y RDB
Detenga redis, cierre aof, copie la copia de seguridad rdb, reinicie redis, confirme la recuperación de datos, modifique directamente la configuración de redis en la línea de comando, abra aof, este redis escribirá el registro correspondiente a los datos en memoria en el archivo aof
En este momento, los datos de los dos archivos de datos de aof y rdb están sincronizados
config set appendonly yes Sí Modifique en caliente los parámetros de configuración, los parámetros reales en el archivo de configuración no pueden modificarse permanentemente, vuelva a detener redis, modifique manualmente el archivo de configuración, abra el comando aof y reinicie redis nuevamente
(4) Si todos los archivos RDB en la máquina actual están dañados, extraiga la última instantánea RDB del servicio en la nube remota para recuperar los datos
(5) Si se descubre que hay un error de datos importante, por ejemplo, un programa que se puso en línea durante una hora determinada ha contaminado completamente los datos y los datos están completamente equivocados, puede elegir un punto de tiempo anterior para recuperar los datos
Por ejemplo, el código se puso en línea a las 12 en punto y se descubrió que el código tenía errores, lo que hizo que todos los datos almacenados en caché generados por el código se escribieran en redis, lo cual era incorrecto.
Encuentre una copia de seguridad en frío de RDB de 11 puntos y luego siga los pasos anteriores para restaurar los datos a 11 puntos, ¿está bien?