Klaster MySQL — MySQL Cluster

Klaster MySQL

Deweloper(zy)	Wyrocznia
Pierwsze wydanie	Listopad 2004
Wersja stabilna	8,0 / 11 maja 2021 ; 4 miesiące temu ( 11.05.2021 )
System operacyjny	Wieloplatformowy
Dostępne w	język angielski
Rodzaj	RDBMS
Licencja	Powszechna Licencja Publiczna GNU (wersja 2, z wyjątkiem łączenia ) lub komercyjna umowa EULA
Strona internetowa

MySQL Cluster to technologia zapewniająca klastrowanie bez współużytkowania i automatyczne sharding dla systemu zarządzania bazą danych MySQL . Został zaprojektowany, aby zapewnić wysoką dostępność i wysoką przepustowość przy niskich opóźnieniach, przy jednoczesnym zapewnieniu niemal liniowej skalowalności. MySQL klastra jest realizowany przez NDB silnika składowania lub NDBCLUSTER MySQL ( "NDB" oznacza N etwork D ATA b ASE).

Architektura

MySQL Cluster został zaprojektowany w oparciu o rozproszoną architekturę zgodną z wieloma wzorcami, zgodną z ACID, bez pojedynczego punktu awarii . MySQL Cluster wykorzystuje automatyczne sharding (partycjonowanie) w celu skalowania w poziomie operacji odczytu i zapisu na standardowym sprzęcie i można uzyskać do niego dostęp za pośrednictwem interfejsów API SQL i Non-SQL (NoSQL)

Replikacja

Wewnętrznie klaster MySQL wykorzystuje synchroniczną replikację poprzez mechanizm dwufazowego zatwierdzania , aby zagwarantować, że dane są zapisywane do wielu węzłów po zatwierdzeniu danych. (W przeciwieństwie do tego, co zwykle nazywa się „replikacją MySQL”, która jest asynchroniczna .) Do zagwarantowania dostępności wymagane są dwie kopie (znane jako repliki ) danych. Klaster MySQL automatycznie tworzy „grupy węzłów” z określonej przez użytkownika liczby replik i węzłów danych. Aktualizacje są synchronicznie replikowane między członkami grupy węzłów w celu ochrony przed utratą danych i obsługi szybkiego przełączania awaryjnego między węzłami.

Możliwe jest również asynchroniczne replikowanie między klastrami; jest to czasami określane jako „replikacja klastra MySQL” lub „replikacja geograficzna”. Jest to zwykle używane do replikacji klastrów między centrami danych w celu odzyskiwania danych po awarii lub zmniejszenia skutków opóźnień w sieci poprzez fizyczne zlokalizowanie danych bliżej zbioru użytkowników. W przeciwieństwie do standardowej replikacji MySQL, replikacja geograficzna MySQL Cluster wykorzystuje optymistyczną kontrolę współbieżności i koncepcję Epochs, aby zapewnić mechanizm wykrywania i rozwiązywania konfliktów, umożliwiając aktywne/aktywne klastrowanie między centrami danych.

Począwszy od MySQL Cluster 7.2, obsługa synchronicznej replikacji między centrami danych była obsługiwana przez funkcję Multi-Site Clustering.

Poziome partycjonowanie danych (auto-sharding)

MySQL Cluster jest zaimplementowany jako w pełni rozproszona baza danych z wieloma wzorcami, dzięki czemu aktualizacje dokonywane przez dowolną aplikację lub węzeł SQL są natychmiast dostępne dla wszystkich innych węzłów uzyskujących dostęp do klastra, a każdy węzeł danych może akceptować operacje zapisu.

Dane w tabelach MySQL Cluster (NDB) są automatycznie dzielone na partycje we wszystkich węzłach danych w systemie. Odbywa się to na podstawie algorytmu mieszającego opartego na kluczu podstawowym w tabeli i jest niewidoczne dla aplikacji końcowej . Klienci mogą łączyć się z dowolnym węzłem w klastrze, a zapytania automatycznie uzyskują dostęp do odpowiednich fragmentów potrzebnych do spełnienia zapytania lub zatwierdzenia transakcji. Klaster MySQL jest w stanie obsługiwać zapytania i transakcje typu cross-shard.

Użytkownicy mogą definiować własne schematy partycjonowania. Pozwala to programistom na dodanie „świadomości dystrybucji” do aplikacji poprzez partycjonowanie na podstawie podklucza, który jest wspólny dla wszystkich wierszy, do których uzyskują dostęp transakcje o dużej liczbie operacji. Gwarantuje to, że dane używane do realizacji transakcji są zlokalizowane w tym samym fragmencie, co zmniejsza liczbę przeskoków w sieci.

Pamięć hybrydowa

MySQL Cluster umożliwia przechowywanie i dostęp do zbiorów danych większych niż pojemność pojedynczej maszyny na wielu maszynach.

Klaster MySQL utrzymuje wszystkie indeksowane kolumny w pamięci rozproszonej. Kolumny nieindeksowane mogą być również utrzymywane w pamięci rozproszonej lub mogą być utrzymywane na dysku z pamięcią podręczną stron w pamięci . Przechowywanie nieindeksowanych kolumn na dysku umożliwia MySQL Cluster przechowywanie zestawów danych większych niż zagregowana pamięć maszyn klastrowanych.

MySQL Cluster zapisuje logi Redo na dysk dla wszystkich zmian danych, a także regularnie sprawdza dane na dysk. Dzięki temu klaster może konsekwentnie odzyskiwać dane z dysku po pełnej awarii klastra. Ponieważ dzienniki Redo są zapisywane asynchronicznie w odniesieniu do zatwierdzania transakcji, pewna niewielka liczba transakcji może zostać utracona w przypadku awarii pełnego klastra, jednak można to złagodzić za pomocą replikacji geograficznej lub klastra wielolokacyjnego omówionego powyżej. Bieżące domyślne opóźnienie zapisu asynchronicznego wynosi 2 sekundy i można je konfigurować. Normalne scenariusze z pojedynczym punktem awarii nie powodują utraty danych z powodu synchronicznej replikacji danych w klastrze.

Gdy tabela klastra MySQL jest przechowywana w pamięci, klaster będzie miał dostęp do pamięci dyskowej tylko w celu zapisania rekordów i punktów kontrolnych Redo. Ponieważ te zapisy są sekwencyjne i są zaangażowane ograniczone wzorce dostępu losowego, MySQL Cluster może osiągnąć wyższą przepustowość zapisu przy ograniczonym sprzęcie dyskowym w porównaniu z tradycyjnym RDBMS z pamięcią podręczną opartą na dyskach. To wskazywanie na dysk danych tabeli w pamięci można wyłączyć (na podstawie tabeli), jeśli trwałość na dysku nie jest potrzebna.

Nic nie udostępniono

Klaster MySQL został zaprojektowany tak, aby nie mieć pojedynczego punktu awarii . Zakładając, że klaster jest poprawnie skonfigurowany, każdy pojedynczy węzeł, system lub element sprzętu może ulec awarii bez awarii całego klastra. Dysk współdzielony ( SAN ) nie jest wymagany. Połączenia między węzłami mogą być standardowymi połączeniami Ethernet , Gigabit Ethernet , InfiniBand lub SCI .

API SQL i NoSQL

Ponieważ MySQL Cluster przechowuje tabele w węzłach danych, a nie w MySQL Server, istnieje wiele interfejsów umożliwiających dostęp do bazy danych:

• Dostęp do SQL przez MySQL Server
• Interfejsy API NoSQL, w których biblioteki MySQL Cluster można osadzać w aplikacji, aby zapewnić bezpośredni dostęp do węzłów danych bez przechodzenia przez warstwę SQL. Obejmują one:
  • Memcached
  • Node.js / JavaScript
  • Java i JPA
  • HTTP / REST
  • Interfejs API NDB (C++)

Menedżer klastra MySQL

Jako część komercyjnego MySQL Cluster CGE, MySQL Cluster Manager to narzędzie zaprojektowane w celu uproszczenia tworzenia i administrowania bazą danych MySQL Cluster CGE poprzez automatyzację typowych zadań zarządzania, w tym skalowanie online, aktualizacje, tworzenie kopii zapasowych/przywracanie i rekonfigurację. MySQL Cluster Manager monitoruje również i automatycznie odzyskuje węzły aplikacji i węzły zarządzania MySQL Server, a także węzły danych MySQL Cluster.

