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

Cómo ejecutar y administrar copias de seguridad de MySQL para Oracle DBA

Migrar de la base de datos Oracle al código abierto puede traer una serie de beneficios. El menor costo de propiedad es tentador y empuja a muchas empresas a migrar. Al mismo tiempo, DevOps, SysOps o DBA necesitan mantener estrictos SLA para abordar las necesidades comerciales.

Una de las principales preocupaciones cuando planifica la migración de datos a otra base de datos, especialmente de código abierto, es cómo evitar la pérdida de datos. No es descabellado que alguien haya borrado accidentalmente parte de la base de datos, que alguien haya olvidado incluir una cláusula WHERE en una consulta DELETE o ejecutar DROP TABLE accidentalmente. La pregunta es cómo recuperarse de tales situaciones.

Cosas como esa pueden suceder y sucederán, es inevitable, pero el impacto puede ser desastroso. Como alguien dijo:"Todo es diversión y juegos hasta que falla la copia de seguridad". El activo más valioso no puede ser comprometido. Punto.

El miedo a lo desconocido es natural si no estás familiarizado con las nuevas tecnologías. De hecho, el conocimiento de las soluciones de bases de datos de Oracle, la confiabilidad y las excelentes características que ofrece Oracle Recovery Manager (RMAN) pueden desanimarlo a usted o a su equipo a migrar a un nuevo sistema de base de datos. Nos gusta usar cosas que conocemos, entonces, ¿por qué migrar cuando nuestra solución actual funciona? ¿Quién sabe cuántos proyectos se suspendieron porque el equipo o el individuo no estaba convencido de la nueva tecnología?

Copias de seguridad lógicas (exp/imp, expdp/impdb)

Según la documentación de MySQL, la copia de seguridad lógica es "una copia de seguridad que reproduce la estructura de la tabla y los datos, sin copiar los archivos de datos reales". Esta definición puede aplicarse a los mundos de MySQL y Oracle. Lo mismo es "por qué" y "cuándo" utilizará la copia de seguridad lógica.

Las copias de seguridad lógicas son una buena opción cuando sabemos qué datos se modificarán para que pueda hacer una copia de seguridad solo de la parte que necesita. Simplifica la restauración potencial en términos de tiempo y complejidad. También es muy útil si necesitamos mover una parte de un conjunto de datos de tamaño pequeño o mediano y volver a copiarlo en otro sistema (a menudo en una versión de base de datos diferente). Oracle utiliza utilidades de exportación como exp y expdp para leer los datos de la base de datos y luego exportarlos a un archivo en el nivel del sistema operativo. A continuación, puede volver a importar los datos a una base de datos mediante las utilidades de importación imp o impdp.

Oracle Export Utilities nos brinda muchas opciones para elegir qué datos se deben exportar. Definitivamente no encontrará la misma cantidad de funciones con mysql, pero la mayoría de las necesidades están cubiertas y el resto se puede hacer con secuencias de comandos adicionales o herramientas externas (consulte mydumper).

MySQL viene con un paquete de herramientas que ofrece una funcionalidad muy básica. Son mysqldump, mysqlpump (la versión moderna de mysqldump que tiene soporte nativo para la paralelización) y el cliente MySQL que se puede usar para extraer datos a un archivo plano.

A continuación puede encontrar varios ejemplos de cómo usarlos:

Solo la estructura de la base de datos de copia de seguridad

mysqldump --no-data -h localhost -u root -ppassword mydatabase > mydatabase_backup.sql

Estructura de la tabla de respaldo

mysqldump --no-data --single- transaction -h localhost -u root -ppassword mydatabase table1 table2 > mydatabase_backup.sql

Copia de seguridad de filas específicas

mysqldump -h localhost --single- transaction -u root -ppassword mydatabase table_name --where="date_created='2019-05-07'" > table_with_specific_rows_dump.sql

Importación de la tabla

mysql -u username -p -D dbname < tableName.sql

El comando anterior detendrá la carga si ocurre un error.

Si carga datos directamente desde el cliente mysql, los errores se ignorarán y el cliente continuará

