Rozwiązania skalujące dla MySQL (replikacja, klastrowanie)

Na starcie , nad którym pracuję, rozważamy teraz skalowanie rozwiązań dla naszej bazy danych. Sprawy stają się nieco zagmatwane (przynajmniej dla mnie) z MySQL, który ma klaster MySQL , replikację i replikację klastra MySQL (od wersji 5.1.6), który jest asynchroniczną wersją klastra MySQL. Podręcznik MySQL wyjaśnia niektóre różnice w często zadawanych pytaniach dotyczących klastrów , ale trudno jest na ich podstawie ustalić, kiedy należy użyć jednego lub drugiego.

Byłbym wdzięczny za każdą radę osób, które znają różnice między tymi rozwiązaniami, jakie są wady i zalety oraz kiedy warto z nich skorzystać.

Dużo czytałem na temat dostępnych opcji. Dostałem też w swoje ręce 2. wydanie High Performance MySQL, które bardzo polecam.

Oto, co udało mi się złożyć razem:

Grupowanie

Klastrowanie w sensie ogólnym polega na rozkładaniu obciążenia na wiele serwerów, które dla zewnętrznej aplikacji wyglądają jak jeden serwer.

Klaster MySQL NDB

MySQL NDB Cluster jest rozproszonym, działającym w pamięci, silnikiem pamięci masowej bez współdzielenia z synchroniczną replikacją i automatycznym partycjonowaniem danych (przepraszam, zapożyczam dosłownie z książki High Performance, ale bardzo ładnie to ujęli). Może to być rozwiązanie o wysokiej wydajności dla niektórych aplikacji, ale aplikacje internetowe generalnie nie działają na nim dobrze.

Główny problem polega na tym, że poza bardzo prostymi zapytaniami (które dotykają tylko jednej tabeli), klaster będzie zazwyczaj musiał wyszukiwać dane w kilku węzłach, umożliwiając wkradanie się opóźnień w sieci i znaczne spowolnienie czasu wypełniania zapytań. Ponieważ aplikacja traktuje klaster jak jeden komputer, nie może jej powiedzieć, z którego węzła ma pobierać dane.

Ponadto wymaganie dotyczące pamięci nie działa w przypadku wielu dużych baz danych.

Ciągła sekwoja

To kolejne rozwiązanie klastrowe dla MySQL, które działa jako oprogramowanie pośredniczące na serwerze MySQL. Oferuje replikację synchroniczną, równoważenie obciążenia i przełączanie awaryjne. Zapewnia również, że żądania zawsze otrzymują dane z najnowszej kopii, automatycznie wybierając węzeł, który ma świeże dane.

Przeczytałem o nim kilka dobrych rzeczy i ogólnie brzmi to całkiem obiecująco.

Federacja

Federacja jest podobna do klastrowania, więc tutaj też ją ściągnąłem. MySQL oferuje federację za pośrednictwem federacyjnego mechanizmu magazynowania. Podobnie jak rozwiązanie klastrowe NDB, działa dobrze tylko z prostymi zapytaniami - ale jeszcze gorzej z klastrem dla skomplikowanych (ponieważ opóźnienie sieci jest znacznie wyższe).

Replikacja i równoważenie obciążenia

MySQL ma wbudowaną możliwość tworzenia replikacji bazy danych na różnych serwerach. Można to wykorzystać do wielu celów - dzielenia obciążenia między serwerami, tworzenia kopii zapasowych na gorąco, tworzenia serwerów testowych i przełączania awaryjnego.

Podstawowa konfiguracja replikacji polega na tym, że jeden serwer główny obsługuje głównie zapisy, a co najmniej jeden serwer podrzędny obsługuje tylko odczyty. Bardziej zaawansowaną odmianą jest konfiguracja master-master , która umożliwia skalowanie zapisów poprzez jednoczesne zapisywanie przez kilka serwerów.

Każda konfiguracja ma swoje wady i zalety, ale jednym z problemów, które wszyscy dzielą, jest opóźnienie replikacji - ponieważ replikacja MySQL jest asynchroniczna, nie wszystkie węzły mają zawsze najświeższe dane. Wymaga to, aby aplikacja była świadoma replikacji i zawierała zapytania obsługujące replikację, aby działały zgodnie z oczekiwaniami. W przypadku niektórych aplikacji może to nie stanowić problemu, ale jeśli zawsze potrzebujesz najświeższych danych, sytuacja nieco się komplikuje.

Replikacja wymaga równoważenia obciążenia, aby rozdzielić obciążenie między węzłami. Może to być tak proste, jak modyfikacje kodu aplikacji lub użycie dedykowanych rozwiązań programowych i sprzętowych.

Sharding i partioning

Sharding to powszechnie stosowane podejście do skalowania rozwiązań bazodanowych. Dzielisz dane na mniejsze fragmenty i rozprowadzasz je po różnych węzłach serwera. Wymaga to od aplikacji świadomości modyfikacji sposobu przechowywania danych, aby działała wydajnie, ponieważ musi wiedzieć, gdzie znaleźć potrzebne informacje.

