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

Cómo hacer una copia de seguridad de su base de datos Moodle MariaDB

Anteriormente, habíamos escrito en un blog sobre cómo hacer una copia de seguridad de su base de datos MySQL de Moodle. Esta vez, se trata de hacer una copia de seguridad de su base de datos Moodle MariaDB. De hecho, comparte el mismo enfoque al hacer una copia de seguridad de su base de datos Moodle MySQL que con su base de datos Moodle MariaDB. Sin embargo, desde MariaDB 10.2, se ha desviado lentamente y sigue teniendo diferencias drásticas con la versión de MySQL. En este sentido, preste atención a los enfoques que podría tener que considerar cuando esté haciendo una copia de seguridad de su MariaDB en contraste con MySQL si fuera de allí.

Mejores prácticas para hacer su copia de seguridad de Moodle MariaDB

Primero consideremos este tema. Hacer una copia de seguridad de sus datos de Moodle tiene que aplicar las mejores prácticas para su copia de seguridad de MariaDB, ya que esto le brinda seguridad y garantía, especialmente cuando surge un desastre o una catástrofe en situaciones impredecibles.

Entonces, ¿qué pasa con esto? Hacer una copia de seguridad de su Moodle tiene que ver al menos con las siguientes copias de seguridad:

  • Copia de seguridad lógica
  • Copia física de su copia de seguridad
  • Recuperación de un punto en el tiempo (incremental)

Copia de seguridad lógica

Una copia de seguridad lógica de los datos se almacena en un formato legible por humanos como SQL. Las copias de seguridad lógicas guardan información representada como una estructura de base de datos lógica (instrucciones CREATE DATABASE, CREATE TABLE) y contenido (instrucciones INSERT o archivos de texto delimitado). Este tipo de respaldo es adecuado para cantidades más pequeñas de datos en los que puede editar los valores de los datos o la estructura de la tabla, o recrear los datos en una arquitectura de máquina diferente. Si tiende a usar una gran copia de seguridad de la base de datos, asegúrese de tener habilitada la compresión. Advertencia ya que esto puede ocupar mucho espacio en disco especialmente.

En MariaDB, una herramienta común para usar es mysqldump, pero cambiará en el futuro con mariadb-dump a partir de MariaDB 10.4.6 o 10.5.2 en adelante. Alternativamente, una herramienta común para usar con MySQL/MariaDB DBA es mydumper si desea una copia de seguridad paralela para su copia de seguridad lógica. Aunque hay algunos problemas en algunas versiones o podría tener problemas, especialmente para las últimas versiones de MariaDB. Si desea usar esto, preste atención a sus registros de respaldo cuando cree una copia.

Copia de seguridad física

La copia de seguridad física contiene los datos binarios de la base de datos que consisten en copias sin formato de los directorios y archivos que almacenan el contenido de la base de datos. Esta es una acción adecuada especialmente para una base de datos grande y es más rápido recuperar una copia completa de la base de datos en comparación con una copia de seguridad lógica. Por otro lado, realizar una copia de seguridad física completa lleva tiempo, especialmente si tiene un conjunto de datos muy grande. También depende de los parámetros que haya habilitado o configurado que puedan afectar su ETA de respaldo.

Una herramienta común para MariaDB es usar mariabackup. Mariabackup es una herramienta de código abierto proporcionada por MariaDB. Es una bifurcación de Percona XtraBackup diseñada para trabajar con tablas cifradas y comprimidas, y es el método de copia de seguridad recomendado para bases de datos MariaDB.

Recuperación de un punto en el tiempo (PITR)

Recuperación de un momento dado se refiere a la recuperación de cambios en los datos hasta un momento determinado. Este punto dado en el tiempo es el objetivo de recuperación deseado que se ha determinado y se requiere que se vuelva a establecer, que se aplica durante la recuperación. PITR es una recuperación de un punto hacia adelante y eso significa que puede restaurar los datos desde la hora de inicio deseada hasta la hora de finalización deseada, para la lectura opuesta Usando MariaDB Flashback en un servidor MySQL. PITR también se considera un método adicional de protección de datos, ya que salvaguarda la pérdida de información importante.