mysql> source tableName.sql

Para registrar la salida, debe usar

mysql> tee import_tableName.log

Puede encontrar todas las banderas explicadas en los siguientes enlaces:

  • https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html
  • https://dev.mysql.com/doc/refman/8.0/en/mysqlimport.html
  • https://dev.mysql.com/doc/refman/8.0/en/mysql.html

Si planea usar una copia de seguridad lógica en diferentes versiones de la base de datos, asegúrese de tener la configuración de intercalación correcta. La siguiente declaración se puede utilizar para comprobar el juego de caracteres y la intercalación predeterminados para una base de datos determinada:

USE mydatabase;
SELECT @@character_set_database, @@collation_database;

Otra forma de recuperar la variable del sistema collation_database es usar MOSTRAR VARIABLES.

SHOW VARIABLES LIKE 'collation%';

Debido a las limitaciones del volcado de mysql, a menudo tenemos que modificar la salida. Un ejemplo de tal modificación puede ser la necesidad de eliminar algunas líneas. Afortunadamente, tenemos la flexibilidad de ver y modificar la salida usando herramientas de texto estándar antes de restaurar. Herramientas como awk, grep, sed pueden convertirse en tus amigas. A continuación se muestra un ejemplo simple de cómo eliminar la tercera línea del archivo de volcado.

sed -i '1,3d' file.txt

Las posibilidades son infinitas. Esto es algo que no encontraremos con Oracle ya que los datos se escriben en formato binario.

Hay algunas cosas que debe tener en cuenta cuando ejecuta mysql lógico. Una de las principales limitaciones es el soporte puro del paralelismo y el bloqueo de objetos.

Consideraciones de respaldo lógico

Cuando se ejecuta dicha copia de seguridad, se realizarán los siguientes pasos.

  • Mesa LOCK TABLE.
  • MOSTRAR mesa CREAR TABLA.
  • SELECCIONE * DE la tabla AL archivo temporal OUTFILE.
  • Escriba el contenido del archivo temporal al final del archivo de volcado.
  • DESBLOQUEAR MESAS

De manera predeterminada, mysqldump no incluye rutinas y eventos en su salida; debe establecer explícitamente --routines y --events flags.

Otra consideración importante es el motor que utiliza para almacenar sus datos. Con suerte, en estos días, la mayoría de los sistemas de producción utilizan un motor compatible con ACID llamado InnoDB. El motor anterior MyISAM tenía que bloquear todas las tablas para garantizar la coherencia. Esto es cuando se ejecutó FLUSH TABLES WITH READ LOCK. Desafortunadamente, es la única forma de garantizar una instantánea consistente de las tablas MyISAM mientras se ejecuta el servidor MySQL. Esto hará que el servidor MySQL sea de solo lectura hasta que se ejecute UNLOCK TABLES.

Para las tablas en el motor de almacenamiento InnoDB, se recomienda utilizar la opción --single-transaction. MySQL luego produce un punto de control que permite que el volcado capture todos los datos antes del punto de control mientras recibe los cambios entrantes.

La opción --single-transaction de mysqldump no FLUSH TABLES WITH READ LOCK. Hace que mysqldump configure una transacción de LECTURA REPETIBLE para todas las tablas que se vuelcan.

Una copia de seguridad de mysqldump es mucho más lenta que las herramientas de Oracle exp, expdp. Mysqldump es una herramienta de subproceso único y este es su inconveniente más importante:el rendimiento está bien para bases de datos pequeñas, pero rápidamente se vuelve inaceptable si el conjunto de datos crece a decenas de gigabytes.

  • INICIE LA TRANSACCIÓN CON UNA INSTANTÁNEA CONSISTENTE.
  • Para cada tabla y esquema de base de datos, un volcado realiza estos pasos:
    • MOSTRAR mesa CREAR TABLA.
    • SELECCIONE * DE la tabla AL archivo temporal OUTFILE.
    • Escriba el contenido del archivo temporal al final del archivo de volcado.
  • COMPROMISO.

Copias de seguridad físicas (RMAN)

