El núcleo de ClusterControl es su automatización, al igual que garantizar que sus datos estén respaldados de forma segura y listos para restaurarse cuando algo salga mal. Tener una estrategia de copia de seguridad y un plan de recuperación ante desastres eficaz es clave para el éxito de cualquier aplicación o entorno.
En nuestra última versión, ClusterControl 1.5, hemos introducido una serie de mejoras para realizar copias de seguridad de sistemas basados en MySQL y MariaDB.
Una de las mejoras clave es la capacidad de realizar copias de seguridad desde ClusterControl al proveedor de la nube de su elección. Los proveedores de la nube como Google Cloud Services y Amazon S3 ofrecen almacenamiento prácticamente ilimitado, lo que reduce las necesidades de espacio local. Esto le permite retener sus archivos de copia de seguridad por más tiempo, durante el tiempo que desee y no tener preocupaciones sobre el espacio en el disco local.
Exploremos todas las nuevas y emocionantes funciones de copia de seguridad para ClusterControl 1.5...
Rediseño del asistente de copia de seguridad/restauración
En primer lugar, notará que los asistentes de copia de seguridad y restauración se han renovado para mejorar la experiencia del usuario. Ahora se cargará como un menú lateral a la derecha de la pantalla:
La lista de copias de seguridad también recibe un ajuste menor en el que se muestran los detalles de la copia de seguridad al hacer clic en la copia de seguridad en particular:
Podrá ver la ubicación de la copia de seguridad y qué bases de datos están dentro de la copia de seguridad. También hay opciones para restaurar la copia de seguridad o subirla a la nube.
Copia de seguridad compatible con PITR
ClusterControl realiza la copia de seguridad estándar de mysqldump con esquemas y volcados de datos separados. Esto facilita la restauración de copias de seguridad parciales. Sin embargo, rompe la coherencia de la copia de seguridad (el esquema y los datos se vuelcan en dos sesiones separadas), por lo que no se puede utilizar para aprovisionar una recuperación secundaria o puntual.
Una copia de seguridad compatible con mysqldump PITR contiene un solo archivo de volcado, con información de GTID, archivo binlog y posición. Por lo tanto, solo el nodo de la base de datos que produce el registro binario tendrá disponible la opción "compatible con PITR", como se destaca en la siguiente captura de pantalla:
Cuando se activa la opción compatible con PITR, los campos de la base de datos y la tabla aparecen atenuados, ya que ClusterControl siempre realizará la copia de seguridad de todas las bases de datos, eventos, disparadores y rutinas del servidor MySQL de destino.
Las siguientes líneas aparecerán en las primeras ~50 líneas del archivo de volcado completo:
$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...La información se puede usar para crear esclavos a partir de la copia de seguridad o realizar una recuperación puntual junto con registros binarios, donde puede iniciar la recuperación desde MASTER_LOG_FILE y MASTER_LOG_POS informados en el archivo de volcado utilizando la utilidad "mysqlbinlog". Tenga en cuenta que ClusterControl no realiza una copia de seguridad de los registros binarios.
Crear esclavos a partir de una copia de seguridad Otra característica es la capacidad de crear un esclavo directamente desde una copia de seguridad compatible con PITR, en lugar de hacerlo desde un maestro elegido. Esta es una gran ventaja ya que descarga el servidor maestro. Esta opción se puede utilizar con MySQL Replication o Galera Cluster. Se puede usar una copia de seguridad existente para reconstruir un esclavo de replicación existente o agregar un nuevo esclavo de replicación durante la fase de preparación, como se muestra en la siguiente captura de pantalla:
Una vez que se complete la puesta en escena, el esclavo se conectará al maestro elegido y comenzará a ponerse al día. Anteriormente, ClusterControl realizaba una copia de seguridad de transmisión directamente desde el maestro elegido utilizando Percona Xtrabackup. Esto podría afectar el rendimiento del maestro al escalar un conjunto de datos grande, a pesar de que la operación no bloquee el maestro. Con la nueva opción, si la copia de seguridad se almacena en ClusterControl, solo estos hosts (ClusterControl + el esclavo) estarán ocupados al almacenar los datos en el esclavo.
Copia de seguridad en la nube
Las copias de seguridad ahora se pueden cargar automáticamente en la nube. Esto requiere que se instale un módulo ClusterControl, llamado clustercontrol-cloud (módulo de integración en la nube) y clustercontrol-clud (CLI de carga/descarga en la nube) que están disponibles en v1.5 y posteriores. Las instrucciones de actualización se han incluido con estos paquetes y vienen sin ninguna configuración adicional. Por el momento, las plataformas en la nube admitidas son Amazon Web Services y Google Cloud Platform. Las credenciales de la nube se configuran en ClusterControl -> Configuración -> Integraciones -> Proveedores de la nube.
Al crear o programar una copia de seguridad, debería ver las siguientes opciones adicionales cuando se activa "Cargar copia de seguridad en la nube":
La característica permite una carga única o programar copias de seguridad para que se carguen después de la finalización (Amazon S3 o Google Cloud Storage). A continuación, puede descargar y restaurar las copias de seguridad según sea necesario.
Compresión personalizada para mysqldump
De hecho, esta característica se introdujo por primera vez con ClusterControl v1.4.2 después de su lanzamiento. Agregamos un nivel de compresión de respaldo basado en gzip. Anteriormente, ClusterControl usaba la compresión de copia de seguridad predeterminada (nivel 6) si el destino de la copia de seguridad estaba en el nodo del controlador. Se usó la compresión más baja (nivel 1:más rápida, menos compresión) si el destino de la copia de seguridad estaba en el propio host de la base de datos, para garantizar un impacto mínimo en la base de datos durante la operación de compresión.
En esta versión, hemos pulido el aspecto de la compresión y ahora puede personalizar el nivel de compresión, independientemente del destino de la copia de seguridad. Al actualizar su instancia de ClusterControl, todas las copias de seguridad programadas se convertirán automáticamente para usar el nivel 6, a menos que las edite explícitamente en v1.5.
La compresión de respaldo es vital cuando su conjunto de datos es grande, combinado con una política de retención de respaldo prolongada, mientras que el espacio de almacenamiento es limitado. Mysqldump, que está basado en texto, puede beneficiarse de la compresión con un ahorro de hasta el 60 % del espacio en disco del tamaño del archivo original. En algunas ocasiones, la relación de compresión más alta es la mejor opción, aunque tiene el precio de una descompresión más prolongada al restaurar.
Característica adicional:verificación de copia de seguridad automática
Como dicen los viejos administradores de sistemas:una copia de seguridad no es una copia de seguridad si no se puede restaurar. La verificación de copias de seguridad es algo que muchos suelen descuidar. Algunos administradores de sistemas han desarrollado rutinas internas para esto, generalmente más manuales que automatizadas. Automatizarlo es difícil, principalmente debido a la complejidad de la operación en su conjunto:desde el aprovisionamiento del host, la instalación y preparación de MySQL, la transferencia de archivos de copia de seguridad, la descompresión, la operación de restauración, los procedimientos de verificación y, finalmente, la limpieza del sistema después del proceso. Todas estas molestias hacen que las personas descuiden un aspecto tan importante de una copia de seguridad confiable. En general, se debe realizar una prueba de restauración de respaldo al menos una vez al mes, o en caso de cambios significativos en el tamaño de los datos o la estructura de la base de datos. Encuentra un horario que funcione para ti y formalízalo con un evento programado.
ClusterControl puede automatizar la verificación de la copia de seguridad realizando la restauración en un host nuevo, sin comprometer ninguno de los procedimientos de verificación mencionados anteriormente. Esto se puede hacer después de un tiempo o justo después de que se haya completado la copia de seguridad. Informará el estado de la copia de seguridad según el código de salida de la operación de restauración, realizará un apagado automático si se verifica la copia de seguridad o simplemente dejará que el host restaurado se ejecute para que realice verificaciones manuales adicionales en los datos.
Al crear o programar una copia de seguridad, tendrá opciones adicionales si se activa "Verificar copia de seguridad":
Si está habilitado "Instalar software de base de datos", ClusterControl eliminará cualquier instalación de MySQL existente en el host de destino y reinstalará el software de base de datos con la misma versión que el servidor MySQL existente. De lo contrario, si tiene una configuración específica para el host restaurado, puede omitir esta opción. El resto de las opciones se explican por sí mismas.
Característica adicional:no se olvide de PostgreSQL
Además de toda esta excelente funcionalidad para MySQL y MariaDB, ClusterControl 1.5 ahora también proporciona a PostgreSQL un método de copia de seguridad adicional (pg_basebackup) que se puede utilizar para copias de seguridad binarias en línea. Las copias de seguridad realizadas con pg_basebackup se pueden usar más tarde para la recuperación de un punto en el tiempo y como punto de partida para un envío de registros o servidores en espera de replicación de transmisión.
Eso es todo por ahora. Pruebe ClusterControl v1.5, juegue con las nuevas funciones y díganos lo que piensa.
