Skalowanie rozwiązań dla MySQL (replikacja, klastrowanie)

Zastrzeżenie: nie używałem MySQL Cluster, więc idę tylko z tego, co słyszałem.

Klaster MySQL jest rozwiązaniem HA (high availability). Jest szybki, bo wszystko jest w pamięci, ale prawdziwym punktem sprzedaży jest dostępność. Nie ma jednego punktu awarii. Z replikacji, z drugiej strony, jeśli master idzie w dół, trzeba rzeczywiście przełączyć się na replikę, a nie może być niewielka ilość przestoju. (chociaż rozwiązanie DRBD jest inną alternatywą, która ma wysoka dostępność)

Klaster wymaga, aby cała baza danych mieściła się w pamięci. Oznacza to, że każda maszyna w klastrze musi mieć wystarczającą ilość pamięci do przechowywania całej bazy danych. Nie jest to więc realne rozwiązanie dla bardzo dużych baz danych (a przynajmniej jest to bardzo drogie rozwiązanie).

Myślę, że jeśli HA nie jest super ważne (Czytaj: prawdopodobnie nie), to jest więcej kłopotów (i pieniędzy) niż jest warte. Replikacja jest częściej lepszym sposobem.

Edit: I zapomniałem też wspomnieć, że klaster nie pozwala na obce klucze, a Skanowanie zasięgu jest wolniejsze niż w innych silnikach. Oto link mówiący o znanych ograniczeniach klastra MySQL

Są dobre Dyskusje o tym, jak ludzie, którzy utrzymują drupal.org mają ustrukturyzowane serwery baz danych:

• Dries Buytaert ' s blog
• blog o pracy

Oba pochodzą z 2007 roku, więc Obsługa klastrów może być teraz silniejsza, ale w czasie, gdy wybrali replikację.

Fajną rzeczą w replikacji jest to, że jest to łatwe. Wystarczy skonfigurować 2 pola mysql, zmienić serverID na drugim polu, a następnie skierować drugie pole na pierwsze za pomocą polecenia Zmień master do.

Oto odpowiednia próbka slave my.cnf config

#
#       Log names
#

log-bin=binlog
relay-log=relaylog
log-error=errors.log

#
#       Log tuning
#

sync_binlog = 1
binlog_cache_size = 1M

#
#       Replication rules (what are we interested in listening for...)
#
#       In our replicants, we are interested in ANYTHING that isn't a permission table thing
#

replicate-ignore-db =      mysql
replicate-wild-ignore-table=mysql.%

#
#       Replication server ID
#

server-id      =        2

Więc upewnij się, że każdy slave otrzyma serverID zwiększony o 1 (Więc następnym slave jest Serwer 3)

Skonfiguruj nazwę użytkownika i hasło, które slave może połączyć, Następnie uruchom Zmień master NA MASTER_HOST = "x. x.x. x"; Zmień master NA MASTER_PASSWORD = "xxxxx";

I tak dalej.

Na koniec uruchom "start slave;"

Zakłada się, że zaczynasz od 2 pustych serwerów. Następnie możesz zrzucić swój db do serwera głównego, a gdy ładuje się tam, ładuje się również na slave.

Możesz sprawdzić status slave uruchamiając:

Show Slave status \G

Ograniczenie "w pamięci" uniemożliwia nam korzystanie z MySQL cluster dla naszych prawie 50GB danych, więc używamy DRBD i Linux Heartbeat.

To coś w rodzaju macierzy raid pomiędzy dwoma (lub więcej) skrzynkami, która utrzymuje synchronizację baz danych / logów / configów (ale tylko jeden serwer może być "na żywo" na raz). Przełączanie awaryjne jest automatyczne, używa tego samego adresu IP i jest szybkie, jak restart mysql, więc było to dobre rozwiązanie dla nas.

Podczas badania wysokiej dostępności natknąłem się na wiele rozwiązań i prawdopodobnie w naszym przypadku, który był bardziej intensywnym systemem pisania, znalazłem klaster DRBD lepszy niż klaster NDB, ponieważ zapewnia większą liczbę transakcji na sekundę.

Replikacja Mysql może zapewnić maszynę kopii zapasowej, która może być używana jako odczyt slave lub może być używana w przypadku odzyskiwania po awarii.

Z różnymi trybami zarządzania transakcjami dostarczonymi przez DRBD możesz trochę zmniejszyć wydajność dzięki replikacji danych na poziomie urządzenia przez sieć. Dla niezawodnego systemu, który nie powinien stracić żadnej transakcji w przypadku awarii, użyj trybu C, w przeciwnym razie przejdź do B.

Próbowałem wymienić niektóre nauki, które zrobiłem podczas konfigurowania klastra DRBD na http://www.techiegyan.com/?p=132

Działa bardzo dobrze na dedykowanym połączeniu do replikacji tzn. rezerwuje osobne szybkie interfejsy na obu maszynach tylko dla replikacji drbd. Bicie serca może kontrolować klaster ładnie ze wszystkimi usługami jeden po drugim tj. adresami IP, partycjami, drbd i mysql.

Jeszcze nie odkryłem konfiguracji Master-Master NA DRBD. Zaktualizuje się jak i kiedy osiągnę sukces w tym.

Moim zdaniem, zamieszanie tutaj po prostu wysyła mnie z powrotem do Mnesia. Z fragmentacją, deklaratywnym i pragmatycznym sposobem obsługi indeksów, przezroczystością lokalizacji replik baz danych e.t. C

W naszej konfiguracji uruchamiamy zarówno MySQL Cluster jak i Mnesia. Nasze dane są sezonowe. Więc po jakimś czasie zwalniamy mnesia z danych, które już nie są używane i wrzucamy je do klastra MYSQL. Dzięki temu nasza mnesia jest wydajna. Mamy również aplikacje zaimplementowane w głównych językach strumienia (Python, Clojure e.t. c), które wykorzystują dane bezpośrednio z MySQL.

W skrócie, uruchamiamy mnesia na górze klastra MySQL. Klaster MySQL może obsługiwać duże zestawy danych, baza danych może wzrosnąć do 50GB plus. Mamy mnesia zasilające aplikacje Erlang/OTP . Java i PHP dostęp do danych z mnesia poprzez dopasowane REST (ostatnio Thrift ) API wykorzystujące JSON i XML jako formaty wymiany.

Warstwa dostępu do danych ma abstrakcyjny dostęp do danych w Mnesia i stare wysyłane dane w klastrze MySQL w razie potrzeby. Mnesia służy głównie do zasilania aplikacji Erlang / OTP.Gdy zostanie zapchany danymi, wrzucamy go do MYSQL Clustera. Warstwa dostępu do danych może uzyskać dostęp zarówno do danych w mnesia, jak i MySQL w abstrakcyjnym API w imieniu wszystkich aplikacji.

Mogę tu powiedzieć, że Mnesia była dla nas najlepszą opcją. Tabele są bardzo fragmentaryczne i indeksowane, zapytania działają bardzo dobrze, a baza danych jest replikowana przez 2 miejsca, połączone tunelem.

Wcześniej obawialiśmy się, że mnesia może nie obsłużyć tak wielu rekordów, jak to możliwe z powodu ograniczenia rozmiaru tabeli. Ale uznaliśmy to stwierdzenie za błędne. Przy dobrym tuningu (fragmentacji) nasze bazy danych mnesia przechowują średnio około 250 milionów rekordów rocznie.

Skorzystaliśmy ze złożonej struktury danych Erlanga i faktu, że Mnesia może ją pochłonąć bez zmian. Aplikacje Erlang / OTP są najbardziej wydajne ze wszystkich innych aplikacji w starszej wersji języków, a dzięki naszemu systemowi planujemy migrację tego wszystkiego do technologii Erlang / OTP. Z Erlang wydaje się, że dostęp do danych z MySQL klastra i wykonywać zapytania na swoich serwerach bardzo cudownie, w rzeczywistości, mamy wywnioskować, że jego Erlang / OTP, które mogą w pełni korzystać z zasobów serwera MySQL ze względu na jego (Erlang) masową współbieżność.

Mnesia pracuje dla nas bardzo dobrze.Mnesia całkowicie zmieniła sposób patrzenia na bazy danych ze względu na ekscytującą wydajność. Nasze Solaris Serwerowe rdzenie CPU są zajęte średnio około 48% zużycia w godzinach szczytu.

Radzę sprawdzić mnesia i kto wie, może to odpowiedzieć na wiele Twoich potrzeb dystrybucji lub replikacji.

Nie używałem ich, ale z dokumentów powiedziałbym, że replikacja jest preferowanym rozwiązaniem, jeśli największe obciążenie to odczyt z bazy danych.

MySQL cluster jest dziwną bestią i za każdym razem, gdy oceniamy, jest albo wykonywany bardzo źle, albo zawodny.

Konfiguracja jest strasznie skomplikowana(potrzebujesz co najmniej trzech węzłów, być może więcej). Nie ma również przepisu na to, że klienci nie przejdą, więc musisz to zrobić sam (lub użyć czegoś innego, aby działać jako proxy itp.).

Jest to niezwykle sprytne, ponieważ robi automatyczne partycjonowanie hash na kluczu głównym, co pozwala skalować zapisy, a także ponieważ nie ma jednego punktu awarii.

Ale myślę, że lepiej nadaje się do bardzo specjalnych przypadków, do których został zaprojektowany. W większości przypadków nie może zastąpić innego silnika bazy danych (np.