Zbalansowany klaster MySQL bez modułu równoważenia obciążenia

Chcę utworzyć klaster MySQL z równoważeniem obciążenia, ale bez faktycznego równoważenia obciążenia, aby nie dodawać kolejnego punktu awarii lub złożoności.

Myślałem o następujących rzeczach:

1. Mieć konfigurację master-master dla MySQL

2. Na każdym kliencie umieść prosty okrągły serwer proxy, który obracałby żądania między serwerami.

czy to możliwe? Czy istnieją lepsze sposoby na osiągnięcie tego?

Proszę przeczytać moją drugą odpowiedź na to pytanie, zanim zacznę korzystać z serwera proxy MySQL dowolnego rodzaju. Jeśli masz 2 serwery master-master, na których pisze CMS, i 10 httpd, które tylko z niego czytają, wszystko będzie dobrze, ale (jak wskazano w drugiej odpowiedzi) nie zawsze tak jest. Zostałeś ostrzeżony.

MySQL Proxy to prosty program, który znajduje się między Twoim klientem a serwerami MySQL, który może monitorować, analizować lub przekształcać ich komunikację. Jego elastyczność pozwala na nieograniczone wykorzystanie; do typowych należą: równoważenie obciążenia; praca awaryjna; analiza zapytań; filtrowanie i modyfikowanie zapytań; i wiele więcej.

.

HAProxy to bezpłatne, bardzo szybkie i niezawodne rozwiązanie oferujące wysoką dostępność, równoważenie obciążenia i proxy dla aplikacji opartych na TCP i HTTP

Jeśli uruchomisz go w trybie TCP, może być jeszcze lepszy niż Wackamole. Gdybym musiał wybierać między nimi, użyłbym HAProxy. Również HAProxy może mieć wiele backendów, Waclamole może mieć tylko 2. Zauważ, że HAProxy jest „głupi”, łączy gniazda bez patrzenia na to, co jest w strumieniu - dedykowany serwer proxy MySQL może mieć opcję kierowania różnych żądań do określonych serwerów .

Warto wspomnieć, że Galera Replication for MySQL to prawdziwa konfiguracja MySQL dla wielu użytkowników. Galera to synchroniczny protokół replikacji, więc aplikacje mogą odczytywać i zapisywać dane na dowolnym serwerze MySQL. Oto krótki samouczek: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial

Jeśli chodzi o usługi równoważenia obciążenia przed serwerami MySQL, użyj albo łącznika MySQL, który obsługuje tę funkcję (np. Connector / J dla Java lub Mysqlnd dla php)

Jeśli nie masz łącznika, który mógłby to zrobić, użyj czegoś takiego jak serwer proxy HA. Ten skrypt automatycznie konfiguruje serwer proxy HA i utrzymuje listę dobrych serwerów MySQL: https://github.com/severalnines/haproxy

Z poważaniem,

Vinay

www.severalnines.com

Replikacja master-master nie jest tak dobra, jak mogłoby się wydawać, to samo dotyczy round-robin proxy i podobnych „łatwych” rozwiązań. Jeśli odpowiednio szybko zbierzesz dane do oddzielnych serwerów (szybciej niż opóźnienie między serwerami, które na serwerach produkcyjnych może wynosić do pełnej sekundy *), oba zaakceptują dane. Jeśli masz serwer aukcyjny, właśnie sprzedałeś dwa razy ten sam samochód . Kto to kupił? To zależy od tego, który DB poprosisz!

Aplikacja musi wiedzieć, że istnieją 2 bazy danych i musi znać oba ich adresy IP. Jeśli chcesz „sprzedać”, powinieneś np

DB_number = `auction_number` % `number_of_databases`

( %jest dla modulo)

... i zatwierdzić do bazy danych DB_number. Jeśli pojawi się błąd połączenia, być może zrób to z drugim (ale w przypadku serwera aukcyjnego po prostu wyświetliłbym błąd).

