Avanceret failover ved brug af Post/pre Script Hooks

$ systemctl genstart cmon

For denne blog fokuserer vi hovedsageligt på, hvordan man bruger pre/post script-hooks, hvilket i bund og grund er en stor fordel for avanceret replikeringsfailover.

Cluster failover-replikering før/efter script-understøttelse

Som tidligere nævnt understøtter MySQL-varianter, der bruger asynkron (inklusive semi-synkron) replikering og streaming replikering til PostgreSQL/TimescaleDB denne mekanisme. ClusterControl har følgende konfigurationsmuligheder, som kan bruges til pre og post script hooks. Dybest set kan disse konfigurationsmuligheder indstilles via deres konfigurationsfiler eller kan indstilles via web-brugergrænsefladen (vi vil behandle dette senere).

Vores dokumentation angiver, at disse er følgende konfigurationsmuligheder, der kan ændre failover-mekanismen ved at bruge pre/post script-hooks:

Teknisk, når du har indstillet følgende konfigurationsindstillinger i din /etc/cmon.d/cmon_.cnf-konfigurationsfil, kræver det at genstarte cmon, dvs. køre følgende kommando:

$ systemctl restart cmon

Alternativt kan du også indstille konfigurationsmulighederne ved at gå til → Indstillinger → Runtime Configuration. Se skærmbillede nedenfor:

Denne tilgang vil stadig kræve en genstart til cmon-tjenesten, før den kan afspejle ændringer foretaget for disse konfigurationsmuligheder for pre/post script hooks.

Eksempel på pre/post script hooks

Ideelt set er pre/post script-hooks dedikeret, når du har brug for en avanceret failover, som ClusterControl ikke kunne håndtere kompleksiteten af ​​din databaseopsætning til. For eksempel, hvis du kører forskellige datacentre med skærpet sikkerhed, og du vil afgøre, om alarmen om, at netværket ikke kan nås, ikke er en falsk positiv alarm. Den skal kontrollere, om den primære og slaven kan nå hinanden og omvendt, og den kan også nå fra databasenoderne, der går til ClusterControl-værten.

Lad os gøre det i vores eksempel og demonstrere, hvordan du kan drage fordel af det.

Serverdetaljer og scripts

I dette eksempel bruger jeg en MariaDB-replikeringsklynge med kun en primær og en replika. Administreret af ClusterControl til at administrere failover.

ClusterControl =192.168.40.110

primær (debnode5) =192.168.30.50

replika (debnode9) =192.168.30.90

I den primære node skal du oprette scriptet som angivet nedenfor,

[email protected]:~# cat /opt/pre_failover.sh
#!/bin/bash

date -u +%s | ssh -i /home/vagrant/.ssh/id_rsa [email protected] -T "cat >> /tmp/debnode5.tmp"

Sørg for, at /opt/pre_failover.sh er eksekverbar, dvs.

$ chmod +x /opt/pre_failover.sh

Brug derefter dette script til at blive involveret via cron. I dette eksempel oprettede jeg en fil /etc/cron.d/ccfailover og har følgende indhold:

[email protected]:~# cat /etc/cron.d/ccfailover
#!/bin/bash

* * * * * vagrant /opt/pre_failover.sh

I din replika skal du blot bruge følgende trin, vi gjorde for den primære, bortset fra at ændre værtsnavnet. Se følgende af, hvad jeg har nedenfor i min replika:

[email protected]:~# tail -n+1 /etc/cron.d/ccfailover /opt/pre_failover.sh
==> /etc/cron.d/ccfailover <==
#!/bin/bash
* * * * * vagrant /opt/pre_failover.sh

==> /opt/pre_failover.sh <==
#!/bin/bash

date -u +%s | ssh -i /home/vagrant/.ssh/id_rsa [email protected] -T "cat > /tmp/debnode9.tmp"

og sørg for, at scriptet, der påberåbes i vores cron, er eksekverbart,

[email protected]:~# ls -alth /opt/pre_failover.sh
-rwxr-xr-x 1 root root 104 Jun 14 05:09 /opt/pre_failover.sh

ClusterControl før/efter scripts

I denne demonstration er mit cluster_id 3. Som nævnt tidligere i vores dokumentation, kræver det, at disse scripts skal ligge i vores CC-controller-vært. Så i min /etc/cmon.d/cmon_3.cnf har jeg følgende:

[[email protected] cmon.d]# tail -n3 /etc/cmon.d/cmon_3.cnf
replication_pre_failover_script = /etc/cmon.d/failover/replication_failover_pre_clus3.sh
replication_post_failover_script = /etc/cmon.d/failover/replication_failover_post_clus3.sh
replication_post_unsuccessful_failover_script = /etc/cmon.d/failover/replication_unsuccessful_failover_post_clus3.sh

Men det følgende "pre" failover-script bestemmer, om begge noder var i stand til at nå CC-controllerværten. Se følgende:

[[email protected] cmon.d]# tail -n+1 /etc/cmon.d/failover/replication_failover_pre_clus3.sh
#!/bin/bash

arg1=$1
debnode5_tstamp=$(tail /tmp/debnode5.tmp)
debnode9_tstamp=$(tail /tmp/debnode9.tmp)
cc_tstamp=$(date -u +%s)
diff_debnode5=$(expr $cc_tstamp - $debnode5_tstamp)
diff_debnode9=$(expr $cc_tstamp - $debnode5_tstamp)

if [[ "$diff_debnode5" -le  60 && "$diff_debnode9" -le 60 ]]; then
   echo "failover cannot proceed. It's just a false alarm. Checkout the firewall in your CC host";
   exit 1;
elif [[ "$diff_debnode5" -gt 60 || "$diff_debnode9" -gt 60 ]]; then
        echo "Either both nodes ($arg1) or one of them  were not able to connect the CC host. One can be unreachable. Failover proceed!";
    exit 0;
else
   echo "false alarm. Failover discarded!"
   exit 1;
fi
Whereas my post scripts just simply echoes and redirects the output to a file, just for the test.
[[email protected] failover]# tail -n+1 replication_*_post*3.sh
==> replication_failover_post_clus3.sh <==
#!/bin/bash
echo "post failover script on cluster 3 with args: [email protected]" > /tmp/post_failover_script_cid3.txt
==> replication_unsuccessful_failover_post_clus3.sh <==
#!/bin/bash
echo "post unsuccessful  failover script on cluster 3 with args: [email protected]" > /tmp/post_unsuccessful_failover_script_cid3.txt

Demo af failover

Lad os nu prøve at simulere netværksudfald på den primære node og se, hvordan den vil reagere. I min primære node fjerner jeg netværksgrænsefladen, der bruges til at kommunikere med replikaen og CC-controlleren.

[email protected]:~# ip link set enp0s8 down

Under det første forsøg på failover var CC i stand til at køre mit præscript, som er placeret på /etc/cmon.d/failover/replication_failover_pre_clus3.sh. Se nedenfor, hvordan det virker:

Det mislykkes naturligvis, fordi tidsstemplet, der er blevet logget, endnu ikke er mere end et minut, eller det var blot et par sekunder siden, at den primære stadig var i stand til at oprette forbindelse til CC-controlleren. Det er naturligvis ikke den perfekte tilgang, når du har at gøre med et rigtigt scenarie. ClusterControl var dog i stand til at påkalde og udføre scriptet perfekt som forventet. Hvad med, hvis den faktisk når mere end et minut (dvs.> 60 sekunder)?

I vores andet forsøg på failover, da tidsstemplet når mere end 60 sekunder, anses det for at være et sandt positivt resultat, og det betyder, at vi skal failover som tilsigtet. CC har været i stand til at udføre det perfekt og endda eksekvere postscriptet efter hensigten. Dette kan ses i jobloggen. Se skærmbilledet nedenfor:

Ved at bekræfte, om mit indlægsscript blev kørt, var det i stand til at oprette loggen fil i CC /tmp-mappen som forventet,

[[email protected] tmp]# cat /tmp/post_failover_script_cid3.txt

post failover-script på klynge 3 med args:192.168.30.50 192.168.30.90  192.168.30.50 192.168.30.90 192.168.30.90

Nu er min topologi blevet ændret, og failoveren lykkedes!

Konklusion

For enhver kompliceret databaseopsætning, du måtte have, når en avanceret failover er påkrævet, kan pre/post-scripts være meget nyttige for at gøre tingene opnåelige. Da ClusterControl understøtter disse funktioner, har vi demonstreret, hvor kraftfuldt og nyttigt det er. Selv med dets begrænsninger er der altid måder at gøre tingene opnåelige og nyttige, især i produktionsmiljøer.