En situaciones comunes, su copia de seguridad de PITR aplicable para su tipo de recuperación se realiza después de restaurar una copia de seguridad completa que lleva el servidor a su estado en el momento en que se realizó la copia de seguridad. La recuperación de un punto en el tiempo luego actualiza el servidor de forma incremental desde el momento de la copia de seguridad completa hasta un momento más reciente. También acelera la creación de una réplica dentro de un clúster de replicación para que no se ponga al día con su base de datos principal o de escritor activo de MariaDB.

Entonces, ¿qué son estas copias de seguridad? En MariaDB, las copias de seguridad comunes aplicables a su PITR son sus registros binarios. El registro binario debe configurarse correctamente en su base de datos MariaDB y debe estar habilitado. Si está utilizando ClusterControl, puede que no le resulte difícil configurarlo, ya que se configura automáticamente y se activa especialmente al configurar un clúster de replicación.

Al aplicar PITR, la herramienta más común para usar es mysqlbinlog o mariadb-binlog para MariaDB 10.5.2 en adelante.

El mejor enfoque para hacer una copia de seguridad de su base de datos Moodle MariaDB

Cuando realice su base de datos Moodle MariaDB, siempre realice su copia de seguridad durante las horas no pico o cuando el tráfico sea demasiado bajo. Antes de hacer esto, asegúrese de haber probado la copia de seguridad y de que se haya finalizado con éxito. Una vez que haya terminado, pruebe una restauración si su copia de seguridad es útil o no y si satisface sus necesidades cuando se necesita la recuperación de datos o cuando necesita su copia de seguridad para crear otro conjunto de clústeres (control de calidad, desarrollo o extensión a otro centro de datos). Básicamente, las siguientes subsecciones serán el enfoque y la configuración con los que debe lidiar.

Configurar una réplica y realizar la copia de seguridad en la réplica

Si no está familiarizado con la replicación, lea nuestro documento técnico Replicación de MySQL para alta disponibilidad. Básicamente, no ahorre su nodo de base de datos principal o de escritor activo para realizar o ejecutar una copia de seguridad. La realización de una copia de seguridad debe probarse y no debe realizarse en producción si aún no se ha probado con un conjunto de comandos y su política de copia de seguridad que haya creado. Una vez que esté bien, simplemente déjelo y apúntelo en una réplica. Puede realizar una copia de seguridad de su base de datos principal/maestra de MariaDB si no tiene otra opción o si al menos está seguro de lo que está haciendo.

Ejecutar copia de seguridad durante las horas no pico

Al realizar una copia de seguridad, asegúrese de que sean sus horas pico. Su réplica debe tener el menor retraso posible, por lo que los datos más actualizados se ocultarán.

Crear una política de copia de seguridad

La política de copia de seguridad consta de sus parámetros y la programación en la que se activa su copia de seguridad. Para los parámetros, asegúrese de que sea suficiente para sus necesidades, es decir, seguridad, compresión, etc. La programación debe ser permanente para que su la copia de seguridad estará allí cuando sea necesario en tiempos de desastre y se necesite recuperación de datos. También podrá determinar su objetivo de tiempo de recuperación para que pueda determinar con qué frecuencia se ejecutará su programa de copia de seguridad y cuándo.

Cómo crear una copia de seguridad de su base de datos Moodle MariaDB

Uso de mariadb-dump/mysqldump

El siguiente comando creará una copia de seguridad de su base de datos para Moodle. En este ejemplo, el nombre de la base de datos es moodle. Incluimos activadores, procedimientos almacenados o rutinas y eventos. Imprima el GTID y la información maestra que es útil cuando desea aprovisionar una réplica desde el nodo de la base de datos maestra o principal.

