En la parte anterior, probamos el tiempo de respaldo y la efectividad de la compresión para diferentes niveles y métodos de compresión de respaldo. En este blog continuaremos con nuestros esfuerzos y hablaremos sobre más configuraciones que, probablemente, la mayoría de los usuarios realmente no cambian, pero que pueden tener un efecto visible en el proceso de copia de seguridad.
La configuración es la misma que en la parte anterior:usaremos el clúster de replicación maestro-esclavo de MariaDB con ProxySQL y Keepalived.
Hemos generado 7,6 GB de datos usando sysbench:
sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.111 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=6033 --tables=32 --table-size=1000000 prepareUso de PIGZ
Esta vez vamos a habilitar Usar PIGZ para gzip paralelo para nuestras copias de seguridad. Como antes, probaremos cada nivel de compresión para ver cómo funciona.
Estamos almacenando la copia de seguridad localmente en la instancia, la instancia está configurada con 4 vCPU.
El resultado es algo esperado. El proceso de respaldo fue significativamente más rápido que cuando usábamos un solo núcleo de CPU. El tamaño de la copia de seguridad sigue siendo prácticamente el mismo, no hay ninguna razón real para que cambie significativamente. Está claro que usar pigz mejora el tiempo de respaldo. Sin embargo, hay un lado oscuro en el uso de gzip paralelo, y es la utilización de la CPU:
Como puede ver, la utilización de la CPU se dispara y alcanza casi el 100 % para niveles de compresión más altos. Aumentar la utilización de la CPU en el servidor de la base de datos no es necesariamente la mejor idea ya que, por lo general, queremos que la CPU esté disponible para la base de datos. Por otro lado, si tenemos una réplica dedicada a realizar copias de seguridad y, digamos, consultas más pesadas, un nodo que no se usa para atender un tipo de tráfico OLTP, podemos habilitar gzip paralelo para reducir en gran medida la copia de seguridad. tiempo. Como se puede ver claramente, no es una opción para todos, pero definitivamente es algo que puede resultar útil en algunos escenarios particulares. Solo tenga en cuenta que la utilización de la CPU es algo que debe rastrear, ya que afectará la latencia de las consultas y, a través de ella, afectará la experiencia del usuario, algo que siempre debemos considerar al trabajar con las bases de datos.
Hilos de copia en paralelo de Xtrabackup
Otra configuración que queremos destacar es Xtrabackup Parallel Copy Threads. Para entender de qué se trata, hablemos un poco sobre el funcionamiento de Xtrabackup (o MariaBackup). En resumen, esas herramientas realizan dos acciones al mismo tiempo. Copian los datos, los archivos físicos, desde el servidor de la base de datos a la ubicación de la copia de seguridad mientras supervisan los registros de rehacer de InnoDB en busca de actualizaciones. La copia de seguridad consta de los archivos y el registro de todos los cambios en InnoDB que ocurrieron durante el proceso de copia de seguridad. Esto, con bloqueos de copia de seguridad o FLUSH TABLES CON READ LOCK, permite crear una copia de seguridad coherente en el momento en que finaliza la transferencia de datos. Xtrabackup Parallel Copy Threads define el número de subprocesos que realizarán la transferencia de datos. Si lo establecemos en 1, se copiará un archivo al mismo tiempo. Si lo configuramos en 8, teóricamente se pueden transferir hasta 8 archivos a la vez. Por supuesto, tiene que haber un almacenamiento lo suficientemente rápido para beneficiarse realmente de dicha configuración. Vamos a realizar varias pruebas, cambiando Xtrabackup Parallel Copy Threads de 1 a 2 y 4 a 8. Ejecutaremos pruebas en el nivel de compresión 6 (el predeterminado) con y sin gzip paralelo habilitado.
Las primeras cuatro copias de seguridad (27 - 30) se crearon sin gzip paralelo, a partir de 1 a 2, 4 y 8 subprocesos de copia paralelos. Luego repetimos el mismo proceso para las copias de seguridad 31 a 34, esta vez usando gzip paralelo. Como puede ver, en nuestro caso apenas hay diferencia entre los hilos de copia paralelos. Lo más probable es que esto tenga un mayor impacto si aumentáramos el tamaño del conjunto de datos. También mejoraría el rendimiento de la copia de seguridad si usáramos un almacenamiento más rápido y confiable. Como de costumbre, su kilometraje variará y, en diferentes entornos, esta configuración puede afectar el proceso de copia de seguridad más de lo que vemos aquí.
Limitación de red
Finalmente, en esta parte de nuestra breve serie, nos gustaría hablar sobre la capacidad de acelerar el uso de la red.
Como habrá visto, las copias de seguridad se pueden almacenar localmente en el nodo o también se puede transmitir al host del controlador. Esto sucede a través de la red y, de forma predeterminada, se hará "lo más rápido posible".
En algunos casos, donde el rendimiento de su red es limitado (instancias en la nube, por ejemplo), es posible que desee reducir el uso de la red causado por MariaBackup estableciendo un límite en la transferencia de la red. Cuando lo haga, ClusterControl usará la herramienta 'pv' para limitar el ancho de banda disponible para el proceso.
Como puede ver, la primera copia de seguridad tomó alrededor de 3 minutos, pero cuando redujo el rendimiento de la red, la copia de seguridad tardó 13 minutos y 37 segundos.
En ambos casos usamos pigz y el nivel de compresión 1. El gráfico anterior muestra que la aceleración de la red también redujo la utilización de la CPU. Tiene sentido, si pigz tiene que esperar a que la red transfiera los datos, no tiene que esforzarse mucho en la CPU, ya que tiene que estar inactiva la mayor parte del tiempo.
Espero que haya encontrado este breve blog interesante y tal vez lo anime a experimentar con algunas de las funciones y opciones de MariaBackup que no se usan con tanta frecuencia. Si desea compartir algo de su experiencia, nos gustaría saber de usted en los comentarios a continuación.
