MariaDB
 sql >> Database >  >> RDS >> MariaDB

Esecuzione di un cluster MariaDB Galera senza strumenti di orchestrazione dei contenitori:prima parte

Gli strumenti di orchestrazione dei container semplificano l'esecuzione di un sistema distribuito, distribuendo e ridistribuendo i container e gestendo eventuali errori che si verificano. Potrebbe essere necessario spostare le applicazioni, ad esempio per gestire gli aggiornamenti, il ridimensionamento o gli errori degli host sottostanti. Anche se suona bene, non sempre funziona bene con un cluster di database fortemente coerente come Galera. Non puoi semplicemente spostare i nodi del database, non sono applicazioni stateless. Inoltre, l'ordine in cui si eseguono operazioni su un cluster ha un'importanza elevata. Ad esempio, il riavvio di un cluster Galera deve iniziare dal nodo più avanzato, altrimenti perderai dati. Pertanto, ti mostreremo come eseguire Galera Cluster su Docker senza uno strumento di orchestrazione dei container, in modo da avere il controllo totale.

In questo post del blog, esamineremo come eseguire un cluster MariaDB Galera su contenitori Docker utilizzando l'immagine Docker standard su più host Docker, senza l'aiuto di strumenti di orchestrazione come Swarm o Kubernetes. Questo approccio è simile all'esecuzione di un cluster Galera su host standard, ma la gestione del processo è configurata tramite Docker.

Prima di saltare ulteriormente nei dettagli, assumiamo che tu abbia installato Docker, disabilitato SElinux/AppArmor e chiarito le regole all'interno di iptables, firewalld o ufw (a seconda di quale stai utilizzando). I seguenti sono tre host Docker dedicati per il nostro cluster di database:

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

Rete multi-host

Prima di tutto, la rete Docker predefinita è legata all'host locale. Docker Swarm introduce un altro livello di rete chiamato overlay network, che estende l'internetworking del container a più host Docker in un cluster chiamato Swarm. Molto prima che questa integrazione entrasse in vigore, c'erano molti plug-in di rete sviluppati per supportarla:Flannel, Calico, Weave sono alcuni di questi.

Qui useremo Weave come plug-in di rete Docker per la rete multi-host. Ciò è dovuto principalmente alla sua semplicità nell'installarlo e farlo funzionare e al supporto per il resolver DNS (i contenitori in esecuzione su questa rete possono risolversi a vicenda il nome host). Esistono due modi per far funzionare Weave:systemd o tramite Docker. Lo installeremo come unità systemd, quindi è indipendente dal demone Docker (altrimenti, dovremmo avviare Docker prima che Weave venga attivato).

  1. Scarica e installa Weave:

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

  2. Crea un file di unità systemd per 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. Definisci gli indirizzi IP o il nome host dei peer all'interno di /etc/sysconfig/weave:

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

  4. Avvia e abilita Weave all'avvio:

    $ systemctl start weave
$ systemctl enable weave

Ripeti i 4 passaggi precedenti su tutti gli host Docker. Verifica con il seguente comando una volta terminato:

$ weave status

Il numero di pari è ciò di cui ci occupiamo. Dovrebbe essere 3:

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

Eseguire un cluster Galera

Ora che la rete è pronta, è il momento di attivare i nostri contenitori di database e formare un cluster. Le regole di base sono:

  • Il container deve essere creato in --net=weave per avere una connettività multi-host.
  • Le porte dei container che devono essere pubblicate sono 3306, 4444, 4567, 4568.
  • L'immagine Docker deve supportare Galera. Se desideri utilizzare Oracle MySQL, ottieni la versione Codership. Se desideri Percona, usa invece questa immagine. In questo post del blog, stiamo usando MariaDB.

I motivi per cui abbiamo scelto MariaDB come fornitore del cluster Galera sono:

  • Galera è incorporato in MariaDB, a partire da MariaDB 10.1.
  • L'immagine MariaDB è gestita dai team Docker e MariaDB.
  • Una delle immagini Docker più popolari in circolazione.

