Architektura bazy danych master-master czy master-slave?

Słyszałem o dwóch rodzajach architektur baz danych.

• mistrz-mistrz

• pan-niewolnik

Czy master-master nie jest bardziej odpowiedni dla dzisiejszej sieci, ponieważ jest jak Git, każda jednostka ma cały zestaw danych, a jeśli jeden z nich się zepsuje, nie ma to większego znaczenia.

Master-slave przypomina mi SVN (którego nie lubię), w którym masz jedną jednostkę centralną, która obsługuje.

Pytania:

1. Jakie są zalety i wady każdego z nich?

2. Jeśli chcesz mieć lokalną bazę danych w telefonie komórkowym, taką jak iPhone, która jest bardziej odpowiednia?

3. Czy wybór jednego z nich jest krytycznym czynnikiem, który należy dokładnie rozważyć?

Stawiamy na dostępność, spójność i złożoność. Aby najpierw odpowiedzieć na ostatnie pytanie: czy to ma znaczenie? Tak, bardzo! Wybory dotyczące sposobu zarządzania danymi są absolutnie fundamentalne i nie ma „najlepszych praktyk” uchylających się od decyzji. Musisz zrozumieć swoje szczególne wymagania.

Istnieje fundamentalne napięcie:

Jedna kopia: spójność jest łatwa, ale jeśli zdarzy się, że spadnie, wszyscy są poza wodą, a jeśli ludzie są daleko, mogą zapłacić straszne koszty komunikacji. Umieść na zdjęciu urządzenia przenośne, które mogą wymagać odłączenia, a jedna kopia go nie przytnie.

Master Slave: spójność nie jest zbyt trudna, ponieważ każdy element danych ma dokładnie jednego właściciela. Ale co zrobisz, jeśli nie możesz zobaczyć tego mistrza, potrzebna jest jakaś odłożona praca.

Mistrz-mistrz: cóż, jeśli możesz sprawić, że to zadziała, to wydaje się, że oferuje wszystko, nie ma pojedynczego punktu awarii, każdy może pracować przez cały czas. Problem polega na tym, że bardzo trudno jest zachować absolutną spójność. Więcej informacji znajdziesz w artykule na Wikipedii .

Wikipedia wydaje się mieć fajne podsumowanie zalet i wad

Zalety

• Jeśli jeden master zawiedzie, inni będą kontynuować aktualizację bazy danych.

• Masters mogą być zlokalizowane w kilku fizycznych lokalizacjach, tj. Rozproszone w całej sieci.

Niedogodności

• Większość systemów replikacji typu multi-master jest tylko luźno spójnych, tj. Leniwych i asynchronicznych, co narusza właściwości ACID.

• Systemy chętnej replikacji są złożone i wprowadzają pewne opóźnienia w komunikacji.

• Problemy, takie jak rozwiązywanie konfliktów, mogą stać się nie do rozwiązania, gdy liczba zaangażowanych węzłów wzrasta, a wymagane opóźnienie maleje.

Podczas badania różnych architektur baz danych. Zebrałem sporo informacji, które mogą być przydatne dla kogoś innego prowadzącego badania w przyszłości. przeszedłem przez

1. Replikacja typu master-slave
2. Replikacja typu master-master
3. Klaster MySQL

Zdecydowałem się zadowolić użyciem MySQL Cluster w moim przypadku użycia. Prosimy jednak o zapoznanie się z różnymi zaletami i wadami, które zestawiłem poniżej

1. Replikacja typu master-slave

Plusy

• Aplikacje analityczne mogą odczytywać dane z urządzeń podrzędnych bez wpływu na urządzenie główne
• Kopie zapasowe całej bazy danych, które stosunkowo nie mają wpływu na master
• Slaves może zostać przełączony w tryb offline i zsynchronizowany z powrotem do mastera bez żadnych przestojów

Cons

• W przypadku niepowodzenia niewolnik musi zostać awansowany na pana, aby zająć jego miejsce. Brak automatycznego przełączania awaryjnego
• Przestój i możliwa utrata danych w przypadku awarii urządzenia głównego
• Wszystkie zapisy muszą być również wykonane do mastera w układzie master-slave
• Każdy dodatkowy slave dodaje trochę obciążenia do mastera, ponieważ dziennik binarny musi zostać odczytany, a dane skopiowane do każdego slave'a
• Może być konieczne ponowne uruchomienie aplikacji

2. Replikacja typu master-master

Plusy

• Aplikacje mogą czytać od obu mistrzów
• Rozkłada obciążenie zapisu na oba węzły główne
• Proste, automatyczne i szybkie przełączanie awaryjne

Cons

• Luźno spójne
• Konfiguracja i wdrażanie nie jest tak proste, jak master-slave

3. Klaster MySQL

Nowy dzieciak w mieście oparty na projekcie klastra MySQL. Klaster MySQL został opracowany z myślą o wysokiej dostępności i skalowalności i jest idealnym rozwiązaniem do wykorzystania w środowiskach, które nie wymagają przestojów, wysokiej dostępności i skalowalności poziomej.

Aby uzyskać więcej informacji, zobacz MySQL Cluster 101

Plusy

• (Wysoka dostępność) Brak pojedynczego punktu awarii
• Bardzo duża przepustowość
• 99,99% czasu sprawności
• Automatyczne dzielenie na fragmenty
• Responsywność w czasie rzeczywistym
• Operacje on-line (zmiany schematu itp.)
• Rozproszone pisma

Cons

• Zobacz znane ograniczenia

Możesz odwiedzić mój blog, aby zapoznać się z pełnym opisem, w tym diagramami architektury, które zawierają dalsze szczegóły dotyczące trzech wspomnianych architektur.