Jak uruchomić klaster MySQL lub MariaDB Galera — zaktualizowano

W przeciwieństwie do standardowego serwera MySQL i klastra MySQL, sposób uruchamiania klastra MySQL/MariaDB Galera jest nieco inny. Galera wymaga uruchomienia węzła w klastrze jako punktu odniesienia, zanim pozostałe węzły będą mogły dołączyć i utworzyć klaster. Ten proces jest znany jako bootstrap klastra. Bootstrapping to wstępny krok do wprowadzenia węzła bazy danych jako podstawowego komponentu, zanim inni zobaczą go jako punkt odniesienia do synchronizacji danych.

Jak to działa?

Gdy Galera uruchomi się poleceniem bootstrap na węźle, ten konkretny węzeł osiągnie stan podstawowy (sprawdź wartość wsrep_cluster_status). Pozostałe węzły będą wymagały tylko normalnego polecenia startu i będą automatycznie szukały istniejącego komponentu podstawowego (PC) w klastrze i połączą się, aby utworzyć klaster. Synchronizacja danych odbywa się wtedy za pomocą przyrostowego transferu stanu (IST) lub transferu stanu migawki (SST) między dołączającym a dawcą.

Tak więc w zasadzie powinieneś załadować klaster tylko wtedy, gdy chcesz uruchomić nowy klaster lub gdy żadne inne węzły w klastrze nie są w stanie PODSTAWOWYM. Należy zachować ostrożność podczas wybierania akcji, w przeciwnym razie możesz skończyć z podziałem klastrów lub utratą danych.

Poniższe przykładowe scenariusze ilustrują, kiedy należy załadować klaster z trzema węzłami na podstawie stanu węzła (wsrep_local_state_comment) i stanu klastra (wsrep_cluster_status):

Stan Galera	Przepływ Bootstrapa
	Uruchom ponownie zainicjowany węzeł.
	Uruchom ponownie zainicjowany węzeł. Po zakończeniu uruchom nowy węzeł.
	Bootstrap najbardziej zaawansowany węzeł za pomocą „pc.bootstrap=1”. Uruchom ponownie pozostałe węzły, po jednym węźle na raz.
	Uruchom nowy węzeł.
	Uruchom nowy węzeł, po jednym węźle na raz.
	Załaduj dowolny węzeł. Uruchom pozostałe węzły, po jednym węźle na raz.

Jak uruchomić klaster Galera?

Trzech dostawców Galera używa różnych poleceń ładowania początkowego (w oparciu o najnowszą wersję oprogramowania). Na pierwszym węźle uruchom:

• Klaster MySQL Galera (kodowanie):

  $ service mysql bootstrap # sysvinit
  $ galera_new_cluster # systemd
  $ mysqld_safe --wsrep-new-cluster # command line

• Klaster Percona XtraDB (Percona):

  $ service mysql bootstrap-pxc # sysvinit
  $ systemctl start [email protected] # systemd

• Klaster MariaDB Galera (MariaDB):

  $ service mysql bootstrap # sysvinit
  $ service mysql start --wsrep-new-cluster # sysvinit
  $ galera_new_cluster # systemd
  $ mysqld_safe --wsrep-new-cluster # command line

Powyższe polecenie jest tylko opakowaniem i faktycznie uruchamia instancję MySQL w tym węźle z gcomm:// jako zmienną wsrep_cluster_address. Możesz także ręcznie zdefiniować zmienne w my.cnf i uruchomić standardowe polecenie start/restart. Nie zapomnij jednak ponownie zmienić wsrep_cluster_address, aby zawierał adresy wszystkich węzłów po starcie.

Gdy pierwszy węzeł jest aktywny, uruchom następujące polecenie na kolejnych węzłach:

$ service mysql start
$ systemctl start mysql

Nowy węzeł łączy się z elementami klastra zgodnie z definicją za pomocą parametru wsrep_cluster_address. Teraz automatycznie pobierze mapę klastra i połączy się z pozostałymi węzłami i utworzy klaster.

Ostrzeżenie:nigdy nie uruchamiaj ładowania początkowego, gdy chcesz ponownie podłączyć węzeł do istniejącego klastra i NIGDY nie uruchamiaj ładowania początkowego na więcej niż jednym węźle.

