Estoy ejecutando Mongodb en una instancia AWS EC2. Los datos/registro/y diario se almacenan en un volumen separado, con formato xfs. Actualmente estamos deteniendo la instancia de mongodb para tomar una instantánea, pero leemos esto: https://docs.mongodb.com/ecosystem/tutorial/backup-and-restore-mongodb-on-amazon-ec2/ aparentemente no hay necesidad de detener el servicio durante la instantánea ya que el diario está habilitado. ¿Estoy en lo correcto? ¿Puedo crear una instantánea coherente incluso si el servicio se está ejecutando?
Respuesta1
En general, no confíe en ningún procedimiento de copia de seguridad hasta que haya confirmado la integridad de una restauración desde un medio a largo plazo.
Ya tiene la capacidad de realizar una copia de seguridad de la capa del sistema de almacenamiento en línea. En este caso, con volúmenes EBS o Linux LVM. El problema es conseguir que la base de datos esté en un estado coherente.
Es posible realizar una copia de seguridad en línea con o sin diario. En cualquier caso, la forma en que mongo suspende las escrituras en la base de datos es fsync y lock, como se describe en ese tutorial.
Sin un diario, es difícil saber qué datos son duraderos en el disco y cuáles están almacenados en el búfer y aún no confirmados. fsync y lock establecen un punto en el tiempo y detiene cualquier escritura en curso hasta que se realiza la copia de seguridad.
El bloqueo también es necesario con varios discos, donde (en este sistema de almacenamiento) las instantáneas no son consistentes entre sí. Suspender las escrituras durante la copia de seguridad significa que el disco /dev/sdfno estará en un momento ligeramente diferente en comparación con /dev/sdg.
Mongo afirma que si solo tienes unsolterodisco, ytenerun diario, no es necesario sincronizarlo ni bloquearlo. Presumiblemente, la instantánea de EBS es un punto en el tiempo suficientemente consistente con las fallas, y la recuperación directa del diario puede corregir cualquier escritura incompleta.