Afortunadamente, la mayoría de las limitaciones de la copia de seguridad lógica se pueden resolver con la herramienta Percona Xtrabackup. Percona XtraBackup es el software de copia de seguridad en caliente MySQL/MariaDB de código abierto más popular que realiza copias de seguridad sin bloqueo para las bases de datos InnoDB y XtraDB. Cae en la categoría de copia de seguridad física, que consta de copias exactas del directorio de datos de MySQL y los archivos que se encuentran debajo.

Es la misma categoría de herramientas como Oracle RMAN. RMAN viene como parte del software de la base de datos, XtraBackup debe descargarse por separado. Xtrabackup está disponible como paquete rpm y deb y solo es compatible con plataformas Linux. La instalación es muy sencilla:

$ wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-8.0.4/binary/redhat/7/x86_64/percona-XtraBackup-80-8.0.4-1.el7.x86_64.rpm
$ yum localinstall percona-XtraBackup-80-8.0.4-1.el7.x86_64.rpm

XtraBackup no bloquea su base de datos durante el proceso de copia de seguridad. Para bases de datos grandes (más de 100 GB), proporciona un tiempo de restauración mucho mejor en comparación con mysqldump. El proceso de restauración implica preparar los datos de MySQL a partir de los archivos de respaldo, antes de reemplazarlos o cambiarlos con el directorio de datos actual en el nodo de destino.

Percona XtraBackup funciona recordando el número de secuencia de registro (LSN) cuando se inicia y luego copiando los archivos de datos a otra ubicación. La copia de datos lleva algún tiempo y, si los archivos están cambiando, reflejan el estado de la base de datos en diferentes momentos. Al mismo tiempo, XtraBackup ejecuta un proceso en segundo plano que vigila los archivos del registro de transacciones (también conocido como registro de rehacer) y copia los cambios. Esto debe hacerse continuamente porque los registros de transacciones se escriben de forma rotativa y se pueden reutilizar después de un tiempo. XtraBackup necesita los registros del registro de transacciones para cada cambio en los archivos de datos desde que comenzó la ejecución.

Cuando se instala XtraBackup, finalmente puede realizar sus primeras copias de seguridad físicas.

xtrabackup --user=root --password=PASSWORD --backup --target-dir=/u01/backups/

Otra opción útil que hacen los administradores de MySQL es la transmisión de copias de seguridad a otro servidor. Dicha transmisión se puede realizar con el uso de la herramienta xbstream, como en el siguiente ejemplo:

Inicie un oyente en el servidor externo en el puerto preferible (en este ejemplo, 1984)

nc -l 1984 | pigz -cd - | pv | xbstream -x -C /u01/backups

Ejecute la copia de seguridad y transfiera a un host externo

innobackupex --user=root --password=PASSWORD --stream=xbstream /var/tmp | pigz  | pv | nc external_host.com 1984

Como puede notar, el proceso de restauración se divide en dos pasos principales (similar a Oracle). Los pasos son restauración (copiar de nuevo) y recuperación (aplicar registro).

XtraBackup --copy-back --target-dir=/var/lib/data
innobackupex --apply-log --use-memory=[values in MB or GB] /var/lib/data

La diferencia es que solo podemos realizar la recuperación hasta el punto en que se realizó la copia de seguridad. Para aplicar los cambios después de la copia de seguridad, debemos hacerlo manualmente.

Restauración de un punto en el tiempo (recuperación RMAN)

En Oracle, RMAN realiza todos los pasos cuando realizamos la recuperación de la base de datos. Se puede hacer en SCN o en el tiempo o en función del conjunto de datos de copia de seguridad.

RMAN> run
{
allocate channel dev1 type disk;
set until time "to_date('2019-05-07:00:00:00', 'yyyy-mm-dd:hh24:mi:ss')";
restore database;
recover database; }

En mysql, necesitamos otra herramienta para extraer datos de registros binarios (similares a los registros de archivo de Oracle) mysqlbinlog. mysqlbinlog puede leer los registros binarios y convertirlos en archivos. Lo que tenemos que hacer es

