Copias de seguridad de MongoDB PIT en profundidad

En este blog hay una discusión en profundidad de las copias de seguridad PIT de MongoDB.

Nota: ZONA LIBRE DE BULLYING!! Esta publicación está destinada a ser entregada al lector. no más del conocimiento que se necesita para comprender el material. Esto incluye conocimientos básicos de MongoDB y otros conceptos básicos. Intento incluir enlaces a más investigaciones donde puedo. Úselo donde lo necesite y hacer preguntas. ¡Estamos aquí para ayudar!

Introducción

En esta serie de dos partes, cubriremos algunas de las deficiencias que puede tener para ayudar a obtener una fantástica copia de seguridad de un punto en el tiempo (PIT) en MongoDB. Estos procedimientos funcionarán para MongoDB y Percona Server para MongoDB. Esto está destinado a ser una precuela. MongoDB PIT Backup blog de David Murphy correo. En ese blog, David le muestra cómo tomar y restaurar un volcado hasta que ocurre una operación problemática. Si no has leído ese post, sigue leyendo este. Esta base lo ayudará a comprender mejor cómo y por qué tomar los pasos necesarios. Pasemos a algunos conceptos básicos en MongoDB, pero primero, déjame decirte qué esperar en todas partes.

Blog 1 (este): conceptos básicos: copias de seguridad de conjuntos de réplicas, declaración del problema y solución

Blog 2: Getting Shardy: por qué es difícil mantener la coherencia y cómo resolverlo

conceptos de corazon

Conjunto de réplicas (nombre del proceso: mungodu) – MongoDB utiliza conjuntos de replicación para distribuir datos con fines de recuperación ante desastres. Los conjuntos de réplicas consisten en primario, secundario y/o árbitro. Estos son muy similares a los pares maestro/esclavo en MySQL, pero con una gran advertencia. ¡Hay un protocolo de elección incluido que también maneja la conmutación por error! ¡Es correcto, alta disponibilidad (HA) también! Entonces, en general, hay una «regla de tres» al pensar en la cantidad mínima de servidores para colocar en sus conjuntos de réplicas. Esto es necesario para evitar una cerebro dividido guión.

Oplog (nombre de la colección: local.oplog.rs) El complemento es el registro que registra los cambios en los datos en el MongoDB principal (los secundarios también tienen un registro de operaciones). Al igual que MySQL, los miembros no primarios (secundarios) extraen operaciones del registro de operaciones y las aplican a sus colecciones. Los secundarios pueden extraer de cualquier miembro del sector réplica que esté frente a ellos. Las operaciones en el oplog son idempotente, lo que significa que siempre dan como resultado el mismo cambio en la base de datos, sin importar cuántas veces se realicen.

fragmentación (nombre del proceso: monjes) – MongoDB también ha incorporado escalabilidad horizontal. Esto se implementa en una arquitectura de «nada compartido». Un clúster fragmentado consta de varios conjuntos de réplicas. Cada conjunto de replicación contiene un rango único de datos. Los datos se distribuyen a través de conjuntos de replicación basados ​​en un clave de fragmentación. También hay un enrutador de fragmentación (mongos) que se ejecuta como un paraguas de enrutamiento sobre el clúster. En una configuración fragmentada, la aplicación interactúa solo con el enrutador de fragmentación (nunca se establece la replicación). Esta es la función principal de la báscula. leer o el escribe en MongoDB. Escalar ambos requiere un diseño muy cuidadoso, pero puede que no sea posible.

Mongodump (nombre de la utilidad: mongodump) – MongoDB ha creado una utilidad de volcado de base de datos con la que puede interactuar mungodu o monjes. Mongodump también puede usar el registro de operaciones del servidor que se está ejecutando para crear una copia de seguridad oportuna a lo largo del tiempo utilizando una estrategia de «avance».

Mongorestore (nombre de la utilidad: mongorestore) – MongoDB tiene una utilidad de restauración de base de datos integrada. Mongorestore es una utilidad bastante simple que reproducirá volcados binarios creados por mongodump. cuando se usa con -plogReproducir al restablecer un volcado hecho con mongodump‘s -log cambio, puede convertirse en una instalación de seguridad muy funcional.

Consejo: asegúrese de que los permisos de usuario estén configurados correctamente al usar -plogReproducir – además de restaurar, cada acción y cada recurso debe ser concedido.

¿OK y eso qué?

Primero debemos comprender cómo funciona la copia de seguridad en un entorno simple (un único conjunto de réplicas). Las cosas se pondrán mucho más interesantes cuando veamos los clústeres fragmentados en la próxima publicación.

Copia de seguridad

En un solo conjunto de réplicas, las cosas son bastante simples. No hay un enrutador de fragmentación con el que lidiar. Puede obtener un conjunto de datos completo para interactuar con un servidor. El único problema con el que debe lidiar son los cambios que se realizan en la base de datos mientras el suyo mongodump Está en proceso. Si el concepto de transacciones faltantes es un poco confuso para usted, considere este caso de uso simple:

Vamos a hacer un mongodump y vamos a tener una colección con cuatro documentos:

Empecemos mongodump sobre esta colección. También ejecutamos nuestra aplicación al mismo tiempo, por lo que no podemos abandonar la producción. Mongodump escanea desde el primero hasta el último en la colección (como un escaneo de intervalo basado en IDENTIFICACIÓN). En este caso mongodump hizo una copia de seguridad de todos los documentos de identificación: 1 mediante identificación: 4Copias de seguridad PIT de MongoDB

En este mismo momento, nuestra aplicación inserta identificación: 3 en la colecciónCopias de seguridad PIT de MongoDB

Es el documento con identificación: 3 se incluirá en el mongodump? La respuesta es: lo más probable es que no. El problema es que esperas que esté completamente descargado. Sin embargo, si necesita restaurar esta copia de seguridad, la perderá identificación: 3. Ahora bien, esto es perfectamente normal en los escenarios de recuperación ante desastres. Saber que esto está sucediendo es la parte clave. Su copia de seguridad tendrá la consistencia de un queso suizo si no tiene una forma de realizar un seguimiento de los cambios que se realizan mientras se ejecuta la copia de seguridad. La pérdida de datos desconocida es una de las peores situaciones por las que uno puede pasar. Lo que necesitamos es un proceso para capturar los cambios mientras se ejecuta la copia de seguridad.

Aquí es donde la inclusión de la -log La bandera es muy importante. tu -log flag permitirá que mongodump capture los cambios que se realizan en la base de datos mientras se ejecuta la copia de seguridad. Dado que el oplog es impotente, Existe la posibilidad de que cambiemos los datos durante una restauración. esto da la mongodump una instantánea consistente de cuándo finaliza el volcado, como la mayoría de las operaciones de tipo «clonar».

Restaurar

cuando corre mongorestorepuedes usar -plogReproducir opción. El uso de oplog se recupera hasta el momento en que se completa el volcado. Volviendo al caso de uso, no pudimos atraparlo identificación: 3 en el primer paso en este caso, pero hasta que capturemos el registro de operaciones hasta que se complete la copia de seguridad, lo haremos identificación: 3 disponible. Cuando se reproduce el oplog durante mongorestore, Solo necesitamos reanudar la operación de inserción, completando el conjunto de datos. El enchufe BSON marca la hora de todas las entradas, por lo que sabemos con certeza cuánto tiempo las hemos capturado.

SUGERENCIA: si necesita convertir una marca de tiempo en algo legible por humanos, aquí hay algo para ayudar

U terminar

Ahora tenemos un conocimiento firme del problema. Una vez que comprendemos el problema, podemos idear fácilmente una solución para garantizar que nuestras copias de seguridad tengan la integridad que exige nuestro entorno. En la próxima publicación, aumentaremos la complejidad al examinar las copias de seguridad junto con la característica más compleja que tiene MongoDB: la fragmentación. Hasta entonces, publique sus comentarios y preguntas en la sección de comentarios a continuación.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario