Porównanie rozwiązania Oracle RAC HA z Galera Cluster for MySQL lub MariaDB

Biznes nieustannie dążył do czerpania wniosków z informacji, aby podejmować niezawodne, mądrzejsze, oparte na faktach decyzje w czasie rzeczywistym. Ponieważ firmy w większym stopniu polegają na danych i bazach danych, informacje i przetwarzanie danych stanowią podstawę wielu operacji biznesowych i decyzji biznesowych. Wiara w bazę danych jest całkowita. Żadna z codziennych usług firmy nie może działać bez bazowych platform bazodanowych. W konsekwencji konieczność skalowalności i wydajności oprogramowania systemów bazodanowych jest bardziej krytyczna niż kiedykolwiek. Główne zalety klastrowego systemu baz danych to skalowalność i wysoka dostępność. W tym blogu postaramy się porównać Oracle RAC i Galera Cluster w świetle tych dwóch aspektów. Real Application Clusters (RAC) to najwyższej klasy rozwiązanie Oracle do klastrowania baz danych Oracle, które zapewnia wysoką dostępność i skalowalność. Galera Cluster to najpopularniejsza technologia klastrowania dla MySQL i MariaDB.

Przegląd architektury

Oracle RAC wykorzystuje oprogramowanie Oracle Clusterware do łączenia wielu serwerów. Oracle Clusterware to rozwiązanie do zarządzania klastrami, które jest zintegrowane z bazą danych Oracle, ale może być również używane z innymi usługami, nie tylko z bazą danych. Oracle Clusterware to dodatkowe oprogramowanie instalowane na serwerach z tym samym systemem operacyjnym, które umożliwia łączenie serwerów w łańcuchy tak, jakby były jednym serwerem.

Oracle Clusterware obserwuje instancję i automatycznie uruchamia ją ponownie w przypadku awarii. Jeśli Twoja aplikacja jest dobrze zaprojektowana, możesz nie doświadczyć żadnych przerw w działaniu usług. Awaria dotyczy tylko grupy sesji (tych połączonych z instancją, która uległa awarii). Zaciemnienie można skutecznie zamaskować przed użytkownikiem końcowym za pomocą zaawansowanych funkcji RAC, takich jak szybkie powiadamianie o aplikacjach i szybkie przełączanie awaryjne połączenia klienta Oracle. Oracle Clusterware kontroluje członkostwo w węzłach i zapobiega objawom podziału mózgu, w których co najmniej dwie instancje próbują kontrolować instancję.

Galera Cluster to synchroniczna technologia klastrowania aktywnych-aktywnych baz danych dla MySQL i MariaDB. Galera Cluster różni się od tego, co jest znane jako Oracle MySQL Cluster - NDB. Klaster MariaDB jest oparty na wtyczce replikacji multi-master dostarczanej przez Codership. Od wersji 5.5 wtyczka Galera (wsrep API) jest integralną częścią MariaDB. Klaster Percona XtraDB (PXC) jest również oparty na wtyczce Galera. Architektura wtyczek Galera opiera się na trzech podstawowych warstwach:certyfikacji, replikacji i strukturze komunikacji grupowej. Warstwa certyfikacji przygotowuje zestawy zapisów i przeprowadza na nich kontrole certyfikacyjne, gwarantując, że można je zastosować. Warstwa replikacji zarządza protokołem replikacji i zapewnia pełną zdolność zamawiania. Group Communication Framework implementuje architekturę wtyczek, która umożliwia innym systemom łączenie się za pośrednictwem schematu zaplecza gcomm.

Aby zachować identyczny stan w klastrze, interfejs API wsrep używa globalnego identyfikatora transakcji. Unikalny identyfikator GTID jest tworzony i kojarzony z każdą transakcją zatwierdzoną w węźle bazy danych. W Oracle RAC różne instancje bazy danych współdzielą dostęp do zasobów, takich jak bloki danych w buforze pamięci podręcznej, aby kolejkować bloki danych. Dostęp do zasobów współdzielonych między instancjami RAC musi być skoordynowany, aby uniknąć konfliktów. Aby zorganizować współdzielony dostęp do tych zasobów, rozproszona pamięć podręczna przechowuje informacje, takie jak identyfikator bloku danych, która instancja RAC przechowuje bieżącą wersję tego bloku danych oraz tryb blokady, w którym każda instancja zawiera blok danych.

Kluczowe pojęcia dotyczące przechowywania danych

Oracle RAC opiera się na architekturze dysku rozproszonego. Pliki bazy danych, pliki kontrolne i dzienniki ponownego wykonywania online bazy danych muszą być dostępne dla każdego węzła w klastrze. Istnieje wiele sposobów konfigurowania współdzielonej pamięci masowej, w tym dyski podłączone bezpośrednio, sieci SAN (Storage Area Networks), pamięć masowa z dołączonym sieciowym (NAS) i Oracle ASM. Dwa najpopularniejsze to OCFS i ASM. Oracle Cluster File System (OCFS) to współużytkowany system plików zaprojektowany specjalnie dla Oracle RAC. OCFS eliminuje konieczność podłączania plików bazy danych Oracle do dysków logicznych i umożliwia wszystkim węzłom współużytkowanie jednego urządzenia Oracle Home ASM, RAW. Oracle ASM to zalecane przez firmę Oracle rozwiązanie do zarządzania pamięcią masową, które stanowi alternatywę dla konwencjonalnych menedżerów woluminów, systemów plików i urządzeń surowych. Oracle ASM zapewnia warstwę wirtualizacji między bazą danych a pamięcią masową. Traktuje wiele dysków jako pojedynczą grupę dysków i umożliwia dynamiczne dodawanie lub usuwanie dysków przy jednoczesnym utrzymywaniu baz danych online.

Dla Galera nie ma potrzeby budowania wyrafinowanej współdzielonej pamięci dyskowej, ponieważ każdy węzeł ma swoją pełną kopię danych. Jednak dobrą praktyką jest zapewnienie niezawodności przechowywania dzięki pamięci podręcznej zapisu podtrzymywanej bateryjnie.

Komunikacja i pamięć podręczna węzłów klastra

Oracle Real Application Clusters ma architekturę współdzielonej pamięci podręcznej, wykorzystuje infrastrukturę Oracle Grid, aby umożliwić współdzielenie zasobów serwera i pamięci masowej. Komunikacja między węzłami jest krytycznym aspektem integralności klastra. Każdy węzeł musi mieć co najmniej dwie karty sieciowe lub karty interfejsu sieciowego:jedną dla interfejsu sieci publicznej i jedną dla połączenia międzysieciowego. Każdy węzeł klastra jest połączony ze wszystkimi innymi węzłami za pośrednictwem prywatnej szybkiej sieci, znanej również jako połączenie klastra.

Sieć prywatna jest zwykle tworzona przy użyciu Gigabit Ethernet, ale w przypadku środowisk o dużym natężeniu ruchu wielu dostawców oferuje rozwiązania o niskich opóźnieniach i dużej przepustowości przeznaczone dla Oracle RAC. Linux rozszerza również sposób łączenia wielu fizycznych kart sieciowych w jedną wirtualną kartę sieciową, aby zapewnić zwiększoną przepustowość i dostępność.

Chociaż domyślnym podejściem do łączenia węzłów Galera jest użycie jednej karty sieciowej na host, możesz mieć więcej niż jedną kartę. ClusterControl może pomóc w takiej konfiguracji. Główną różnicą jest wymagana przepustowość łącza. Oracle RAC przesyła bloki danych między instancjami, więc obciąża połączenie międzysieciowe większym obciążeniem w porównaniu z zestawami zapisu Galera (które składają się z listy operacji).

Dzięki funkcji Redundant Interconnect Usage w RAC można zidentyfikować wiele interfejsów do użytku w sieci klastra prywatnego bez konieczności korzystania z łączenia lub innych technologii. Ta funkcjonalność jest dostępna od Oracle Database 11gR2. Jeśli używasz funkcji nadmiernego połączenia Oracle Clusterware, musisz użyć adresów IPv4 dla interfejsów (UDP jest ustawieniem domyślnym).

Aby zarządzać wysoką dostępnością, każdemu węzłowi klastra przypisywany jest wirtualny adres IP (VIP). W przypadku awarii węzła, adres IP uszkodzonego węzła można ponownie przypisać do działającego węzła, aby umożliwić aplikacjom dostęp do bazy danych przez ten sam adres IP.

Technologia Cache Fusion firmy Oracle wymaga zaawansowanej konfiguracji sieci, aby połączyć pamięć fizyczną w każdym hoście w jedną pamięć podręczną. Oracle Cache Fusion zapewnia dostęp do danych przechowywanych w pamięci podręcznej jednej instancji Oracle przez każdą inną instancję, przenosząc je przez sieć prywatną. Chroni również integralność danych i spójność pamięci podręcznej, przesyłając informacje o blokowaniu i dodatkowej synchronizacji poza węzły klastra.

Oprócz opisanej konfiguracji sieci możesz ustawić pojedynczy adres bazy danych dla swojej aplikacji — pojedynczą nazwę dostępu klienta (SCAN). Głównym celem SCAN jest zapewnienie łatwości zarządzania połączeniami. Na przykład możesz dodać nowe węzły do ​​klastra bez zmiany parametrów połączenia klienta. Ta funkcja jest spowodowana tym, że Oracle automatycznie rozsyła żądania odpowiednio na podstawie adresów IP SCAN, które wskazują na odpowiednie adresy VIP. Odbiorniki skanowania tworzą pomost między klientami a bazowymi lokalnymi słuchaczami, które są zależne od VIP.

W przypadku Galera Cluster odpowiednikiem SCAN byłoby dodanie serwera proxy bazy danych przed węzłami Galera. Serwer proxy byłby pojedynczym punktem kontaktowym dla aplikacji, może umieszczać na czarnej liście nieudane węzły i kierować zapytania do sprawnych węzłów. Sam serwer proxy może być redundantny dzięki Keepalved i Virtual IP.

Przełączanie awaryjne i odzyskiwanie danych

Główna różnica między Oracle RAC a MySQL Galera Cluster polega na tym, że Galera nie ma współdzielonej architektury. Zamiast dysków współdzielonych Galera wykorzystuje replikację opartą na certyfikacji z komunikacją grupową i porządkowaniem transakcji w celu uzyskania replikacji synchronicznej. Klaster bazy danych powinien być w stanie przetrwać utratę węzła, chociaż osiąga się to na różne sposoby. W przypadku Galery krytycznym aspektem jest liczba węzłów, Galera wymaga kworum, aby działać. Klaster z trzema węzłami może przetrwać awarię jednego węzła. Dzięki większej liczbie węzłów w klastrze Twoja dostępność wzrośnie. Oracle RAC nie wymaga kworum do działania po awarii węzła. Dzieje się tak dzięki dostępowi do rozproszonej pamięci masowej, która utrzymuje spójne informacje o stanie klastra. Jednak przechowywanie danych może być potencjalnym punktem awarii w planie wysokiej dostępności. Chociaż rozmieszczenie węzłów klastra Galera w centrach danych geolokalizacyjnych jest dość prostym zadaniem, nie byłoby to takie proste w przypadku RAC. Oracle RAC wymaga dodatkowego, zaawansowanego dublowania dysków, jednak podstawowy RAID, taki jak nadmiarowość, można osiągnąć wewnątrz grupy dysków ASM.

Schematy blokowania

W bazie danych jednego użytkownika użytkownik może zmieniać dane bez obaw o inne sesje modyfikujące te same dane w tym samym czasie. Jednak w wielowęzłowym środowisku bazy danych z wieloma użytkownikami staje się to trudniejsze. Baza danych dla wielu użytkowników musi zawierać następujące elementy:

• współbieżność danych - pewność, że użytkownicy mogą uzyskać dostęp do danych w tym samym czasie,
• spójność danych - pewność, że każdy użytkownik widzi spójny widok danych.

Instancje klastra wymagają trzech głównych typów blokowania współbieżności:

• Zbieżność danych odczytuje w różnych instancjach,
• Współbieżność danych odczytuje i zapisuje w różnych instancjach,
• Zbieżność danych zapisuje w różnych instancjach.

Oracle pozwala wybrać politykę blokowania, pesymistyczną lub optymistyczną, w zależności od wymagań. Aby uzyskać blokowanie współbieżności, RAC ma dwa dodatkowe bufory. Są to Global Cache Service (GCS) i Global Enqueue Service (GES). Te dwie usługi obejmują proces Cache Fusion, transfery zasobów i eskalację zasobów między instancjami. GES obejmuje blokady pamięci podręcznej, blokady słownika, blokady transakcji i blokady tabel. GCS utrzymuje tryby blokowania i transfery bloków między instancjami.

W klastrze Galera każdy węzeł ma swoją pamięć masową i bufory. Gdy transakcja jest uruchamiana, zaangażowane są zasoby bazy danych lokalne dla tego węzła. Podczas zatwierdzania operacje, które są częścią tej transakcji, są transmitowane jako część zestawu zapisu do reszty grupy. Ponieważ wszystkie węzły mają ten sam stan, zestaw zapisu albo powiedzie się na wszystkich węzłach, albo zawiedzie na wszystkich węzłach.

Galera Cluster używa na poziomie klastra optymistycznej kontroli współbieżności, która może pojawiać się w transakcjach skutkujących przerwaniem COMMIT. Pierwsze zatwierdzenie wygrywa. Gdy na poziomie klastra występują aborcje, Galera Cluster wyświetla błąd zakleszczenia. Może to mieć wpływ na architekturę aplikacji lub nie. Duża liczba wierszy do replikacji w pojedynczej transakcji wpłynęłaby na odpowiedzi węzłów, chociaż istnieją techniki pozwalające uniknąć takiego zachowania.

Wymagania dotyczące sprzętu i oprogramowania

Konfiguracja sprzętu obu klastrów nie wymaga dużych zasobów. Minimalna konfiguracja klastra Oracle RAC byłaby spełniona przez dwa serwery z dwoma procesorami, pamięcią fizyczną co najmniej 1,5 GB pamięci RAM, ilością przestrzeni wymiany równą ilości pamięci RAM i dwiema kartami sieciowymi Gigabit Ethernet. Minimalna konfiguracja węzłów Galera to trzy węzły (jeden z nich może być arbitrem, gardb), każdy z jednordzeniowym procesorem 1GHz, 512 MB pamięci RAM, kartą sieciową 100 Mb/s. Chociaż są to minimum, możemy śmiało powiedzieć, że w obu przypadkach prawdopodobnie chciałbyś mieć więcej zasobów dla swojego systemu produkcyjnego.

Każdy węzeł przechowuje oprogramowanie, więc będziesz musiał przygotować kilka gigabajtów swojej pamięci. Zarówno Oracle, jak i Galera mogą indywidualnie łatać węzły, usuwając je pojedynczo. Ta krocząca poprawka pozwala uniknąć całkowitego wyłączenia aplikacji, ponieważ zawsze dostępne są węzły bazy danych do obsługi ruchu.

Należy wspomnieć, że produkcyjny klaster Galera może z łatwością działać na maszynach wirtualnych lub w podstawowym systemie bare metal, podczas gdy RAC wymaga inwestycji w zaawansowaną współdzieloną pamięć masową i komunikację światłowodową.

Monitorowanie i zarządzanie

Oracle Enterprise Manager to preferowane podejście do monitorowania Oracle RAC i Oracle Clusterware. Oracle Enterprise Manager to ujednolicony system zarządzania oparty na sieci Web firmy Oracle, służący do monitorowania i administrowania środowiskiem bazy danych. Jest częścią licencji Oracle Enterprise i powinien być zainstalowany na osobnym serwerze. Monitorowanie i zarządzanie kontrolą klastra odbywa się za pomocą kombinacji poleceń crsctl i srvctl, które są częścią plików binarnych klastra. Poniżej znajdziesz kilka przykładowych poleceń.

Sprawdzanie stanu zasobów oprogramowania klastrowego:

    crsctl status resource -t (or shorter: crsctl stat res -t)

Przykład:

$ crsctl stat res ora.test1.vip
NAME=ora.test1.vip
TYPE=ora.cluster_vip_net1.type
TARGET=ONLINE
STATE=ONLINE on test1

Sprawdź stan stosu Oracle Clusterware:

    crsctl check cluster

Przykład:

$ crsctl check cluster -all
*****************************************************************
node1:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
*****************************************************************
node2:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Sprawdź stan usług Oracle High Availability Services i stosu Oracle Clusterware na serwerze lokalnym:

    crsctl check crs

Przykład:

$ crsctl check crs
CRS-4638: Oracle High Availablity Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Zatrzymaj usługi Oracle High Availability Services na serwerze lokalnym.

    crsctl stop has

Zatrzymaj usługi Oracle High Availability Services na serwerze lokalnym.

    crsctl start has

Wyświetla stan aplikacji węzła:

    srvctl status nodeapps

Wyświetla informacje o konfiguracji dla wszystkich VIP-ów SCAN

    srvctl config scan

Przykład:

srvctl config scan -scannumber 1
SCAN name: testscan, Network: 1
Subnet IPv4: 192.51.100.1/203.0.113.46/eth0, static
Subnet IPv6: 
SCAN 1 IPv4 VIP: 192.51.100.195
SCAN VIP is enabled.
SCAN VIP is individually enabled on nodes:
SCAN VIP is individually disabled on nodes:

Narzędzie Cluster Verification Utility (CVU) przeprowadza kontrole systemu w ramach przygotowań do instalacji, aktualizacji poprawek lub innych zmian w systemie:

    cluvfy comp ocr

Przykład:

Verifying OCR integrity
Checking OCR integrity...
Checking the absence of a non-clustered configurationl...
All nodes free of non-clustered, local-only configurations
ASM Running check passed. ASM is running on all specified nodes
Checking OCR config file “/etc/oracle/ocr.loc"...
OCR config file “/etc/oracle/ocr.loc" check successful
Disk group for ocr location “+DATA" available on all the nodes
NOTE:
This check does not verify the integrity of the OCR contents. Execute ‘ocrcheck' as a privileged user to verify the contents of OCR.
OCR integrity check passed
Verification of OCR integrity was successful.

Węzły Galera i klaster wymagają, aby interfejs API wsrep zgłaszał kilka stanów, co jest ujawniane. Obecnie dostępne są 34 dedykowane zmienne stanu, które można wyświetlić za pomocą instrukcji SHOW STATUS.

mysql> SHOW STATUS LIKE 'wsrep_%';

Administracja MySQL Galera Cluster pod wieloma względami jest bardzo podobna. Istnieje tylko kilka wyjątków, takich jak ładowanie początkowe klastra z węzła początkowego lub odzyskiwanie węzłów za pomocą operacji SST lub IST.

Klaster ładowania początkowego:

$ service mysql bootstrap # sysvinit
$ service mysql start --wsrep-new-cluster # sysvinit
$ galera_new_cluster # systemd
$ mysqld_safe --wsrep-new-cluster # command line

Równoważnym internetowym, gotowym do użycia rozwiązaniem do zarządzania i monitorowania Galera Cluster jest ClusterControl. Zapewnia interfejs sieciowy do wdrażania klastrów, monitoruje kluczowe metryki, zapewnia doradców bazy danych i zajmuje się zadaniami zarządzania, takimi jak tworzenie kopii zapasowych i przywracanie, automatyczne łatanie, szyfrowanie ruchu i zarządzanie dostępnością.

Ograniczenia dotyczące obciążenia

Oracle dostarcza technologię SCAN, której brakowało w klastrze Galera. Zaletą SCAN jest to, że informacje o połączeniu klienta nie muszą się zmieniać, jeśli dodasz lub usuniesz węzły lub bazy danych w klastrze. Podczas używania SCAN baza danych Oracle losowo łączy się z jednym z dostępnych detektorów SCAN (zazwyczaj trzema) w sposób okrężny i równoważy połączenia między nimi. Można skonfigurować dwa rodzaje równoważenia obciążenia:po stronie klienta, równoważenie obciążenia w czasie połączenia oraz po stronie serwera, równoważenie obciążenia w czasie wykonywania. Chociaż w samym klastrze Galera nie ma nic podobnego, tę samą funkcjonalność można rozwiązać za pomocą dodatkowego oprogramowania, takiego jak ProxySQL, HAProxy, Maxscale w połączeniu z Keepalived.

Jeśli chodzi o projektowanie obciążenia aplikacji dla klastra Galera, należy unikać konfliktów aktualizacji w tym samym wierszu, ponieważ prowadzi to do zakleszczeń w całym klastrze. Unikaj zbiorczych wstawek lub aktualizacji, ponieważ mogą one być większe niż maksymalny dozwolony zestaw zapisów. Może to również spowodować zastoje klastra.

Projektując Oracle HA z RAC, musisz pamiętać, że RAC chroni tylko przed awarią serwera, a także musisz dublować pamięć masową i mieć nadmiarowość sieci. Nowoczesne aplikacje internetowe wymagają dostępu do usług danych niezależnych od lokalizacji, a ze względu na ograniczenia architektury pamięci masowej RAC może to być trudne do osiągnięcia. Musisz także poświęcić znaczną ilość czasu na zdobycie odpowiedniej wiedzy do zarządzania środowiskiem; to długi proces. Po stronie obciążenia aplikacji istnieją pewne wady. Dystrybucja oddzielnych operacji odczytu lub zapisu na tym samym zestawie danych nie jest optymalna, ponieważ opóźnienie jest dodawane przez dodatkową wymianę danych międzywęzłowych. Rzeczy takie jak partycjonowanie, pamięć podręczna sekwencji i operacje sortowania powinny zostać sprawdzone przed migracją do RAC.

