Copias de seguridad lógicas distribuidas de MySQL: una prueba de concepto

La importancia de tener un respaldo periódico es un hecho en la vida de la Base de Datos. Los hay de varios sabores: binario (Percona XtraBackup), respaldos binlog, instantáneas de disco (lvm, ebs, etc.) y los clásicos: respaldos lógicos, los que puedes tomar con herramientas como mysqldump, mydumper o mysqlpump. Cada uno con un propósito específico, MTTR, políticas de retención, etc.

Otro hecho es que realizar una copia de seguridad puede ser una tarea muy lenta a medida que crecen sus datos: más datos almacenados, más datos para leer y respaldar. Pero aún así, otro hecho es que no solo los datos están creciendo, sino que también aumenta (generalmente) la cantidad de instancias de MySQL disponibles en su entorno. Entonces, ¿por qué no aprovechar más instancias de MySQL para realizar copias de seguridad lógicas en un intento de acelerar esta operación?

Copias de seguridad distribuidas (o uso de todos los esclavos disponibles)

La idea es simple: en lugar de tomar la copia de seguridad completa de un solo servidor, use todos los servidores disponibles. Esta Prueba de Concepción se enfoca únicamente en el uso de réplicas en una topología Maestro/Esclavo(s). Ni siquiera puedo usar Master, pero en este caso, decidí dejarlo solo para evitar agregar la copia de seguridad.

Testi!

En una topología Master / 3-Slaves:

Gráfico por orquestador GUI

Con una pequeña base de datos de unos 64 GB de datos (excluyendo el tamaño del índice) y 300 tablas (esquema «sb»):

Usando las 3 réplicas, la copia de seguridad lógica distribuida con mysqldump tomó 6 minutos, 13 segundos:

La misma copia de seguridad en una sola repetición tomó 11 minutos, 59 segundos:

En otras palabras:

La distribución fue ¡48% más rápido!

Y este es un conjunto de datos bastante pequeño. Vale la pena. ¿Entonces, cómo funciona?

Concepciones

La lógica es simple y se puede dividir en etapas.

Etapa 1: Preparación

  • Averigüe cuántas réplicas hay disponibles
  • Averigüe la cantidad de tablas en el esquema de las que desea realizar una copia de seguridad
  • Divida el número de tablas por todas las réplicas disponibles. Las piezas resultantes serán las tablas de las que cada réplica hará una copia de seguridad.

Etapa 2: Garantizar la consistencia

  • Evita que el Maestro realice operaciones que cambien la posición del binlog. Por lo general, esto se hace con FLUSH TABLES CON READ LOCK, pero este PoC usa la genial función de LOCK BINLOG FOR BACKUP disponible en Percona Server para MySQL y es mucho menos perjudicial.
  • Encuentra la última réplica
  • Asegúrese de que todas las demás réplicas correspondan a la última actualización con START SLAVE UNTIL
  • Haga un mysqldump para replicar con la pieza de tabla correspondiente y use -lock-for-backup (otra característica de Percona Server)

El guión completo se puede encontrar aquí:

https://github.com/nethalo/parallel-mysql-backup/blob/master/dist_backup.sh

Vale la pena señalar que el script tiene su propio logotipo que describirá cada paso, se ve así:

Requisitos

Ciertos requisitos básicos:

  • Entonces la herramienta usa el comando MOSTRAR LOS HUESOS DE ESCLAVOes obligatorio configurar la variable host_report, que si usa Orchestrator, probablemente ya lo haya establecido.
  • El host establecido en la variable «report_host» debe ser accesible. Por ejemplo, una IP o host que se pueda resolver (DNS, editar archivo /etc/hosts).
  • No hay filtro de replicación en ninguna de las réplicas involucradas. Esto es para asegurar la consistencia de los datos.
  • Actualmente, el script debe ejecutarse en el servidor maestro.
  • Solo funciona en Percona Server debido al uso de Backup Locks.
  • Se espera que las credenciales de usuario de MySQL estén disponibles en el directorio de inicio en el archivo .my.cnf.

¡Queremos sus comentarios!

¿Interesante o no?

  • ¿Es algo que será útil para sus operaciones de rescate?
  • ¿Hay algo más que quieras ver del guión?
  • ¿Falta algo?

Siendo esta una prueba de concepción, no faltan características que eventualmente (si se convierte en una herramienta más madura) se lograrán, tales como:

    • Añadir pesos a los esclavos para poder modificar la distribución
    • Opción de usar Master como uno de los servidores de respaldo, si lo desea
    • Usar FTWRL cuando el servidor no es Percona Server
    • Use MyDumper/MysqlPump con subprocesos múltiples en lugar de MySQLDump
    • Etc.

¡Infórmenos en la sección para comentarios!

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario