Preparación de un servidor MySQL o MariaDB para producción:segunda parte

En el blog anterior, hemos cubierto algunos consejos y trucos para preparar un servidor MySQL para el uso de producción desde la perspectiva del administrador del sistema. Esta entrada de blog es la continuación...

Usar una herramienta de respaldo de base de datos

Cada herramienta de respaldo tiene sus propias ventajas y desventajas. Por ejemplo, Percona Xtrabackup (o MariaDB Backup for MariaDB) puede realizar una copia de seguridad física en caliente sin bloquear las bases de datos, pero solo se puede restaurar a la misma versión en otra instancia. Mientras que para mysqldump, es compatible con otras versiones principales de MySQL y mucho más simple para la copia de seguridad parcial, aunque es relativamente más lento durante la restauración en comparación con Percona Xtrabackup en grandes bases de datos. MySQL 5.7 también presenta mysqlpump, similar a mysqldump con capacidades de procesamiento paralelo para acelerar el proceso de volcado.

No deje de configurar todas estas herramientas de copia de seguridad en su servidor MySQL, ya que están disponibles gratuitamente y son muy importantes para la recuperación de datos. Dado que mysqldump y mysqlpump ya están incluidos en MySQL 5.7 y versiones posteriores, solo necesitamos instalar Percona Xtrabackup (o MariaDB Backup para MariaDB), pero requiere algunos preparativos, como se muestra en los siguientes pasos:

Paso uno

Asegúrese de que la herramienta de respaldo y sus dependencias estén instaladas:

$ yum install -y epel-release
$ yum install -y socat pv percona-xtrabackup

Para los servidores MariaDB, utilice MariaDB Backup en su lugar:

$ yum install -y socat pv MariaDB-Backup

Paso dos

Crear usuario 'xtrabackup' en maestro si no existe:

mysql> CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';

Paso tres

Cree otro usuario llamado 'mysqldump' en el maestro si no existe. Este usuario se utilizará para 'mysqldump' y 'mysqlpump':

mysql> CREATE USER 'mysqldump'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, RELOAD, REPLICATION CLIENT ON *.* TO 'mysqldump'@'localhost';

Cuarto Paso

Agregue las credenciales de los usuarios de respaldo dentro del archivo de configuración de MySQL bajo las directivas [xtrabackup], [mysqldump] y [mysqlpump]:

$ cat /etc/my.cnf

...

[xtrabackup]
user=xtrabackup
password='Km4z9^sT2X'

[mysqldump]
user=mysqldump
password='Km4z9^sT2X'

[mysqlpump]
user=mysqldump
password='Km4z9^sT2X'

Al especificar las líneas anteriores, no necesitamos especificar el nombre de usuario y la contraseña en el comando de copia de seguridad, ya que la herramienta de copia de seguridad cargará automáticamente esas opciones de configuración desde el archivo de configuración principal.

Asegúrese de que las herramientas de copia de seguridad se hayan probado correctamente de antemano. Para Xtrabackup, que admite la transmisión de copias de seguridad a través de la red, esto debe probarse primero para asegurarse de que el enlace de comunicación se pueda establecer correctamente entre el servidor de origen y el de destino. En el servidor de destino, ejecute el siguiente comando para que socat escuche el puerto 9999 y esté listo para aceptar la transmisión entrante:

$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysql

Luego, cree una copia de seguridad en el servidor de origen y transmítala al puerto 9999 en el servidor de destino:

$ innobackupex --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | socat - TCP4:192.168.0.202:9999

Debería obtener un flujo continuo de salida después de ejecutar el comando de copia de seguridad. Espere hasta que vea la línea 'Completado OK' que indica una copia de seguridad exitosa.