$  /usr/bin/mariadb-dump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --skip-lock-tables --triggers --routines --events --gtid --databases moodle

Simplemente puede reemplazar mariadb-dump con mysqldump si está utilizando la versión de MariaDB <10.5.2. Si necesita comprimir, puede ejecutar el siguiente comando:

$  /usr/bin/mysqldump --defaults-file=/etc/my.cnf --flush-privileges --hex-blob --opt --master-data=2 --single-transaction --skip-lock-tables --triggers --routines --events --gtid --databases moodle |gzip -6 -c > /backups/backup-n1/mysqldump_2021-01-25_182643_schemaanddata.sql.gz

Usando mariabackup

La copia de seguridad de maria se puede tomar simplemente. Para esto, usaremos mbstream como el formato deseado de transmisión y archivo. Puede usar el siguiente comando:

$ /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --parallel 1 --stream=xbstream > backup.xbstream

Si pretende comprimirlo, puede ejecutar el siguiente comando:

$ /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --parallel 1 --stream=xbstream | gzip -6 - > backup.xbstream.gz

Uso de ClusterControl

Si cambia a una solución administrada especialmente para hacer una copia de seguridad de su Moodle, ClusterControl lo toma de manera simple pero ofrece funciones avanzadas para hacer copias de seguridad. Echa un vistazo a la captura de pantalla a continuación:

Hacer una copia de seguridad es muy simple y fácil de crear. Todo lo que necesita hacer es ir a → Copia de seguridad → Crear copia de seguridad.

En la captura de pantalla anterior, tengo mysqldump, mysqldump compatible con PITR y mariabackup. Puede seleccionar qué host realizar la copia de seguridad. Como se mencionó anteriormente, asegúrese de realizar la copia de seguridad en la réplica o el esclavo. Eso significa, asegúrese de que el esclavo esté seleccionado. Vea la captura de pantalla a continuación:

Al seleccionar o elegir mysqldump, ClusterControl permite al usuario elegir el tipo de datos a volcar. Esto también incluye un volcado compatible con PITR para la copia de seguridad. Vea la captura de pantalla a continuación:

Para su copia de seguridad binaria o física, además de mysqldump como su copia de seguridad lógica, puede elegir mariabackup ya sea completo o incremental. Ver a continuación:

Las ubicaciones de almacenamiento solo permiten al usuario elegir permanecer en el nodo o transmítalo al host ClusterControl. Si tiene un servidor externo que no está registrado en ClusterControl, puede usar NFS para montar el volumen en el que desea que se descargue su copia de seguridad. Aunque eso podría no ser lo ideal, en algunos casos, esto satisfará especialmente si el ancho de banda de la red o la transferencia de la red es lo suficientemente rápido como para transmitir los datos localmente al otro nodo a través de la red.

Esencialmente, puede elegir las copias de seguridad que se cargarán en la nube. Puede ver la captura de pantalla anterior y simplemente marque la casilla de verificación para habilitarla como se muestra a continuación:

Como se mencionó anteriormente, ClusterControl realiza la copia de seguridad de una manera fácil de usar pero proporciona características avanzadas, estas son las opciones que puede configurar.

Para mysqldump,

Para mariabackup,

muy fácil de usar. ClusterControl también ofrece verificación de copia de seguridad y restauración de copia de seguridad, por lo que es fácil para usted determinar si la copia de seguridad es útil o no. Esto ayuda a que la copia de seguridad de la base de datos de Moodle sea útil, especialmente cuando se debe aplicar la recuperación de datos para emergencias y recuperación.

Conclusión

Puede ser fácil hacer una copia de seguridad de su base de datos Moodle MariaDB, pero cuando los datos aumentan y el tráfico aumenta, puede ser un gran desafío. Solo necesita seguir las mejores prácticas, asegurarse de haber protegido sus datos, asegurarse de que su copia de seguridad esté verificada y que sea útil cuando se deba aplicar la recuperación de datos.