Qué considerar cuando realiza una copia de seguridad de un servidor MySQL remoto con ZRM a través de Internet
Por Dmitri Joukovski y Pavel Pragin
La base de datos MySQL se ha convertido en la base de datos de código abierto más popular del mundo debido a su rendimiento rápido constante, alta confiabilidad y facilidad de uso. Es posible que esté usando la base de datos MySQL para sus foros en línea y wiki ubicados en el proveedor de alojamiento administrado, o puede que la esté usando en una oficina remota para rastrear errores con Bugzilla, o puede que simplemente esté pensando en desarrollar una nueva aplicación Web 2.0 que use MySQL. . De cualquier manera, si valora la información almacenada en su base de datos MySQL, necesitará garantizar copias de seguridad exitosas, seguras y consistentes de MySQL con un impacto mínimo en la aplicación de la base de datos. Asegúrese de que su solución de respaldo brinde el uso más eficiente de la red, el servidor y los recursos de almacenamiento.
Si está buscando una solución que simplifique su vida al brindarle una solución fácil de usar pero flexible y copia de seguridad y recuperación robustas para MySQL, Zmanda Recovery Manager (ZRM) podría ser la opción correcta para usted. Detalles sobre La funcionalidad ZRM está disponible aquí.
Para cualquier copia de seguridad de una base de datos, las consideraciones principales son la coherencia de la copia de seguridad y el impacto en los usuarios y las aplicaciones. Sin embargo, una copia de seguridad del MySQL remoto tiene desafíos adicionales relacionados con:
- uso de la red
- seguridad, y
- flexibilidad de recuperabilidad de datos MySQL en un host diferente.
El último punto podría ser importante cuando no tiene el control total de su entorno MySQL y desea tener una opción para recuperar sus datos en un proveedor de alojamiento administrado diferente con una versión diferente del servidor MySQL o un sistema operativo diferente.
Las copias de seguridad incrementales reducen significativamente la ventana de la copia de seguridad y el uso de la red porque solo los cambios desde la última copia de seguridad completa o incremental se mueven a través del cable. ZRM le facilita la recuperación de sus datos a partir de copias de seguridad incrementales, incluso si tiene que usar varias imágenes de copia de seguridad incrementales para que sus datos vuelvan a un punto en particular en el tiempo. Las copias de seguridad incrementales requieren que los registros binarios de MySQL estén habilitados, pero de acuerdo con la documentación de MySQL, la habilitación de los registros binarios dará como resultado impacto de rendimiento de menos del 1%.
Las copias de seguridad lógicas proporcionan más flexibilidad para la recuperación porque el archivo de copia de seguridad es un archivo de texto que contiene todas las declaraciones de MySQL para recrear tanto el esquema como el contenido de la base de datos. La copia de seguridad lógica funciona para todos los motores de almacenamiento, excepto el motor NDB que se utiliza para la agrupación en clústeres de MySQL. La mayor ventaja de la copia de seguridad lógica es la flexibilidad para la recuperación de una base de datos. Puede restaurar la copia de seguridad lógica de MySQL a otra arquitectura e incluso a otra base de datos. La transportabilidad de las imágenes de respaldo lógicas de ZRM hace que ZRM sea una herramienta conveniente para la migración. Por ejemplo, puede mover sus datos MySQL:
- De MySQL en Solaris a MySQL en Linux
- De un motor de almacenamiento a otro
- De un servidor de 32 bits a un servidor de 64 bits
- Desde un proveedor de alojamiento administrado hasta su centro de datos u otro proveedor con una configuración de MySQL diferente
Por supuesto, hay un precio que pagar por una recuperación tan flexible. La restauración de los datos de las copias de seguridad lógicas puede llevar mucho tiempo, ya que debe leer y reproducir todas las declaraciones de MySQL. Otro inconveniente es que podría ser difícil predecir el tamaño de su copia de seguridad lógica. Según el tipo de datos y el esquema de su base de datos, el tamaño de la copia de seguridad lógica podría ser mayor que la base de datos en sí. Un remedio es que, dado que la copia de seguridad lógica es básicamente un archivo de texto, normalmente puede obtener una compresión decente.
La copia de seguridad sin formato proporciona una copia coherente de una base de datos y su copia de seguridad es un archivo binario. Las ventajas de las copias de seguridad sin procesar sobre las copias de seguridad lógicas son:
- Las copias de seguridad y especialmente las recuperaciones son mucho más rápidas. Por ejemplo, no es inusual ver que para la misma base de datos con un tamaño de 4-5 GB, la copia de seguridad sin formato es 5 veces más rápida que la copia de seguridad lógica y la recuperación de la imagen de copia de seguridad sin formato es 20 veces más rápida que la recuperación de la copia de seguridad lógica. imagen.
- Siempre sabrá el tamaño exacto de su copia de seguridad, ya que es solo una copia de una base de datos.
- Proporciona una mejor escalabilidad, lo que podría ser importante si su base de datos MySQL es bastante grande, por ejemplo, de 10 a 20 GB o más.
Las copias de seguridad sin procesar SÓLO se pueden recuperar en la misma versión del servidor MySQL en el mismo sistema operativo que los datos originales. Significa que sus posibilidades de recuperar imágenes de copia de seguridad sin procesar de MySQL en otro proveedor de alojamiento administrado no son muy altas y debe tenerlo en cuenta al elegir una copia de seguridad sin formato frente a una copia de seguridad lógica.
Tanto las copias de seguridad en bruto como las lógicas proporcionan una copia de seguridad en caliente, lo que significa que no es necesario apagar el servidor MySQL para realizar la copia de seguridad, pero todas las tablas se bloquean durante la copia de seguridad y los usuarios no pueden ingresar sus datos. Es por eso que debería considerar el uso del complemento de programación ZRM que permite retrasar las copias de seguridad en función de los umbrales que defina. Por ejemplo, puede posponer la copia de seguridad durante una hora si más de 50 usuarios acceden a la base de datos.
Una de las consideraciones importantes para la copia de seguridad remota de MySQL es la decisión sobre qué tipo de conexión establecer entre ZRM y el servidor MySQL remoto. ZRM proporciona un complemento para la conexión basada en zócalos y otro complemento para la conexión basada en SSH. La arquitectura flexible de ZRM permite a los usuarios escribir sus propios complementos.
Como sugiere el nombre, el complemento de copia de socket establece un socket que proporciona comunicación entre ZRM y MySQL a través de una red basada en IP. El complemento de copia de socket requiere que el servicio xinetd se esté ejecutando en el servidor MySQL y que el puerto predeterminado 25300 esté abierto. Si es necesario, un administrador de respaldo puede cambiar el puerto. El complemento de copia de socket no es seguro y debe usarse solo cuando la seguridad no es un problema o cuando la seguridad se establece por otros medios, por ejemplo, cuando tiene una conexión VPN entre ZRM y su servidor MySQL remoto.
El complemento de copia SSH proporciona un canal seguro entre ZRM y el servidor MySQL remoto. Utiliza criptografía de clave pública para autenticar el servidor MySQL remoto y el usuario de respaldo que ejecuta ZRM. El complemento SSH requiere que el puerto TCP estándar 22 esté abierto y que el demonio SSH esté en ejecución. El complemento de copia SSH es más adecuado cuando es importante garantizar la seguridad de los datos de respaldo. Dado que la conexión SSH requiere ciclos de CPU adicionales para el cifrado, puede haber un impacto en el rendimiento de la copia de seguridad en comparación con la copia de seguridad con conexión de socket.
La siguiente tabla resume las consideraciones al elegir el complemento de copia de socket frente a SSH para la copia de seguridad remota de MySQL:
| Conección remota plug-in |
Puerto utilizado | Seguridad | Desempeño relativo | Comentarios de instalación |
|---|---|---|---|---|
| Copia SSH | 22 (fijo) | Proporciona autenticación y cifrado sólidos para transferir datos de respaldo a través del cable | Rendimiento más bajo y depende de la memoria del servidor MySQL, los recursos de la CPU y el ancho de banda disponible. | A menudo, es posible que tenga una conexión SSH a un servidor MySQL remoto ya establecido por razones distintas a la copia de seguridad y la recuperación. De lo contrario, debe establecer una conexión SSH entre ZRM y el servidor MySQL. |
| Copia de socket | 25300 (se puede cambiar) | Los datos de respaldo por cable no son seguros | Mayor rendimiento | Se debe instalar software adicional en el servidor MySQL. Por ejemplo, para la versión Enterprise de ZRM 1.1, use MySQL-zrm-enterprise-socket-server-1.1-1.noarch.rpm. Para la versión comunitaria, consulte la página de descargas para conocer el paquete exacto. |
Para obtener más detalles técnicos, regístrese de forma gratuita en Zmanda Network y descargue la versión completa de este documento técnico. Aprenderá a usar ZRM para varios escenarios comunes. Por ejemplo, proporcionaremos detalles técnicos sobre cómo realizar una copia de seguridad con los datos seguros en el cable y en reposo utilizando el complemento de copia SSH para este caso de uso:
Además, proporcionaremos detalles técnicos sobre copias de seguridad lógicas y sin formato más eficientes utilizando el complemento de copia de socket.
Con toda su rica funcionalidad, ZRM para MySQL es solo una herramienta para implementar una estrategia de respaldo y recuperación óptima para sus necesidades específicas de protección de datos. ZRM es robusto y fácil de usar, pero dependiendo de su propia implementación del servidor MySQL remoto y sus requisitos específicos de respaldo y recuperación, debe considerar todas las compensaciones asociadas con cada opción operativa proporcionada por ZRM para MySQL.
Referencias:
ZRM para MySQL
Wiki de ZRM para MySQL
Foros de Zmanda