Copia de seguridad y restablecimiento de MySQL

Existen dos formas principales de crear una copia de seguridad de una base de datos de MySQL: física y lógicode Google Analytics. La copia de seguridad física copia los archivos de datos reales y la copia de seguridad lógica genera declaraciones, como CREATE TABLE y INSERT, que pueden recrear los datos.

Una copia de seguridad física contiene las copias sin procesar de todos los archivos y directorios tal como existen en el disco. Este tipo de copia de seguridad es adecuada para bases de datos grandes, ya que copiar los archivos sin procesar es mucho más rápido que realizar una copia de seguridad lógica.

Ventajas:

• Las copias de seguridad físicas son sencillas y eficientes. no necesitan mucha memoria o muchos ciclos de CPU para ejecutarse

• Las copias de seguridad físicas no requieren ningún trabajo adicional para generar los archivos sin procesar; solo tienes que copiar los archivos y directorios sin procesar en la ubicación de la copia de seguridad

• Las copias de seguridad físicas se restablecen con mayor rapidez que las lógicas, ya que MySQL no tiene que volver a crear objetos de base de datos ni importar datos.

Desventajas:

• Las copias de seguridad físicas a menudo ocupan mucho más espacio que las lógicas, ya que contienen registros de transacciones, registros de deshacer y otros, además de los espacios de tabla de InnoDB (que son compartidos y por archivos de table.ibd, por lo general, tienen espacio fragmentado).

• Las copias de seguridad físicas no siempre se pueden usar en las plataformas, los sistemas operativos y las versiones de MySQL

• Dado que las copias de seguridad físicas copian los archivos sin procesar, si tienen daños subyacentes, también se copiarán en los archivos de copias de seguridad

Algunas herramientas comunes de copia de seguridad física en el ecosistema de MySQL

• Copia de seguridad de MySQL Enterprise 
• Percona XtraBackup 
• MariaDB Marianabackup

Una copia de seguridad lógica contiene los datos de la base de datos de una forma que MySQL puede interpretar como SQL o como texto delimitado. Es una representación de tu base de datos como una secuencia de instrucciones de SQL que se puede ejecutar para volver a crear objetos de base de datos y también importar datos. Este tipo de copia de seguridad es adecuada para bases de datos pequeñas, ya que las copias de seguridad lógicas pueden tardar mucho más en restablecerse que las que se restablecen. Este tipo de copia de seguridad también es útil cuando se migra hacia los servicios de bases de datos administrados en la nube o desde ellos.

Ventajas:

• Las copias de seguridad lógicas son muy flexibles. Ofrecen un nivel de detalle alto en las operaciones de copia de seguridad y restablecimiento a nivel del servidor (todas las bases de datos), a nivel de la base de datos (todas las tablas en una base de datos particular), a nivel de la tabla o incluso a nivel de la fila (tabla). filas que coinciden con la condición WHERE). 

• Las copias de seguridad lógicas son más fáciles de restablecer: Solo debes canalizar el archivo de copia de seguridad al cliente MySQL y usar la instrucción CARGAR DATOS o el comando mysqlimport para cargar los archivos delimitados por texto.

• Las copias de seguridad lógicas se pueden ejecutar de forma remota desde otra máquina, lo que te permite hacer una copia de seguridad de tu base de datos y restablecerla en una red. Esto es muy útil para las bases de datos de Cloud, como Google Cloud SQL, Amazon RDS y Microsoft Azure, en las que los usuarios no tienen acceso directo a la máquina virtual.

• Las copias de seguridad lógicas ayudan a evitar la corrupción de datos. Las copias de seguridad físicas pueden dañarse y pasar desapercibidas hasta la verificación. Como las copias de seguridad lógicas suelen ser archivos de texto, es más fácil revisarlas con un editor de texto y detectar cualquier daño. Las copias de seguridad lógicas rara vez se dañan.

• A diferencia de las copias de seguridad físicas, las copias de seguridad lógicas son altamente portátiles entre plataformas, sistemas operativos y versiones de MySQL. 

• Las copias de seguridad lógicas tienen un alto nivel de compresión.

Desventajas:

• Las copias de seguridad lógicas tienen un proceso de creación más lento, ya que es necesario consultar el servidor MySQL para obtener el esquema y las filas y, luego, convertirlas a un formato lógico

• Las copias de seguridad lógicas también tardan más en restablecerse, ya que MySQL necesita ejecutar instrucciones de SQL para crear la tabla, importar las filas y volver a compilar los índices

• En comparación con las copias de seguridad físicas, las copias de seguridad lógicas requieren más recursos de servidor (CPU, RAM y E/S de disco) para las operaciones de copia de seguridad y restablecimiento

Algunas herramientas comunes de copia de seguridad lógica

• mysqldump
• mydumper
• mysqlpump

MySQL shell utilities — dump | load

Como su nombre lo sugiere, la recuperación de un momento determinado te ayuda a recuperar una instancia en un momento específico. Por ejemplo, si un error provoca pérdida de datos, puedes recuperar el estado de una base de datos antes de que se produjera el error.

La PITR es un proceso de dos pasos que se basa en registros binarios:

1. Restablecer una copia de seguridad física o lógica completa para que el servidor vuelva al estado en el que se encontraba en el momento de la copia de seguridad. 
2. Aplica los registros binarios para volver a reproducir los cambios entre el momento de la copia de seguridad y el momento deseado

Los registros binarios contienen cualquier cambio realizado en la instancia de base de datos, como crear tabla, insertar, actualizar o borrar filas, y mucho más. Por ejemplo, supongamos que tus copias de seguridad diarias se ejecutan a las 6:00 a.m. y quieres poder recuperar tu instancia en cualquier momento hasta las 10:15 a.m. Para recuperar tu estado a las 10:15 a.m., primero debes restablecer la copia de seguridad completa a las 6:00 a.m. y, luego, volver a reproducir los eventos del registro binario desde las 6:00 a.m. hasta las 10:15 a.m. Esto mantendrá el servidor en el estado deseado en el momento deseado.

Se requieren registros binarios para la replicación y la PITR. son tan importantes como los datos subyacentes. Se debe crear una copia de seguridad de los registros binarios en tiempo real para que sean eficaces en tu planificación de recuperación. Puedes descargarlos con el comando mysqlbinlog.

Por ejemplo:

<binlog_filename> será el primer archivo que se descargará, y mysqlbinlog pasará automáticamente a los archivos siguientes. Esos registros binarios se escriben en el directorio actual del servidor que ejecuta el comando mysqlbinlog. Puedes cambiar el nombre del archivo y la ubicación con la opción --result-file. También puedes usar la opción --stop-never para permitir que mysqlbinlog binlog permanezca conectado al servidor y descargue los cambios nuevos a medida que se escriben.

Puedes obtener más información en el manual mysqlbinlog para conectarte a un servidor remoto y descargar los registros binarios a medida que se escriben.

Como servicio de base de datos administrada de Google Cloud para MySQL, Cloud SQL ofrece copias de seguridad automáticas y recuperación de un momento determinado (PITR) para proteger los datos. Están habilitados de forma predeterminada y son necesarios para habilitar la alta disponibilidad (HA) en una instancia de Cloud SQL para MySQL. 

  Cualquier copia de seguridad de Cloud SQL es un tipo de copia de seguridad física, ya que son instantáneas tomadas en Persistent Disk (PD). Cloud SQL ofrece la flexibilidad de hacer que las copias de seguridad se realicen automáticamente o puedes realizarlas a pedido en cualquier momento. Aún puedes realizar una copia de seguridad lógica con las herramientas estándar de MySQL para copias de seguridad, como mysqldump, mydumper, mysqlpump y otras, sin interferir en tus copias de seguridad administradas. 

Analicemos cómo funcionan las copias de seguridad de Cloud SQL.

Cloud SQL usa disco persistente (PD) para el almacenamiento, y cada instancia de Cloud SQL tiene un disco de datos persistente conectado a fin de almacenar los archivos de la base de datos y los directorios.