Flaga Safe-to-Bootstrap

Galera począwszy od wersji 3.19 zawiera nową flagę o nazwie „safe_to_bootstrap” wewnątrz pliku grastate.dat. Ta flaga ułatwia podejmowanie decyzji i zapobiega niebezpiecznym wyborom poprzez śledzenie kolejności, w jakiej węzły są zamykane. Węzeł, który został zamknięty jako ostatni, zostanie oznaczony jako „Safe-to-Bootstrap”. Wszystkie inne węzły zostaną oznaczone jako niebezpieczne do załadowania.

Patrząc na zawartość pliku grastate.dat (domyślnie w katalogu danych MySQL) powinieneś zauważyć flagę w ostatniej linii:

# GALERA saved state
version: 2.1
uuid:    8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno:   2575
safe_to_bootstrap: 0

Podczas ładowania nowego klastra Galera odmówi uruchomienia pierwszego węzła, który został oznaczony jako niebezpieczny do załadowania. W dziennikach zobaczysz następujący komunikat:

„Załadowanie klastra z tego węzła może nie być bezpieczne. Nie był to ostatni, który opuścił klaster i może nie zawierać wszystkich aktualizacji.

Aby wymusić ładowanie klastra w tym węźle, ręcznie edytuj plik grastate.dat i ustaw safe_to_bootstrap na 1 ”.

W przypadku nieczystego zamknięcia lub poważnej awarii, wszystkie węzły będą miały „safe_to_bootstrap:0”, więc musimy skonsultować się z silnikiem przechowywania InnoDB, aby określić, który węzeł zatwierdził ostatnią transakcję w klastrze. Można to osiągnąć, uruchamiając mysqld ze zmienną „--wsrep-recover” na każdym z węzłów, która generuje następujący wynik:

$ mysqld --wsrep-recover
...
2016-11-18 01:42:15 36311 [Note] InnoDB: Database was not shutdown normally!
2016-11-18 01:42:15 36311 [Note] InnoDB: Starting crash recovery.
...
2016-11-18 01:42:16 36311 [Note] WSREP: Recovered position: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f:114428
...

Liczba po ciągu UUID w wierszu „Pozycja odzyskana” jest tą, której należy szukać. Wybierz węzeł, który ma najwyższy numer i edytuj jego plik grastate.dat, aby ustawić „safe_to_bootstrap:1”, jak pokazano w poniższym przykładzie:

# GALERA saved state
version: 2.1
uuid:    8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno:   -1
safe_to_bootstrap: 1

Następnie możesz wykonać standardowe polecenie ładowania początkowego na wybranym węźle.

Co się stanie, jeśli węzły się rozejdą?

W pewnych okolicznościach węzły mogą się od siebie odbiegać. Stan wszystkich węzłów może zmienić się na inny niż podstawowy z powodu podziału sieci między węzły, awarii klastra lub jeśli Galera napotka wyjątek podczas określania składnika podstawowego. Następnie musisz wybrać węzeł i wypromować go jako komponent podstawowy.

Aby określić, który węzeł należy załadować, porównaj wartość wsrep_last_committed na wszystkich węzłach bazy danych:

node1> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name        | Value       |
+----------------------+-------------+
| wsrep_last_committed | 10032       |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+

node2> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name        | Value       |
+----------------------+-------------+
| wsrep_last_committed | 10348       |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+

node3> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name        | Value       |
+----------------------+-------------+
| wsrep_last_committed |   997       |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+

Z powyższych wyników węzeł2 ma najbardziej aktualne dane. W takim przypadku wszystkie węzły Galera są już uruchomione, więc nie jest konieczne ponowne uruchamianie klastra. Musimy tylko promować node2 jako główny komponent:

node2> SET GLOBAL wsrep_provider_options="pc.bootstrap=1";

Pozostałe węzły ponownie połączą się z komponentem podstawowym (węzeł 2) i ponownie zsynchronizują swoje dane w oparciu o ten węzeł.

Lub z ClusterControl> Wydajność> Stan bazy danych strona: