Copias de seguridad:una de las cosas más importantes a tener en cuenta al administrar bases de datos. Se dice que hay dos tipos de personas:las que hacen copias de seguridad de sus datos y las que harán copias de seguridad de sus datos. En esta publicación de blog, analizaremos las buenas prácticas en torno a las copias de seguridad y le mostraremos cómo puede crear un sistema de copia de seguridad confiable utilizando ClusterControl.
Veremos cómo ClusterControl le proporciona una gestión centralizada de copias de seguridad para MySQL, MariaDB, MongoDB y PostgreSQL. Le proporciona copias de seguridad activas de grandes conjuntos de datos, recuperación puntual, cifrado de datos en reposo y en tránsito, integridad de datos a través de la verificación de restauración automática, copias de seguridad en la nube (AWS, Google y Azure) para recuperación ante desastres, políticas de retención para garantizar el cumplimiento y alertas e informes automatizados.
Tipos de copia de seguridad
Hay dos tipos principales de copia de seguridad que podemos hacer en ClusterControl:
- Copia de seguridad lógica:la copia de seguridad de los datos se almacena en un formato legible por humanos como SQL
- Copia de seguridad física:la copia de seguridad contiene datos binarios
Ambos se complementan entre sí:la copia de seguridad lógica le permite (más o menos fácilmente) recuperar hasta una sola fila de datos. Las copias de seguridad físicas requerirían más tiempo para lograrlo, pero, por otro lado, le permiten restaurar un host completo muy rápidamente (algo que puede llevar horas o incluso días cuando se utiliza la copia de seguridad lógica).
ClusterControl admite copias de seguridad para MySQL/MariaDB/Percona Server, PostgreSQL y MongoDB.
Copia de seguridad programada
Iniciar una copia de seguridad en ClusterControl es simple y eficiente usando un asistente. La programación de una copia de seguridad ofrece facilidad de uso y accesibilidad a otras funciones como el cifrado, la prueba/verificación automática de la copia de seguridad o el archivado en la nube.
Las copias de seguridad programadas disponibles se enumerarán en la pestaña Copias de seguridad programadas, como se ve en la siguiente imagen:
Como buena práctica para programar una copia de seguridad, ya debe tener su retención de copia de seguridad definida y se recomienda una copia de seguridad diaria. Sin embargo, también depende de los datos que necesite, el tráfico que puede esperar y la disponibilidad de los datos cuando los necesite, especialmente durante la recuperación de datos donde los datos se eliminaron accidentalmente o se dañó el disco, que son inevitables. También hay situaciones en las que la pérdida de datos es reproducible o se puede duplicar manualmente, como por ejemplo, generación de informes, miniaturas o datos en caché. Aunque la pregunta se basa en qué tan inmediatamente los necesita cada vez que ocurre un desastre; cuando sea posible, querrá realizar copias de seguridad de mysqldump y xtrabackup diariamente para MySQL aprovechando la disponibilidad de copias de seguridad lógicas y físicas. Para cubrir aún más bases, es posible que desee programar varias ejecuciones incrementales de xtrabackup por día. Esto podría ahorrar algo de espacio en disco, E/S de disco o incluso E/S de CPU en lugar de realizar una copia de seguridad completa.
En ClusterControl, puede programar fácilmente estos diferentes tipos de copias de seguridad. Hay un par de configuraciones para decidir. Puede almacenar una copia de seguridad en el controlador o localmente, en el nodo de la base de datos donde se realiza la copia de seguridad. Debe decidir la ubicación en la que se debe almacenar la copia de seguridad y qué bases de datos desea respaldar:¿todos los conjuntos de datos o esquemas separados? Vea la imagen a continuación:
La configuración Avanzada aprovecharía una configuración similar a cron para una mayor granularidad. Ver imagen a continuación:
Cada vez que ocurre una falla, ClusterControl maneja estos problemas de manera eficiente y produce registros para un diagnóstico posterior de la falla de la copia de seguridad.
Dependiendo del tipo de copia de seguridad que haya elegido, hay configuraciones separadas para configurar. Para Xtrabackup y Galera Cluster, puede tener las opciones para elegir qué configuraciones se aplicarían a su copia de seguridad física al ejecutarse. Ver a continuación:
- Usar compresión
- Nivel de compresión
- Nodo de desincronización durante la copia de seguridad
- Bloqueos de respaldo
- Bloquear DDL por tabla
- Hilos de copia en paralelo de Xtrabackup
- Velocidad de aceleración de transmisión de red (MB/s)
- Utilice PIGZ para gzip paralelo
- Habilitar cifrado
- Retención
Puede ver, en la imagen a continuación, cómo puede marcar las opciones en consecuencia y hay íconos de información sobre herramientas que brindan más información sobre las opciones que le gustaría aprovechar para su política de copia de seguridad.
Dependiendo de su política de respaldo, ClusterControl se puede adaptar de acuerdo con las mejores prácticas para actualizar sus respaldos disponibles. Al definir su política de copia de seguridad, se anticipa que debe tener disponible la configuración necesaria desde el hardware hasta el software y la nube, la durabilidad, la alta disponibilidad o la escalabilidad.
Al realizar copias de seguridad en un clúster de Galera, es una buena práctica configurar el nodo de Galera wsrep_desync=ON mientras se ejecuta la copia de seguridad. Esto evitará que el nodo participe en el control de flujo y protegerá a todo el clúster del retraso en la replicación, especialmente si los datos que se van a respaldar son grandes. En ClusterControl, tenga en cuenta que esto también puede eliminar su nodo de copia de seguridad de destino del conjunto de equilibrio de carga. Esto es especialmente cierto si utiliza proxies HAProxy, ProxySQL o MaxScale. Si tiene configurado un administrador de alertas en caso de que el nodo esté desincronizado, puede apagarlo durante ese período cuando se haya activado la copia de seguridad.
Otra forma popular de minimizar el impacto de una copia de seguridad en un Galera Cluster o un maestro de replicación es implementar un esclavo de replicación y luego usarlo como fuente de copias de seguridad; de esta manera, Galera Cluster no se verá afectado en ningún momento ya que la copia de seguridad en el el esclavo está desacoplado del clúster.
Puede implementar un esclavo de este tipo con solo unos pocos clics utilizando ClusterControl. Ver imagen a continuación:
y una vez que haga clic en ese botón, puede seleccionar en qué nodos configurar un esclavo. Asegúrese de que el registro binario de los nodos esté habilitado. La habilitación del registro binario también se puede hacer a través de ClusterControl, lo que agrega más factibilidad para administrar el maestro deseado. Ver imagen a continuación:
y también puede configurar un esclavo de replicación existente,
Para PostgreSQL, tiene opciones para realizar copias de seguridad lógicas o físicas. En ClusterControl, puede aprovechar sus copias de seguridad de PostgreSQL seleccionando pg_dump o pg_basebackup. pg_basebackup no funcionará para versiones anteriores a la 9.3.
Para MongoDB, ClusterControl ofrece coherencia con mongodump o mongodb. Es posible que deba tener en cuenta que mongodb consistente no es compatible con RHEL 7, pero es posible que pueda instalarlo manualmente.
De forma predeterminada, ClusterControl mostrará un informe de todas las copias de seguridad que se han realizado, con éxito o fallidas. Ver a continuación:
Puede consultar la lista de informes de copia de seguridad que se han creado o programado mediante ClusterControl. Dentro de la lista, puede ver los registros para una mayor investigación y diagnóstico. Por ejemplo, si la copia de seguridad finalizó correctamente de acuerdo con su política de copia de seguridad deseada, si la compresión y el cifrado están configurados correctamente, o si el tamaño de datos de copia de seguridad deseado es correcto. Esta es una buena manera de realizar una comprobación rápida de la cordura:si su conjunto de datos tiene un tamaño de alrededor de 1 GB, no hay forma de que una copia de seguridad completa sea tan pequeña como 100 KB; algo debe haber salido mal en algún momento.
Recuperación de desastres
El almacenamiento de copias de seguridad dentro del clúster (ya sea directamente en un nodo de base de datos o en el host de ClusterControl) es útil cuando desea restaurar rápidamente sus datos:todos los archivos de copia de seguridad están en su lugar y se pueden descomprimir y restaurar rápidamente. Cuando se trata de recuperación ante desastres (DR), esta puede no ser la mejor opción. Pueden ocurrir diferentes problemas:los servidores pueden fallar, la red puede no funcionar de manera confiable, incluso los centros de datos completos pueden no estar accesibles debido a algún tipo de interrupción. Puede suceder si trabaja con un proveedor de servicios más pequeño con un solo centro de datos o con un proveedor global como Amazon Web Services. Por lo tanto, no es seguro mantener todos sus huevos en una sola canasta; debe asegurarse de tener una copia de su copia de seguridad almacenada en alguna ubicación externa. ClusterControl es compatible con Amazon S3, Google Storage y Azure Cloud Storage.
Para aquellos que deseen implementar sus propias políticas de recuperación ante desastres, las copias de seguridad de ClusterControl se almacenan en un directorio bien estructurado. También tiene la opción de subir su copia de seguridad a la nube. Ver imagen a continuación:
Puede seleccionar y cargar en Amazon Web Services, Google Cloud y Microsoft Azure. Ver imagen a continuación:
Como buena práctica al archivar las copias de seguridad de su base de datos, asegúrese de que su destino de nube de destino esté basado en la misma región que sus servidores de base de datos, o al menos en la más cercana. Asegúrese de que ofrezca alta disponibilidad, durabilidad y escalabilidad; ya que debe considerar con qué frecuencia e inmediatez necesita sus datos.
Además de crear una copia de seguridad lógica o física para su DR, la creación de una instantánea completa de sus datos (por ejemplo, mediante LVM Snapshot, Amazon EBS Snapshots o Volume Snapshots si utiliza el sistema de archivos de Veritas) en el nodo en particular puede aumentar la recuperación de su copia de seguridad. También puede usar WAL (para Postgres) para su recuperación de punto en el tiempo (PITR) o sus registros binarios de MySQL para su PITR. Por lo tanto, debe considerar que es posible que deba crear su propio archivo para su PITR. Por lo tanto, está perfectamente bien crear e implementar su propio conjunto de scripts y manejar DR de acuerdo con sus requisitos exactos.
Otra excelente manera de implementar una política de recuperación ante desastres es usar un esclavo de replicación asincrónica, algo que mencionamos anteriormente en esta publicación de blog. Puede implementar dicho esclavo asíncrono en una ubicación remota, tal vez en otro centro de datos, y luego usarlo para hacer copias de seguridad y almacenarlas localmente en ese esclavo. Por supuesto, querrá realizar una copia de seguridad local de su clúster para tenerlo localmente si necesita recuperar el clúster. Mover datos entre centros de datos puede llevar mucho tiempo, por lo que tener una copia de seguridad de los archivos disponible localmente puede ahorrarle algo de tiempo. En caso de que pierda el acceso a su clúster de producción principal, aún puede tener acceso al esclavo. Esta configuración es muy flexible:primero, tiene un host MySQL en ejecución con sus datos de producción, por lo que no debería ser demasiado difícil implementar su aplicación completa en el sitio DR. También tendrá copias de seguridad de sus datos de producción que podría usar para escalar su entorno DR.
Por último y más importante, una copia de seguridad que no se ha probado sigue siendo una copia de seguridad no verificada, también conocida como Copia de seguridad de Schroedinger. Para asegurarse de que tiene una copia de seguridad que funcione, debe realizar una prueba de recuperación. ClusterControl ofrece una forma de verificar y probar automáticamente su copia de seguridad.
Esperamos que esto le brinde suficiente información para crear un procedimiento de respaldo seguro y confiable para sus bases de datos de código abierto.