Il bootstrap di un cluster Galera deve essere eseguito in sequenza. Innanzitutto, il nodo più aggiornato deve essere avviato con "wsrep_cluster_address=gcomm://". Quindi, avvia i nodi rimanenti con un indirizzo completo composto da tutti i nodi nel cluster, ad esempio "wsrep_cluster_address=gcomm://node1,node2,node3". Per eseguire questi passaggi utilizzando il container, è necessario eseguire alcuni passaggi aggiuntivi per garantire che tutti i container funzionino in modo omogeneo. Quindi il piano è:

  1. Dovremmo iniziare con 4 contenitori in questo ordine:mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
  2. Il contenitore mariadb0 utilizzerà la stessa datadir e configdir con mariadb1.
  3. Usa mariadb0 su host1 per il primo bootstrap, quindi avvia mariadb2 su host2, mariadb3 su host3.
  4. Rimuovi mariadb0 su host1 per lasciare il posto a mariadb1.
  5. Infine, avvia mariadb1 su host1.

Alla fine della giornata, avresti un Cluster Galera a tre nodi (mariadb1, mariadb2, mariadb3). Il primo contenitore (mariadb0) è un contenitore transitorio solo a scopo di bootstrap, che utilizza l'indirizzo del cluster "gcomm://". Condivide la stessa datadir e configdir con mariadb1 e verrà rimossa una volta formato il cluster (mariadb2 e mariadb3 sono attivi) e sincronizzati i nodi.

Per impostazione predefinita, Galera è disattivata in MariaDB e deve essere abilitata con un flag chiamato wsrep_on (impostato su ON) e wsrep_provider (impostato sul percorso della libreria Galera) più un numero di parametri relativi a Galera. Pertanto, è necessario definire un file di configurazione personalizzato affinché il contenitore configuri Galera correttamente.

Iniziamo con il primo contenitore, mariadb0. Crea un file in /containers/mariadb1/conf.d/my.cnf e aggiungi le seguenti righe:

$ 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

Poiché l'immagine non viene fornita con MariaDB Backup (che è il metodo SST preferito per MariaDB 10.1 e MariaDB 10.2), per il momento continueremo con xtrabackup-v2.

Per eseguire il primo bootstrap per il cluster, esegui il container bootstrap (mariadb0) su host1 con "datadir" e "conf.d" di 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

I parametri utilizzati nel comando precedente sono:

  • --nome , crea il contenitore denominato "mariadb0",
  • --nome host , assegna al contenitore un nome host "mariadb0.weave.local",
  • --net , posiziona il contenitore nella rete weave per il supporto della rete multi-host,
  • --pubblica , espone le porte 3306, 4444, 4567, 4568 del container all'host,
  • $(tessere dns-args) , configura il resolver DNS per questo contenitore. Questo comando può essere tradotto in Docker eseguito come "--dns=172.17.0.1 --dns-search=weave.local.",
  • --env MYSQL_ROOT_PASSWORD , la password principale di MySQL,
  • --env MYSQL_USER , crea l'utente "proxysql" da utilizzare in seguito con ProxySQL per l'instradamento del database,
  • --env MYSQL_PASSWORD , la password utente "proxysql",
  • --volume /containers/mariadb1/datadir:/var/lib/mysql , crea /containers/mariadb1/datadir se non esiste e lo mappa con /var/lib/mysql (MySQL datadir) del contenitore (per il nodo bootstrap, questo potrebbe essere saltato),
  • --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , monta i file nella directory /containers/mariadb1/conf.d dell'host Docker, nel contenitore in /etc/mysql/mariadb.conf.d.
  • mariadb:10.2.15 , utilizza l'immagine MariaDB 10.2.15 da qui,
  • --wsrep_cluster_address , Stringa di connessione Galera per il cluster. "gcomm://" significa bootstrap. Per il resto dei contenitori utilizzeremo invece un indirizzo completo.
  • --wsrep_sst_auth , stringa di autenticazione per l'utente SST. Usa lo stesso utente come root,
  • --wsrep_node_address , il nome host del nodo, in questo caso utilizzeremo l'FQDN fornito da Weave.

Il contenitore bootstrap contiene diversi elementi chiave:

  • Il nome, hostname e wsrep_node_address è mariadb0, ma utilizza i volumi di mariadb1.
  • L'indirizzo del cluster è "gcomm://"
  • Ci sono due parametri --env aggiuntivi:MYSQL_USER e MYSQL_PASSWORD. Questi parametri creeranno un utente aggiuntivo per il nostro scopo di monitoraggio proxysql.

Verifica con il seguente comando:

