MariaDB MaxScale es un proxy de base de datos complementario avanzado para servidores de bases de datos MariaDB. Se encuentra entre las aplicaciones del cliente y los servidores de la base de datos, enrutando las consultas de los clientes y las respuestas del servidor. MaxScale también supervisa los servidores, por lo que notará rápidamente cualquier cambio en el estado del servidor o en la topología de replicación. Esto convierte a MaxScale en una opción natural para controlar la conmutación por error y funciones similares.
En esta serie de blogs de dos partes, ofreceremos un recorrido completo sobre cómo ejecutar MariaDB MaxScale en Docker. Esta parte cubre la implementación como un contenedor Docker independiente y la agrupación en clúster MaxScale a través de Docker Swarm para una alta disponibilidad.
MariaDB MaxScale en Docker
Hay varias imágenes de MariaDB Docker disponibles en Docker Hub. En este blog, vamos a utilizar la imagen oficial mantenida y publicada por MariaDB llamada "mariadb/maxscale" (etiqueta:más reciente). La imagen tiene un tamaño de alrededor de 71 MB. Al momento de escribir este artículo, la imagen está preinstalada con MaxScale 2.3.4 como parte de sus paquetes requeridos.
Por lo general, se requieren los siguientes pasos para ejecutar MaxScale con esta imagen en un entorno de contenedor:
- Una replicación de MariaDB (maestro-esclavo o maestro-maestro) en ejecución/un clúster de Galera o un clúster de NDB
- Cree y otorgue un usuario de base de datos dedicado para el monitoreo de MaxScale
- Preparar el archivo de configuración de MaxScale
- Asigne el archivo de configuración al contenedor o cárguelo en Kubernetes ConfigMap o Docker Swarm Configs
- Iniciar el contenedor/pod/servicio/replicaset
Tenga en cuenta que MaxScale es un producto de MariaDB, lo que significa que está diseñado para el servidor MariaDB. La mayoría de las funciones siguen siendo compatibles con MySQL, excepto algunas partes como, por ejemplo, el manejo de GTID, la configuración de Galera Cluster y los archivos de datos internos. La versión que vamos a utilizar es la 2.3.4, que se publica bajo Business Source License (BSL). Permite que todo el código esté abierto y el uso en TRES servidores es gratuito. Cuando el uso supera los tres servidores backend, la empresa que lo utiliza debe pagar una suscripción comercial. Después de un período de tiempo específico (2 años en el caso de MaxScale), la versión pasa a GPL y todo el uso es gratuito.
Para que quede claro, dado que este es un entorno de prueba, podemos tener más de 2 nodos. Como se indica en la página de preguntas frecuentes de MariaDB BSL:
P:¿Puedo usar productos de MariaDB con licencia de BSL en un entorno de prueba y desarrollo?
R:Sí, en un entorno de prueba y desarrollo que no sea de producción, puede usar productos con licencia de BSL sin necesidad de una suscripción de MariaDB
En este tutorial, ya tenemos implementada una replicación de MariaDB de tres nodos mediante ClusterControl. El siguiente diagrama ilustra la configuración que vamos a implementar:
La arquitectura de nuestro sistema consta de:
- mariadb1 - 192.168.0.91 (maestro)
- mariadb2 - 192.168.0.92 (esclavo)
- mariadb3 - 192.168.0.93 (esclavo)
- docker1 - 192.168.0.200 (host Docker para contenedores - maxscale, aplicación)
Preparación del usuario de MaxScale
En primer lugar, cree un usuario de base de datos MySQL para MaxScale y permita todos los hosts en la red 192.168.0.0/24:
MariaDB> CREATE USER 'maxscale'@'192.168.0.%' IDENTIFIED BY 'my_s3cret';Luego, conceda los privilegios requeridos. Si solo desea monitorear los servidores backend con equilibrio de carga, las siguientes concesiones serían suficientes:
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'192.168.0.%';
MariaDB> GRANT SELECT ON `mysql`.* TO 'maxscale'@'192.168.0.%';Sin embargo, MaxScale puede hacer mucho más que enrutar consultas. Tiene la capacidad de realizar conmutación por error y conmutación, por ejemplo, promover un esclavo a un nuevo maestro. Esto requiere privilegios SUPER y CLIENTE DE REPLICACIÓN. Si desea utilizar esta función, asigne TODOS LOS PRIVILEGIOS al usuario:
mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.0.%';Eso es todo por la parte del usuario.
Preparación del archivo de configuración de MaxScale
La imagen requiere que se asigne un archivo de configuración funcional al contenedor antes de que se inicie. El archivo de configuración mínimo provisto en el contenedor no nos ayudará a construir el proxy inverso que queremos. Por lo tanto, el archivo de configuración debe prepararse de antemano.
La siguiente lista puede ayudarnos a recopilar la información básica necesaria para construir nuestro archivo de configuración:
- Tipo de clúster:MaxScale admite la replicación MariaDB (maestro-esclavo, maestro-maestro), Galera Cluster, Amazon Aurora, MariaDB ColumnStore y NDB Cluster (también conocido como MySQL Cluster).
- Dirección IP y/o nombre de host de back-end:dirección IP o nombre de host accesible para todos los servidores de back-end.
- Algoritmo de enrutamiento:MaxScale admite dos tipos de enrutamiento de consultas:división de lectura y escritura y equilibrio de carga en turnos.
- Puerto para escuchar por MaxScale:de forma predeterminada, MaxScale usa el puerto 4006 para conexiones de turno rotativo y el 4008 para conexiones divididas de lectura y escritura. Puede usar un zócalo UNIX si lo desea.
En el directorio actual, cree un archivo de texto llamado maxscale.cnf para que podamos asignarlo al contenedor al iniciar. Pegue las siguientes líneas en el archivo:
########################
## Server list
########################
[mariadb1]
type = server
address = 192.168.0.91
port = 3306
protocol = MariaDBBackend
serv_weight = 1
[mariadb2]
type = server
address = 192.168.0.92
port = 3306
protocol = MariaDBBackend
serv_weight = 1
[mariadb3]
type = server
address = 192.168.0.93
port = 3306
protocol = MariaDBBackend
serv_weight = 1
#########################
## MaxScale configuration
#########################
[maxscale]
threads = auto
log_augmentation = 1
ms_timestamp = 1
syslog = 1
#########################
# Monitor for the servers
#########################
[monitor]
type = monitor
module = mariadbmon
servers = mariadb1,mariadb2,mariadb3
user = maxscale
password = my_s3cret
auto_failover = true
auto_rejoin = true
enforce_read_only_slaves = 1
#########################
## Service definitions for read/write splitting and read-only services.
#########################
[rw-service]
type = service
router = readwritesplit
servers = mariadb1,mariadb2,mariadb3
user = maxscale
password = my_s3cret
max_slave_connections = 100%
max_sescmd_history = 1500
causal_reads = true
causal_reads_timeout = 10
transaction_replay = true
transaction_replay_max_size = 1Mi
delayed_retry = true
master_reconnection = true
master_failure_mode = fail_on_write
max_slave_replication_lag = 3
[rr-service]
type = service
router = readconnroute
servers = mariadb1,mariadb2,mariadb3
router_options = slave
user = maxscale
password = my_s3cret
##########################
## Listener definitions for the service
## Listeners represent the ports the service will listen on.
##########################
[rw-listener]
type = listener
service = rw-service
protocol = MariaDBClient
port = 4008
[ro-listener]
type = listener
service = rr-service
protocol = MariaDBClient
port = 4006Un poco de explicaciones para cada sección:
- Lista de servidores:los servidores backend. Defina cada servidor MariaDB de este clúster en su propia stanza. El nombre de la estrofa se usará cuando especifiquemos la definición del servicio más abajo. El tipo de componente debe ser "servidor".
- Configuración de MaxScale:defina todas las configuraciones relacionadas con MaxScale allí.
- Módulo de supervisión:cómo MaxScale debe supervisar los servidores back-end. El tipo de componente debe ser "monitor" seguido de cualquiera de los módulos de monitoreo. Para ver la lista de monitores compatibles, consulte Monitores MaxScale 2.3.
- Servicio:dónde enrutar la consulta. El tipo de componente debe ser "servicio". Para ver la lista de enrutadores admitidos, consulte Enrutadores MaxScale 2.3.
- Oyente:cómo MaxScale debe escuchar las conexiones entrantes. Puede ser un puerto o un archivo de socket. El tipo de componente debe ser "oyente". Por lo general, los oyentes están vinculados a los servicios.
Básicamente, nos gustaría que MaxScale escuche en dos puertos, 4006 y 4008. El puerto 4006 es específicamente para la conexión por turnos, adecuado para cargas de trabajo de solo lectura para nuestra replicación MariaDB, mientras que el puerto 4008 es específicamente para cargas de trabajo críticas de lectura y escritura. También queremos usar MaxScale para realizar acciones en nuestra replicación en caso de una conmutación por error, conmutación o reincorporación de esclavos, por lo que usamos el módulo de monitoreo llamado "mariadbmon".
Ejecución del contenedor
Ahora estamos listos para ejecutar nuestro contenedor MaxScale independiente. Asigne el archivo de configuración con -v y asegúrese de publicar los dos puertos de escucha 4006 y 4008. Opcionalmente, puede habilitar la interfaz API REST de MaxScale en el puerto 8989:
$ docker run -d \
--name maxscale \
--restart always \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscaleVerifique con:
$ docker logs -f maxscale
...
2019-06-14 07:15:41.060 notice : (main): Started REST API on [127.0.0.1]:8989
2019-06-14 07:15:41.060 notice : (main): MaxScale started with 8 worker threads, each with a stack size of 8388608 bytes.Asegúrese de no ver ningún error al mirar los registros anteriores. Verifique si los procesos de docker-proxy están escuchando en los puertos publicados:4006, 4008 y 8989:
$ netstat -tulpn | grep docker-proxy
tcp6 0 0 :::8989 :::* LISTEN 4064/docker-proxy
tcp6 0 0 :::4006 :::* LISTEN 4092/docker-proxy
tcp6 0 0 :::4008 :::* LISTEN 4078/docker-proxyEn este punto, nuestro MaxScale se está ejecutando y es capaz de procesar consultas.
CtrlMax
MaxCtrl es un cliente administrativo de línea de comandos para MaxScale que utiliza la API REST de MaxScale para la comunicación. Está destinado a ser el software de reemplazo para el cliente de línea de comandos heredado de MaxAdmin.
Para ingresar a la consola MaxCtrl, ejecute el comando "maxctrl" dentro del contenedor:
$ docker exec -it maxscale maxctrl
maxctrl: list servers
┌──────────┬──────────────┬──────┬─────────────┬─────────────────┬─────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼─────────────┤
│ mariadb1 │ 192.168.0.91 │ 3306 │ 0 │ Master, Running │ 0-5001-1012 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼─────────────┤
│ mariadb2 │ 192.168.0.92 │ 3306 │ 0 │ Slave, Running │ 0-5001-1012 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼─────────────┤
│ mariadb3 │ 192.168.0.93 │ 3306 │ 0 │ Slave, Running │ 0-5001-1012 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴─────────────┘Para verificar si todo está bien, simplemente ejecute los siguientes comandos:
maxctrl: list servers
maxctrl: list services
maxctrl: list filters
maxctrl: list sessionsPara obtener más información sobre cada componente, prefije el comando "mostrar", por ejemplo:
maxctrl: show servers
┌──────────────────┬──────────────────────────────────────────┐
│ Server │ mariadb3 │
├──────────────────┼──────────────────────────────────────────┤
│ Address │ 192.168.0.93 │
├──────────────────┼──────────────────────────────────────────┤
│ Port │ 3306 │
├──────────────────┼──────────────────────────────────────────┤
│ State │ Slave, Running │
├──────────────────┼──────────────────────────────────────────┤
│ Last Event │ new_slave │
├──────────────────┼──────────────────────────────────────────┤
│ Triggered At │ Mon, 17 Jun 2019 08:57:59 GMT │
├──────────────────┼──────────────────────────────────────────┤
│ Services │ rw-service │
│ │ rr-service │
├──────────────────┼──────────────────────────────────────────┤
│ Monitors │ monitor │
├──────────────────┼──────────────────────────────────────────┤
│ Master ID │ 5001 │
├──────────────────┼──────────────────────────────────────────┤
│ Node ID │ 5003 │
├──────────────────┼──────────────────────────────────────────┤
│ Slave Server IDs │ │
├──────────────────┼──────────────────────────────────────────┤
│ Statistics │ { │
│ │ "connections": 0, │
│ │ "total_connections": 0, │
│ │ "persistent_connections": 0, │
│ │ "active_operations": 0, │
│ │ "routed_packets": 0, │
│ │ "adaptive_avg_select_time": "0ns" │
│ │ } │
├──────────────────┼──────────────────────────────────────────┤
│ Parameters │ { │
│ │ "address": "192.168.0.93", │
│ │ "protocol": "MariaDBBackend", │
│ │ "port": 3306, │
│ │ "extra_port": 0, │
│ │ "authenticator": null, │
│ │ "monitoruser": null, │
│ │ "monitorpw": null, │
│ │ "persistpoolmax": 0, │
│ │ "persistmaxtime": 0, │
│ │ "proxy_protocol": false, │
│ │ "ssl": "false", │
│ │ "ssl_cert": null, │
│ │ "ssl_key": null, │
│ │ "ssl_ca_cert": null, │
│ │ "ssl_version": "MAX", │
│ │ "ssl_cert_verify_depth": 9, │
│ │ "ssl_verify_peer_certificate": true, │
│ │ "disk_space_threshold": null, │
│ │ "type": "server", │
│ │ "serv_weight": "1" │
│ │ } │
└──────────────────┴──────────────────────────────────────────┘Conexión a la base de datos
El usuario de la base de datos de la aplicación debe recibir el host MaxScale ya que, desde el punto de vista del servidor MariaDB, solo puede ver el host MaxScale. Considere el siguiente ejemplo sin MaxScale en la imagen:
- Nombre de la base de datos:myapp
- Usuario:myapp_user
- Host:192.168.0.133 (servidor de aplicaciones)
Para permitir que el usuario acceda a la base de datos dentro del servidor MariaDB, se debe ejecutar la siguiente instrucción:
MariaDB> CREATE USER 'myapp_user'@'192.168.0.133' IDENTIFIED BY 'mypassword';
MariaDB> GRANT ALL PRIVILEGES ON myapp.* to 'myapp_user'@'192.168.0.133';Con MaxScale en la imagen, se debe ejecutar la siguiente declaración (reemplace la dirección IP del servidor de aplicaciones con la dirección IP de MaxScale, 192.168.0.200):
MariaDB> CREATE USER 'myapp_user'@'192.168.0.200' IDENTIFIED BY 'mypassword';
MariaDB> GRANT ALL PRIVILEGES ON myapp.* to 'myapp_user'@'192.168.0.200';Desde la aplicación, hay dos puertos que puede usar para conectarse a la base de datos:
- 4006:oyente de operación por turnos, adecuado para cargas de trabajo de solo lectura.
- 4008 - Oyente dividido de lectura y escritura, adecuado para cargas de trabajo de escritura.
Si su aplicación puede especificar solo un puerto MySQL (por ejemplo, Wordpress, Joomla, etc.), elija el puerto RW 4008 en su lugar. Esta es la conexión de punto final más segura, independientemente del tipo de clúster. Sin embargo, si su aplicación puede manejar conexiones a múltiples puertos MySQL, puede enviar las lecturas al oyente de turno rotativo. Este oyente tiene menos sobrecarga y es mucho más rápido en comparación con el oyente dividido de lectura y escritura.
Para nuestra configuración de replicación de MariaDB, conéctese a cualquiera de estos puntos finales como combinación de host/puerto de base de datos:
- 192.168.0.200 puerto 4008 - MaxScale - lectura/escritura o solo escritura
- 192.168.0.200 puerto 4006 - MaxScale - equilibrado de solo lectura
- 192.168.0.91 puerto 3306 - Servidor MariaDB (maestro) - lectura/escritura
- 192.168.0.92 puerto 3306 - Servidor MariaDB (esclavo) - solo lectura
- 192.168.0.93 puerto 3306 - Servidor MariaDB (esclavo) - solo lectura
Tenga en cuenta que para el tipo de clúster multimaestro como Galera Cluster y NDB Cluster, el puerto 4006 se puede usar como conexiones balanceadas de escritura múltiple en su lugar. Con MaxScale, tiene muchas opciones para elegir cuando se conecta a la base de datos, y cada una de ellas ofrece su propio conjunto de ventajas.
Clústeres MaxScale con Docker Swarm
Con Docker Swarm, podemos crear un grupo de instancias MaxScale a través del servicio Swarm con más de una réplica junto con Swarm Configs. En primer lugar, importe el archivo de configuración a Swarm:
$ cat maxscale.conf | docker config create maxscale_config -Verifique con:
$ docker config inspect --pretty maxscale_configLuego, permita que el usuario de la base de datos MaxScale se conecte desde cualquier host Swarm en la red:
MariaDB> CREATE USER 'maxscale'@'192.168.0.%' IDENTIFIED BY 'my_s3cret';
MariaDB> GRANT ALL PRIVILEGES ON *.* TO [email protected]'192.168.0.%';Al iniciar el servicio Swarm para MaxScale, podemos crear varios contenedores (llamados réplicas) asignados al mismo archivo de configuración, como se muestra a continuación:
$ docker service create \
--name maxscale-cluster \
--replicas=3 \
--publish published=4008,target=4008 \
--publish published=4006,target=4006 \
--config source=maxscale_config,target=/etc/maxscale.cnf \
mariadb/maxscaleLo anterior creará tres contenedores MaxScale distribuidos en los nodos Swarm. Verifique con:
$ docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
yj6u2xcdj7lo maxscale-cluster replicated 3/3 mariadb/maxscale:latest *:4006->4006/tcp, *:4008->4008/tcpSi las aplicaciones se ejecutan dentro de la red Swarm, simplemente puede usar el nombre de servicio "maxscale-cluster" como host de la base de datos para sus aplicaciones. Externamente, puede conectarse a cualquiera de los hosts de Docker en los puertos publicados y la red Swarm enrutará y equilibrará las conexiones a los contenedores correctos de forma rotativa. En este punto, nuestra arquitectura se puede ilustrar de la siguiente manera:
En la segunda parte, veremos casos de uso avanzados de MaxScale en Docker, como el control de servicios, la gestión de configuración, el procesamiento de consultas, la seguridad y la reconciliación de clústeres.
