Knowledge base
Jak zbudować wysoko dostępny klaster bazodanowy MySQL, korzystając z DRBD, corosynca i pacemakera?
Posted by Pomoc Oktawave on 28.10.2014 20:48

W celu zapewnienia wysokiej dostępności bazy danych wykorzystamy klaster wysoko dostępny składający się z dwóch węzłów. Replikacja danych między węzłami będzie się odbywać na poziomie blokowym z wykorzystaniem oprogramowania DRBD. Dla zwiększenia niezawodności proponowanego rozwiązania możemy tworzyć węzły w różnych subregionach, aby pracowały w fizycznie oddzielonych pulach zasobów. Aby dowiedzieć się więcej o subregionach, kliknij TUTAJ.

 

1. Założenia

Wykorzystamy szablony z Ubuntu Server, do każdej z dwóch utworzonych instancji podłączymy po jednym OVS o identycznych rozmiarach, na którym przechowywać będziemy pliki bazy danych. Skorzystamy z bazy MySQL dostępnej w domyślnym repozytorium.

Obydwie instancje podłączone są do OPN, w którym za pomocą pakietów corosync i pacemaker odbywa się komunikacja między węzłami w ramach klastra. W omawianym przykładzie wykorzystamy podsieć 10.0.0.0/24 ze statycznie skonfigurowanymi adresami.

 

db01:	10.0.0.1
db02:	10.0.0.2
db:	10.0.0.10

 

10.0.0.10 to adres, po którym będziemy uzyskiwać dostęp do bazy danych.

 

2. Konfiguracja środowiska

Warunkiem koniecznym poprawnego działania oprogramowania klastra jest posiadanie poprawnych wpisów w /etc/hosts na wszystkich węzłach.

 

10.0.0.1	db01 
10.0.0.2	db02

Zmieniamy również hostname, np.

 

 hostname db01
 echo 'db01' > /etc/hostname

 

Na każdej z instancji bazodanowych aktualizujemy informacje o repozytoriach pakietów.

 

 apt-get update
 apt-get install drbd8-utils pacemaker fence-agents mysql-server

 

Aby zapewnić swobodną komunikację w ramach OPN, oznaczmy odpowiadający jej interfejs jako zaufany w /etc/firewall.conf.

 

TRUSTED_INTERFACES='lo eth1'

 

Zrestartujmy lokalnego firewalla, aby zatwierdzić nowe ustawienia.

 

service firewall restart


2.1 DRBD

W naszym rozwiązaniu będą występowały dwa węzły działające w trybie active-passive. Każdy z nich należy skonfigurować według poniższych zaleceń, o ile nie wyszczególniono inaczej. Plik konfiguracyjny DRBD znajduje się w /etc/drbd.conf, jednak domyślna zawartość tego pliku wskazuje na inne pliki, w których zapisana jest konfiguracja.

 

include "drbd.d/global_common.conf";
# Ustawienia globalne dla wszystkich udziałów
include "drbd.d/*.res";
# Ustawienia udziałów skonfigurowanych przez nas

 

W /etc/drbd.d/global_common.conf zadbajmy o zastosowanie replikacji synchronicznej w celu zapewnienia spójności danych między węzłami, poprzez umieszczenie odpowiedniego zapisu w klauzuli net – powinna mieć ona następującą postać.

 

net {
 protocol C;
 }

 

Następnie musimy skonfigurować zasób DRBD, poniżej zamieszczamy propozycję odpowiedniej konfiguracji.

 

# cat /etc/drbd.d/mysql.res 
resource mysql {
 device		/dev/drbd1; 
 disk		/dev/sdb; 
 meta-disk	internal; 
 syncer {
 rate 100M; 
 }
 net { 
 after-sb-0pri discard-zero-changes; 
 after-sb-1pri discard-secondary; 
 } 
 on db01 { 
 address	10.0.0.1:7789; 
 } 
 on db02 { 
 address	10.0.0.2:7789; 
 } 
} 

 

W klauzuli syncer deklarujemy przepustowość dostępną dla replikacji zasobów między węzłami, wartość podana w przykładzie jest w OPN w zupełności wystarczająca. W klauzuli net określamy sposób zachowania się poszczególnych węzłów na wypadek wystąpienia zjawiska split-brain, czyli sytuacji, gdy węzły utracą ze sobą kontakt i nie będą mogły informować się wzajemnie o swoim stanie.

  • Gdy w momencie wykrycia split-braina udział nie jest w stanie aktywnym na żadnym z węzłów, i nie nastąpiły zmiany w danych na którymś z nich, ich stan jest odrzucany. Jeżeli występuje konflikt, połączenie między węzłami jest zrywane i pracują one samodzielnie, konflikt musi natomiast zostać rozwiązany manualnie przez administratora.

  • Gdy w momencie wykrycia split-braina udział jest w stanie aktywnym na jednym z węzłów, stan na węzłach pasywnych jest odrzucany.

Następnie inicjalizujemy nowo utworzony zasób.

 