Nadmiarowość w wielu centrach danych

Zgodnie z dokumentacją Oracle, maksymalna odległość między dwiema skrzynkami połączonymi punkt-punkt i biegnącymi synchronicznie może wynosić tylko 10 km. Za pomocą specjalistycznych urządzeń odległość tę można zwiększyć do 100 km.

Galera Cluster jest dobrze znany ze swoich możliwości replikacji w wielu centrach danych. Posiada bogate wsparcie dla ustawień sieci Wider Area Networks. Można go skonfigurować pod kątem dużych opóźnień w sieci, wykonując pomiary czasu podróży w obie strony (RTT) między węzłami klastra i dostosowując niezbędne parametry. Parametry wsrep_provider_options umożliwiają skonfigurowanie ustawień, takich jak podejrzany_czas, interaktywny_czas, przyłączenie_retrans_timouts i wiele innych.

Korzystanie z Galery i RAC w chmurze

Zgodnie z notatką Oracle www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf żadna chmura innej firmy nie spełnia obecnie wymagań Oracle dotyczących natywnej udostępnianej pamięci masowej. „Natywny” w tym kontekście oznacza, że ​​dostawca chmury musi obsługiwać współdzieloną pamięć masową w ramach swojej infrastruktury zgodnie z polityką asysty technicznej Oracle.

Dzięki architekturze niczego współdzielonego, która nie jest powiązana z wyrafinowanym rozwiązaniem pamięci masowej, klaster Galera można łatwo wdrożyć w środowisku chmury. Rzeczy takie jak:

• zoptymalizowany protokół sieciowy,
• replikacja z uwzględnieniem topologii,
• szyfrowanie ruchu,
• wykrywanie i automatyczne usuwanie zawodnych węzłów,

sprawia, że ​​proces migracji do chmury jest bardziej niezawodny.

Licencje i ukryte koszty

Licencjonowanie Oracle to złożony temat i wymagałby osobnego artykułu na blogu. Czynnik skupienia sprawia, że ​​jest to jeszcze trudniejsze. Koszt rośnie, ponieważ musimy dodać kilka opcji licencji na kompletne rozwiązanie RAC. Tutaj chcemy tylko podkreślić, czego się spodziewać i gdzie znaleźć więcej informacji.

RAC jest funkcją licencji Oracle Enterprise Edition. Licencja Oracle Enterprise jest podzielona na dwa typy:na nazwanego użytkownika i na procesor. Jeśli rozważasz wersję Enterprise Edition z licencją na rdzeń, koszt pojedynczego rdzenia wynosi RAC 23 000 USD + Oracle DB EE 47 500 USD, a nadal musisz dodać ~ 22% opłaty za wsparcie. Chcielibyśmy odnieść się do świetnego bloga na temat cen, który można znaleźć na https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba obliczył cenę czterowęzłowego rozwiązania Oracle RAC. Całkowita kwota wyniosła 902,400 USD plus dodatkowe 595 584 USD za trzyletnią konserwację bazy danych i nie obejmuje ona funkcji takich jak partycjonowanie lub baza danych w pamięci, a wszystko to z 60% rabatem Oracle.

Galera Cluster to rozwiązanie typu open source, które każdy może uruchomić za darmo. Subskrypcje są dostępne dla wdrożeń produkcyjnych, które wymagają wsparcia dostawcy. Dobre obliczenia TCO można znaleźć na https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Wniosek

Chociaż istnieją znaczne różnice w architekturze, oba klastry podzielają główne zasady i mogą osiągnąć podobne cele. Produkt Oracle dla przedsiębiorstw zawiera wszystko po wyjęciu z pudełka (i ma swoją cenę). Przy koszcie w zakresie>1 mln USD, jak widać powyżej, jest to rozwiązanie z najwyższej półki, na które wielu przedsiębiorstw nie byłoby stać. Galera Cluster można opisać jako przyzwoite rozwiązanie wysokiej dostępności dla mas. W niektórych przypadkach Galera może być bardzo dobrą alternatywą dla Oracle RAC. Jedną wadą jest to, że musisz zbudować własny stos, chociaż można to całkowicie zautomatyzować dzięki ClusterControl. Chętnie poznamy Twoją opinię na ten temat.