sql >> Base de Datos >  >> RDS >> MariaDB

Ejecución de un clúster Galera de MariaDB sin herramientas de orquestación de contenedores:primera parte

Las herramientas de orquestación de contenedores simplifican el funcionamiento de un sistema distribuido, implementando y reimplementando contenedores y manejando cualquier falla que ocurra. Uno podría necesitar mover aplicaciones, por ejemplo, para manejar actualizaciones, escalado o fallas subyacentes del host. Si bien esto suena muy bien, no siempre funciona bien con un clúster de base de datos muy consistente como Galera. No puede simplemente mover los nodos de la base de datos, no son aplicaciones sin estado. Además, el orden en que realiza las operaciones en un clúster tiene una gran importancia. Por ejemplo, reiniciar un clúster de Galera tiene que comenzar desde el nodo más avanzado o, de lo contrario, perderá datos. Por lo tanto, le mostraremos cómo ejecutar Galera Cluster en Docker sin una herramienta de orquestación de contenedores, para que tenga el control total.

En esta publicación de blog, veremos cómo ejecutar MariaDB Galera Cluster en contenedores Docker usando la imagen estándar de Docker en múltiples hosts Docker, sin la ayuda de herramientas de orquestación como Swarm o Kubernetes. Este enfoque es similar a ejecutar Galera Cluster en hosts estándar, pero la gestión del proceso se configura a través de Docker.

Antes de entrar en más detalles, asumimos que instaló Docker, deshabilitó SElinux/AppArmor y borró las reglas dentro de iptables, firewalld o ufw (lo que esté usando). Los siguientes son tres hosts Docker dedicados para nuestro clúster de base de datos:

  • host1.local - 192.168.55.161
  • host2.local - 192.168.55.162
  • host3.local - 192.168.55.163

Redes de varios hosts

En primer lugar, la red Docker predeterminada está vinculada al host local. Docker Swarm presenta otra capa de red llamada red superpuesta, que extiende el trabajo en red del contenedor a múltiples hosts Docker en un clúster llamado Swarm. Mucho antes de que se implementara esta integración, se desarrollaron muchos complementos de red para respaldar esto:Flannel, Calico, Weave son algunos de ellos.

Aquí, vamos a utilizar Weave como el complemento de red de Docker para redes de múltiples hosts. Esto se debe principalmente a su simplicidad para instalarlo y ejecutarlo, y la compatibilidad con la resolución de DNS (los contenedores que se ejecutan en esta red pueden resolver el nombre de host de cada uno). Hay dos formas de ejecutar Weave:systemd o a través de Docker. Vamos a instalarlo como una unidad systemd, por lo que es independiente del demonio Docker (de lo contrario, tendríamos que iniciar Docker primero antes de que se active Weave).

  1. Descarga e instala Weave:

    $ curl -L git.io/weave -o /usr/local/bin/weave
$ chmod a+x /usr/local/bin/weave

  2. Cree un archivo de unidad systemd para Weave:

    $ cat > /etc/systemd/system/weave.service << EOF
[Unit]
Description=Weave Network
Documentation=http://docs.weave.works/weave/latest_release/
Requires=docker.service
After=docker.service
[Service]
EnvironmentFile=-/etc/sysconfig/weave
ExecStartPre=/usr/local/bin/weave launch --no-restart $PEERS
ExecStart=/usr/bin/docker attach weave
ExecStop=/usr/local/bin/weave stop
[Install]
WantedBy=multi-user.target
EOF

  3. Defina las direcciones IP o el nombre de host de los pares dentro de /etc/sysconfig/weave:

    $ echo 'PEERS="192.168.55.161 192.168.55.162 192.168.55.163"' > /etc/sysconfig/weave

  4. Inicie y habilite Weave en el arranque:

    $ systemctl start weave
$ systemctl enable weave

Repita los 4 pasos anteriores en todos los hosts de Docker. Verifique con el siguiente comando una vez hecho:

$ weave status

El número de compañeros es lo que estamos cuidando. Debería ser 3:

          ...
          Peers: 3 (with 6 established connections)
          ...

Ejecutar un clúster de Galera

Ahora que la red está lista, es hora de activar nuestros contenedores de base de datos y formar un clúster. Las reglas básicas son:

  • El contenedor debe crearse bajo --net=weave para tener conectividad multi-host.
  • Los puertos de contenedor que deben publicarse son 3306, 4444, 4567, 4568.
  • La imagen de Docker debe ser compatible con Galera. Si desea utilizar Oracle MySQL, obtenga la versión de Codership. Si desea Percona, use esta imagen en su lugar. En esta publicación de blog, estamos usando MariaDB.

Las razones por las que elegimos MariaDB como proveedor del clúster de Galera son:

  • Galera está integrado en MariaDB, a partir de MariaDB 10.1.
  • La imagen de MariaDB es mantenida por los equipos de Docker y MariaDB.
  • Una de las imágenes de Docker más populares que existen.

El arranque de un clúster de Galera debe realizarse en secuencia. En primer lugar, el nodo más actualizado debe iniciarse con "wsrep_cluster_address=gcomm://". Luego, inicie los nodos restantes con una dirección completa que incluya todos los nodos del clúster, por ejemplo, "wsrep_cluster_address=gcomm://node1,node2,node3". Para lograr estos pasos usando un contenedor, tenemos que hacer algunos pasos adicionales para asegurarnos de que todos los contenedores funcionen de manera homogénea. Así que el plan es:

  1. Necesitaríamos comenzar con 4 contenedores en este orden:mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
  2. El contenedor mariadb0 usará el mismo datadir y configdir con mariadb1.
  3. Utilice mariadb0 en host1 para el primer arranque, luego inicie mariadb2 en host2, mariadb3 en host3.
  4. Elimine mariadb0 en host1 para dar paso a mariadb1.
  5. Por último, inicie mariadb1 en host1.

Al final del día, tendría un clúster Galera de tres nodos (mariadb1, mariadb2, mariadb3). El primer contenedor (mariadb0) es un contenedor transitorio solo con fines de arranque, que utiliza la dirección de clúster "gcomm://". Comparte el mismo datadir y configdir con mariadb1 y se eliminará una vez que se forme el clúster (mariadb2 y mariadb3 estén activos) y los nodos estén sincronizados.

De forma predeterminada, Galera está desactivada en MariaDB y debe habilitarse con un indicador llamado wsrep_on (establecido en ON) y wsrep_provider (establecido en la ruta de la biblioteca de Galera) más una serie de parámetros relacionados con Galera. Por lo tanto, necesitamos definir un archivo de configuración personalizado para que el contenedor configure Galera correctamente.

Comencemos con el primer contenedor, mariadb0. Cree un archivo en /containers/mariadb1/conf.d/my.cnf y agregue las siguientes líneas:

$ mkdir -p /containers/mariadb1/conf.d
$ cat /containers/mariadb1/conf.d/my.cnf
[mysqld]

default_storage_engine          = InnoDB
binlog_format                   = ROW

innodb_flush_log_at_trx_commit  = 0
innodb_flush_method             = O_DIRECT
innodb_file_per_table           = 1
innodb_autoinc_lock_mode        = 2
innodb_lock_schedule_algorithm  = FCFS # MariaDB >10.1.19 and >10.2.3 only

wsrep_on                        = ON
wsrep_provider                  = /usr/lib/galera/libgalera_smm.so
wsrep_sst_method                = xtrabackup-v2

Dado que la imagen no viene con MariaDB Backup (que es el método SST preferido para MariaDB 10.1 y MariaDB 10.2), por el momento nos quedaremos con xtrabackup-v2.

Para realizar el primer arranque para el clúster, ejecute el contenedor de arranque (mariadb0) en host1 con "datadir" y "conf.d" de mariadb1:

$ docker run -d \
        --name mariadb0 \
        --hostname mariadb0.weave.local \
        --net weave \
        --publish "3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --env MYSQL_USER=proxysql \
        --env MYSQL_PASSWORD=proxysqlpassword \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