El procedimiento básico sería

  • Restaurar copia de seguridad completa
  • Restaurar copias de seguridad incrementales
  • Para identificar las horas de inicio y finalización de la recuperación (que podría ser el final de la copia de seguridad y el número de posición antes de, lamentablemente, descartar la tabla).
  • Convierta los binglogs necesarios a SQL y aplique los archivos SQL recién creados en la secuencia adecuada; asegúrese de ejecutar un solo comando mysqlbinlog. 
    > mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p

Cifrar copias de seguridad (Oracle Wallet)

Percona XtraBackup se puede utilizar para cifrar o descifrar copias de seguridad locales o de transmisión con la opción xbstream para agregar otra capa de protección a las copias de seguridad. Tanto la opción --encrypt-key como la opción --encryptkey-file se pueden usar para especificar la clave de cifrado. Las claves de cifrado se pueden generar con comandos como

$ openssl rand -base64 24
$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1

Este valor se puede utilizar como clave de cifrado. Ejemplo del comando innobackupex utilizando --encrypt-key:

$ innobackupex --encrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1” /storage/backups/encrypted

Para descifrar, simplemente use la opción --decrypt con la --encrypt-key adecuada:

$ innobackupex --decrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1”
/storage/backups/encrypted/2019-05-08_11-10-09/

Políticas de copia de seguridad

No hay una funcionalidad de política de copia de seguridad integrada en MySQL/MariaDB o incluso en la herramienta de Percona. Si desea administrar sus copias de seguridad físicas o lógicas de MySQL, puede usar ClusterControl para eso.

ClusterControl es el sistema de administración de bases de datos de código abierto con todo incluido para usuarios con entornos mixtos. Proporciona funciones avanzadas de gestión de copias de seguridad para MySQL o MariaDB.

Con ClusterControl puede:

  • Crear políticas de copia de seguridad
  • Supervise el estado de las copias de seguridad, las ejecuciones y los servidores sin copias de seguridad
  • Ejecute copias de seguridad y restauraciones (incluida una recuperación de un punto en el tiempo)
  • Controle la retención de copias de seguridad
  • Guardar copias de seguridad en el almacenamiento en la nube
  • Validar copias de seguridad (prueba completa con la restauración en el servidor independiente)
  • Cifrar copias de seguridad
  • Comprimir copias de seguridad
  • Y muchos otros
ClusterControl:Gestión de copias de seguridad

Mantenga copias de seguridad en la nube

Históricamente, las organizaciones han implementado soluciones de respaldo en cinta como un medio para proteger
los datos de fallas. Sin embargo, la aparición de la computación en la nube pública también ha permitido nuevos modelos con un TCO más bajo que el que tradicionalmente ha estado disponible. No tiene sentido comercial abstraer el costo de una solución DR del diseño de la misma, por lo que las organizaciones deben implementar el nivel correcto de protección al menor costo posible.

La nube ha cambiado la industria de las copias de seguridad de datos. Debido a su precio asequible, las empresas más pequeñas tienen una solución externa que realiza una copia de seguridad de todos sus datos (y sí, asegúrese de que esté encriptada). Tanto Oracle como MySQL no ofrecen soluciones integradas de almacenamiento en la nube. En su lugar, puede utilizar las herramientas proporcionadas por los proveedores de la nube. Un ejemplo aquí podría ser s3.

aws s3 cp severalnines.sql s3://severalnine-sbucket/mysql_backups

Conclusión

Hay varias formas de hacer una copia de seguridad de su base de datos, pero es importante revisar las necesidades comerciales antes de decidir una estrategia de copia de seguridad. Como puede ver, hay muchas similitudes entre las copias de seguridad de MySQL y Oracle que, con suerte, pueden cumplir con sus SLA.

Siempre asegúrese de practicar estos comandos. No solo cuando es nuevo en la tecnología, sino también cuando DBMS se vuelve inutilizable para que sepa qué hacer.

Si desea obtener más información sobre MySQL, consulte nuestro documento técnico La guía DevOps para copias de seguridad de bases de datos para MySQL y MariaDB.