sql >> Base de Datos >  >> RDS >> MariaDB

Cómo programar copias de seguridad de bases de datos con ClusterControl

La copia de seguridad de la base de datos es una parte crítica de la gestión de la base de datos y debe planificarse cuidadosamente. Programar una copia de seguridad no es suficiente, también es necesario verificar la coherencia y la integridad de los datos de la copia de seguridad. Hay otras consideraciones como el cifrado y el archivo fuera del sitio. Un buen administrador de copias de seguridad tendría funciones que tuvieran en cuenta todas estas consideraciones diferentes.

En esta publicación de blog, veremos cómo puede programar las copias de seguridad de su base de datos con ClusterControl.

Copias de seguridad de bases de datos usando ClusterControl

ClusterControl admite varios métodos de copia de seguridad según el tipo de clúster, como se resume en la siguiente tabla:

Tipo de clúster Método de copia de seguridad admitido
MySQL (replicación, Galera, clúster NDB, replicación de grupo)
  • mysqldump
  • Percona Xtrabackup (completa e incremental)
  • Copia de seguridad de MariaDB (solo MariaDB)
  • Copia de seguridad NDB (solo clúster de MySQL)
MongoDB (conjunto de réplicas, clúster fragmentado)
  • mongodump
  • mongodb-cosistent-backup (beta, Percona Server solo para MongoDB)
PostgreSQL (replicación de transmisión)
  • pg_dumpall
  • pg_basebackup

Al programar una copia de seguridad con ClusterControl, cada uno de los métodos de copia de seguridad se puede configurar con un conjunto de opciones sobre cómo desea que se ejecute la copia de seguridad. Diferentes cargas de trabajo de base de datos y estrategias de copia de seguridad requerirían soporte para diferentes funciones, por ejemplo:

  • Limitación de IOPS de disco
  • Limitación de la red
  • Bloqueos de respaldo
  • Cifrado
  • Compresión
  • Período de retención
  • Verificación

ClusterControl configurará automáticamente una serie de opciones de respaldo, siguiendo las mejores prácticas del proveedor de la base de datos en particular. Por ejemplo, si el nodo de la base de datos de destino tiene habilitado el registro binario, agregará un indicador adicional, --master-data para incluir las coordenadas de registro binario (nombre de archivo y posición) del servidor volcado. Si es un nodo de Galera y el método de respaldo es xtrabackup, ClusterControl agregará un indicador adicional, --galera-info que contiene el estado del nodo local en el momento de la copia de seguridad.

Planificación de una copia de seguridad

Antes de programar cualquier copia de seguridad, tenemos que planificar cómo debe ser la operación de copia de seguridad. Responder a las siguientes preguntas de ejemplo sería útil antes de crear un programa de copia de seguridad:

  • ¿Qué método de copia de seguridad desea utilizar? Algunos métodos de copia de seguridad no bloquean, pero consumen muchos recursos. Comprenda las ventajas y desventajas, para que no se sorprenda acerca de cómo se comporta el proceso en producción.
  • ¿Con qué frecuencia desea realizar copias de seguridad de sus bases de datos? Ejecutar una copia de seguridad completa puede ser doloroso si el intervalo de copia de seguridad es demasiado corto. Probablemente necesite una combinación de copias de seguridad incrementales y completas.
  • ¿Qué tan rápido desea restaurar sus datos? La copia de seguridad física suele ser mucho más rápida que la copia de seguridad lógica en términos de tiempo de restauración completo. Por otro lado, la copia de seguridad lógica suele ser más rápida para la restauración parcial.
  • ¿Qué tan grande es su tamaño de datos? En algunos casos, la copia de seguridad lógica no es una buena opción para grandes bases de datos y la copia de seguridad binaria es la única forma de hacerlo.
  • ¿Cuánto espacio libre tienes para almacenar tu copia de seguridad? Las copias de seguridad tienden a consumir mucho espacio. Decida si se necesita compresión y el nivel de compresión que puede permitirse. Una mejor compresión requiere un mayor uso de la CPU.
  • ¿Qué sucede si el servidor de respaldo está inactivo durante el tiempo de respaldo? ¿Debería conmutar por error la copia de seguridad a otro host disponible? Omitir una copia de seguridad debido a una ventana de mantenimiento generalmente no es una buena idea.
  • ¿Cómo garantizar la integridad de la copia de seguridad creada? Recuerde, una copia de seguridad no es una copia de seguridad si no se puede restaurar.
  • ¿Confías en el almacenamiento de respaldo? El cifrado puede ser una buena idea para proteger sus datos.

En general, al responder esas preguntas, podemos idear una estrategia de respaldo adecuada. La lista de preguntas podría ser más larga según su política de copia de seguridad y restauración.

Hemos cubierto este capítulo en detalle en nuestro documento técnico, La guía de DevOps para copias de seguridad de bases de datos para MySQL y MariaDB.


Programar una copia de seguridad
 

Con ClusterControl, la programación es bastante sencilla. Vaya directamente a Copia de seguridad -> Crear copia de seguridad -> Programar copia de seguridad y aparecerá el siguiente cuadro de diálogo:

Según el tipo de clúster, las opciones pueden ser diferentes, como se muestra en las siguientes capturas de pantalla para PostgreSQL y MongoDB:

PostgreSQL MongoDB

La mayoría de las opciones se explican por sí mismas y se tratan en detalle en la Guía del usuario. Una vez que se crea la programación, puede editar las copias de seguridad de configuración, habilitar/deshabilitar la copia de seguridad o eliminar la programación en la pestaña "Copias de seguridad programadas":

Tome nota al programar la copia de seguridad con ClusterControl, todo el tiempo debe programarse en la zona horaria UTC del servidor ClusterControl. La razón detrás de esto es eliminar la confusión del tiempo de ejecución de la copia de seguridad. Cuando se trabaja con un clúster, los servidores de la base de datos pueden distribuirse en diferentes zonas horarias y diferentes áreas geográficas. El uso de una zona horaria de referencia para administrarlos todos garantizará que las copias de seguridad siempre se ejecuten en el momento correcto.

Puede monitorear el progreso de una copia de seguridad mirando Actividad -> Trabajos una vez que haya llegado el momento. Si el trabajo de copia de seguridad falla, verá el error de inmediato:

También se puede acceder al registro anterior en la pestaña Copia de seguridad en cada una de las entradas de copia de seguridad:

Comprobaciones y verificación posteriores a la copia de seguridad

Una vez que finaliza el trabajo de copia de seguridad, no significa que su responsabilidad haya terminado. Hay un par de cosas que necesitan seguimiento. El más importante es el estado de la copia de seguridad creada. ClusterControl proporciona notificaciones por correo electrónico y le notificará sobre el estado. Por supuesto, este servicio de notificación se puede configurar en función de la gravedad en Configuración -> Configuración general -> Configuración de notificaciones por correo electrónico -> Copia de seguridad:

Entregar significa que ClusterControl enviará una notificación por correo electrónico inmediatamente después de que se active una alarma para este componente. También puede configurarlo como Ignorar o Resumen, donde ClusterControl envía un resumen diario de las alarmas generadas.

Si la copia de seguridad se crea correctamente, se recomienda enfáticamente verificar si la copia de seguridad es restaurable. Puede utilizar la función de Verificación de copia de seguridad haciendo clic en el botón "Restaurar" del ID de copia de seguridad elegido y se le presentarán dos opciones de restauración:

"Restaurar y verificar en un host independiente" requiere un host separado, que aún no forma parte de la configuración de la base de datos. ClusterControl primero implementará una instancia de MySQL en el host de destino, iniciará el servicio, copiará la copia de seguridad del repositorio de copias de seguridad e iniciará la restauración. Una vez hecho esto, puede tener la opción de apagar el servidor una vez restaurado o dejar que se ejecute para que pueda realizar más investigaciones en el servidor.

La limpieza también es importante para mantener solo las copias de seguridad útiles en su almacenamiento. Por lo tanto, configure la retención de respaldo según sea necesario. Por defecto, ClusterControl purga las copias de seguridad que tienen más de 30 días. También puede personalizar cada uno de los programas de copia de seguridad con diferentes períodos de retención.

Si el almacenamiento de la copia de seguridad se está acercando a los límites de espacio, o si desea archivar su copia de seguridad fuera de juego, puede optar por eliminar manualmente el archivo haciendo clic en el icono de la papelera o subirlo a la nube, como se destaca a continuación:

En el momento de escribir este artículo, se admiten AWS S3 y GCP Cloud Storage. Las credenciales de la nube deben configurarse previamente en Menú lateral -> Integraciones -> Proveedores de la nube.

Eso es todo, amigos. ¡Feliz agrupamiento!