Ponadto adresy IP powinny być wackamole -d między oboma serwerami. W scenariuszu katastrofy, w którym jeden serwer bazy danych wyłącza się na kilka godzin w szczytowym czasie użytkowania, przekonasz się, że aplikacja będzie próbowała połączyć się z nieobecnym serwerem i zawiesić się, dopóki TIMEOUT, powiedzmy 3s. Nagle połowa twoich zapytań działa o 3 sekundy dłużej (wszystkie ostatecznie trafiają do tej samej bazy danych - co nie sprawia, że ​​działa szybciej niż przed katastrofą). To nie sprawia, że ​​Twój httpd jest szczęśliwy, ponieważ prawdopodobnie ma ograniczoną pulę połączeń współbieżnych wątków obsługi żądań ...

* opóźnienie replikacji na serwerach produkcyjnych może wynosić nawet pełną sekundę - przetestowałem to w zdalnej kolokacji oraz w naszym centrum danych i przez około 99% czasu wynosi 0, ale czasami mysql pokazuje 1s. Na ogromnym ruchu miałem wiele kolizji z powodu złożenia przez aplikację kliencką dwóch żądań, co spowodowało dwa zapytania, wstaw i wybierz. W niektórych przypadkach wiersz po prostu jeszcze nie istniał , więc użyliśmy skrótu ID użytkownika i naprawiłem problem

Mam nadzieję, że nauczysz się na moich błędach ;-)

Zrównoważony obciążeniem klaster bazy danych MySQL (lub inny) jest dość daremny. Jeśli piszesz na więcej niż jednym serwerze, wtedy napotkasz problemy lub użyjesz synchronicznej replikacji (która zresztą nie obsługuje MySQL), co negatywnie wpływa na wydajność, ponieważ wymaga synchronizacji blokad.

Zalecam podzielenie obciążeń odczytu / zapisu i zrównoważenie obciążenia odczytów między urządzeniami slave mysql i posiadanie albo jednego wzorca do zapisu, albo użycie pary aktywnej / pasywnej pracy awaryjnej dla swojego wzorca.

Zasadniczo nie można skalować zapisów poprzez umieszczenie większej liczby serwerów w bazie danych jako urządzeń podrzędnych, ponieważ każdy nadal musi zapisać cały ładunek zapisu aplikacji.

Aby skalować zapisy, musisz logicznie podzielić dane na wiele serwerów, dzieląc je na partycje lub „sharding” itp. Zazwyczaj wymaga to nietrywialnych (bardzo trudnych do przetestowania) zmian w aplikacji, więc nie chcesz tego robić, chyba że NAPRAWDĘ potrzebuję tego.

Możesz oczywiście użyć klastra MySQL, jeśli naprawdę chcesz, ale jest to zupełnie inny silnik z własnymi funkcjami i wadami - konfiguracja jest nieco skomplikowana, ale naprawdę zapewnia bazę danych z równoważeniem obciążenia HA na sprzęcie towarowym. Nadal cierpi z powodu ograniczeń wydajności zapisu przy użyciu replikacji synchronicznej, ale pozwala skalować zapisy, ponieważ ma wbudowane partycjonowanie między serwerami.

Kolejny świetny przewodnik na ten temat, który znalazłem ...

http://www.dancryer.com/2010/01/mysql-circular-replication

To jest część 1 serii trzech postów:

• Przewodnik po klastrze równoważącym obciążenie MySQL - część 1 - konfigurowanie samych serwerów i konfiguracja replikacji MySQL.

• MySQL Load-Balanced Cluster Guide - część 2 - skonfiguruj skrypt do monitorowania stanu twoich węzłów klastra MySQL, którego użyjemy w następnym przewodniku do skonfigurowania naszego proxy.

• Przewodnik po klastrze równoważenia obciążenia MySQL - część 3 - konfigurowanie modułu równoważenia obciążenia za pomocą HAProxy przy użyciu skryptów monitorowania