Con pv, podemos limitar el uso del ancho de banda o ver el progreso como un proceso que se canaliza a través de él. Comúnmente, el proceso de transmisión saturará la red si no se habilita la limitación y esto podría causar problemas con otros servidores para interactuar con otro en el mismo segmento. Usando pv, podemos acelerar el proceso de transmisión antes de pasarlo a la herramienta de transmisión como socat o netcat. El siguiente ejemplo muestra que la transmisión de respaldo se acelerará alrededor de 80 MB/s para las conexiones entrantes y salientes:

$ innobackupex --slave-info --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | pv -q -L 80m | socat - TCP4:192.168.0.202:9999

La transmisión de una copia de seguridad se usa comúnmente para organizar un esclavo o almacenar la copia de seguridad de forma remota en otro servidor.

Para mysqldump y mysqlpump, podemos probar con los siguientes comandos:

$ mysqldump --set-gtid-purged=OFF --all-databases
$ mysqlpump --set-gtid-purged=OFF --all-databases

Asegúrese de que aparezcan líneas sin error en la salida.

Prueba de estrés del servidor

La prueba de estrés del servidor de la base de datos es importante para comprender la capacidad máxima que podemos anticipar para el servidor en particular. Esto será útil cuando se acerque a umbrales o cuellos de botella en una etapa posterior. Puede usar muchas herramientas de evaluación comparativa disponibles en el mercado como mysqlslap, DBT2 y sysbench.

En este ejemplo, usamos sysbench para medir el rendimiento máximo del servidor, el nivel de saturación y también la temperatura de los componentes mientras se ejecuta en un entorno de alta carga de trabajo de base de datos. Esto le dará una idea básica de lo bueno que es el servidor y anticipará la carga de trabajo que el servidor puede procesar para nuestra aplicación en producción.

Para instalar y configurar sysbench, puede compilarlo desde el código fuente o instalar el paquete desde el repositorio de Percona:

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

Cree el esquema de la base de datos y el usuario en el servidor MySQL:

mysql> CREATE DATABASE sbtest;
mysql> CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'sysbenchP4ss';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'localhost';

Generar los datos de prueba:

$ sysbench \
/usr/share/sysbench/oltp_common.lua \
--db-driver=mysql \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
prepare

Luego ejecute el punto de referencia durante 1 hora (3600 segundos):

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=64 \
--max-requests=0 \
--db-driver=mysql \
--time=3600 \
--db-ps-mode=disable \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
run

Mientras se ejecuta la prueba, use iostat (disponible en el paquete sysstat) en otro terminal para monitorear la utilización del disco, el ancho de banda, las IOPS y la espera de E/S:

$ yum install -y sysstat
$ iostat -x 60

avg-cpu:  %user %nice %system %iowait  %steal %idle
          40.55    0.00 55.27    4.18 0.00 0.00

Device:         rrqm/s wrqm/s     r/s w/s rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await svctm  %util
sda               0.19 6.18 1236.23  816.92 61283.83 14112.44    73.44 4.00 1.96 2.83    0.65 0.34 69.29

El resultado anterior se imprimirá cada 60 segundos. Espere hasta que termine la prueba y tome el promedio de r/s (lecturas/segundo), w/s (escrituras/segundo), %iowait, %util, rkB/s y wkB/s (ancho de banda). Si observa una utilización relativamente baja del disco, la CPU, la RAM o la red, probablemente necesite aumentar el valor "--threads" a un número aún mayor para que utilice todos los recursos hasta el límite.

Considere los siguientes aspectos a medir:

Consultas por segundo =Resumen de Sysbench una vez que se completa la prueba en Estadísticas de SQL -> Consultas -> Por segundo.
Latencia de consulta =resumen de Sysbench una vez que se completa la prueba en Latencia (ms) -> percentil 95.
IOPS de disco =Promedio de r/s + w/s
Utilización del disco =Promedio de %util
Ancho de banda del disco R/W =Promedio de rkB/s / Promedio de wkB/s
Espera de E/S de disco =Promedio de %iowait
Carga promedio del servidor =Promedio de carga promedio según lo informado por el comando superior.
Uso de CPU de MySQL =Uso promedio de CPU según lo informado por el comando superior.

