Köra ett MariaDB Galera-kluster utan verktyg för containerorkestrering:Del ett

Behållarorkestreringsverktyg förenklar driften av ett distribuerat system genom att distribuera och omdistribuera behållare och hantera eventuella fel som uppstår. Man kan behöva flytta runt applikationer, t.ex. för att hantera uppdateringar, skalning eller underliggande värdfel. Även om detta låter bra, fungerar det inte alltid bra med ett starkt konsekvent databaskluster som Galera. Du kan inte bara flytta runt databasnoder, de är inte statslösa applikationer. Ordningen i vilken du utför operationer på ett kluster har också stor betydelse. Omstart av ett Galera-kluster måste till exempel börja från den mest avancerade noden, annars kommer du att förlora data. Därför kommer vi att visa dig hur du kör Galera Cluster på Docker utan ett containerorkestreringsverktyg, så att du har total kontroll.

I det här blogginlägget kommer vi att undersöka hur man kör ett MariaDB Galera Cluster på Docker-behållare med standard Docker-bilden på flera Docker-värdar, utan hjälp av orkestreringsverktyg som Swarm eller Kubernetes. Detta tillvägagångssätt liknar att köra ett Galera-kluster på standardvärdar, men processhanteringen konfigureras genom Docker.

Innan vi går vidare in i detaljer, antar vi att du har installerat Docker, inaktiverat SElinux/AppArmor och rensat upp reglerna i iptables, brandvägg eller ufw (vilken du än använder). Följande är tre dedikerade Docker-värdar för vårt databaskluster:

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

Nätverk med flera värdar

Först och främst är standard Docker-nätverk bunden till den lokala värden. Docker Swarm introducerar ett annat nätverkslager som kallas överlagringsnätverk, som utökar containerinternetarbetet till flera Docker-värdar i ett kluster som heter Swarm. Långt innan den här integrationen kom på plats fanns det många nätverksplugins utvecklade för att stödja detta - Flannel, Calico, Weave är några av dem.

Här kommer vi att använda Weave som Docker-nätverksplugin för nätverk med flera värdar. Detta beror främst på dess enkelhet att installera och köra, och stöd för DNS-resolver (behållare som körs under detta nätverk kan lösa varandras värdnamn). Det finns två sätt att få Weave igång - systemd eller genom Docker. Vi kommer att installera den som en systemd-enhet, så den är oberoende av Docker-demonen (annars måste vi starta Docker först innan Weave aktiveras).

1. Ladda ner och installera Weave:

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

2. Skapa en systemd enhetsfil för 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. Definiera IP-adresser eller värdnamn för peers inuti /etc/sysconfig/weave:

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

4. Starta och aktivera Weave on boot:

   $ systemctl start weave
   $ systemctl enable weave

Upprepa ovanstående 4 steg på alla Docker-värdar. Verifiera med följande kommando när du är klar:

$ weave status

Antalet kamrater är vad vi ser efter. Det borde vara 3:

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

Köra ett Galera-kluster

Nu är nätverket klart, det är dags att avfyra våra databascontainrar och bilda ett kluster. Grundreglerna är:

• Behållaren måste skapas under --net=weave för att ha multi-host-anslutning.
• Behållarportar som måste publiceras är 3306, 4444, 4567, 4568.
• Docker-bilden måste stödja Galera. Om du vill använda Oracle MySQL, skaffa Codership-versionen. Om du vill ha Perconas, använd den här bilden istället. I det här blogginlägget använder vi MariaDB:s.

Anledningarna till att vi valde MariaDB som Galera-klusterleverantör är:

• Galera är inbäddat i MariaDB, från och med MariaDB 10.1.
• MariaDB-avbildningen underhålls av Docker- och MariaDB-teamen.
• En av de mest populära Docker-bilderna som finns.

Bootstrapping av ett Galera-kluster måste utföras i sekvens. För det första måste den mest uppdaterade noden startas med "wsrep_cluster_address=gcomm://". Starta sedan de återstående noderna med en fullständig adress som består av alla noder i klustret, t.ex. "wsrep_cluster_address=gcomm://node1,node2,node3". För att utföra dessa steg med behållare måste vi göra några extra steg för att säkerställa att alla behållare körs homogent. Så planen är:

1. Vi skulle behöva börja med fyra behållare i denna ordning - mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
2. Behållaren mariadb0 kommer att använda samma datadir och configdir som mariadb1.
3. Använd mariadb0 på host1 för den första bootstrap, starta sedan mariadb2 på host2, mariadb3 på host3.
4. Ta bort mariadb0 på värd1 för att ge vika för mariadb1.
5. Starta slutligen mariadb1 på värd1.

I slutet av dagen skulle du ha ett Galera-kluster med tre noder (mariadb1, mariadb2, mariadb3). Den första behållaren (mariadb0) är en övergående behållare endast för bootstrapping-ändamål, med klusteradressen "gcomm://". Den delar samma datadir och configdir med mariadb1 och kommer att tas bort när klustret har bildats (mariadb2 och mariadb3 är uppe) och noder synkroniseras.

Som standard är Galera avstängd i MariaDB och måste aktiveras med en flagga som heter wsrep_on (inställd på PÅ) och wsrep_provider (inställd på Galera-bibliotekssökvägen) plus ett antal Galera-relaterade parametrar. Därför måste vi definiera en anpassad konfigurationsfil för behållaren för att konfigurera Galera korrekt.

Låt oss börja med den första behållaren, mariadb0. Skapa en fil under /containers/mariadb1/conf.d/my.cnf och lägg till följande rader:

$ 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

Eftersom bilden inte kommer med MariaDB Backup (vilket är den föredragna SST-metoden för MariaDB 10.1 och MariaDB 10.2), kommer vi att hålla fast vid xtrabackup-v2 tills vidare.

För att utföra den första bootstrap för klustret, kör bootstrap-behållaren (mariadb0) på host1 med mariadb1:s "datadir" och "conf.d":

$ 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

Parametrarna som används i kommandot ovan är:

• --namn , skapar behållaren med namnet "mariadb0",
• --värdnamn , tilldelar behållaren ett värdnamn "mariadb0.weave.local",
• --nät , placerar behållaren i vävnätverket för stöd för nätverk för flera värdar,
• --publicera , exponerar portarna 3306, 4444, 4567, 4568 på behållaren för värden,
• $(väv dns-args) , konfigurerar DNS-resolver för den här behållaren. Detta kommando kan översättas till Docker-körning som "--dns=172.17.0.1 --dns-search=weave.local.",
• --env MYSQL_ROOT_PASSWORD , MySQL root-lösenordet,
• --env MYSQL_USER , skapar "proxysql"-användare för att användas senare med ProxySQL för databasrouting,
• --env MYSQL_PASSWORD , användarlösenordet "proxysql",
• --volym /containers/mariadb1/datadir:/var/lib/mysql , skapar /containers/mariadb1/datadir om det inte finns och mappar det med /var/lib/mysql (MySQL datadir) i behållaren (för bootstrap-noden kan detta hoppas över),
• --volym /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , monterar filerna under katalogen /containers/mariadb1/conf.d hos Docker-värden, i behållaren på /etc/mysql/mariadb.conf.d.
• mariadb:10.2.15 , använder MariaDB 10.2.15-bild härifrån,
• --wsrep_cluster_address , Galera anslutningssträng för klustret. "gcomm://" betyder bootstrap. För resten av behållarna kommer vi att använda en fullständig adress istället.
• --wsrep_sst_auth , autentiseringssträng för SST-användare. Använd samma användare som root,
• --wsrep_node_address , nodens värdnamn, i det här fallet kommer vi att använda FQDN från Weave.

Bootstrap-behållaren innehåller flera viktiga saker:

• Namnet, värdnamnet och wsrep_node_address är mariadb0, men det använder volymerna för mariadb1.
• Klusteradressen är "gcomm://"
• Det finns ytterligare två --env-parametrar - MYSQL_USER och MYSQL_PASSWORD. Dessa parametrar kommer att skapa ytterligare användare för vårt proxysql-övervakningsändamål.

Verifiera med följande kommando:

$ docker ps
$ docker logs -f mariadb0

När du ser följande rad indikerar det att bootstrap-processen är klar och Galera är aktiv:

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

Skapa katalogen för att ladda vår anpassade konfigurationsfil i de återstående värddatorerna:

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

Kopiera sedan my.cnf som vi har skapat för mariadb0 och mariadb1 till mariadb2 respektive 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

Skapa sedan ytterligare 2 databasbehållare (mariadb2 och mariadb3) på värd2 respektive värd3:

$ 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

** Ersätt ${NAME} med mariadb2 respektive mariadb3.

Det finns dock en hake. Entrypoint-skriptet kontrollerar mysqld-tjänsten i bakgrunden efter databasinitiering genom att använda MySQL root-användare utan lösenord. Eftersom Galera automatiskt utför synkronisering genom SST eller IST vid uppstart kommer MySQL root-användarlösenordet att ändras, vilket speglar den bootstrappade noden. Således skulle du se följande fel under den första uppstarten:

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.

Tricket är att starta om de misslyckade behållarna en gång till, för den här gången skulle MySQL-datakatalogen ha skapats (i det första försöket) och den skulle hoppa över databasinitieringsdelen:

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

När du har startat, verifiera genom att titta på följande rad:

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

Vid det här laget finns det 3 behållare igång, mariadb0, mariadb2 och mariadb3. Observera att mariadb0 startas med bootstrap-kommandot (gcomm://), vilket betyder att om behållaren automatiskt startas om av Docker i framtiden, kan den potentiellt bli osammanhängande med den primära komponenten. Därför måste vi ta bort den här behållaren och ersätta den med mariadb1, använda samma Galera-anslutningssträng med resten och använda samma datadir och configdir med mariadb0.

Först, stoppa mariadb0 genom att skicka SIGTERM (för att säkerställa att noden kommer att stängas av på ett elegant sätt):

$ docker kill -s 15 mariadb0

Starta sedan mariadb1 på host1 med liknande kommandon som mariadb2 eller 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

Den här gången behöver du inte göra omstarttricket eftersom MySQL datadir redan finns (skapat av mariadb0). När behållaren har startat, verifiera att klusterstorleken är 3, statusen måste vara i Primär och den lokala staten är synkroniserad:

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

Vid det här laget ser vår arkitektur ut ungefär så här:

Även om körkommandot är ganska långt, beskriver det väl behållarens egenskaper. Det är förmodligen en bra idé att linda in kommandot i ett skript för att förenkla exekveringsstegen, eller använda en skrivfil istället.

Databasrouting med ProxySQL

Nu har vi tre databasbehållare igång. Det enda sättet att komma åt klustret nu är att komma åt den individuella Docker-värdens publicerade port av MySQL, som är 3306 (karta till 3306 till behållaren). Så vad händer om en av databasbehållarna misslyckas? Du måste manuellt failover klientens anslutning till nästa tillgängliga nod. Beroende på applikationsanslutningen kan du också ange en lista med noder och låta anslutningen göra failover och frågedirigering åt dig (Connector/J, PHP mysqlnd). Annars skulle det vara en bra idé att förena databasresurserna till en enda resurs, som kan kallas en tjänst.

Det är här ProxySQL kommer in i bilden. ProxySQL kan fungera som frågerouter, lastbalanserande databasanslutningar liknande vad "Service" i Swarm eller Kubernetes världen kan göra. Vi har byggt en ProxySQL Docker-bild för detta ändamål och kommer att underhålla bilden för varje ny version med vårt bästa.

Innan vi kör ProxySQL-behållaren måste vi förbereda konfigurationsfilen. Följande är vad vi har konfigurerat för proxysql1. Vi skapar en anpassad konfigurationsfil under /containers/proxysql1/proxysql.cnf på värd1:

$ 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"
        }
)

Ovanstående konfiguration kommer:

• konfigurera två värdgrupper, en- och flerskrivargruppen, enligt definitionen i avsnittet "mysql_servers",
• skicka läsningar till alla Galera-noder (värdgrupp 20) medan skrivoperationer går till en enda Galera-server (värdgrupp 10),
• schemalägg proxysql_galera_checker.sh,
• använd monitor_username och monitor_password som övervakningsuppgifter som skapades när vi först startade klustret (mariadb0).

Kopiera konfigurationsfilen till host2, för ProxySQL-redundans:

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

Kör sedan ProxySQL-behållarna på värd1 respektive värd2:

$ 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

** Ersätt ${NAME} med proxysql1 respektive proxysql2.

Vi angav --restart=alltid att göra den alltid tillgänglig oavsett utgångsstatus, samt automatisk start när Docker-demonen startar. Detta kommer att se till att ProxySQL-behållarna fungerar som en demon.

Verifiera MySQL-servrarnas status som övervakas av båda ProxySQL-instanserna (OFFLINE_SOFT förväntas för värdgruppen med en skrivare):

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

Vid det här laget ser vår arkitektur ut ungefär så här:

Alla anslutningar som kommer från 6033 (antingen från host1, host2 eller containerns nätverk) kommer att lastbalanseras till backend-databascontainrarna med ProxySQL. Om du vill komma åt en enskild databasserver, använd port 3306 för den fysiska värden istället. Det finns ingen virtuell IP-adress som en enda slutpunkt konfigurerad för ProxySQL-tjänsten, men vi skulle kunna ha det genom att använda Keepalved, vilket förklaras i nästa avsnitt.

Virtuell IP-adress med Keepalived

Eftersom vi konfigurerade ProxySQL-behållare för att köras på värd1 och värd2, kommer vi att använda Keepalved-behållare för att knyta samman dessa värdar och tillhandahålla virtuell IP-adress via värdnätverket. Detta gör att en enda slutpunkt för applikationer eller klienter kan ansluta till lastbalanseringsskiktet som stöds av ProxySQL.

Skapa som vanligt en anpassad konfigurationsfil för vår Keepalved-tjänst. Här är innehållet i /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
}

Kopiera konfigurationsfilen till host2 för den andra instansen:

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

Ändra prioriteten från 101 till 100 i den kopierade konfigurationsfilen på värd2:

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

**Den högre prioriterade instansen kommer att hålla den virtuella IP-adressen (i detta fall är värd 1) tills VRRP-kommunikationen avbryts (om värd 1 går ner).

Kör sedan följande kommando på värd1 respektive värd2:

$ 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

** Ersätt ${NAME} med keepalived1 och keepalived2.

Kommandot kör säger åt Docker att:

• --namn , skapa en behållare med
• --cap-add=NET_ADMIN , lägg till Linux-funktioner för nätverksadministration
• --net=värd , anslut behållaren till värdnätverket. Detta kommer att tillhandahålla virtuell IP-adress på värdgränssnittet, ens33
• --restart=alltid , håll alltid behållaren igång,
• --volume=/containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , mappa den anpassade konfigurationsfilen för behållarens användning.

Efter att båda behållarna har startat, verifiera att den virtuella IP-adressen finns genom att titta på det fysiska nätverksgränssnittet för MASTER-noden:

$ 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

Klienterna och applikationerna kan nu använda den virtuella IP-adressen 192.168.55.160 för att komma åt databastjänsten. Denna virtuella IP-adress finns på värd1 för närvarande. Om värd1 går ner kommer keepalived2 att ta över IP-adressen och ta upp den på värd2. Observera att konfigurationen för denna keepalved inte övervakar ProxySQL-behållarna. Den övervakar bara VRRP-reklamen från Keepalive-kamrater.

Vid det här laget ser vår arkitektur ut ungefär så här:

Sammanfattning

Så nu har vi ett MariaDB Galera-kluster med en högt tillgänglig ProxySQL-tjänst, som alla körs på Docker-containrar.

I del två kommer vi att undersöka hur man hanterar denna inställning. Vi kommer att titta på hur man utför operationer som graciös avstängning, bootstrapping, detektering av den mest avancerade noden, failover, återställning, skala upp/ned, uppgraderingar, säkerhetskopiering och så vidare. Vi kommer också att diskutera för- och nackdelar med att ha den här inställningen för vår klustrade databastjänst.

Lycka till med containersändningen!