Los parámetros utilizados en el comando anterior son:

  • --nombre , crea el contenedor llamado "mariadb0",
  • --nombre de host , asigna al contenedor un nombre de host "mariadb0.weave.local",
  • --red , coloca el contenedor en la red de tejido para soporte de red de múltiples hosts,
  • --publicar , expone los puertos 3306, 4444, 4567, 4568 en el contenedor al host,
  • $(weave dns-args) , configura la resolución de DNS para este contenedor. Este comando se puede traducir a la ejecución de Docker como "--dns=172.17.0.1 --dns-search=weave.local.",
  • --env MYSQL_ROOT_PASSWORD , la contraseña raíz de MySQL,
  • --env MYSQL_USER , crea un usuario "proxysql" que se usará más tarde con ProxySQL para el enrutamiento de la base de datos,
  • --env MYSQL_PASSWORD , la contraseña de usuario "proxysql",
  • --volumen /containers/mariadb1/datadir:/var/lib/mysql , crea /containers/mariadb1/datadir si no existe y mapéelo con /var/lib/mysql (MySQL datadir) del contenedor (para el nodo de arranque, esto podría omitirse),
  • --volumen /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , monta los archivos en el directorio /containers/mariadb1/conf.d del host Docker, en el contenedor en /etc/mysql/mariadb.conf.d.
  • mariadb:10.2.15 , usa la imagen MariaDB 10.2.15 de aquí,
  • --wsrep_cluster_address , Cadena de conexión de Galera para el clúster. "gcomm://" significa arranque. Para el resto de los contenedores, usaremos una dirección completa en su lugar.
  • --wsrep_sst_auth , cadena de autenticación para el usuario de SST. Utilice el mismo usuario que root,
  • --wsrep_node_address , el nombre de host del nodo, en este caso vamos a utilizar el FQDN proporcionado por Weave.

El contenedor de arranque contiene varias cosas clave:

  • El nombre, hostname y wsrep_node_address es mariadb0, pero usa los volúmenes de mariadb1.
  • La dirección del clúster es "gcomm://"
  • Hay dos parámetros --env adicionales:MYSQL_USER y MYSQL_PASSWORD. Estos parámetros crearán un usuario adicional para nuestro propósito de monitoreo de proxysql.

Verifique con el siguiente comando:

$ docker ps
$ docker logs -f mariadb0

Una vez que vea la siguiente línea, indica que el proceso de arranque se completó y Galera está activa:

2018-05-30 23:19:30 139816524539648 [Note] WSREP: Synchronized with group, ready for connections

Cree el directorio para cargar nuestro archivo de configuración personalizado en los hosts restantes:

$ mkdir -p /containers/mariadb2/conf.d # on host2
$ mkdir -p /containers/mariadb3/conf.d # on host3

Luego, copie el my.cnf que hemos creado para mariadb0 y mariadb1 a mariadb2 y mariadb3 respectivamente:

$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb2/conf.d/ # on host1
$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb3/conf.d/ # on host1

A continuación, cree otros 2 contenedores de base de datos (mariadb2 y mariadb3) en host2 y host3 respectivamente:

$ docker run -d \
        --name ${NAME} \
        --hostname ${NAME}.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/${NAME}/datadir:/var/lib/mysql \
        --volume /containers/${NAME}/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=${NAME}.weave.local

** Reemplace ${NAME} con mariadb2 o mariadb3 respectivamente.

Sin embargo, hay una trampa. El script de punto de entrada comprueba el servicio mysqld en segundo plano después de la inicialización de la base de datos utilizando el usuario root de MySQL sin contraseña. Dado que Galera realiza automáticamente la sincronización a través de SST o IST al iniciarse, la contraseña de usuario raíz de MySQL cambiará, reflejando el nodo de arranque. Por lo tanto, vería el siguiente error durante la primera puesta en marcha:

018-05-30 23:27:13 140003794790144 [Warning] Access denied for user 'root'@'localhost' (using password: NO)
MySQL init process in progress…
MySQL init process failed.

