MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Executando um cluster MariaDB Galera sem ferramentas de orquestração de contêiner:parte um


As ferramentas de orquestração de contêineres simplificam a execução de um sistema distribuído, implantando e reimplantando contêineres e tratando de quaisquer falhas que ocorram. Pode ser necessário mover aplicativos, por exemplo, para lidar com atualizações, dimensionamento ou falhas de host subjacentes. Embora isso pareça ótimo, nem sempre funciona bem com um cluster de banco de dados fortemente consistente como o Galera. Você não pode simplesmente mover nós de banco de dados, eles não são aplicativos sem estado. Além disso, a ordem na qual você executa as operações em um cluster tem alta significância. Por exemplo, reiniciar um cluster Galera deve começar a partir do nó mais avançado, caso contrário você perderá dados. Portanto, mostraremos como executar o Galera Cluster no Docker sem uma ferramenta de orquestração de contêineres, para que você tenha total controle.

Nesta postagem do blog, veremos como executar um MariaDB Galera Cluster em contêineres do Docker usando a imagem padrão do Docker em vários hosts do Docker, sem a ajuda de ferramentas de orquestração como Swarm ou Kubernetes. Essa abordagem é semelhante à execução de um Galera Cluster em hosts padrão, mas o gerenciamento de processos é configurado por meio do Docker.

Antes de entrarmos em mais detalhes, presumimos que você instalou o Docker, desativou o SElinux/AppArmor e esclareceu as regras dentro do iptables, firewalld ou ufw (o que estiver usando). A seguir estão três hosts Docker dedicados para nosso cluster de banco de dados:
  • host1.local - 192.168.55.161
  • host2.local - 192.168.55.162
  • host3.local - 192.168.55.163

Rede de vários hosts


Em primeiro lugar, a rede padrão do Docker está vinculada ao host local. O Docker Swarm apresenta outra camada de rede chamada rede de sobreposição, que estende o inter-redes do contêiner para vários hosts Docker em um cluster chamado Swarm. Muito antes dessa integração acontecer, havia muitos plugins de rede desenvolvidos para suportar isso - Flannel, Calico, Weave são alguns deles.

Aqui, vamos usar o Weave como o plug-in de rede do Docker para rede multi-host. Isso se deve principalmente à sua simplicidade para instalá-lo e executá-lo e ao suporte para resolvedor de DNS (os contêineres executados nesta rede podem resolver o nome de host um do outro). Existem duas maneiras de executar o Weave - systemd ou através do Docker. Vamos instalá-lo como uma unidade systemd, portanto, é independente do daemon do Docker (caso contrário, teríamos que iniciar o Docker antes que o Weave fosse ativado).

  1. Baixe e instale o Weave:
    $ curl -L git.io/weave -o /usr/local/bin/weave
    $ chmod a+x /usr/local/bin/weave

  2. Crie um arquivo de unidade systemd para o 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 endereços IP ou nome de host dos peers dentro de /etc/sysconfig/weave:
    $ echo 'PEERS="192.168.55.161 192.168.55.162 192.168.55.163"' > /etc/sysconfig/weave

  4. Inicie e ative o Weave na inicialização:
    $ systemctl start weave
    $ systemctl enable weave

Repita as 4 etapas acima em todos os hosts do Docker. Verifique com o seguinte comando uma vez feito:
$ weave status

O número de pares é o que estamos procurando. Deve ser 3:
          ...
          Peers: 3 (with 6 established connections)
          ...

Executando um cluster Galera


Agora que a rede está pronta, é hora de disparar nossos contêineres de banco de dados e formar um cluster. As regras básicas são:
  • O contêiner deve ser criado em --net=weave para ter conectividade com vários hosts.
  • As portas de contêiner que precisam ser publicadas são 3306, 4444, 4567, 4568.
  • A imagem do Docker deve ser compatível com Galera. Se você quiser usar o Oracle MySQL, obtenha a versão Codership. Se você gostaria de Percona, use esta imagem em vez disso. Nesta postagem do blog, estamos usando o MariaDB.

As razões pelas quais escolhemos o MariaDB como fornecedor do cluster Galera são:
  • O Galera está incorporado ao MariaDB, a partir do MariaDB 10.1.
  • A imagem do MariaDB é mantida pelas equipes do Docker e do MariaDB.
  • Uma das imagens do Docker mais populares do mercado.

