Jakie są wady korzystania z Galera Cluster zamiast replikacji Master / Slave?

Jakie są wady korzystania z Galera Cluster zamiast zwykłej replikacji Master / Slave? Opóźnienie zerowe Galery 0, synchroniczna replikacja i brak pojedynczego punktu awarii wydają się bardzo atrakcyjne, więc dlaczego klaster Galera nie jest tak powszechny?

— Sam
źródło

Odpowiedzi:

Ponieważ, jak każda inna optymalizacja, nie pasuje do każdego obciążenia.

Galera może zostać przytłoczona wysokim tempem transakcji lub gdy transakcje aktualizują wiele wierszy. Może to również powodować opóźnienia aplikacji w trybie COMMIT podczas synchronizacji klastra.

Galera również nie aktualizuje synchronicznie innych węzłów. Po prostu przesyła zadania synchronicznie. W ten sposób przypomina trochę standardową replikację w trybie półsynchronicznym. Dlatego nadal istnieje niewielka szansa na odczyt nieaktualnych danych z innego węzła klastra. Istnieje opcja, którą można ustawić, aby wymusić na SELECT czekanie, aż kolejka zadań zaktualizuje bazę danych, ale oznacza to, że masz opóźnienia w SELECT. A nawet szansa na zablokowanie SELECT, co wydaje się sprzeczne z intuicją.

Galera jest genialna, ale nie jest uniwersalną technologią. Nadal istnieją dobre powody, aby używać replikacji asynchronicznej.

— Bill Karwin
źródło

Dzięki Bill, btw Od jakiegoś czasu czytam wasze prezentacje w Perconie.

— Sam

Inną wadą jest to, że węzeł dawcy jest wyłączony i może być używany do kopiowania (przez xtrabackup, rsync, mysqldump) do dowolnego węzła wprowadzonego do klastra, pozostawiając pozostałe węzły w klastrze, aby wykonać ciężkie podnoszenie, dopóki nowy węzeł nie zostanie zsynchronizowany. To nie jest taka wada dla małych i średnich DB.

— RolandoMySQLDBA,

@RolandoMySQLDBA Metody SST, takie jak xtrabackup, precyzyjnie unikają blokowania dawcy. Chociaż prawdą jest, że w każdym przypadku dawca pogorszy wydajność, jeśli baza danych jest duża.

— jynus

@ jynus, problem nie blokuje się na węźle dawcy , ale że węzeł odbiorczy jest w trybie offline i niedostępny dla jakichkolwiek zapytań, gdy trwa SST. Dlatego jeśli używasz klastra do równoważenia obciążenia zapytaniami, zapytania, które trafiłyby do węzła odbiorczego, muszą być wysyłane do innych węzłów, aż do zakończenia SST.

— Bill Karwin,

W przypadku, gdy ktokolwiek szuka, opcja, do której odnosi się Bill, jest wsrep_causal_reads... ustawiona na WŁĄCZONA z, SET GLOBAL wsrep_causal_reads = 'ON';aby selekcje czekały na zakończenie wszystkich zestawów zapisu.

— Luke Cousins

Niektóre wady Galera obejmują:

Obsługa silnika pamięci masowej: ograniczona do InnoDB / XtraDB (plus eksperymentalna obsługa MyISAM)
Obsługa systemu operacyjnego: tylko Oses typu Linux / Unix

Istnieją również pewne ograniczenia, na które należy zwrócić uwagę, ale być może można je obejść:

Domyślnie (Total Order Isolation) operacje DDL blokują cały klaster, dopóki się nie zakończą
Każda tabela musi mieć wyraźny klucz podstawowy, jedno- lub wielokolumnowy
Blokowanie: niektóre typy jawnego blokowania nie są obsługiwane.

Aby uzyskać więcej informacji, zobacz szczegóły w Codership (i tutaj na temat blokowania DDL), MariaDB i Percona .

EDYCJA: Zauważ też, że niektórzy twierdzą, że ciasno powiązane klastry baz danych, takie jak Galera, nie powinny mieć węzłów rozproszonych geograficznie z powodu problemów wynikających z nieodłącznej niewiarygodności warstwy sieci. Zamiast tego w takich przypadkach należy zastosować rozwiązania asynchroniczne. Zobacz: Jak nie robić MySQL Wysoka dostępność: dystrybucja węzłów geograficznych z niewłaściwym użyciem replikacji opartej na Galera . Niemniej blog Galera stwierdza, że (2015):

Argumenty przemawiające za budowaniem geograficznie rozproszonych klastrów baz danych są silne. Podejście Galera do replikacji i specyficzne funkcje produktu sprawiają, że praktyczne jest budowanie klastrów Galera obejmujących wiele centrów danych, a wielu użytkowników ma takie klastry już w produkcji.

— dbdemon
źródło