Osobiście lepszym sposobem byłoby użycie modułu równoważenia obciążenia!

Tak, dodaje kolejny punkt awarii, ale każda rutyna, którą umieścisz lub zainstalujesz na KAŻDYM kliencie, znacznie bardziej skomplikuje niż standardowy moduł równoważenia obciążenia ....

Złącze / J ma możliwość równoważenia obciążenia zapytań na kilku serwerach. Jest to przede wszystkim przeznaczone dla klastra NDB MySQL, w którym wszystkie węzły SQL będą miały spójny widok danych, ale jeśli możesz zapewnić, że baza danych dwóch wzorców będzie w miarę spójna między tymi dwoma wzorcami, może być bezpieczna dla twojej aplikacji.

Ciąg połączenia wyglądałby mniej więcej tak:

jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "random" & loadBalanceBlacklistTimeout = 5000

Podział zapisów nie odciąży serwerów, ponieważ zapisy wciąż muszą zostać zreplikowane.

Jeśli używasz tylko 2 serwerów, korzystaj z pulsu z drbd i pozwól drbd obsługiwać replikację. Jeśli pierwszy serwer ulegnie awarii, drugi serwer przejmie kontrolę. Jeśli chcesz użyć drugiego serwera, możesz użyć gfs nad drbd, a następnie uruchomić drugi serwer jako tylko do odczytu i użyć go jako serwera do odczytu. Kiedy nastąpi przełączenie awaryjne, zmień serwer na odczyt / zapis.

re: wackamole - wackamole nie ogranicza się do 2 serwerów

Pracuję nad serią samouczków na ten temat, ale konfiguracja jest naprawdę prosta.

Aby udzielić bardziej aktualnej odpowiedzi na to pytanie, w wersji 5.6 MySQL wprowadzono GTID (Global Transaction Identifieres), które mają na celu uczynienie asynchronicznej replikacji bardziej niezawodnym i ponownie postawić MySQL w wyścigu o HA (wysoką dostępność).

W tej sekcji opisano replikację opartą na transakcjach przy użyciu globalnych identyfikatorów transakcji (GTID). Podczas korzystania z identyfikatorów GTID każdą transakcję można zidentyfikować i śledzić, ponieważ jest ona zatwierdzana na serwerze źródłowym i stosowana przez dowolne urządzenia podrzędne; oznacza to, że nie jest konieczne, gdy używa się identyfikatorów GTID w odniesieniu do plików dziennika lub pozycji w tych plikach podczas uruchamiania nowego urządzenia podrzędnego lub przełączania awaryjnego do nowego urządzenia nadrzędnego, co znacznie upraszcza te zadania. Ponieważ replikacja oparta na GTID jest całkowicie oparta na transakcjach, łatwo jest ustalić, czy elementy nadrzędne i podrzędne są spójne; tak długo, jak wszystkie transakcje dokonane na urządzeniu głównym są również dokonywane na urządzeniu podrzędnym, zapewniona jest zgodność między nimi. Możesz używać replikacji opartej na instrukcjach lub opartej na wierszach z identyfikatorami GTID (patrz Sekcja 16.2.1, „Formaty replikacji”); jednak dla uzyskania najlepszych rezultatów

Odniesienie: 16.1.3 Replikacja za pomocą globalnych identyfikatorów transakcji (dokumentacja MySQL)

Myślałem, że użycie HAProxy do zapytań o równoważenie obciążenia wprowadza SPOF (Single Point Of Failure), a dodanie pulsu powoduje, że to rozwiązanie jest kłopotliwe.

Prostszym rozwiązaniem jest połączenie przez złącze Java JConnector, które ma na celu ładowanie zapytań o równoważenie obciążenia poprzez adres URL jdbc ze wszystkimi węzłami MySQL. Może obsługiwać konfiguracje master / slave lub master / master .

Umożliwia to skonfigurowanie rozwiązania klastrowego HA od razu z MySQL.