Realizacja

Klaster MySQL wykorzystuje trzy różne typy węzłów (procesów):

• Węzeł danych (proces ndbd/ndbmtd) : Te węzły przechowują dane. Tabele są automatycznie dzielone na fragmenty w węzłach danych, które również w przejrzysty sposób obsługują równoważenie obciążenia, replikację, przełączanie awaryjne i samonaprawianie.
• Węzeł zarządzania (proces ndb_mgmd) : Używany do konfiguracji i monitorowania klastra. Są one wymagane tylko do uruchomienia lub ponownego uruchomienia węzła klastra. Można je również skonfigurować jako arbitrów, ale nie jest to obowiązkowe (zamiast tego serwery MySQL można skonfigurować jako arbitrzy).
• Węzeł aplikacji lub węzeł SQL (proces mysqld) : serwer MySQL (mysqld), który łączy się ze wszystkimi węzłami danych w celu przechowywania i pobierania danych. Ten typ węzła jest opcjonalny; możliwe jest wysyłanie zapytań do węzłów danych bezpośrednio przez interfejs API NDB, natywnie przy użyciu interfejsu API C++ lub jednego z dodatkowych interfejsów API NoSQL opisanych powyżej.

Ogólnie oczekuje się, że każdy węzeł będzie działał na osobnym hoście fizycznym, maszynie wirtualnej lub instancji w chmurze (chociaż bardzo często łączy się węzły zarządzania z serwerami MySQL). W celu uzyskania najlepszej praktyki zaleca się, aby nie umieszczać węzłów w tej samej grupie węzłów na jednym hoście fizycznym (ponieważ reprezentowałby to pojedynczy punkt awarii).

Wersje

Począwszy od wersji 8.0 klaster MySQL jest oparty bezpośrednio na odpowiednich wersjach 8.0 serwera MySQL. Wcześniej numery wersji MySQL Cluster były oddzielone od numerów MySQL Server - na przykład MySQL Cluster 7.6 był oparty na/zawierał komponent serwera z MySQL 5.7.

Wyższe wersje MySQL Cluster zawierają wszystkie funkcje niższych wersji oraz kilka nowych funkcji.

Starsze wersje (już nie w fazie rozwoju):

• Ndb zawarty w drzewie źródłowym MySQL 5.1.X
• MySQL Cluster 6.2 oparty na MySQL 5.1.A

Pierwsze wydanie „telco” lub „carrier grade edition”. Obsługuje 255 węzłów, zmianę tabel online, opóźnienia replikacji i ulepszenia przepustowości itp.

• MySQL Cluster 6.3 oparty na MySQL 5.1.B

Obejmuje skompresowaną kopię zapasową + LCP, obsługę replikacji cyklicznej, wykrywanie/rozwiązywanie konfliktów, optymalizację tabel itp.

• MySQL Cluster 7.0 oparty na MySQL 5.1.C

Obejmuje wielowątkowe węzły danych (ndbmtd), Transactional DDL, obsługę Windows.

• MySQL Cluster 7.1 oparty na MySQL 5.1.D

Zawiera złącza ClusterJ i ClusterJPA

Obecnie dostępne wersje:

• MySQL Cluster 7.2 oparty na MySQL 5.5

Obejmuje adaptacyjną lokalizację zapytań (wypycha operacje JOIN do węzłów danych), interfejs API Memcached, uproszczoną replikację geograficzną Active/Active, klastrowanie w wielu lokalizacjach, ulepszenia skalowalności węzłów danych, skonsolidowane uprawnienia użytkowników.

• MySQL Cluster 7.3 oparty na MySQL 5.6

Obejmuje obsługę ograniczeń kluczy obcych , Node.js / JavaScript API i autoinstalatora.

• MySQL Cluster 7.4 oparty na MySQL 5.6

Obejmuje ulepszone wykrywanie i rozwiązywanie konfliktów, skrócone czasy ponownego uruchamiania węzłów, nowy interfejs API zdarzeń.

• MySQL Cluster 7.5 oparty na MySQL 5.7

Obejmuje obsługę większych zestawów danych (ponad 128 TB na węzeł), ulepszoną skalowalność odczytu dzięki zoptymalizowanym tabelom odczytu, ulepszoną obsługę SQL.

