Avancerad failover med Post/pre Script Hooks

$ systemctl restart cmon

För den här bloggen fokuserar vi huvudsakligen på hur man använder pre/post-skriptkroken, vilket i grunden är en stor fördel för avancerad replikeringsfailover.

Stöd för kluster-failover-replikering före/efter skript

Som nämnts tidigare stöder MySQL-varianter som använder asynkron (inklusive semisynkron) replikering och strömmande replikering för PostgreSQL/TimescaleDB denna mekanism. ClusterControl har följande konfigurationsalternativ som kan användas för pre och post script hooks. I grund och botten kan dessa konfigurationsalternativ ställas in via deras konfigurationsfiler eller kan ställas in via webbgränssnittet (vi kommer att ta itu med detta senare).

Vår dokumentation anger att dessa är följande konfigurationsalternativ som kan ändra failover-mekanismen genom att använda pre/post script-hooks:

Tekniskt sett, när du väl har ställt in följande konfigurationsalternativ i din /etc/cmon.d/cmon_.cnf-konfigurationsfil, måste du starta om cmon, dvs köra följande kommando:

$ systemctl restart cmon

Alternativt kan du också ställa in konfigurationsalternativen genom att gå till → Inställningar → Runtime Configuration. Se skärmdump nedan:

Det här tillvägagångssättet skulle fortfarande kräva en omstart till cmon-tjänsten innan det kan återspegla ändringar gjorda för dessa konfigurationsalternativ för pre/post script hooks.

Exempel på pre/post script hooks

I idealfallet är pre/post-skriptkroken dedikerade när du behöver en avancerad failover för vilken ClusterControl inte kunde hantera komplexiteten i din databasinstallation. Till exempel, om du driver olika datacenter med skärpt säkerhet och du vill avgöra om varningen om att nätverket inte kan nås inte är ett falskt positivt larm. Den måste kontrollera om primär och slav kan nå varandra och vice versa och den kan också nå från databasnoderna som går till ClusterControl-värden.

Låt oss göra det i vårt exempel och visa hur du kan dra nytta av det.

Serverinformation och skripten

I det här exemplet använder jag ett MariaDB-replikeringskluster med bara en primär och en replik. Hanteras av ClusterControl för att hantera failover.

ClusterControl =192.168.40.110

primär (debnode5) =192.168.30.50

replika (debnode9) =192.168.30.90

I den primära noden, skapa skriptet enligt nedan,

[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"

Se till att /opt/pre_failover.sh är körbar, dvs.

$ chmod +x /opt/pre_failover.sh

Använd sedan detta skript för att vara involverad via cron. I det här exemplet skapade jag filen /etc/cron.d/ccfailover och har följande innehåll:

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

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

I din replik, använd bara följande steg vi gjorde för den primära förutom att ändra värdnamnet. Se följande av vad jag har nedan i min replik:

[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"

och se till att skriptet som anropas i vår cron är körbart,

[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öre/efter skript

I den här demonstrationen är mitt cluster_id 3. Som nämnts tidigare i vår dokumentation kräver det att dessa skript måste finnas i vår CC-styrenhetsvärd. Så i min /etc/cmon.d/cmon_3.cnf har jag följande:

[[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

Medan följande "pre" failover-skript avgör om båda noderna kunde nå CC-styrenhetens värd. Se följande:

[[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 av failover

Nu ska vi försöka simulera nätverksavbrott på den primära noden och se hur den kommer att reagera. I min primära nod tar jag ner nätverksgränssnittet som används för att kommunicera med repliken och CC-styrenheten.

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

Under det första försöket med failover kunde CC köra mitt prescript som finns på /etc/cmon.d/failover/replication_failover_pre_clus3.sh. Se nedan hur det fungerar:

Självklart misslyckas det eftersom tidsstämpeln som har loggats ännu inte är mer än en minut eller så var det bara några sekunder sedan som den primära fortfarande kunde ansluta till CC-styrenheten. Uppenbarligen är det inte det perfekta tillvägagångssättet när du har att göra med ett verkligt scenario. ClusterControl kunde dock anropa och köra skriptet perfekt som förväntat. Vad sägs om om det verkligen når mer än en minut (dvs> 60 sekunder)?

I vårt andra försök med failover, eftersom tidsstämpeln når mer än 60 sekunder, anses det vara ett sant positivt, och det betyder att vi måste göra failover som avsett. CC har kunnat exekvera det perfekt och till och med exekvera postskriptet som avsett. Detta kan ses i jobbloggen. Se skärmdumpen nedan:

För att verifiera om mitt inläggsskript kördes kunde det skapa loggen fil i katalogen CC /tmp som förväntat,

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

lägg upp ett failover-skript på kluster 3 med args:192.168.30.50 192.168.30.90  192.168.30.50 192.168.30.90 192.168.30.90

Nu har min topologi ändrats och failover lyckades!

Slutsats

För alla komplicerade databasinställningar du kan ha, när en avancerad failover krävs, kan pre/post-skript vara till stor hjälp för att göra saker genomförbara. Eftersom ClusterControl stöder dessa funktioner har vi visat hur kraftfullt och användbart det är. Även med dess begränsningar finns det alltid sätt att göra saker genomförbara och användbara, särskilt i produktionsmiljöer.