$ docker ps
$ docker logs -f mariadb0

Quando vedi la seguente riga, indica che il processo di bootstrap è completato e Galera è attivo:

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

Crea la directory per caricare il nostro file di configurazione personalizzato negli host rimanenti:

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

Quindi, copia il file my.cnf che abbiamo creato per mariadb0 e mariadb1 rispettivamente in mariadb2 e mariadb3:

$ 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

Successivamente, crea altri 2 contenitori di database (mariadb2 e mariadb3) rispettivamente su host2 e host3:

$ 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

** Sostituisci ${NAME} rispettivamente con mariadb2 o mariadb3.

Tuttavia, c'è un problema. Lo script entrypoint controlla il servizio mysqld in background dopo l'inizializzazione del database utilizzando l'utente root MySQL senza password. Poiché Galera esegue automaticamente la sincronizzazione tramite SST o IST all'avvio, la password dell'utente root MySQL cambierà, rispecchiando il nodo di bootstrap. Pertanto, durante il primo avvio vedresti il ​​seguente errore:

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.

Il trucco è riavviare ancora una volta i container falliti, perché questa volta sarebbe stata creata la datadir MySQL (al primo tentativo di esecuzione) e salterebbe la parte di inizializzazione del database:

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

Una volta avviato, verifica guardando la seguente riga:

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

A questo punto, ci sono 3 contenitori in esecuzione, mariadb0, mariadb2 e mariadb3. Tieni presente che mariadb0 viene avviato utilizzando il comando bootstrap (gcomm://), il che significa che se il contenitore viene riavviato automaticamente da Docker in futuro, potrebbe potenzialmente essere disconnesso dal componente principale. Pertanto, dobbiamo rimuovere questo contenitore e sostituirlo con mariadb1, utilizzando la stessa stringa di connessione Galera con il resto e utilizzare la stessa datadir e configdir con mariadb0.

Per prima cosa, ferma mariadb0 inviando SIGTERM (per assicurarti che il nodo venga spento correttamente):

$ docker kill -s 15 mariadb0

Quindi, avvia mariadb1 su host1 usando un comando simile 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

Questa volta, non è necessario eseguire il trucco del riavvio perché MySQL datadir esiste già (creato da mariadb0). Una volta avviato il contenitore, verifica che la dimensione del cluster sia 3, lo stato deve essere Primario e lo stato locale sia sincronizzato:

$ 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                                                                        |
+---------------------------+-------------------------------------------------------------------------------+

A questo punto, la nostra architettura è simile a questa:

Sebbene il comando di esecuzione sia piuttosto lungo, descrive bene le caratteristiche del contenitore. Probabilmente è una buona idea racchiudere il comando in uno script per semplificare i passaggi di esecuzione o utilizzare invece un file di composizione.

Routing del database con ProxySQL

Ora abbiamo tre contenitori di database in esecuzione. L'unico modo per accedere al cluster ora è accedere alla porta pubblicata di MySQL del singolo host Docker, che è 3306 (mappa a 3306 al container). Quindi cosa succede se uno dei contenitori del database si guasta? È necessario eseguire manualmente il failover della connessione del client al successivo nodo disponibile. A seconda del connettore dell'applicazione, puoi anche specificare un elenco di nodi e lasciare che il connettore esegua il failover e il routing delle query per te (Connettore/J, PHP mysqlnd). In caso contrario, sarebbe una buona idea unificare le risorse del database in un'unica risorsa, che può essere chiamata servizio.

È qui che entra in gioco ProxySQL. ProxySQL può fungere da router di query, bilanciando il carico delle connessioni del database in modo simile a ciò che può fare "Service" nel mondo Swarm o Kubernetes. Abbiamo creato un'immagine ProxySQL Docker per questo scopo e manterremo l'immagine per ogni nuova versione con il nostro massimo sforzo.

Prima di eseguire il container ProxySQL, dobbiamo preparare il file di configurazione. Quello che segue è ciò che abbiamo configurato per proxysql1. Creiamo un file di configurazione personalizzato in /containers/proxysql1/proxysql.cnf su 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 configurazione di cui sopra:

  • configurare due gruppi host, il gruppo di autori singoli e multiscrittori, come definito nella sezione "mysql_servers",
  • invia letture a tutti i nodi Galera (gruppo host 20) mentre le operazioni di scrittura andranno a un singolo server Galera (gruppo host 10),
  • pianifica il proxysql_galera_checker.sh,
  • usa monitor_username e monitor_password come credenziali di monitoraggio create al primo avvio del cluster (mariadb0).

Copia il file di configurazione su host2, per la ridondanza ProxySQL:

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

Quindi, esegui i contenitori ProxySQL rispettivamente su host1 e host2:

$ 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

** Sostituisci ${NAME} rispettivamente con proxysql1 o proxysql2.

Abbiamo specificato --restart=always per renderlo sempre disponibile indipendentemente dallo stato di uscita, oltre all'avvio automatico all'avvio del demone Docker. Ciò assicurerà che i contenitori ProxySQL agiscano come un demone.

Verifica lo stato dei server MySQL monitorato da entrambe le istanze ProxySQL (OFFLINE_SOFT è previsto per il gruppo host a scrittore singolo):

$ 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       |
+--------------+----------------------+--------------+

A questo punto, la nostra architettura è simile a questa:

Tutte le connessioni provenienti da 6033 (dalla rete host1, host2 o container) verranno bilanciate in carico ai contenitori di database back-end utilizzando ProxySQL. Se desideri accedere a un singolo server di database, utilizza invece la porta 3306 dell'host fisico. Non esiste un indirizzo IP virtuale come singolo endpoint configurato per il servizio ProxySQL, ma potremmo averlo utilizzando Keepalived, come spiegato nella sezione successiva.

Indirizzo IP virtuale con Keepalived

Poiché abbiamo configurato i contenitori ProxySQL per l'esecuzione su host1 e host2, utilizzeremo i contenitori Keepalived per collegare insieme questi host e fornire un indirizzo IP virtuale tramite la rete host. Ciò consente a un singolo endpoint per applicazioni o client di connettersi al livello di bilanciamento del carico supportato da ProxySQL.

Come al solito, crea un file di configurazione personalizzato per il nostro servizio Keepalived. Ecco il contenuto di /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
}