drbdadm create-md mysql
drbdadm up mysql

 

Następnie na jednej z instancji wykonujemy następujące polecenie.

 

drbdadm -- --overwrite-data-of-peer primary mysql

 

Wybór instancji, na której je wykonamy, ma znaczenie jedynie wtedy, gdy już posiadamy na zasobie jakieś dane, które chcemy zreplikować na pozostały węzeł. W tym przypadku tworzymy nowy zasób, więc wybór węzła nie ma znaczenia. Stan replikacji możemy śledzić za pomocą poleceń service drbd status i drbd-overview.

Kolejnym krokiem jest utworzenie systemu plików na nowo utworzonym zasobie, np. ext4. Krok ten wykonujemy również tylko na aktywnym węźle.


 mkfs.ext4 /dev/drbd1


2.2 MySQL

Zatrzymujemy usługę serwera MySQL.

 

service mysql stop

 

Tymczasowo podmontujemy zasób DRBD na aktywnym węźle, aby skopiować na niego zawartość katalogu /var/lib/mysql, gdzie będzie podmontowywany przez klaster.

 

 mkdir /mnt/tmp
 mount /dev/drbd1 /mnt/tmp
 cp -ar /var/lib/mysql/* /mnt/tmp/
 umount /mnt/tmp

 

Następnie zawartość tego katalogu na dyskach systemowych instancji możemy usunąć.

 

rm -rf /var/lib/mysql/*
 

Pozostaje zmienić konfigurację serwera MySQL, tak aby bindował się do adresu klastra. W tym celu ustawiamy bind-address = 10.0.0.10 w /etc/mysql/my.cnf.

 

2.3 Klaster

Do realizacji funkcjonalności klastra wykorzystamy pakiety corosync i pacemaker. Corosync odpowiada za komunikację między węzłami w klastrze, a pacemaker za zarządzanie zasobami.

W pliku /etc/default/corosync ustawiamy START=yes, natomiast w pliku /etc/corosync/corosync.conf należy w klauzuli interface ustawić bindnetaddr na adres naszego węzła w OPN oraz zwiększyć expected_votes w klauzuli quorum do 2 (zasadniczo wartość ta powinna wynosić 50% liczby węzłów w klastrze + 1).

Ponieważ usługi DRBD i MySQL na wszystkich węzłach będą zarządzane przez klaster, musimy zadbać o to, by nie uruchamiały się przy starcie systemu z wykorzystaniem swoich standardowych skryptów inicjalizacyjnych.

 

update-rc.d -f drbd remove
update-rc.d -f mysql remove
echo "manual" > /etc/init/mysql.override
update-rc.d -f pacemaker remove
update-rc.d pacemaker start 50 1 2 3 4 5 . stop 01 0 6 .

 

Po wstępnym skonfigurowaniu corosynca możemy włączyć usługi klastrowe.

 

service corosync start
service pacemaker start

 

Możemy teraz przystąpić do konfiguracji klastra na jednym z węzłów za pomocą narzędzia crm.

 

crm
configure
property stonith-enabled=false
property no-quorum-policy=ignore
primitive DRBD_MYSQL ocf:linbit:drbd params drbd_resource="mysql" op monitor 
interval="9s" role="Master" op monitor interval="11s" role="Slave"
ms MS_DRBD_MYSQL DRBD_MYSQL meta master-max="1" master-node-max="1" 
clone-max="2" clone-node-max="1" notify="true"
primitive MYSQL_FS ocf:heartbeat:Filesystem params device="/dev/drbd1" 
directory="/var/lib/mysql" fstype="ext4"
primitive MYSQL_IP ocf:heartbeat:IPaddr2 params ip=10.0.0.10 cidr_netmask=24 
op monitor interval=10s
primitive MYSQL_SERVER lsb:mysql
group MYSQL MYSQL_FS MYSQL_IP MYSQL_SERVER
colocation MYSQL_ON_DRBD inf: MYSQL MS_DRBD_MYSQL:Master
order MYSQL_AFTER_DRBD inf: MS_DRBD_MYSQL:promote MYSQL:start
exit

 

Gdy zostaniemy zapytani o zatwiedzenie zmian, potwierdzamy. Przedstawiona przykładowa konfiguracja obejmuje zasób DRBD, system plików na nim, adres IP, za pomocą którego będziemy się łączyć z bazą, oraz usługę serwera baz danych. Konfiguracja zapewnia właściwą kolejność uruchamiania usług i zależności między nimi. Aktualną konfigurację klastra możemy zobaczyć po wydaniu następującego polecenia.

 

crm configure show

 

Stan klastra i usług zarządzanych za jego pomocą możemy sprawdzić za pomocą poleceń.

 

crm_mon
crm status 
(7 vote(s))
This article was helpful
This article was not helpful

Comments (0)
Post a new comment
 
 
Full Name:
Email:
Comments:
CAPTCHA Verification 
 
Please enter the text you see in the image into the textbox below. This is required to prevent automated registrations and form submissions.