Cloud SQL usa instantáneas de PD para las copias de seguridad, que hacen referencia al estado del disco de datos en un momento determinado. La primera instantánea de un PD es una instantánea completa que contiene todos los datos del PD, mientras que las posteriores son incrementales y solo contienen datos nuevos o modificados desde la instantánea anterior. Piensa en estas instantáneas como copias físicas administradas en la nube de discos de datos persistentes y son la base de todas las funciones de copia de seguridad y restablecimiento de Cloud SQL, incluida la PITR.

Cloud SQL realiza dos tipos de copias de seguridad administradas: automatizadas y a pedido. Ambos tipos se almacenan en la ubicación multirregional más cercana a la instancia de forma predeterminada. Por ejemplo, si tu instancia de Cloud SQL en us-central1, tus copias de seguridad se almacenarán en la multirregión de EE.UU. de forma predeterminada. Sin embargo, una ubicación predeterminada como australia-southeast1 está fuera de una multirregión y se colocará en la multirregión más cercana, que es asia. También puedes elegir una ubicación personalizada para las copias de seguridad.

Copias de seguridad automáticas

Las copias de seguridad automáticas se realizan a diario durante un período de 4 horas que elijas. La copia de seguridad se inicia durante el período asignado y puede continuar fuera de este hasta que finalice. Puedes configurar la cantidad de copias de seguridad automáticas que se conservarán, de una a 365. La política de retención predeterminada es conservar las siete copias de seguridad más recientes.

Copias de seguridad a pedido

También puedes crear copias de seguridad a pedido en cualquier momento. Son útiles si necesitas una copia de seguridad y no quieres esperar el período asignado. Además, a diferencia de las copias de seguridad automáticas, las copias de seguridad a pedido no se borran automáticamente. Estas persisten hasta que las borres o hasta que se borre su instancia.

Puedes restablecer una copia de seguridad en la misma instancia en la que se tomó o en una instancia diferente en el mismo proyecto. Ten en cuenta que la instancia de destino no debe ser una réplica de lectura en sí misma, ni debe tener réplicas de lectura cuando se restablece la copia de seguridad, ya que las réplicas de lectura son copias de una instancia principal y crean el riesgo de que las réplicas se obtengan de sincronización con el primario. Siempre puedes agregar réplicas de lectura posteriormente.

Cuando se restablece la copia de seguridad, se crea un PD nuevo a partir de esa instantánea de copia de seguridad y se adjunta a la instancia. La base de datos comienza a usar el disco nuevo y realiza el proceso de recuperación ante fallas estándar de MySQL antes de ponerse en línea como una base de datos de MySQL completa y recién restablecida a partir de la instantánea.

Restablece a la misma instancia

Cuando restableces a partir de una copia de seguridad a la misma instancia, puedes regresar los datos de esa instancia al estado que tenían al copiarla. 

Restablece a una instancia diferente

Cuando restableces a partir de una copia de seguridad a una instancia diferente, se actualizan los datos en la instancia de destino al estado de la de origen cuando realizaste la copia.

Importante: Cuando se restablece una copia de seguridad, se reemplazan todos los datos actuales en la instancia de destino, incluidos los registros anteriores de recuperación de un momento determinado. Los datos reemplazados no se pueden recuperar.

En Cloud SQL, PITR siempre crea una instancia nueva que hereda la configuración de la instancia de origen, similar a la operación de instancia de clonación. Esta función requiere que se habiliten las copias de seguridad automáticas y la recuperación de un momento determinado (registros binarios) en la instancia de origen. La política de retención predeterminada de los registros binarios es de 7 días, y puedes configurar el período de retención de entre 1 y 7 días.

La PITR se logra mediante la creación de una instancia nueva a partir de la copia de seguridad de la instancia original y la repetición de los registros binarios almacenados en el disco de datos de la instancia original hasta el punto determinado. 

Cuando realizan una PITR en Cloud SQL, los clientes pueden optar por clonar el estado actual de la instancia o clonarlo en una marca de tiempo anterior. 

La IU para realizar la PITR se verá de la siguiente manera.