• MySQL Cluster 7.6 oparty na MySQL 5.7

Skrócone czasy ponownego uruchamiania i odzyskiwania, zmniejszone wykorzystanie miejsca na dysku, ulepszona wydajność łączenia, nowe narzędzie do importowania, komunikacja w pamięci współdzielonej, ulepszona świadomość topologii dla chmury.

• MySQL Cluster 8.0 oparty na MySQL 8.0

Zwiększenie maksymalnego rozmiaru wiersza do 30kB, Obsługa do 144 węzłów danych, Ulepszone filtrowanie i łączenie rozproszone, Obsługa równoległych złączeń zewnętrznych i semijoin, Ulepszona obsługa schematów i list ACL, Zmiana nazwy kolumn online, Uproszczona konfiguracja, Wielowątkowe równoległe tworzenie kopii zapasowych i przywracanie, Poprawa wydajności danych dyskowych, Ulepszona obsługa konfiguracji z 3 i 4 replikami, Obsługa wielogniazdowej sieci mesh, Obsługa transformacji przywracania, Poprawiona wydajność zapisu obiektów Blob, Szyfrowanie kopii zapasowych, Obsługa IPv6, Autokonfiguracja wątków, Poprawiona wydajność odzyskiwania, Ulepszona wielowątkowość zapytań.

Wymagania

W celach ewaluacyjnych możliwe jest uruchomienie MySQL Cluster na jednym fizycznym serwerze. W przypadku wdrożeń produkcyjnych minimalne wymagania systemowe to 3 x instancje/hosty:

• 2 × węzły danych
• 1 × Węzeł aplikacji/zarządzania

lub

• 2 × węzeł danych + aplikacja
• 1 × węzeł zarządzający

Konfiguracje w następujący sposób:

• System operacyjny: Linux , Solaris , Windows . macOS (tylko do programowania)
• Procesor: Intel/AMD x86/x86-64, UltraSPARC
• Pamięć: 1 GB
• Dysk twardy: 3 GB
• Sieć: 1+ węzły (standardowy Ethernet - TCP/IP)

Wskazówki i zalecenia dotyczące wdrażania wysokowydajnych klastrów klasy produkcyjnej można znaleźć w przewodniku MySQL Cluster Evaluation Guide oraz Guide to Optimizing Performance of the MySQL Cluster Database .

Historia

MySQL AB nabył technologię kryjącą się za MySQL Cluster od Alzato , małej firmy venture założonej przez Ericsson . NDB został pierwotnie zaprojektowany dla rynku telekomunikacyjnego , ze względu na jego wysoką dostępność i wysokie wymagania dotyczące wydajności.

Klaster MySQL oparty na silniku pamięci masowej NDB został od tego czasu zintegrowany z produktem MySQL , a jego pierwsze wydanie znajduje się w MySQL 4.1.

Wsparcie

MySQL Cluster jest objęty licencją GPLv 2. Komercyjne wsparcie jest dostępne w ramach MySQL Cluster CGE, który obejmuje również dodatki non-open source, takie jak MySQL Cluster Manager, MySQL Enterprise Monitor, a także MySQL Enterprise Security i MySQL Enterprise Audit.

Zobacz też

• Galera Cluster , ogólna synchroniczna biblioteka replikacji z wieloma wzorcami dla transakcyjnych baz danych dla MySQL i MariaDB. [1]
• Percona xtradb klastra jest również kombinacja Galera biblioteki replikacji MySQL różnorodnego matrycy.

Bibliografia

Zewnętrzne linki

MySQL

• Oficjalna dokumentacja klastra MySQL
• Przewodnik dla programistów interfejsu API klastra MySQL
• Demonstracja klastra MySQL
• Arkusz danych klastra MySQL
• Często zadawane pytania dotyczące klastra MySQL
• Samouczek autoinstalatora klastra MySQL
• Blog dotyczący klastra MySQL
• Pierwsze kroki z klastrem MySQL
• Oficjalne dokumenty i przewodniki dotyczące klastra MySQL
• Forum społeczności MySQL Cluster

Inne

• Projektowanie i modelowanie równoległego serwera danych dla aplikacji telekomunikacyjnych (1997) Motywacja do projektowania oryginalnego klastra MySQL.