Copia il file di configurazione su host2 per la seconda istanza:

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

Modifica la priorità da 101 a 100 all'interno del file di configurazione copiato su host2:

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

**L'istanza con priorità più alta manterrà l'indirizzo IP virtuale (in questo caso è host1), fino a quando la comunicazione VRRP non viene interrotta (nel caso in cui host1 si interrompa).

Quindi, esegui il seguente comando rispettivamente su host1 e host2:

$ 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

** Sostituisci ${NAME} con keepalived1 e keepalived2.

Il comando run dice a Docker di:

  • --nome , crea un contenitore con
  • --cap-add=NET_ADMIN , aggiungi funzionalità Linux per l'ambito dell'amministratore di rete
  • --net=host , collegare il contenitore alla rete host. Ciò fornirà l'indirizzo IP virtuale sull'interfaccia host, ens33
  • --restart=sempre , mantieni sempre in esecuzione il contenitore,
  • --volume=/containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , mappa il file di configurazione personalizzato per l'utilizzo del contenitore.

Dopo aver avviato entrambi i container, verifica l'esistenza dell'indirizzo IP virtuale osservando l'interfaccia di rete fisica del nodo 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

I client e le applicazioni possono ora utilizzare l'indirizzo IP virtuale, 192.168.55.160 per accedere al servizio di database. Questo indirizzo IP virtuale esiste su host1 in questo momento. Se host1 non funziona, keepalived2 prenderà il controllo dell'indirizzo IP e lo porterà su host2. Tieni presente che la configurazione per questo keepalived non monitora i contenitori ProxySQL. Monitora solo la pubblicità VRRP dei peer Keepalived.

A questo punto, la nostra architettura è simile a questa:

Riepilogo

Quindi, ora abbiamo un MariaDB Galera Cluster fronteggiato da un servizio ProxySQL ad alta disponibilità, tutto in esecuzione su contenitori Docker.

Nella seconda parte, esamineremo come gestire questa configurazione. Vedremo come eseguire operazioni come lo spegnimento regolare, il bootstrap, il rilevamento del nodo più avanzato, il failover, il ripristino, la scalabilità verticale, gli aggiornamenti, il backup e così via. Discuteremo anche i pro ei contro di avere questa configurazione per il nostro servizio di database in cluster.

Buona containerizzazione!