El truco consiste en reiniciar los contenedores fallidos una vez más, porque esta vez, el directorio de datos de MySQL se habría creado (en el primer intento de ejecución) y se saltaría la parte de inicialización de la base de datos:

$ docker start mariadb2 # on host2
$ docker start mariadb3 # on host3

Una vez iniciado, verifique observando la siguiente línea:

$ docker logs -f mariadb2
…
2018-05-30 23:28:39 139808069601024 [Note] WSREP: Synchronized with group, ready for connections

En este punto, hay 3 contenedores en ejecución, mariadb0, mariadb2 y mariadb3. Tenga en cuenta que mariadb0 se inicia con el comando de arranque (gcomm://), lo que significa que si Docker reinicia automáticamente el contenedor en el futuro, podría desconectarse del componente principal. Por lo tanto, debemos eliminar este contenedor y reemplazarlo con mariadb1, usando la misma cadena de conexión de Galera con el resto y usar el mismo datadir y configdir con mariadb0.

Primero, detenga mariadb0 enviando SIGTERM (para asegurarse de que el nodo se cerrará correctamente):

$ docker kill -s 15 mariadb0

Luego, inicie mariadb1 en host1 usando un comando similar a mariadb2 o mariadb3:

$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb1.weave.local

Esta vez, no necesita hacer el truco de reinicio porque MySQL datadir ya existe (creado por mariadb0). Una vez que se inicia el contenedor, verifique que el tamaño del clúster sea 3, el estado debe ser Primario y el estado local está sincronizado:

$ docker exec -it mariadb3 mysql -uroot "-pPM7%[email protected]^1" -e 'select variable_name, variable_value from information_schema.global_status where variable_name in ("wsrep_cluster_size", "wsrep_local_state_comment", "wsrep_cluster_status", "wsrep_incoming_addresses")'
+---------------------------+-------------------------------------------------------------------------------+
| variable_name             | variable_value                                                                |
+---------------------------+-------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 3                                                                             |
| WSREP_CLUSTER_STATUS      | Primary                                                                       |
| WSREP_INCOMING_ADDRESSES  | mariadb1.weave.local:3306,mariadb3.weave.local:3306,mariadb2.weave.local:3306 |
| WSREP_LOCAL_STATE_COMMENT | Synced                                                                        |
+---------------------------+-------------------------------------------------------------------------------+

En este punto, nuestra arquitectura se parece a esto:

Aunque el comando de ejecución es bastante largo, describe bien las características del contenedor. Probablemente sea una buena idea envolver el comando en una secuencia de comandos para simplificar los pasos de ejecución, o usar un archivo de redacción en su lugar.

Enrutamiento de base de datos con ProxySQL

Ahora tenemos tres contenedores de bases de datos ejecutándose. La única forma de acceder al clúster ahora es acceder al puerto publicado de MySQL del host Docker individual, que es 3306 (mapa a 3306 para el contenedor). Entonces, ¿qué sucede si falla uno de los contenedores de la base de datos? Debe conmutar por error manualmente la conexión del cliente al siguiente nodo disponible. Según el conector de la aplicación, también puede especificar una lista de nodos y dejar que el conector realice la conmutación por error y el enrutamiento de consultas por usted (Connector/J, PHP mysqlnd). De lo contrario, sería una buena idea unificar los recursos de la base de datos en un solo recurso, que se puede llamar servicio.

Aquí es donde ProxySQL entra en escena. ProxySQL puede actuar como el enrutador de consultas, equilibrando la carga de las conexiones de la base de datos de manera similar a lo que puede hacer "Servicio" en el mundo Swarm o Kubernetes. Hemos creado una imagen de ProxySQL Docker para este propósito y mantendremos la imagen para cada nueva versión con nuestro mejor esfuerzo.

Antes de ejecutar el contenedor ProxySQL, debemos preparar el archivo de configuración. Lo siguiente es lo que hemos configurado para proxysql1. Creamos un archivo de configuración personalizado en /containers/proxysql1/proxysql.cnf en host1:

$ cat /containers/proxysql1/proxysql.cnf
datadir="/var/lib/proxysql"
admin_variables=
{
        admin_credentials="admin:admin"
        mysql_ifaces="0.0.0.0:6032"
        refresh_interval=2000
}
mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
        interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.1.30"
        connect_timeout_server=10000
        monitor_history=60000
        monitor_connect_interval=200000
        monitor_ping_interval=200000
        ping_interval_server=10000
        ping_timeout_server=200
        commands_stats=true
        sessions_sort=true
        monitor_username="proxysql"
        monitor_password="proxysqlpassword"
}
mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)
mysql_users =
(
        { username = "sbtest" , password = "password" , default_hostgroup = 10 , active = 1 }
)
mysql_query_rules =
(
        {
                rule_id=100
                active=1
                match_pattern="^SELECT .* FOR UPDATE"
                destination_hostgroup=10
                apply=1
        },
        {
                rule_id=200
                active=1
                match_pattern="^SELECT .*"
                destination_hostgroup=20
                apply=1
        },
        {
                rule_id=300
                active=1
                match_pattern=".*"
                destination_hostgroup=10
                apply=1
        }
)
scheduler =
(
        {
                id = 1
                filename = "/usr/share/proxysql/tools/proxysql_galera_checker.sh"
                active = 1
                interval_ms = 2000
                arg1 = "10"
                arg2 = "20"
                arg3 = "1"
                arg4 = "1"
                arg5 = "/var/lib/proxysql/proxysql_galera_checker.log"
        }
)

