Hacer copias de seguridad adecuadas de la base de datos es una tarea crítica. Además de configurar la arquitectura de alta disponibilidad de su MongoDB para los servicios de base de datos, también necesita tener copias de seguridad de sus bases de datos para garantizar la disponibilidad de los datos en caso de desastre. Por ejemplo, si elimina accidentalmente algunos datos de una base de datos de producción, la única forma de recuperar los datos desde el punto de vista de la base de datos es restaurar desde la copia de seguridad.
Recientemente, ClusterControl comenzó a admitir un nuevo método de respaldo, llamado Percona Backup for MongoDB, desarrollado por Percona. Puede ejecutar copias de seguridad coherentes para conjuntos de réplicas MongoDB y clústeres fragmentados.
En este blog, echaremos un vistazo a la gestión de copias de seguridad para conjuntos de réplicas y clústeres fragmentados de MongoDB.
MongoDB Backup en arquitectura de alta disponibilidad
ClusterControl admite 3 métodos de copia de seguridad, que son mongodump, mongodb consistente y Percona Backup for Mongodb. La copia de seguridad consistente de mongodb utiliza la utilidad mongodump como método de copia de seguridad, y la copia de seguridad se puede restaurar usando mongorestore.
El último método de copia de seguridad admitido es Percona Backup para Mongodb para copias de seguridad coherentes y puntuales de conjuntos de réplicas y clústeres fragmentados, requiere que un agente se ejecute en cada nodo o conjunto de réplicas o nodos de fragmentos y nodos de administración para clústeres de fragmentos como se describe aquí.
Configurar y programar copias de seguridad consistentes utilizando Percona Backup para Mongodb en ClusterControl es muy fácil. Vaya a la página Copia de seguridad y luego configure Percona Backup para Mongodb. El requisito previo es tener Percona Backup for MongoDB ejecutándose en cada nodo, que también se puede instalar desde ClusterControl.
Necesitamos instalar el agente Percona Backup for MongoDB antes de poder programar la copia de seguridad como se muestra a continuación:
Y luego configure el directorio de respaldo. Tenga en cuenta que el directorio de copia de seguridad debe ser un disco compartido que se haya montado en todos los nodos con exactamente la misma ruta de montaje que se muestra a continuación:
Si no tiene ningún tipo de disco compartido listo en el sistema, puede usar NFS para lograr esto. Para configurar el servidor NFS, necesitamos un servidor / máquina virtual dedicado con suficiente espacio libre para almacenar la copia de seguridad. Instale la biblioteca nfs-utils y nfs-utils-lib en el servidor como se muestra a continuación (asumiendo que estamos usando CentOS):
[[email protected] ~]# yum install nfs-utils nfs-utils-lib
[[email protected] ~]# yum install portmapE inicie los servicios portmap y nfs.
[[email protected] ~]# /etc/init.d/portmap start
[[email protected] ~]# /etc/init.d/nfs startDespués de eso, agregue nuevas entradas en /etc/exports como se muestra a continuación:
[[email protected] ~]# vi /etc/exports
/backup 10.10.10.11(rw,sync,no_root_squash)En el nodo de la base de datos, solo necesitamos montar el disco de almacenamiento como almacenamiento compartido.
Por último, simplemente haga clic en el botón de instalación y activará un nuevo trabajo para configurar el agente en cada nodo.
Después de instalar todo el PBM ggent, podemos configurar el método de respaldo para el clúster de la siguiente manera:
Copia de seguridad física vs. lógica
La copia de seguridad de MongoDB admite la copia de seguridad lógica y física. El método para la copia de seguridad lógica utilizando la utilidad mongodump se incluye cuando instala el paquete mongodb. Mongodump necesita acceso a su base de datos mongodb, por lo tanto, requiere acceso de credenciales para mongodump con privilegios de funciones de respaldo y debe tener una acción de búsqueda otorgada para respaldar la base de datos.
Funciona para formatos de volcado de datos BSON. Mongodump se conectará a su base de datos con las credenciales proporcionadas, leerá todos los datos en su base de datos y volcará los datos en archivos. Dado que es un proceso de un solo subproceso, la copia de seguridad llevará más tiempo, especialmente con una base de datos de gran tamaño. Mongodump no mantiene la atomicidad de las transacciones en los fragmentos, por eso no se puede utilizar como estrategia de copia de seguridad para mongodb versión 4.2 y superior en un clúster fragmentado. Percona Backup for MongoDB es una copia de seguridad lógica pero admite copias de seguridad consistentes de clústeres.
La copia de seguridad física en MongoDB funciona a través de la instantánea de los sistemas de archivos mongodb, está copiando los archivos mongodb subyacentes a otra ubicación como copia de seguridad base de su base de datos mongodb. La instantánea del sistema de archivos es un sistema operativo si usa LVM (Administrador de volumen lógico) como software para administrar el diseño y el dispositivo del disco, o el dispositivo de software, por ejemplo. Copia de seguridad de Veritas o NetApp. Debe habilitar el registro en diario, el registro de actividad de cambios en mongodb antes de ejecutar la instantánea del sistema de archivos para que la copia de seguridad sea coherente.
Además de la instantánea del sistema de archivos, también puede usar el comando cp o rsync para copiar archivos de datos de MongoDB, pero debe detener el proceso de escritura en mongodb porque el proceso de copia de archivos de datos no es una operación atómica. La copia de seguridad no se puede utilizar para la recuperación de un punto en el tiempo en conjuntos de réplicas o arquitecturas de clústeres fragmentados.
Percona Backup for MongoDB consta de dos componentes, el pbm-agent que debe instalarse en cada nodo y el pbm como una interfaz de línea de comandos para interactuar y ejecutar las copias de seguridad. El pbm-agent se coordina entre los nodos de la base de datos y ejecutar el proceso de copia de seguridad y restauración. El pbm-agent decidirá el mejor nodo para realizar la copia de seguridad.
Copia de seguridad de PITR
En muchos sistemas de bases de datos, es común usar un punto de control para vaciar los datos en el disco. MongoDB utiliza el motor de almacenamiento WiredTiger como motor de almacenamiento predeterminado y también utiliza puntos de control para proporcionar una vista uniforme de los datos. No solo eso, el punto de control en MongoDB se puede usar para recuperarse del último punto de control. El registro en diario funciona entre cada punto de control, el registro en diario es necesario para recuperarse de interrupciones inesperadas que ocurren en cualquier momento entre los puntos de control. El registro en diario garantiza que las operaciones de escritura se registran en el disco, MongoDB creará una entrada en el diario para cada cambio, incluidos los bytes que cambiaron y la ubicación del disco.
Mongodump y mongorestore se pueden usar para la copia de seguridad de recuperación de un punto en el tiempo, hay una opción para aprovechar el registro de operaciones. El oplog es una colección limitada en MongoDB que rastrea todos los cambios en las colecciones para cada transacción de escritura (por ejemplo, insertar, actualizar, eliminar). Por lo tanto, si desea realizar una recuperación puntual, debe restaurar desde la última copia de seguridad completa y también usar el archivo oplog para aplicar los cambios en el momento exacto en que desea recuperar. Otra herramienta que se puede usar es Percona Backup for MongoDB, el proceso es similar a mongodump, necesitamos restaurar desde la copia de seguridad y luego aplicar el oplog.
Conclusión
Es importante realizar una copia de seguridad consistente, especialmente en configuraciones de MongoDB en clúster (conjunto de réplicas o clúster fragmentado). ClusterControl proporciona una manera fácil de configurar Percona Backup for MongoDB en su clúster y programar sus copias de seguridad.