Istnieją ramy abstrakcji, które pomagają radzić sobie z fragmentowaniem danych, takie jak Hibernate Shards , rozszerzenie Hibernate ORM (który niestety jest w Javie. Używam PHP). HiveDB to kolejne takie rozwiązanie, które obsługuje również równoważenie fragmentów.

Inni

Sfinks

Sphinx to pełnotekstowa wyszukiwarka, której można używać nie tylko do wyszukiwania testowego. W przypadku wielu zapytań jest znacznie szybszy niż MySQL (zwłaszcza w przypadku grupowania i sortowania) i może równolegle odpytywać zdalne systemy i agregować wyniki - co czyni go bardzo użytecznym w użyciu z fragmentowaniem.

Ogólnie rzecz biorąc, sphinx powinien być używany z innymi rozwiązaniami skalującymi, aby uzyskać więcej dostępnego sprzętu i infrastruktury. Wadą jest to, że ponownie potrzebujesz kodu aplikacji, aby być świadomym sfinksa, aby mądrze go używać.

Podsumowanie

Rozwiązania skalujące różnią się w zależności od potrzeb aplikacji, która tego potrzebuje. Uważam, że zarówno dla nas, jak i dla większości aplikacji internetowych, replikacja (prawdopodobnie multi-master) jest drogą do rozwiązania z systemem równoważenia obciążenia rozprowadzającym obciążenie. Dzielenie określonych obszarów problemowych (ogromne tabele) jest również konieczne, aby móc skalować w poziomie.

Zamierzam też dać szansę Continuent Sequoia i sprawdzić, czy naprawdę może zrobić to, co obiecuje, ponieważ będzie wymagał najmniejszej ilości zmian w kodzie aplikacji.

Uwaga: nie korzystałem z klastra MySQL, więc wychodzę tylko z tego, co słyszałem.

MySQL Cluster to rozwiązanie HA (wysoka dostępność). Jest szybki, ponieważ wszystko jest w pamięci, ale prawdziwym punktem sprzedaży jest dostępność. Nie ma jednego punktu awarii. Z drugiej strony, w przypadku replikacji, jeśli master zepsuje się, musisz faktycznie przełączyć się na replikę i może wystąpić niewielki czas przestoju. (chociaż rozwiązanie DRBD to kolejna alternatywa o wysokiej dostępności)

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, aby przechowywać całą bazę 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żny (czytaj: prawdopodobnie nie), jest to bardziej kłopotliwe (i pieniądze) niż jest warte. Replikacja jest często lepszym sposobem.

Edycja: zapomniałem również wspomnieć, że Cluster nie zezwala na klucze obce, a skanowanie zasięgu jest wolniejsze niż na innych silnikach. Oto link, który mówi o znanych ograniczeniach klastra MySQL

Istnieje kilka dobrych dyskusji na temat tego, jak ludzie, którzy utrzymują drupal.org, ustrukturyzowali swoje serwery baz danych:

• Blog Dries Buytaert
• Blog o pracy

Oba pochodzą z 2007 roku, więc wsparcie dla klastrów może być teraz silniejsze, ale wtedy wybrali replikację.

Fajną rzeczą w wykonywaniu replikacji jest to, że jest to łatwe. Po prostu skonfiguruj 2 pola mysql, zmień identyfikator serwera w drugim polu, a następnie skieruj drugie pole na pierwsze, używając wzorca zmiany do polecenia.

Oto odpowiednia przykładowa konfiguracja slave my.cnf

#
#       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 otrzymuje identyfikator serwera zwiększony o 1 (więc następny slave to serwer 3)

ustaw nazwę użytkownika i hasło, z którym slave może się połączyć, a następnie uruchom zmień master na MASTER_HOST = 'xxxx'; zmień master na MASTER_PASSWORD = "xxxxx";

i tak dalej.

na koniec uruchom "start slave;"

Nadchodzi twój niewolnik i zaczyna się replikować. słodki huh!

Zakłada się, że zaczynasz z 2 pustymi serwerami. Następnie możesz zrzucić swoją bazę danych na serwer główny, a gdy się tam załaduje, załaduje się również na serwer podrzędny.

Możesz sprawdzić stan slave, uruchamiając:

pokaż status slave \ G

Baw się tym… baaardzo łatwo…

Robiąc badanie wysokiej dostępności natknąłem się na wiele rozwiązań i prawdopodobnie w naszym przypadku, który był systemem intensywniej zapisującym, stwierdziłem, że klaster DRBD jest lepszy niż klaster NDB, ponieważ zapewnia większą liczbę transakcji na sekundę.

MySQL Replication może zapewnić maszynę do tworzenia kopii zapasowych, która może być używana jako urządzenie podrzędne do odczytu lub może być używana w przypadku odzyskiwania po awarii.

Dzięki różnym trybom zarządzania transakcjami zapewnianym przez DRBD możesz zmniejszyć wydajność replikacji danych na poziomie urządzenia w sieci. Aby uzyskać niezawodny system, który nie powinien stracić żadnej transakcji w przypadku awarii, użyj trybu C, w przeciwnym razie wybierz B.

Próbowałem wymienić niektóre informacje, których nauczyłem się podczas konfigurowania klastra DRBD na http://www.techiegyan.com/?p=132

Działa naprawdę dobrze na dedykowanym połączeniu do replikacji, tj. Rezerwuje oddzielne szybkie interfejsy na obu maszynach tylko do replikacji drbd. Heartbeat może ładnie sterować klastrem za pomocą wszystkich usług pojedynczo, tj. Adresów IP, partycji, drbd i mysql.

Nie odkryłem jeszcze konfiguracji Master-Master na DRBD. Zaktualizuję się, gdy osiągnę sukces.

Dzięki.

moim zdaniem zamieszanie tutaj po prostu odsyła mnie z powrotem do Mnesii. Z fragmentacją, deklaratywnym i pragmatycznym sposobem obsługi indeksów, przejrzystością lokalizacji replik baz danych itp

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

Krótko mówiąc, uruchamiamy mnesię na klastrze MySQL. Klaster MySQL może obsługiwać duże zestawy danych, baza danych może wzrosnąć do 50 GB plus. Mamy mnezję zasilającą aplikacje Erlang / OTP . Dane dostępowe Java i PHP z mnesii przez dostosowane interfejsy API REST (ostatnio Thrift ) wykorzystujące JSON i XML jako formaty wymiany.

Warstwa dostępu do danych wyodrębniła dostęp do danych w Mnesii i starych przesłanych danych w klastrze MySQL, jeśli było to potrzebne. Mnesia jest tutaj głównie po to, aby zasilać aplikacje Erlang / OTP, a gdy zostanie zapełniona danymi, wrzucamy je do klastra MYSQL. Warstwa dostępu do danych może uzyskać dostęp do danych w mnesii i MySQL w abstrakcyjnym API w imieniu wszystkich aplikacji.

Mogę tutaj powiedzieć, że Mnesia była dla nas najlepszą opcją. Tabele są mocno pofragmentowane i indeksowane, zapytania działają bardzo dobrze, a baza danych jest replikowana w 2 lokalizacjach połączonych tunelem.

Wcześniej obawialiśmy się, że mnesia może nie obsłużyć tak wielu rekordów, jak to możliwe, ze względu na ograniczenie rozmiaru tabeli. Ale stwierdziliśmy, że to stwierdzenie jest błędne. Przy dobrym dostrojeniu (fragmentacji) nasze bazy danych mnesia przechowują średnio około 250 milionów rekordów rocznie.

Odnieśliśmy korzyści ze złożonej struktury danych Erlanga i faktu, że Mnesia może pochłonąć ją w niezmienionej postaci. Aplikacje Erlang / OTP są najbardziej wydajne ze wszystkich innych aplikacji w starszych językach, a wraz z naszym systemem planujemy migrację wszystkich do technologii Erlang / OTP. Z Erlang najwyraźniej uzyskujemy dostęp do danych z klastra MySQL i bardzo cudownie wykonujemy zapytania na jego serwery. W rzeczywistości wydedukowaliśmy, że jego Erlang / OTP może w pełni wykorzystywać zasoby serwera MySQL ze względu na ogromną współbieżność (Erlang).

Mnesia działała dla nas bardzo dobrze, a Mnesia całkowicie zmieniła sposób, w jaki patrzymy na bazy danych ze względu na jej niesamowitą wydajność. Rdzenie procesorów naszych serwerów Solaris są zajęte średnio przez około 48% w godzinach szczytu.

Radzę sprawdzić mnezję i kto wie, może ona odpowiedzieć na wiele potrzeb związanych z dystrybucją lub replikacją.

Nie korzystałem z nich, ale z dokumentów powiedziałbym, że replikacja jest preferowanym rozwiązaniem, jeśli największe obciążenie odczytuje z bazy danych.

Ograniczenie „w pamięci” uniemożliwia nam używanie klastra MySQL dla naszych prawie 50 GB danych, więc używamy DRBD plus linux Heartbeat .

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

Klaster MySQL to dziwna bestia i za każdym razem, gdy ocenialiśmy, działał bardzo źle lub był zawodny.

Konfiguracja jest strasznie skomplikowana (potrzebujesz co najmniej trzech węzłów, a może więcej). Nie ma również możliwości przełączania klientów w stan awaryjny, więc musisz to zrobić samodzielnie (lub użyć czegoś innego, aby działać jako proxy itp.).

Jest niezwykle sprytny, ponieważ wykonuje automatyczne partycjonowanie skrótu na kluczu podstawowym, co umożliwia skalowanie zapisów, a także dlatego, że nie ma pojedynczego punktu awarii.

Ale naprawdę uważam, że lepiej pasuje 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. InnoDB) ani pod względem wydajności, ani funkcji.