Zaawansowane przełączanie awaryjne za pomocą haków skryptu Post/pre

$ systemctl restart cmon

W tym blogu skupiamy się głównie na tym, jak używać przechwytów skryptu pre/post, co jest zasadniczo wielką zaletą w przypadku przełączania awaryjnego zaawansowanej replikacji.

Obsługa skryptów przed/po pracy awaryjnej replikacji klastra

Jak wspomniano wcześniej, warianty MySQL, które wykorzystują replikację asynchroniczną (w tym półsynchroniczną) i replikację strumieniową dla PostgreSQL/TimescaleDB, obsługują ten mechanizm. ClusterControl posiada następujące opcje konfiguracyjne, których można użyć do przechwycenia przed i po skrypcie. Zasadniczo te opcje konfiguracji można ustawić za pomocą ich plików konfiguracyjnych lub można je ustawić za pomocą internetowego interfejsu użytkownika (zajmiemy się tym później).

Nasza dokumentacja stwierdza, że ​​są to następujące opcje konfiguracyjne, które mogą zmienić mechanizm przełączania awaryjnego za pomocą zaczepów skryptu pre/post:

Technicznie rzecz biorąc, po ustawieniu następujących opcji konfiguracyjnych w pliku konfiguracyjnym /etc/cmon.d/cmon_.cnf, wymagane jest ponowne uruchomienie cmona, czyli wykonanie następującego polecenia:

$ systemctl restart cmon

Alternatywnie możesz również ustawić opcje konfiguracji, przechodząc do → Ustawienia → Konfiguracja środowiska wykonawczego. Zobacz zrzut ekranu poniżej:

To podejście nadal wymagałoby ponownego uruchomienia usługi cmon, zanim będzie mogło odzwierciedlać zmiany wprowadzone dla tych opcji konfiguracji dla przechwytów pre/post script.

Przykład haków pre/post

Idealnie, podpięcia skryptu pre/post są dedykowane, gdy potrzebne jest zaawansowane przełączanie awaryjne, w przypadku którego ClusterControl nie jest w stanie poradzić sobie ze złożonością konfiguracji bazy danych. Na przykład, jeśli korzystasz z różnych centrów danych z zaostrzonymi zabezpieczeniami i chcesz określić, czy alert o nieosiągalnej sieci nie jest fałszywym alarmem pozytywnym. Musi sprawdzić, czy główny i podrzędny mogą połączyć się ze sobą i na odwrót, a także może połączyć się z węzłami bazy danych przechodzącymi do hosta ClusterControl.

Zróbmy to w naszym przykładzie i zademonstrujmy, jak możesz z tego skorzystać.

Szczegóły serwera i skrypty

W tym przykładzie używam klastra replikacji MariaDB z tylko podstawowym i repliką. Zarządzane przez ClusterControl w celu zarządzania przełączaniem awaryjnym.

ClusterControl =192.168.40.110

podstawowy (debnode5) =192.168.30.50

replika (debnode9) =192.168.30.90

W głównym węźle utwórz skrypt zgodnie z poniższym opisem,

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

Upewnij się, że plik /opt/pre_failover.sh jest wykonywalny, tj.

$ chmod +x /opt/pre_failover.sh

Następnie użyj tego skryptu, aby zaangażować się za pośrednictwem crona. W tym przykładzie utworzyłem plik /etc/cron.d/ccfailover i mam następującą zawartość:

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

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

W replice wykonaj następujące czynności, które wykonaliśmy dla podstawowej, z wyjątkiem zmiany nazwy hosta. Zobacz, co mam poniżej w mojej replice:

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

i upewnij się, że skrypt wywoływany w naszym cronie jest wykonywalny,

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

Skrypty przed i po ClusterControl

W tej demonstracji mój identyfikator klastra to 3. Jak wspomniano wcześniej w naszej dokumentacji, wymaga to, aby te skrypty znajdowały się na hoście kontrolera CC. Tak więc w moim /etc/cmon.d/cmon_3.cnf mam:

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

Następujący skrypt przełączania awaryjnego „pre” określa, czy oba węzły były w stanie połączyć się z hostem kontrolera CC. Zobacz:

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

Demonstracja przełączania awaryjnego

Teraz spróbujmy zasymulować awarię sieci w węźle podstawowym i zobaczmy, jak zareaguje. W moim węźle głównym wyłączam interfejs sieciowy używany do komunikacji z repliką i kontrolerem CC.

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

Podczas pierwszej próby przełączania awaryjnego CC był w stanie uruchomić mój skrypt pre, który znajduje się w /etc/cmon.d/failover/replication_failover_pre_clus3.sh. Zobacz poniżej, jak to działa:

Oczywiście kończy się niepowodzeniem, ponieważ zarejestrowany znacznik czasu nie jest jeszcze dłuższy niż minuta lub zaledwie kilka sekund temu podstawowy nadal był w stanie połączyć się z kontrolerem CC. Oczywiście nie jest to idealne podejście, gdy masz do czynienia z prawdziwym scenariuszem. Jednak ClusterControl był w stanie wywołać i wykonać skrypt idealnie zgodnie z oczekiwaniami. A co powiesz na to, że rzeczywiście trwa dłużej niż minutę (tj.> 60 sekund)?

W naszej drugiej próbie przełączania awaryjnego, ponieważ znacznik czasu przekracza 60 sekund, uznaje się, że jest to prawdziwy pozytyw, a to oznacza, że ​​musimy przełączyć się w tryb awaryjny zgodnie z zamierzeniami. CC był w stanie doskonale go wykonać, a nawet wykonać postscript zgodnie z przeznaczeniem. Można to zobaczyć w dzienniku pracy. Zobacz zrzut ekranu poniżej:

Weryfikowanie, czy mój skrypt posta został uruchomiony, udało się utworzyć dziennik plik w katalogu CC /tmp zgodnie z oczekiwaniami,

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

opublikuj skrypt przełączania awaryjnego w klastrze 3 z argumentami:192.168.30.50 192.168.30.90 192.168.30.50 192.168.30.90 192.168.30.90

Teraz moja topologia została zmieniona i przełączanie awaryjne powiodło się!

Wnioski

W przypadku każdej skomplikowanej konfiguracji bazy danych, gdy wymagane jest zaawansowane przełączanie awaryjne, skrypty pre/post mogą być bardzo pomocne, aby wszystko było osiągalne. Ponieważ ClusterControl obsługuje te funkcje, pokazaliśmy, jak potężny i pomocny jest. Nawet przy jego ograniczeniach zawsze istnieją sposoby, aby rzeczy były osiągalne i użyteczne, zwłaszcza w środowiskach produkcyjnych.