¿Cuál es la forma recomendada para hacer una copia de seguridad de grandes conjuntos de datos en MongoDB? Digamos que tenemos un tamaño de datos del orden de 10 TB, ¿cómo respaldaría eso?

Estamos considerando un nodo de conjunto de réplica oculto, posiblemente retrasado. El retraso nos protegería de caídas accidentales de toda la base de datos. ¿Es esta una solución viable y qué otras opciones recomendaría investigar?

¡Gracias!

Con la necesidad de respaldar 10 TB, esto se vuelve un poco complicado.

Las réplicas no reemplazan las copias de seguridad adecuadas

Si bien los miembros del conjunto de réplicas demoradas pueden proporcionar una forma relativamente fácil de ayudarlo con operaciones accidentales, no hay reemplazo para las copias de seguridad adecuadas, al igual que RAID no es un reemplazo para las copias de seguridad basadas en el sistema de archivos.

Recomendaciones

Eso depende en gran medida de cómo se vea su configuración.

Instantáneas de SAN

Con 10TB, supongo que tiene algún tipo de SAN conectado. La forma más fácil de hacer una copia de seguridad de MongoDB en esos entornos es asegurarse de tener el diario activado tanto en el sistema de archivos como en MongoDB y simplemente tomar una instantánea del volumen SAN de uno de los secundarios, probablemente uno oculto para asegurarse de que sus operaciones no funcionen No te interrumpan. Esto generalmente lleva unos segundos, pero asegúrese de que su ventana de registro de replicación sea suficiente. De lo contrario, es posible que deba volver a sincronizar el secundario.

No use mongodump

Tengo que estar en desacuerdo con RolandoMySQLDBA sobre el uso de mongodump. En primer lugar, impone bloqueos en el servidor. Aunque se levantan relativamente rápido, el simple número de bloqueos puede sumar e interferir con sus operaciones, a menos que se ejecute en un nodo oculto o cuando no haya una preferencia de lectura que golpee los secundarios. Además, no es exactamente rápido. Espero que se ejecute durante horas, al menos, lo más probable es que tarde más que la ventana de respaldo. Nota al margen : siempre ejecute mongodump con la --oplogopción. También tenga en cuenta que mongodump no respalda los índices, sino las operaciones para crear índices. Esos índices deben recrearse durante una restauración, lo que puede aumentar enormemente el tiempo que necesita para ello. Desde mi experiencia, si tiene que restaurar una base de datos, desea tenerla lo más rápido posible. Otro punto por el que mongodump no es adecuado para realizar copias de seguridad de 10 TB.

Notas sobre las instantáneas de LVM

Puede hacer una instantánea LVM en una instancia de mongod en ejecución siempre que tenga habilitado el registro en diario en mongod (y, según mi experiencia, no está de más tenerlo habilitado también en el nivel FS). Sin embargo, las instantáneas de LVM tienen algunas implicaciones. Primero, obviamente necesita tener suficiente espacio en disco que pueda tomar los cambios durante las operaciones de copia de seguridad. Déjame aclarar eso.

Supongamos que tiene una tasa de cambio por hora de 500 GB. Y que desea que se borre su copia de seguridad antes de cargarla en algún almacenamiento. Incluso cuando se usa bzip2 paralelo , la compresión de 10TB necesitaría algunas horas para finalizar, simplemente porque el hecho de que lo más probable es que el rendimiento de almacenamiento en masa se convierta en su factor limitante. Supongamos que tomaría 2 horas comprimir los datos a 2 TB. Por lo tanto, ahora necesitaríamos un total de 2 TB + 2 * 500 GB de espacio libre en disco, 1 TB necesarios para la instantánea LVM. Esto crearía la necesidad de sobreaprovisionar su sistema de archivos al menos30% En caso de que desee tener un margen de seguridad adecuado, esto podría aumentar fácilmente al 60-70% (20% para un factor de utilización de 0.8 para el sistema de archivos original, lo mismo para el tamaño de la instantánea más el espacio necesario para la copia de seguridad comprimida en sí) ) En la mayoría de los entornos de producción, eso sería inaceptable, ya que el exceso de aprovisionamiento sería estático (no querría que una secuencia de comandos de respaldo manipulara su LVM dinámicamente, ¿verdad?).

Copia de seguridad MMS

Si bien la copia de seguridad de MMS tiene algunas características increíbles (copia de seguridad continua, recuperación fácil en un punto en el tiempo), viene con un serio inconveniente: su precio para implementaciones grandes puede ser fácilmente de miles. Con una tasa de cambio por hora supuesta de 500 GB en esos 10 TB, sería una suma media de seis cifras para las copias de seguridad en la nube . Mensual.

Mi sugerencia es que tome una suscripción empresarial para sus servidores para ser elegible para tener una instancia de MMS en las instalaciones, incluida la copia de seguridad.

Resumen

Aquí están las opciones que tomaría en orden descendente de preferencia.

1. Instantáneas de SAN: fáciles de implementar, relativamente baratas
2. Suscripción empresarial: mejores características. Instálalo, configúralo, olvídalo, está ahí cuando lo necesitas
3. Instantáneas de LVM: fáciles de implementar, pero los costos del sobre aprovisionamiento necesario pueden resumirse con el tiempo.

Hay dos opciones

RESPALDO FÍSICO

Si no le importa el tiempo de inactividad, lo más simple es

service mongod stop

Realice una instantánea LVM o una fuerza bruta cpde la carpeta de datos de Mongo en otro disco

service mongod start

Por supuesto, no desea un tiempo de inactividad si los 10 TB de datos se encuentran en una máquina independiente.

JUEGO DE REPLICA RETRASADA

Si tiene una réplica establecida con tres nodos, use uno de los nodos para las copias de seguridad

{
        "_id" : "myreplica",
        "version" : 1,
        "members" : [
                {
                        "_id" : 1,
                        "host" : "10.20.30.40:27017",
                        "priority" : 2
                },
                {
                        "_id" : 2,
                        "host" : "10.20.30.41:27017"
                },
                {
                        "_id" : 3,
                        "host" : "10.20.30.42:27017",
                        "priority" : 0,
                        "slaveDelay" : 3600
                }
        ]
}

Use el nodo con "_id' : 3todas sus copias de seguridad físicas. Por lo tanto, no hay tiempo de inactividad. Para obtener una instantánea de medianoche, puede iniciar la copia de seguridad a la 1:00 a.m., ya que el nodo oculto está 1 hora atrás.

Por supuesto, el inconveniente es tener dos servidores más con 10 TB cada uno y la cordura del administrador de sistemas en riesgo.

MONGODUMP

Puede usar mongodump contra la máquina independiente, pero debe esperar una degradación del rendimiento ya que mongodump es un programa cliente que utiliza una conexión como cualquier otra conexión.

Si desea una copia de seguridad en un punto en el tiempo, debe usar

mongodump --oplog 

La copia de seguridad lógica BSON será más pequeña (especialmente comprimida o comprimida) que la copia de seguridad física.

El uso se mongodump --oplogharía mejor contra el nodo oculto. De esa manera, no hay éxito de rendimiento en el Master.

DESCARGO DE RESPONSABILIDAD

Soy relativamente nuevo en MongoDB (MongoDBA accidental / incidental). Espero que mi respuesta ayude.