Con ClusterControl, puede observar y obtener fácilmente la información anterior a través del panel de descripción general de nodos, como se muestra en la siguiente captura de pantalla:

Además, la información recopilada durante la prueba de estrés se puede usar para ajustar MySQL y variables InnoDB en consecuencia como innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads y también max_connections.

Para obtener más información sobre las pruebas comparativas de rendimiento de MySQL usando sysbench, consulte esta publicación de blog, Cómo comparar el rendimiento de MySQL y MariaDB usando SysBench.

Utilice una herramienta de cambio de esquema en línea

El cambio de esquema es algo inevitable en las bases de datos relacionales. A medida que la aplicación crece y se vuelve más exigente con el tiempo, ciertamente requiere algún cambio en la estructura de la base de datos. Hay algunas operaciones DDL que reconstruirán la tabla, bloqueando así la ejecución de otras declaraciones DML y esto podría afectar la disponibilidad de su base de datos si está realizando cambios estructurales en una tabla enorme. Para ver la lista de operaciones DDL de bloqueo, consulte esta página de documentación de MySQL y busque operaciones que tengan "Permite DML concurrente" =No.

Si no puede permitirse el tiempo de inactividad en los servidores de producción al realizar el cambio de esquema, probablemente sea una buena idea configurar la herramienta de cambio de esquema en línea en la etapa inicial. En este ejemplo, instalamos y configuramos gh-ost, un cambio de esquema en línea creado por Github. Gh-ost utiliza el flujo de registro binario para capturar los cambios de la tabla y los aplica de forma asíncrona a la tabla fantasma.

Para instalar gh-ost en una caja de CentOS, simplemente siga los siguientes pasos:

Paso uno

Descargue el último gh-ost desde aquí:

$ wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-1.0.48-1.x86_64.rpm

Paso dos

Instalar el paquete:

$ yum localinstall gh-ost-1.0.48-1.x86_64.rpm

Paso tres

Cree un usuario de base de datos para gh-ost si no existe y concédale los privilegios adecuados:

mysql> CREATE USER 'gh-ost'@'{host}' IDENTIFIED BY 'ghostP455';
mysql> GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE ON {db_name}.* TO 'gh-ost'@'{host}';
mysql> GRANT SUPER, REPLICATION SLAVE ON *.* TO 'gh-ost'@'{host}';

** Reemplace {host} y {db_name} con sus valores apropiados. Idealmente, el {host} es uno de los hosts esclavos que realizará el cambio de esquema en línea. Consulte la documentación de gh-ost para obtener más detalles.

Cuarto Paso

Cree un archivo de configuración de gh-ost para almacenar el nombre de usuario y la contraseña en /root/.gh-ost.cnf:

[client]
user=gh-ost
password=ghostP455

Del mismo modo, puede configurar el cambio de esquema en línea de Percona Toolkit (pt-osc) en el servidor de la base de datos. La idea es asegurarse de estar preparado con esta herramienta primero en el servidor de la base de datos que probablemente ejecutará esta operación en el futuro.

Utilice el kit de herramientas de Percona

Percona Toolkit es una colección de herramientas avanzadas de línea de comandos de código abierto, desarrollada por Percona, que están diseñadas para realizar una variedad de tareas de servidor y sistema MySQL, MongoDB y PostgreSQL que son demasiado difíciles o complejas para realizar manualmente. Estas herramientas se han convertido en el salvador definitivo, utilizadas por los DBA de todo el mundo para abordar o resolver problemas técnicos que se encuentran en los servidores MySQL y MariaDB.

Para instalar Percona Toolkit, simplemente ejecute el siguiente comando:

$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install percona-toolkit