La configuración anterior:

  • configure dos grupos de host, el grupo de un solo escritor y el grupo de múltiples escritores, como se define en la sección "mysql_servers",
  • enviar lecturas a todos los nodos de Galera (grupo de host 20) mientras que las operaciones de escritura irán a un único servidor de Galera (grupo de host 10),
  • programar el proxysql_galera_checker.sh,
  • use monitor_username y monitor_password como las credenciales de monitoreo creadas cuando arrancamos el clúster por primera vez (mariadb0).

Copie el archivo de configuración a host2, para la redundancia de ProxySQL:

$ mkdir -p /containers/proxysql2/ # on host2
$ scp /containers/proxysql1/proxysql.cnf /container/proxysql2/ # on host1

Luego, ejecute los contenedores ProxySQL en host1 y host2 respectivamente:

$ docker run -d \
        --name=${NAME} \
        --publish 6033 \
        --publish 6032 \
        --restart always \
        --net=weave \
        $(weave dns-args) \
        --hostname ${NAME}.weave.local \
        -v /containers/${NAME}/proxysql.cnf:/etc/proxysql.cnf \
        -v /containers/${NAME}/data:/var/lib/proxysql \
        severalnines/proxysql

** Reemplace ${NAME} con proxysql1 o proxysql2 respectivamente.

Especificamos --restart=always para que esté siempre disponible independientemente del estado de salida, así como el inicio automático cuando se inicia el demonio Docker. Esto asegurará que los contenedores ProxySQL actúen como un demonio.

Verifique el estado de los servidores MySQL monitoreados por ambas instancias de ProxySQL (se espera OFFLINE_SOFT para el grupo host de un solo escritor):

$ docker exec -it proxysql1 mysql -uadmin -padmin -h127.0.0.1 -P6032 -e 'select hostgroup_id,hostname,status from mysql_servers'
+--------------+----------------------+--------------+
| hostgroup_id | hostname             | status       |
+--------------+----------------------+--------------+
| 10           | mariadb1.weave.local | ONLINE       |
| 10           | mariadb2.weave.local | OFFLINE_SOFT |
| 10           | mariadb3.weave.local | OFFLINE_SOFT |
| 20           | mariadb1.weave.local | ONLINE       |
| 20           | mariadb2.weave.local | ONLINE       |
| 20           | mariadb3.weave.local | ONLINE       |
+--------------+----------------------+--------------+

En este punto, nuestra arquitectura se parece a esto:

Todas las conexiones provenientes de 6033 (ya sea desde el host1, el host2 o la red del contenedor) se equilibrarán en la carga de los contenedores de la base de datos back-end mediante ProxySQL. Si desea acceder a un servidor de base de datos individual, utilice el puerto 3306 del host físico en su lugar. No hay una dirección IP virtual como punto final único configurado para el servicio ProxySQL, pero podríamos tener eso usando Keepalived, que se explica en la siguiente sección.

Dirección IP virtual con Keepalived

Dado que configuramos los contenedores ProxySQL para que se ejecuten en host1 y host2, vamos a utilizar contenedores Keepalived para vincular estos hosts y proporcionar una dirección IP virtual a través de la red host. Esto permite que un único punto final para aplicaciones o clientes se conecte a la capa de equilibrio de carga respaldada por ProxySQL.

Como de costumbre, cree un archivo de configuración personalizado para nuestro servicio Keepalived. Aquí está el contenido de /containers/keepalived1/keepalived.conf:

vrrp_instance VI_DOCKER {
   interface ens33               # interface to monitor
   state MASTER
   virtual_router_id 52          # Assign one ID for this route
   priority 101
   unicast_src_ip 192.168.55.161
   unicast_peer {
      192.168.55.162
   }
   virtual_ipaddress {
      192.168.55.160             # the virtual IP
}

Copie el archivo de configuración a host2 para la segunda instancia:

$ mkdir -p /containers/keepalived2/ # on host2
$ scp /containers/keepalived1/keepalived.conf /container/keepalived2/ # on host1

Cambie la prioridad de 101 a 100 dentro del archivo de configuración copiado en host2:

$ sed -i 's/101/100/g' /containers/keepalived2/keepalived.conf

**La instancia de mayor prioridad mantendrá la dirección IP virtual (en este caso, el host1), hasta que se interrumpa la comunicación VRRP (en caso de que el host1 se caiga).

Luego, ejecute el siguiente comando en host1 y host2 respectivamente:

$ docker run -d \
        --name=${NAME} \
        --cap-add=NET_ADMIN \
        --net=host \
        --restart=always \
        --volume /containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf \ osixia/keepalived:1.4.4

** Reemplace ${NAME} con keepalived1 y keepalived2.

El comando ejecutar le dice a Docker que:

  • --nombre , crea un contenedor con
  • --cap-add=NET_ADMIN , agregue capacidades de Linux para el ámbito de administración de red
  • --net=host , adjunte el contenedor a la red host. Esto proporcionará una dirección IP virtual en la interfaz del host, ens33
  • --restart=siempre , mantenga siempre el contenedor en funcionamiento,
  • --volume=/containers/${NOMBRE}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , asigne el archivo de configuración personalizado para el uso del contenedor.

Después de iniciar ambos contenedores, verifique la existencia de la dirección IP virtual observando la interfaz de red física del nodo MAESTRO:

$ ip a | grep ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.55.161/24 brd 192.168.55.255 scope global ens33
    inet 192.168.55.160/32 scope global ens33

Los clientes y las aplicaciones ahora pueden usar la dirección IP virtual, 192.168.55.160 para acceder al servicio de la base de datos. Esta dirección IP virtual existe en host1 en este momento. Si el host1 falla, keepalived2 se hará cargo de la dirección IP y la activará en el host2. Tenga en cuenta que la configuración de este keepalived no supervisa los contenedores ProxySQL. Solo monitorea el anuncio VRRP de los pares Keepalived.

En este punto, nuestra arquitectura se parece a esto:

Resumen

Entonces, ahora tenemos un MariaDB Galera Cluster liderado por un servicio ProxySQL de alta disponibilidad, todo ejecutándose en contenedores Docker.

En la segunda parte, veremos cómo administrar esta configuración. Veremos cómo realizar operaciones como el apagado correcto, el arranque, la detección del nodo más avanzado, la conmutación por error, la recuperación, la ampliación/reducción, las actualizaciones, la copia de seguridad, etc. También discutiremos los pros y los contras de tener esta configuración para nuestro servicio de base de datos en clúster.

¡Feliz contenedorización!