Containerorkestreringsværktøjer forenkler driften af et distribueret system ved at implementere og ominstallere containere og håndtere eventuelle fejl, der opstår. Man skal muligvis flytte rundt på applikationer, for eksempel for at håndtere opdateringer, skalering eller underliggende værtsfejl. Selvom dette lyder godt, fungerer det ikke altid godt med en stærkt konsistent databaseklynge som Galera. Du kan ikke bare flytte rundt på databasenoder, de er ikke statsløse applikationer. Den rækkefølge, du udfører operationer på en klynge i, har også stor betydning. For eksempel skal genstart af en Galera-klynge starte fra den mest avancerede node, ellers vil du miste data. Derfor viser vi dig, hvordan du kører Galera Cluster på Docker uden et containerorkestreringsværktøj, så du har total kontrol.
I dette blogindlæg skal vi se på, hvordan man kører en MariaDB Galera Cluster på Docker-containere ved hjælp af standard Docker-billedet på flere Docker-værter uden hjælp fra orkestreringsværktøjer som Swarm eller Kubernetes. Denne tilgang ligner at køre en Galera Cluster på standardværter, men processtyringen konfigureres gennem Docker.
Før vi springer yderligere ind i detaljer, antager vi, at du har installeret Docker, deaktiveret SElinux/AppArmor og ryddet op i reglerne inde i iptables, firewalld eller ufw (alt efter hvad du bruger). Følgende er tre dedikerede Docker-værter til vores databaseklynge:
- host1.local - 192.168.55.161
- host2.local - 192.168.55.162
- host3.local - 192.168.55.163
Multi-host netværk
Først og fremmest er standard Docker-netværket bundet til den lokale vært. Docker Swarm introducerer et andet netværkslag kaldet overlay-netværk, som udvider containerinternetarbejdet til flere Docker-værter i en klynge kaldet Swarm. Længe før denne integration kom på plads, var der udviklet mange netværksplugins til at understøtte dette - Flannel, Calico, Weave er nogle af dem.
Her skal vi bruge Weave som Docker-netværksplugin til netværk med flere værter. Dette skyldes hovedsageligt dets enkelhed at få det installeret og kørende, og understøttelse af DNS-resolver (containere, der kører under dette netværk, kan løse hinandens værtsnavn). Der er to måder at få Weave til at køre på - systemd eller gennem Docker. Vi skal installere det som en systemd enhed, så det er uafhængigt af Docker-dæmonen (ellers skulle vi starte Docker først, før Weave bliver aktiveret).
-
Download og installer Weave:
$ curl -L git.io/weave -o /usr/local/bin/weave $ chmod a+x /usr/local/bin/weave -
Opret en systemd enhedsfil til 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 -
Definer IP-adresser eller værtsnavn på peers inde i /etc/sysconfig/weave:
$ echo 'PEERS="192.168.55.161 192.168.55.162 192.168.55.163"' > /etc/sysconfig/weave -
Start og aktiver Weave on boot:
$ systemctl start weave $ systemctl enable weave
Gentag ovenstående 4 trin på alle Docker-værter. Bekræft med følgende kommando, når du er færdig:
$ weave statusAntallet af jævnaldrende er det, vi ser efter. Det skal være 3:
...
Peers: 3 (with 6 established connections)
...Kørsel af en Galera-klynge
Nu netværket er klar, er det tid til at fyre vores databasecontainere og danne en klynge. De grundlæggende regler er:
- Containeren skal oprettes under --net=weave for at have multi-host-forbindelse.
- Containerporte, der skal publiceres, er 3306, 4444, 4567, 4568.
- Docker-billedet skal understøtte Galera. Hvis du gerne vil bruge Oracle MySQL, så få Codership-versionen. Hvis du gerne vil have Percona's, så brug dette billede i stedet for. I dette blogindlæg bruger vi MariaDB's.
Årsagerne til, at vi valgte MariaDB som Galera-klyngeleverandøren er:
- Galera er indlejret i MariaDB fra MariaDB 10.1.
- MariaDB-billedet vedligeholdes af Docker- og MariaDB-teamene.
- Et af de mest populære Docker-billeder derude.
Bootstrapping af en Galera Cluster skal udføres i rækkefølge. For det første skal den mest opdaterede node startes med "wsrep_cluster_address=gcomm://". Start derefter de resterende noder med en fuld adresse bestående af alle noder i klyngen, f.eks. "wsrep_cluster_address=gcomm://node1,node2,node3". For at udføre disse trin ved hjælp af container, er vi nødt til at udføre nogle ekstra trin for at sikre, at alle containere kører homogent. Så planen er:
- Vi skal starte med 4 beholdere i denne rækkefølge - mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
- Container mariadb0 vil bruge den samme datadir og configdir som mariadb1.
- Brug mariadb0 på host1 til den første bootstrap, start derefter mariadb2 på host2, mariadb3 på host3.
- Fjern mariadb0 på vært1 for at give plads for mariadb1.
- Start endelig mariadb1 på vært1.
I slutningen af dagen vil du have en Galera-klynge med tre knudepunkter (mariadb1, mariadb2, mariadb3). Den første container (mariadb0) er en forbigående container kun til bootstrapping-formål, der bruger klyngeadressen "gcomm://". Den deler den samme datadir og configdir med mariadb1 og vil blive fjernet, når klyngen er dannet (mariadb2 og mariadb3 er oppe), og noder er synkroniseret.
Som standard er Galera slået fra i MariaDB og skal aktiveres med et flag kaldet wsrep_on (indstillet til TIL) og wsrep_provider (indstillet til Galera-biblioteksstien) plus en række Galera-relaterede parametre. Derfor er vi nødt til at definere en brugerdefineret konfigurationsfil til containeren for at konfigurere Galera korrekt.
Lad os starte med den første beholder, mariadb0. Opret en fil under /containers/mariadb1/conf.d/my.cnf og tilføj følgende linjer:
$ 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-v2Da billedet ikke kommer med MariaDB Backup (som er den foretrukne SST-metode til MariaDB 10.1 og MariaDB 10.2), vil vi foreløbig holde os til xtrabackup-v2.
For at udføre den første bootstrap for klyngen skal du køre bootstrap-beholderen (mariadb0) på host1 med mariadb1's "datadir" og "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.localParametrene brugt i kommandoen ovenfor er:
- --navn , opretter containeren med navnet "mariadb0",
- --værtsnavn , tildeler containeren et værtsnavn "mariadb0.weave.local",
- --net , placerer containeren i vævningsnetværket til understøttelse af multi-host-netværk,
- --udgiv , eksponerer porte 3306, 4444, 4567, 4568 på containeren for værten,
- $(væv dns-args) , konfigurerer DNS-resolver for denne container. Denne kommando kan oversættes til Docker run som "--dns=172.17.0.1 --dns-search=weave.local.",
- --env MYSQL_ROOT_PASSWORD , MySQL root-adgangskoden,
- --env MYSQL_USER , opretter en "proxysql"-bruger, der skal bruges senere med ProxySQL til databaserouting,
- --env MYSQL_PASSWORD , "proxysql"-brugeradgangskoden,
- --volumen /containers/mariadb1/datadir:/var/lib/mysql , opretter /containers/mariadb1/datadir, hvis den ikke eksisterer, og tilknytter den med /var/lib/mysql (MySQL datadir) i containeren (for bootstrap node, dette kunne springes over),
- --bind /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , monterer filerne under mappen /containers/mariadb1/conf.d på Docker-værten i containeren på /etc/mysql/mariadb.conf.d.
- mariadb:10.2.15 , bruger MariaDB 10.2.15-billede herfra,
- --wsrep_cluster_address , Galera-forbindelsesstreng for klyngen. "gcomm://" betyder bootstrap. For resten af containerne vil vi i stedet bruge en fuld adresse.
- --wsrep_sst_auth , godkendelsesstreng for SST-bruger. Brug den samme bruger som root,
- --wsrep_node_address , noden værtsnavn, i dette tilfælde vil vi bruge FQDN fra Weave.
Bootstrap-beholderen indeholder flere vigtige ting:
- Navnet, værtsnavnet og wsrep_node_address er mariadb0, men det bruger volumen af mariadb1.
- Klyngeadressen er "gcomm://"
- Der er to yderligere --env-parametre - MYSQL_USER og MYSQL_PASSWORD. Disse parametre vil oprette yderligere brugere til vores proxysql-overvågningsformål.
Bekræft med følgende kommando:
$ docker ps
$ docker logs -f mariadb0Når du ser følgende linje, indikerer det, at bootstrap-processen er afsluttet, og Galera er aktiv:
2018-05-30 23:19:30 139816524539648 [Note] WSREP: Synchronized with group, ready for connectionsOpret mappen for at indlæse vores brugerdefinerede konfigurationsfil i de resterende værter:
$ mkdir -p /containers/mariadb2/conf.d # on host2
$ mkdir -p /containers/mariadb3/conf.d # on host3Kopier derefter my.cnf, som vi har oprettet for mariadb0 og mariadb1 til henholdsvis mariadb2 og 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 host1Opret derefter yderligere 2 databasebeholdere (mariadb2 og mariadb3) på henholdsvis host2 og 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** Erstat ${NAME} med henholdsvis mariadb2 eller mariadb3.
Der er dog en fangst. Entrypoint-scriptet kontrollerer mysqld-tjenesten i baggrunden efter databaseinitialisering ved at bruge MySQL root-bruger uden adgangskode. Da Galera automatisk udfører synkronisering gennem SST eller IST ved opstart, ændres MySQL root brugeradgangskoden, hvilket afspejler den bootstrappede node. Således vil du se følgende fejl under den første opstart:
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 er at genstarte de fejlbehæftede containere endnu en gang, for denne gang ville MySQL-datafilen være blevet oprettet (i det første kørselsforsøg), og det ville springe databaseinitialiseringsdelen over:
$ docker start mariadb2 # on host2
$ docker start mariadb3 # on host3Når du er startet, skal du bekræfte ved at se på følgende linje:
$ docker logs -f mariadb2
…
2018-05-30 23:28:39 139808069601024 [Note] WSREP: Synchronized with group, ready for connectionsPå dette tidspunkt kører der 3 containere, mariadb0, mariadb2 og mariadb3. Bemærk, at mariadb0 startes ved hjælp af bootstrap-kommandoen (gcomm://), hvilket betyder, at hvis containeren automatisk genstartes af Docker i fremtiden, kan den potentielt blive usammenhængende med den primære komponent. Derfor skal vi fjerne denne beholder og erstatte den med mariadb1 ved at bruge den samme Galera-forbindelsesstreng med resten og bruge den samme datadir og configdir med mariadb0.
Stop først mariadb0 ved at sende SIGTERM (for at sikre, at knudepunktet lukkes elegant):
$ docker kill -s 15 mariadb0Start derefter mariadb1 på vært1 ved at bruge en lignende kommando 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.localDenne gang behøver du ikke genstarte tricket, fordi MySQL datadir allerede eksisterer (oprettet af mariadb0). Når containeren er startet, skal du kontrollere, at klyngestørrelsen er 3, status skal være i Primær, og den lokale tilstand er synkroniseret:
$ 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 |
+---------------------------+-------------------------------------------------------------------------------+På dette tidspunkt ser vores arkitektur nogenlunde sådan her ud:
Selvom run-kommandoen er ret lang, beskriver den godt containerens egenskaber. Det er sandsynligvis en god ide at pakke kommandoen ind i et script for at forenkle udførelsestrinene, eller bruge en skrivfil i stedet for.
Databaserouting med ProxySQL
Nu har vi tre databasecontainere kørende. Den eneste måde at få adgang til klyngen på nu er at få adgang til den individuelle Docker-værts offentliggjorte port af MySQL, som er 3306 (kort til 3306 til containeren). Så hvad sker der, hvis en af databasebeholderne fejler? Du skal manuelt failover klientens forbindelse til den næste tilgængelige node. Afhængigt af applikationsforbindelsen kan du også angive en liste over noder og lade forbindelsen udføre failover og forespørgselsrouting for dig (Connector/J, PHP mysqlnd). Ellers ville det være en god idé at samle databaseressourcerne til en enkelt ressource, der kan kaldes en tjeneste.
Det er her, ProxySQL kommer ind i billedet. ProxySQL kan fungere som forespørgselsrouteren og belastningsbalancere databaseforbindelserne svarende til hvad "Service" i Swarm eller Kubernetes verden kan gøre. Vi har bygget et ProxySQL Docker-image til dette formål og vil vedligeholde billedet for hver ny version med vores bedste indsats.
Før vi kører ProxySQL-beholderen, skal vi forberede konfigurationsfilen. Det følgende er, hvad vi har konfigureret til proxysql1. Vi opretter en brugerdefineret konfigurationsfil under /containers/proxysql1/proxysql.cnf på vært1:
$ 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"
}
)Ovenstående konfiguration vil:
- konfigurer to værtsgrupper, single-writer og multi-writer-gruppen, som defineret under "mysql_servers" sektionen,
- send læsninger til alle Galera-noder (værtsgruppe 20), mens skrivehandlinger vil gå til en enkelt Galera-server (værtsgruppe 10),
- planlæg proxysql_galera_checker.sh,
- brug monitor_username og monitor_password som overvågningslegitimationsoplysningerne, der blev oprettet, da vi første gang bootstrappede klyngen (mariadb0).
Kopier konfigurationsfilen til host2, for ProxySQL-redundans:
$ mkdir -p /containers/proxysql2/ # on host2
$ scp /containers/proxysql1/proxysql.cnf /container/proxysql2/ # on host1Kør derefter ProxySQL-beholderne på henholdsvis vært1 og vært2:
$ 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** Erstat ${NAME} med henholdsvis proxysql1 eller proxysql2.
Vi specificerede --restart=always at gøre den altid tilgængelig uanset exit-status, samt automatisk opstart, når Docker-dæmonen starter. Dette vil sikre, at ProxySQL-beholderne fungerer som en dæmon.
Bekræft MySQL-serverens status, der overvåges af begge ProxySQL-instanser (OFFLINE_SOFT forventes for enkeltskriver-værtsgruppen):
$ 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 |
+--------------+----------------------+--------------+På dette tidspunkt ser vores arkitektur nogenlunde sådan her ud:
Alle forbindelser, der kommer fra 6033 (enten fra vært1, vært2 eller containerens netværk) vil være belastningsbalanceret til backend-databasecontainerne ved hjælp af ProxySQL. Hvis du gerne vil have adgang til en individuel databaseserver, skal du bruge port 3306 på den fysiske vært i stedet. Der er ingen virtuel IP-adresse som enkelt slutpunkt konfigureret til ProxySQL-tjenesten, men det kunne vi have ved at bruge Keepalved, som er forklaret i næste afsnit.
Virtuel IP-adresse med Keepalived
Da vi konfigurerede ProxySQL-containere til at køre på host1 og host2, vil vi bruge Keepalved-containere til at binde disse værter sammen og give virtuel IP-adresse via værtsnetværket. Dette gør det muligt for et enkelt slutpunkt for applikationer eller klienter at oprette forbindelse til belastningsbalanceringslaget understøttet af ProxySQL.
Som sædvanlig skal du oprette en brugerdefineret konfigurationsfil til vores Keepalive-tjeneste. Her er indholdet af /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
}Kopier konfigurationsfilen til host2 for den anden instans:
$ mkdir -p /containers/keepalived2/ # on host2
$ scp /containers/keepalived1/keepalived.conf /container/keepalived2/ # on host1Skift prioriteten fra 101 til 100 i den kopierede konfigurationsfil på vært2:
$ sed -i 's/101/100/g' /containers/keepalived2/keepalived.conf**Den højere prioritetsinstans vil beholde den virtuelle IP-adresse (i dette tilfælde er vært1), indtil VRRP-kommunikationen afbrydes (i tilfælde af at vært1 går ned).
Kør derefter følgende kommando på henholdsvis host1 og 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** Erstat ${NAME} med keepalived1 og keepalived2.
Kør-kommandoen fortæller Docker at:
- --navn , opret en beholder med
- --cap-add=NET_ADMIN , tilføj Linux-funktioner til netværksadministratoromfang
- --net=host , vedhæft beholderen til værtsnetværket. Dette vil give en virtuel IP-adresse på værtsgrænsefladen, ens33
- --genstart=altid , hold altid beholderen kørende,
- --volume=/containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , kortlæg den tilpassede konfigurationsfil til containerens brug.
Efter at begge containere er startet, skal du kontrollere, at den virtuelle IP-adresse eksisterer ved at se på MASTER-nodens fysiske netværksgrænseflade:
$ 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 ens33Klienterne og applikationerne kan nu bruge den virtuelle IP-adresse 192.168.55.160 til at få adgang til databasetjenesten. Denne virtuelle IP-adresse findes på vært1 i øjeblikket. Hvis vært1 går ned, vil keepalived2 overtage IP-adressen og bringe den op på vært2. Bemærk, at konfigurationen for denne keepalived ikke overvåger ProxySQL-beholderne. Den overvåger kun VRRP-reklamen fra Keepalved-kammeraterne.
På dette tidspunkt ser vores arkitektur nogenlunde sådan her ud:
Oversigt
Så nu har vi en MariaDB Galera-klynge med en meget tilgængelig ProxySQL-tjeneste, der alle kører på Docker-containere.
I del to skal vi se på, hvordan man administrerer denne opsætning. Vi vil se på, hvordan man udfører operationer som yndefuld nedlukning, bootstrapping, detektering af den mest avancerede node, failover, gendannelse, op-/nedskalering, opgraderinger, backup og så videre. Vi vil også diskutere fordele og ulemper ved at have denne opsætning til vores klyngedatabasetjeneste.
God fornøjelse med containerisering!