O bootstrap de um Galera Cluster deve ser executado em sequência. Primeiramente, o nó mais atualizado deve ser iniciado com "wsrep_cluster_address=gcomm://". Em seguida, inicie os nós restantes com um endereço completo que consiste em todos os nós do cluster, por exemplo, "wsrep_cluster_address=gcomm://node1,node2,node3". Para realizar essas etapas usando o container, precisamos realizar algumas etapas extras para garantir que todos os containers estejam sendo executados de forma homogênea. Então o plano é:
  1. Precisamos começar com 4 contêineres nesta ordem - mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
  2. O contêiner mariadb0 usará o mesmo datadir e configdir com mariadb1.
  3. Use mariadb0 no host1 para o primeiro bootstrap, depois inicie mariadb2 no host2, mariadb3 no host3.
  4. Remova mariadb0 de host1 para dar lugar a mariadb1.
  5. Por último, inicie mariadb1 no host1.

No final do dia, você teria um Galera Cluster de três nós (mariadb1, mariadb2, mariadb3). O primeiro contêiner (mariadb0) é um contêiner temporário apenas para fins de inicialização, usando o endereço de cluster "gcomm://". Ele compartilha o mesmo datadir e configdir com mariadb1 e será removido assim que o cluster for formado (mariadb2 e mariadb3 estiverem ativos) e os nós forem sincronizados.

Por padrão, Galera está desativado no MariaDB e precisa ser ativado com um sinalizador chamado wsrep_on (definido como ATIVADO) e wsrep_provider (definido para o caminho da biblioteca Galera) mais vários parâmetros relacionados ao Galera. Assim, precisamos definir um arquivo de configuração personalizado do container para configurar o Galera corretamente.

Vamos começar com o primeiro contêiner, mariadb0. Crie um arquivo em /containers/mariadb1/conf.d/my.cnf e adicione as seguintes linhas:
$ 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

Como a imagem não vem com o MariaDB Backup (que é o método SST preferido para MariaDB 10.1 e MariaDB 10.2), vamos ficar com xtrabackup-v2 por enquanto.

Para executar o primeiro bootstrap para o cluster, execute o container bootstrap (mariadb0) no host1 com "datadir" e "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

Os parâmetros usados ​​no comando acima são:
  • --nome , cria o contêiner chamado "mariadb0",
  • --nome do host , atribui ao contêiner um nome de host "mariadb0.weave.local",
  • --net , coloca o contêiner na rede weave para suporte à rede de vários hosts,
  • --publicar , expõe as portas 3306, 4444, 4567, 4568 no contêiner para o host,
  • $(weave dns-args) , configura o resolvedor de DNS para este contêiner. Este comando pode ser traduzido para o Docker executado como "--dns=172.17.0.1 --dns-search=weave.local.",
  • --env MYSQL_ROOT_PASSWORD , a senha raiz do MySQL,
  • --env MYSQL_USER , cria um usuário "proxysql" para ser usado posteriormente com ProxySQL para roteamento de banco de dados,
  • --env MYSQL_PASSWORD , a senha do usuário "proxysql",
  • --volume /containers/mariadb1/datadir:/var/lib/mysql , cria /containers/mariadb1/datadir se não existir e mapeia-o com /var/lib/mysql (MySQL datadir) do contêiner (para nó de bootstrap, isso pode ser ignorado),
  • --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , monta os arquivos no diretório /containers/mariadb1/conf.d do host Docker, no contêiner em /etc/mysql/mariadb.conf.d.
  • mariadb:10.2.15 , usa a imagem MariaDB 10.2.15 daqui,
  • --wsrep_cluster_address , cadeia de conexão Galera para o cluster. "gcomm://" significa bootstrap. Para o restante dos contêineres, usaremos um endereço completo.
  • --wsrep_sst_auth , string de autenticação para usuário SST. Use o mesmo usuário como root,
  • --wsrep_node_address , o nome do host do nó, neste caso vamos usar o FQDN fornecido pelo Weave.

O container bootstrap contém várias coisas importantes:
  • O nome, hostname e wsrep_node_address é mariadb0, mas usa os volumes de mariadb1.
  • O endereço do cluster é "gcomm://"
  • Existem dois parâmetros --env adicionais - MYSQL_USER e MYSQL_PASSWORD. Esses parâmetros criarão um usuário adicional para nosso propósito de monitoramento proxysql.

Verifique com o seguinte comando:
$ docker ps
$ docker logs -f mariadb0

Depois de ver a seguinte linha, ela indica que o processo de bootstrap foi concluído e o Galera está ativo:
2018-05-30 23:19:30 139816524539648 [Note] WSREP: Synchronized with group, ready for connections

Crie o diretório para carregar nosso arquivo de configuração personalizado nos hosts restantes:
$ mkdir -p /containers/mariadb2/conf.d # on host2
$ mkdir -p /containers/mariadb3/conf.d # on host3

Em seguida, copie o my.cnf que criamos para mariadb0 e mariadb1 para mariadb2 e 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

Em seguida, crie outros 2 contêineres de banco de dados (mariadb2 e mariadb3) no host2 e 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

** Substitua ${NAME} por mariadb2 ou mariadb3 respectivamente.

No entanto, há um porém. O script de ponto de entrada verifica o serviço mysqld em segundo plano após a inicialização do banco de dados usando o usuário root do MySQL sem senha. Como o Galera executa automaticamente a sincronização através de SST ou IST ao inicializar, a senha do usuário root do MySQL será alterada, espelhando o nó bootstrap. Assim, você veria o seguinte erro durante a primeira inicialização:
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.

O truque é reiniciar os containers com falha mais uma vez, porque desta vez, o diretório de dados do MySQL teria sido criado (na primeira tentativa de execução) e pularia a parte de inicialização do banco de dados:
$ docker start mariadb2 # on host2
$ docker start mariadb3 # on host3

Uma vez iniciado, verifique olhando para a seguinte linha:
$ docker logs -f mariadb2
…
2018-05-30 23:28:39 139808069601024 [Note] WSREP: Synchronized with group, ready for connections

Neste ponto, existem 3 contêineres em execução, mariadb0, mariadb2 e mariadb3. Observe que o mariadb0 é iniciado usando o comando bootstrap (gcomm://), o que significa que, se o contêiner for reiniciado automaticamente pelo Docker no futuro, ele poderá se desconectar do componente primário. Assim, precisamos remover este container e substituí-lo por mariadb1, usando a mesma string de conexão Galera com o restante e usar o mesmo datadir e configdir com mariadb0.

Primeiro, pare mariadb0 enviando SIGTERM (para garantir que o nó seja desligado normalmente):
$ docker kill -s 15 mariadb0

Em seguida, inicie o mariadb1 no host1 usando um comando semelhante ao mariadb2 ou 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

Desta vez, você não precisa fazer o truque de reinicialização porque o MySQL datadir já existe (criado por mariadb0). Depois que o contêiner for iniciado, verifique se o tamanho do cluster é 3, o status deve estar em Primário e o 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                                                                        |
+---------------------------+-------------------------------------------------------------------------------+

Neste ponto, nossa arquitetura está mais ou menos assim:

Embora o comando run seja bem longo, ele descreve bem as características do container. Provavelmente é uma boa ideia envolver o comando em um script para simplificar as etapas de execução ou usar um arquivo de composição.

Roteamento de banco de dados com ProxySQL


Agora temos três contêineres de banco de dados em execução. A única maneira de acessar o cluster agora é acessar a porta publicada do MySQL do host Docker individual, que é 3306 (mapear para 3306 para o contêiner). Então, o que acontece se um dos contêineres do banco de dados falhar? Você precisa fazer o failover manualmente da conexão do cliente para o próximo nó disponível. Dependendo do conector do aplicativo, você também pode especificar uma lista de nós e permitir que o conector faça o failover e o roteamento de consulta para você (Connector/J, PHP mysqlnd). Caso contrário, seria uma boa ideia unificar os recursos do banco de dados em um único recurso, que pode ser chamado de serviço.

É aqui que o ProxySQL entra em cena. O ProxySQL pode atuar como o roteador de consulta, balanceando a carga das conexões do banco de dados semelhante ao que "Serviço" no mundo Swarm ou Kubernetes pode fazer. Criamos uma imagem do ProxySQL Docker para essa finalidade e manteremos a imagem para cada nova versão com nosso melhor esforço.

Antes de executarmos o container ProxySQL, temos que preparar o arquivo de configuração. O seguinte é o que configuramos para proxysql1. Criamos um arquivo de configuração personalizado em /containers/proxysql1/proxysql.cnf no 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"
        }
)

A configuração acima irá:
  • configurar dois grupos de hosts, o grupo de gravador único e o grupo de vários gravadores, conforme definido na seção "mysql_servers",
  • enviar leituras para todos os nós Galera (hostgroup 20) enquanto as operações de gravação irão para um único servidor Galera (hostgroup 10),
  • agende o proxysql_galera_checker.sh,
  • use monitor_username e monitor_password como as credenciais de monitoramento criadas quando inicializamos o cluster (mariadb0).

Copie o arquivo de configuração para host2, para redundância de ProxySQL:
$ mkdir -p /containers/proxysql2/ # on host2
$ scp /containers/proxysql1/proxysql.cnf /container/proxysql2/ # on host1

Em seguida, execute os contêineres ProxySQL em host1 e 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

** Substitua ${NAME} por proxysql1 ou proxysql2 respectivamente.

Especificamos --restart=always para torná-lo sempre disponível, independentemente do status de saída, bem como a inicialização automática quando o daemon do Docker é iniciado. Isso garantirá que os contêineres ProxySQL funcionem como um daemon.

Verifique o status dos servidores MySQL monitorados por ambas as instâncias do ProxySQL (OFFLINE_SOFT é esperado para o grupo de hosts de gravador único):
$ 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       |
+--------------+----------------------+--------------+

Neste ponto, nossa arquitetura está mais ou menos assim:

Todas as conexões provenientes de 6033 (do host1, host2 ou da rede do contêiner) terão balanceamento de carga para os contêineres de banco de dados de back-end usando ProxySQL. Se desejar acessar um servidor de banco de dados individual, use a porta 3306 do host físico. Não há um endereço IP virtual como único ponto de extremidade configurado para o serviço ProxySQL, mas poderíamos ter isso usando Keepalived, que é explicado na próxima seção.

Endereço IP virtual com Keepalived


Como configuramos os contêineres ProxySQL para serem executados no host1 e no host2, usaremos os contêineres Keepalived para unir esses hosts e fornecer o endereço IP virtual por meio da rede do host. Isso permite que um único endpoint para aplicativos ou clientes se conecte à camada de balanceamento de carga apoiada pelo ProxySQL.

Como de costume, crie um arquivo de configuração personalizado para nosso serviço Keepalived. Aqui está o conteúdo 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 o arquivo de configuração para host2 para a segunda instância:
$ mkdir -p /containers/keepalived2/ # on host2
$ scp /containers/keepalived1/keepalived.conf /container/keepalived2/ # on host1

Altere a prioridade de 101 para 100 dentro do arquivo de configuração copiado no host2:
$ sed -i 's/101/100/g' /containers/keepalived2/keepalived.conf

**A instância de maior prioridade manterá o endereço IP virtual (neste caso é host1), até que a comunicação VRRP seja interrompida (caso o host1 fique inativo).

Em seguida, execute o seguinte comando em host1 e 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

** Substitua ${NAME} por keepalived1 e keepalived2.

O comando run diz ao Docker para:
  • --nome , crie um contêiner com
  • --cap-add=NET_ADMIN , adicione recursos do Linux para escopo de administração de rede
  • --net=host , anexe o contêiner à rede do host. Isso fornecerá o endereço IP virtual na interface do host, ens33
  • --restart=sempre , sempre mantenha o contêiner em execução,
  • --volume=/containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , mapeie o arquivo de configuração personalizado para uso do contêiner.

Depois que os dois contêineres forem iniciados, verifique a existência do endereço IP virtual observando a interface de rede física do nó MASTER:
$ 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

Os clientes e aplicativos agora podem usar o endereço IP virtual, 192.168.55.160 para acessar o serviço de banco de dados. Este endereço IP virtual existe no host1 neste momento. Se o host1 ficar inativo, keepalived2 assumirá o endereço IP e o exibirá no host2. Observe que a configuração deste keepalived não monitora os contêineres ProxySQL. Ele apenas monitora o anúncio VRRP dos pares Keepalived.

Neste ponto, nossa arquitetura está mais ou menos assim:

Resumo


Então, agora temos um MariaDB Galera Cluster com um serviço ProxySQL altamente disponível, tudo rodando em containers Docker.

Na parte dois, veremos como gerenciar essa configuração. Veremos como executar operações como desligamento normal, bootstrapping, detecção do nó mais avançado, failover, recuperação, dimensionamento para cima/para baixo, upgrades, backup e assim por diante. Também discutiremos os prós e contras de ter essa configuração para nosso serviço de banco de dados clusterizado.

Feliz conteinerização!