Copia de seguridad y restablecimiento de MySQL
Cuando sucede lo inesperado, tu empresa puede verse afectada. Las fallas de hardware, los daños de bases de datos, los errores de los usuarios y hasta los ataques maliciosos pueden crear un riesgo de pérdida de datos. Las copias de seguridad de la base de datos te ayudan a recuperar y mantener a tu empresa en funcionamiento, incluso si algo sale mal. Cuando todo va bien, las copias de seguridad de la base de datos te ayudan a cumplir con los requisitos de auditoría y cumplimiento, ya que te permiten restablecer la base de datos a un momento específico en el pasado.
MySQL admite varias opciones para crear copias de seguridad de tus bases de datos, cada una con diferentes fortalezas. Puedes elegir la combinación de métodos que mejor se adapte a tus necesidades.
Tipos de copia de seguridad
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.
Copia de seguridad física
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 tableb., 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 lógica
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 crear y hacer una copia de seguridad de tu base de datos 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 los datos. Las copias de seguridad físicas pueden dañarse, lo que puede pasar inadvertido hasta la verificación. Dado que 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 corrupción. Las copias de seguridad lógicas no suelen dañarse.
- A diferencia de las copias de seguridad físicas, las copias de seguridad lógicas son altamente portátiles en todas las plataformas, sistemas operativos y versiones de MySQL.
- Las copias de seguridad lógicas son muy comprimibles.
Desventajas:
- Las copias de seguridad lógicas son más lentas de crear, ya que necesitas consultar el servidor MySQL para obtener el esquema y las filas y, luego, convertirlos a un formato lógico.
- Las copias de seguridad lógicas también son más lentas de restablecer, ya que MySQL debe 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 del servidor (CPU, RAM y E/S de disco) para las operaciones de copia de seguridad y restablecimiento.
Algunas herramientas de copia de seguridad lógicas comunes
Recuperación de un momento determinado (PITR)
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 los registros binarios:
- Restablece una copia de seguridad física o lógica completa para que el servidor tenga el mismo estado que tenía en el momento en que se creó la copia de seguridad.
- 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 los cambios realizados en la instancia de la base de datos, como la creación de una tabla, la inserción, actualización o eliminación de filas y otros. Por ejemplo, supongamos que tus copias de seguridad diarias se ejecutan a las 6:00 a.m. y deseas poder recuperar la 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 desde las 6:00 a.m. y, luego, volver a reproducir los eventos de registro binarios de 6:00 a.m. a 10:15 a.m. a. m. Esto hará que el servidor alcance 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 efectivos en tu planificación de recuperación. Puedes descargarlos con el comando mysqlbinlog.
Por ejemplo:
|
mysqlbinlog --host=<nombre de host> --port=<port> --user=<usuario> --password=<contraseña> --read-from-remote-server --raw --stop-never <binlog_filename> |
<binlog_filename> será el primer archivo que se descargará, y mysqlbinlog cambiará automáticamente a los siguientes archivos posteriormente. 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 sobre cómo conectarte a un servidor remoto y descargar los registros binarios a medida que se escriben.
Copia de seguridad y restablecimiento en Cloud SQL para MySQL
Como servicio de base de datos administrado de Google Cloud para MySQL, Cloud SQL ofrece copias de seguridad automáticas y recuperación de un momento determinado (PITR) para la protección de 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 disco persistente (PD). Cloud SQL ofrece la flexibilidad para hacer copias de seguridad automáticas o puedes tomarlas a pedido en cualquier momento. Aún puedes realizar una copia de seguridad lógica mediante las herramientas de copia de seguridad lógica estándar de MySQL, como mysqldump, mydumper, mysqlpump y otras, sin interferir en las copias de seguridad administradas.
Analicemos cómo funcionan las copias de seguridad de Cloud SQL.
Información sobre las instantáneas 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, y estas instantáneas 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; las instantáneas posteriores son incrementales y solo contienen datos nuevos o datos modificados desde la instantánea anterior. Puedes considerar estas instantáneas como copias físicas administradas de 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 PITR.
Copias de seguridad de Cloud SQL
Cloud SQL realiza dos tipos de copias de seguridad administradas: automatizadas y a pedido. De forma predeterminada, ambos tipos se almacenan en la ubicación multirregión más cercana a la instancia. 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 ubicará en la multirregión más cercana, que es asia. También puedes elegir una ubicación personalizada para tus copias de seguridad.
Copias de seguridad automáticas
Las copias de seguridad automáticas se realizan a diario durante 4 horas. La copia de seguridad comienza durante el período de copia de seguridad y puede continuar fuera del período hasta que se complete. 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. Estos son útiles si necesitas una copia de seguridad y no quieres esperar al período asignado. Además, a diferencia de las copias de seguridad automáticas, las copias de seguridad a pedido no se borran de forma automática. Estas persisten hasta que las borres o hasta que se borre su instancia.
Restablece una copia de seguridad de Cloud SQL
Puedes restablecer una copia de seguridad en la misma instancia en la que se realizó o en una instancia diferente en el mismo proyecto. Ten en cuenta que la instancia de destino no debería ser una réplica de lectura en sí ni las 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 crea el riesgo de que las réplicas se desincronizan con la principal. 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 estándar de recuperación ante fallas de MySQL antes de conectarse en línea como una base de datos completa de MySQL que se acaba de restablecer 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.
Recuperación de un momento determinado (PITR) de Cloud SQL
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.
Productos y servicios relacionados
Google Cloud ofrece una base de datos administrada de MySQL que se adapta a las necesidades de tu empresa, desde la eliminación de tu centro de datos local hasta la ejecución de aplicaciones SaaS y la migración de los sistemas empresariales principales.