Hay más de 30 herramientas disponibles en este paquete. Algunos de ellos están diseñados específicamente para MongoDB y PostgreSQL. Algunas de las herramientas más populares para la resolución de problemas y el ajuste del rendimiento de MySQL son pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync y pt-archiver. Este kit de herramientas puede ayudar a los administradores de bases de datos a verificar la integridad de la replicación de MySQL al verificar la consistencia de los datos maestros y de réplica, archivar filas de manera eficiente, encontrar índices duplicados, analizar consultas de MySQL desde registros y tcpdump y mucho más.

El siguiente ejemplo muestra el resultado de una de las herramientas (pt-table-checksum) donde puede realizar una verificación de coherencia de replicación en línea mediante la ejecución de consultas de suma de verificación en el maestro, lo que produce diferentes resultados en las réplicas que son inconsistentes con el maestro:

$ pt-table-checksum --no-check-binlog-format --replicate-check-only
Checking if all tables can be checksummed ...
Starting checksum ...

Differences on mysql2.local

TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
mysql.proc 1 0 1
mysql.tables_priv 1 0 1
mysql.user 1 1 1

El resultado anterior muestra que hay 3 tablas en el esclavo (mysql2.local) que son inconsistentes con el maestro. Luego podemos usar la herramienta pt-table-sync para reparar los datos faltantes del maestro, o simplemente volver a sincronizar el esclavo una vez más.

Bloquear el servidor

Finalmente, después de completar la etapa de configuración y preparación, podemos aislar el nodo de la base de datos de la red pública y restringir el acceso del servidor a hosts y redes conocidos. Puede usar firewall (iptables, firewalld, ufw), grupos de seguridad, hosts.allow y/o hosts.deny o simplemente deshabilitar la interfaz de red que se enfrenta a Internet si tiene varias interfaces de red.

Para iptables, es importante especificar un comentario para cada regla usando el indicador '-m comment --comment':

$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -m comment --comment 'Allow local net to SSH port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 3306 -m comment --comment 'Allow local net to MySQL port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 9999 -m comment --comment 'Allow local net to backup streaming port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 0.0.0.0/0 -m comment --comment 'Drop everything apart from the above' -j DROP

De manera similar para el Firewall de Ubuntu (ufw), primero debemos definir la regla predeterminada y luego podemos crear reglas similares para MySQL/MariaDB similares a esta:

$ sudo ufw default deny incoming comment 'Drop everything apart from the above'
$ sudo ufw default allow outgoing comment 'Allow outgoing everything'
$ sudo ufw allow from 192.168.0.0/24 to any port 22 comment 'Allow local net to SSH port'
$ sudo ufw allow from 192.168.0.0/24 to any port 3306 comment 'Allow local net to MySQL port'
$ sudo ufw allow from 192.168.0.0/24 to any port 9999 comment 'Allow local net to backup streaming port'

Habilitar el cortafuegos:

$ ufw enable

Luego, verifique que las reglas estén cargadas correctamente:

$ ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

New profiles: skip

To                         Action From
--                         ------ ----
22                         ALLOW IN 192.168.0.0/24             # Allow local net to SSH port
3306                       ALLOW IN 192.168.0.0/24             # Allow local net to MySQL port
9999                       ALLOW IN 192.168.0.0/24             # Allow local net to backup streaming port

Nuevamente, es muy importante especificar comentarios en cada regla para ayudarnos a entender mejor la regla.

Para la restricción de acceso remoto a la base de datos, también podemos usar un servidor VPN como se muestra en esta publicación de blog, Uso de OpenVPN para asegurar el acceso a su clúster de base de datos en la nube.

Conclusión

Preparar un servidor de producción obviamente no es una tarea fácil, como lo hemos mostrado en esta serie de blogs. Si le preocupa equivocarse, ¿por qué no usa ClusterControl para implementar su clúster de base de datos? ClusterControl tiene un historial muy bueno en la implementación de bases de datos y ha permitido más de 70 000 implementaciones de MySQL y MariaDB para todos los entornos hasta la fecha.