Oracle RAC HA-oplossing vergelijken met Galera Cluster voor MySQL of MariaDB

Het bedrijfsleven heeft voortdurend de wens gehad om inzichten uit informatie te halen om betrouwbare, slimmere, realtime, op feiten gebaseerde beslissingen te nemen. Aangezien bedrijven meer afhankelijk zijn van gegevens en databases, vormen informatie en gegevensverwerking de kern van veel bedrijfsactiviteiten en zakelijke beslissingen. Het vertrouwen in de database is totaal. Geen van de dagelijkse bedrijfsservices kan draaien zonder de onderliggende databaseplatforms. Als gevolg hiervan is de noodzaak van schaalbaarheid en prestaties van databasesysteemsoftware belangrijker dan ooit. De belangrijkste voordelen van het geclusterde databasesysteem zijn schaalbaarheid en hoge beschikbaarheid. In deze blog proberen we Oracle RAC en Galera Cluster te vergelijken in het licht van deze twee aspecten. Real Application Clusters (RAC) is de eersteklas oplossing van Oracle voor het clusteren van Oracle-databases en biedt hoge beschikbaarheid en schaalbaarheid. Galera Cluster is de meest populaire clustertechnologie voor MySQL en MariaDB.

Architectuuroverzicht

Oracle RAC gebruikt Oracle Clusterware-software om meerdere servers te binden. Oracle Clusterware is een oplossing voor clusterbeheer die is geïntegreerd met Oracle Database, maar kan ook worden gebruikt met andere services, niet alleen de database. De Oracle Clusterware is aanvullende software die is geïnstalleerd op servers met hetzelfde besturingssysteem, waarmee de servers aan elkaar kunnen worden gekoppeld om te werken alsof ze één server zijn.

Oracle Clusterware houdt de instance in de gaten en start deze automatisch opnieuw op als er een crash optreedt. Als uw toepassing goed is ontworpen, ondervindt u mogelijk geen onderbreking van de service. Alleen een groep sessies (de sessies die zijn verbonden met de mislukte instantie) wordt beïnvloed door de fout. De black-out kan efficiënt worden gemaskeerd voor de eindgebruiker met behulp van geavanceerde RAC-functies zoals Fast Application Notification en de Fast Connection Failover van de Oracle-client. Oracle Clusterware regelt het lidmaatschap van knooppunten en voorkomt split-brain-symptomen waarbij twee of meer instanties proberen de instantie te besturen.

Galera Cluster is een synchrone actief-actieve databaseclusteringstechnologie voor MySQL en MariaDB. Galera Cluster verschilt van wat bekend staat als Oracle's MySQL Cluster - NDB. MariaDB-cluster is gebaseerd op de multi-master replicatie-plug-in die wordt geleverd door Codership. Sinds versie 5.5 is de Galera-plug-in (wsrep API) een integraal onderdeel van MariaDB. Percona XtraDB Cluster (PXC) is ook gebaseerd op de Galera-plug-in. De architectuur van de Galera-plug-in berust op drie kernlagen:certificering, replicatie en raamwerk voor groepscommunicatie. Certificatielaag bereidt de schrijfsets voor en voert de certificatiecontroles daarop uit, zodat ze kunnen worden toegepast. Replicatielaag beheert het replicatieprotocol en biedt de totale bestelmogelijkheid. Group Communication Framework implementeert een plug-in architectuur waarmee andere systemen verbinding kunnen maken via gcomm back-end schema.

Om de status in het hele cluster identiek te houden, gebruikt de wsrep-API een Global Transaction ID. De unieke GTID-identificatie wordt gemaakt en gekoppeld aan elke transactie die is vastgelegd op het databaseknooppunt. In Oracle RAC delen verschillende database-instances toegang tot bronnen zoals gegevensblokken in de buffercache om gegevensblokken in de wachtrij te plaatsen. Toegang tot de gedeelde bronnen tussen RAC-instanties moet worden gecoördineerd om conflicten te voorkomen. Om gedeelde toegang tot deze bronnen te organiseren, houdt de gedistribueerde cache informatie bij zoals de gegevensblok-ID, welke RAC-instantie de huidige versie van dit gegevensblok bevat en de vergrendelingsmodus waarin elke instantie het gegevensblok bevat.

Sleutelconcepten voor gegevensopslag

Oracle RAC vertrouwt op een gedistribueerde schijfarchitectuur. De databasebestanden, controlebestanden en online redo-logboeken voor de database moeten toegankelijk zijn voor elk knooppunt in het cluster. Er zijn verschillende manieren om gedeelde opslag te configureren, waaronder direct aangesloten schijven, Storage Area Networks (SAN) en Network Attached Storage (NAS) en Oracle ASM. De twee meest populaire zijn OCFS en ASM. Oracle Cluster File System (OCFS) is een gedeeld bestandssysteem dat speciaal is ontworpen voor Oracle RAC. OCFS elimineert de vereiste dat Oracle-databasebestanden moeten worden aangesloten op logische stations en stelt alle knooppunten in staat om één Oracle Home ASM, RAW-apparaat te delen. Oracle ASM is Oracle's aanbevolen opslagbeheeroplossing die een alternatief biedt voor conventionele volumemanagers, bestandssystemen en onbewerkte apparaten. De Oracle ASM zorgt voor een virtualisatielaag tussen de database en de storage. Het behandelt meerdere schijven als een enkele schijfgroep en stelt u in staat dynamisch schijven toe te voegen of te verwijderen terwijl u databases online onderhoudt.

Het is niet nodig om geavanceerde gedeelde schijfopslag voor Galera te bouwen, aangezien elk knooppunt zijn volledige gegevenskopie heeft. Het is echter een goede gewoonte om de opslag betrouwbaar te maken met schrijfcaches met batterijvoeding.

Communicatie en cache van clusterknooppunten

Oracle Real Application Clusters heeft een gedeelde cache-architectuur en maakt gebruik van Oracle Grid Infrastructure om het delen van server- en opslagbronnen mogelijk te maken. Communicatie tussen knooppunten is het kritieke aspect van clusterintegriteit. Elk knooppunt moet ten minste twee netwerkadapters of netwerkinterfacekaarten hebben:één voor de openbare netwerkinterface en één voor de interconnect. Elk clusterknooppunt is verbonden met alle andere knooppunten via een particulier hogesnelheidsnetwerk, ook wel de clusterinterconnect genoemd.

Het privénetwerk wordt meestal gevormd met Gigabit Ethernet, maar voor omgevingen met een hoog volume bieden veel leveranciers oplossingen met lage latentie en hoge bandbreedte die zijn ontworpen voor Oracle RAC. Linux breidt ook een manier uit om meerdere fysieke NIC's te koppelen in een enkele virtuele NIC om meer bandbreedte en beschikbaarheid te bieden.

Hoewel de standaardbenadering voor het verbinden van Galera-knooppunten het gebruik van één NIC per host is, kunt u meer dan één kaart hebben. ClusterControl kan u helpen bij een dergelijke instelling. Het belangrijkste verschil is de vereiste bandbreedte op de interconnect. Oracle RAC verzendt gegevensblokken tussen instanties, dus het belast de interconnect zwaarder in vergelijking met Galera-schrijfsets (die uit een lijst met bewerkingen bestaan).

Met Redundant Interconnect Usage in RAC kunt u meerdere interfaces identificeren om te gebruiken voor het private clusternetwerk, zonder dat u bonding of andere technologieën hoeft te gebruiken. Deze functionaliteit is beschikbaar vanaf Oracle Database 11gR2. Als u de Oracle Clusterware excessieve interconnect-functie gebruikt, moet u IPv4-adressen gebruiken voor de interfaces (UDP is een standaard).

Om hoge beschikbaarheid te beheren, wordt aan elk clusterknooppunt een virtueel IP-adres (VIP) toegewezen. In het geval van een storing van het knooppunt, kan het IP-adres van het defecte knooppunt opnieuw worden toegewezen aan een overgebleven knooppunt, zodat toepassingen de database via hetzelfde IP-adres kunnen blijven bereiken.

Een geavanceerde netwerkconfiguratie is nodig voor Oracle's Cache Fusion-technologie om het fysieke geheugen in elke host in een enkele cache te koppelen. Oracle Cache Fusion biedt gegevens die zijn opgeslagen in de cache van één Oracle-instance die door een andere instance kan worden geopend door deze over het privénetwerk te transporteren. Het beschermt ook de gegevensintegriteit en de cachecoherentie door vergrendelings- en aanvullende synchronisatie-informatie buiten de clusterknooppunten te verzenden.

Bovenop de beschreven netwerkconfiguratie kunt u een enkel databaseadres voor uw toepassing instellen - Single Client Access Name (SCAN). Het primaire doel van SCAN is om het verbindingsbeheer te vergemakkelijken. U kunt bijvoorbeeld nieuwe knooppunten aan het cluster toevoegen zonder uw clientverbindingsreeks te wijzigen. Deze functionaliteit is omdat Oracle verzoeken automatisch dienovereenkomstig distribueert op basis van de SCAN-IP's die naar de onderliggende VIP's verwijzen. Scan-luisteraars vormen de brug tussen clients en de onderliggende lokale luisteraars die VIP-afhankelijk zijn.

Voor Galera Cluster zou het equivalent van SCAN het toevoegen van een databaseproxy voor de Galera-knooppunten zijn. De proxy zou een enkel aanspreekpunt zijn voor applicaties, het kan mislukte knooppunten op de zwarte lijst zetten en query's naar gezonde knooppunten routeren. De proxy zelf kan overbodig worden gemaakt met Keepalived en Virtual IP.

Failover en gegevensherstel

Het belangrijkste verschil tussen Oracle RAC en MySQL Galera Cluster is dat Galera een gedeelde niets-architectuur is. In plaats van gedeelde schijven gebruikt Galera op certificering gebaseerde replicatie met groepscommunicatie en transactiebestelling om synchrone replicatie te bereiken. Een databasecluster moet een verlies van een knoop punt kunnen overleven, hoewel dit op verschillende manieren wordt bereikt. In het geval van Galera is het kritische aspect het aantal nodes, Galera heeft een quorum nodig om operationeel te blijven. Een cluster met drie knooppunten kan de crash van één knooppunt overleven. Met meer nodes in uw cluster, groeit uw beschikbaarheid. Oracle RAC vereist geen quorum om operationeel te blijven na een node-crash. Het is vanwege de toegang tot gedistribueerde opslag die consistente informatie over de clusterstatus bewaart. Uw gegevensopslag kan echter een mogelijk storingspunt zijn in uw hoge-beschikbaarheidsabonnement. Hoewel het een redelijk eenvoudige taak is om Galera-clusterknooppunten te verspreiden over geolocatiedatacenters, zou het met RAC niet zo eenvoudig zijn. Oracle RAC vereist extra high-end schijfspiegeling, maar basis-RAID-achtige redundantie kan worden bereikt binnen een ASM-schijfgroep.

Vergrendelschema's

In een database voor één gebruiker kan een gebruiker gegevens wijzigen zonder zich zorgen te hoeven maken over andere sessies die dezelfde gegevens tegelijkertijd wijzigen. In een multi-user database multi-node-omgeving wordt dit echter lastiger. Een database voor meerdere gebruikers moet het volgende bieden:

• gelijktijdigheid van gegevens - de zekerheid dat gebruikers tegelijkertijd toegang hebben tot gegevens,
• gegevensconsistentie - de zekerheid dat elke gebruiker een consistent beeld van de gegevens ziet.

Clusterinstanties vereisen drie hoofdtypen gelijktijdigheidsvergrendeling:

• Gegevensgelijktijdigheid leest op verschillende instanties,
• Gegevensgelijktijdigheid leest en schrijft op verschillende instanties,
• Gegevens gelijktijdigheid schrijft op verschillende instanties.

Oracle laat u het beleid voor vergrendeling kiezen, pessimistisch of optimistisch, afhankelijk van uw vereisten. Om gelijktijdigheidsvergrendeling te verkrijgen, heeft RAC twee extra buffers. Dit zijn Global Cache Service (GCS) en Global Enqueue Service (GES). Deze twee services hebben betrekking op het Cache Fusion-proces, resourceoverdrachten en resource-escalaties tussen de instanties. GES omvat cachevergrendelingen, woordenboekvergrendelingen, transactievergrendelingen en tafelvergrendelingen. GCS handhaaft de blokmodi en blokoverdrachten tussen de instanties.

In het Galera-cluster heeft elk knooppunt zijn eigen opslag en buffers. Wanneer een transactie wordt gestart, zijn databasebronnen die lokaal zijn voor dat knooppunt erbij betrokken. Bij commit worden de bewerkingen die deel uitmaken van die transactie uitgezonden als onderdeel van een schrijfset naar de rest van de groep. Aangezien alle knooppunten dezelfde status hebben, zal het schrijven op alle knooppunten succesvol zijn of op alle knooppunten mislukken.

Galera Cluster gebruikt op clusterniveau optimistische gelijktijdigheidscontrole, die kan voorkomen in transacties die resulteren in het afbreken van een COMMIT. De eerste inzet wint. Wanneer aborts plaatsvinden op clusterniveau, geeft Galera Cluster een deadlock-fout. Dit kan al dan niet van invloed zijn op uw toepassingsarchitectuur. Een groot aantal rijen dat in een enkele transactie moet worden gerepliceerd, zou van invloed zijn op de reacties van knooppunten, hoewel er technieken zijn om dergelijk gedrag te voorkomen.

Hardware- en softwarevereisten

Het configureren van beide clusterhardware vereist geen krachtige bronnen. Minimale Oracle RAC-clusterconfiguratie zou worden voldaan door twee servers met twee CPU's, fysiek geheugen van ten minste 1,5 GB RAM, een hoeveelheid swapruimte die gelijk is aan de hoeveelheid RAM en twee Gigabit Ethernet NIC's. De minimale knooppuntconfiguratie van Galera is drie knooppunten (een van de knooppunten kan een arbiter zijn, gardb), elk met 1GHz single-core CPU, 512 MB RAM, 100 Mbps netwerkkaart. Hoewel dit het minimum is, kunnen we gerust stellen dat u in beide gevallen waarschijnlijk meer middelen voor uw productiesysteem zou willen hebben.

Elk knooppunt slaat software op, dus u zou enkele gigabytes aan opslagruimte moeten voorbereiden. Oracle en Galera hebben beide de mogelijkheid om de nodes afzonderlijk te patchen door ze één voor één te verwijderen. Deze rolling patch vermijdt een volledige uitval van de applicatie, omdat er altijd databaseknooppunten beschikbaar zijn om het verkeer af te handelen.

Wat belangrijk is om te vermelden, is dat een Galera-productiecluster gemakkelijk op VM's of standaard bare-metal kan draaien, terwijl RAC zou moeten investeren in geavanceerde gedeelde opslag en glasvezelcommunicatie.

Bewaking en beheer

Oracle Enterprise Manager is de favoriete benadering voor het bewaken van Oracle RAC en Oracle Clusterware. Oracle Enterprise Manager is een op Oracle web gebaseerd uniform beheersysteem voor het bewaken en beheren van uw databaseomgeving. Het maakt deel uit van de Oracle Enterprise License en moet op een aparte server worden geïnstalleerd. Clustercontrole-bewaking en -beheer vindt plaats via combinatie op crsctl- en srvctl-opdrachten die deel uitmaken van clusterbinaire bestanden. Hieronder vind je een aantal voorbeeldcommando's.

Statuscontrole van clusterwarebronnen:

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

Voorbeeld:

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

Controleer de status van de Oracle Clusterware-stack:

    crsctl check cluster

Voorbeeld:

$ 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

Controleer de status van Oracle High Availability Services en de Oracle Clusterware-stack op de lokale server:

    crsctl check crs

Voorbeeld:

$ 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

Stop Oracle High Availability Services op de lokale server.

    crsctl stop has

Stop Oracle High Availability Services op de lokale server.

    crsctl start has

Geeft de status van node-applicaties weer:

    srvctl status nodeapps

Geeft de configuratie-informatie weer voor alle SCAN VIP's

    srvctl config scan

Voorbeeld:

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:

De Cluster Verification Utility (CVU) voert systeemcontroles uit ter voorbereiding op installatie, patchupdates of andere systeemwijzigingen:

    cluvfy comp ocr

Voorbeeld:

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.

Galera-knooppunten en het cluster vereisen dat de wsrep-API verschillende statussen rapporteert, die zichtbaar zijn. Er zijn momenteel 34 speciale statusvariabelen die kunnen worden bekeken met de instructie SHOW STATUS.

mysql> SHOW STATUS LIKE 'wsrep_%';

Het beheer van MySQL Galera Cluster lijkt in veel opzichten erg op elkaar. Er zijn slechts enkele uitzonderingen, zoals het bootstrappen van het cluster vanaf het eerste knooppunt of het herstellen van knooppunten via SST- of IST-bewerkingen.

Bootstrapping-cluster:

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

De equivalente webgebaseerde, kant-en-klare oplossing voor het beheren en bewaken van Galera Cluster is ClusterControl. Het biedt een webgebaseerde interface om clusters te implementeren, belangrijke meetgegevens te bewaken, databaseadviseurs te bieden en beheertaken uit te voeren zoals back-up en herstel, automatische patching, verkeerscodering en beschikbaarheidsbeheer.

Beperkingen op de werkbelasting

Oracle biedt SCAN-technologie die we hebben aangetroffen in Galera Cluster. Het voordeel van SCAN is dat de verbindingsgegevens van de client niet hoeven te veranderen als u knooppunten of databases in het cluster toevoegt of verwijdert. Bij gebruik van SCAN maakt de Oracle-database willekeurig verbinding met een van de beschikbare SCAN-luisteraars (meestal drie) op een round robin-manier en balanceert de verbindingen daartussen. Er kunnen twee soorten load-balancing worden geconfigureerd:client-side, load-balancing op de verbindingstijd en aan de server-side, run-time load-balancing. Hoewel er niets vergelijkbaars is binnen het Galera-cluster zelf, kan dezelfde functionaliteit worden aangepakt met aanvullende software zoals ProxySQL, HAProxy, Maxscale in combinatie met Keepalive.

Als het gaat om het ontwerp van applicatieworkloads voor Galera Cluster, moet u conflicterende updates op dezelfde rij vermijden, omdat dit tot impasses in het cluster leidt. Vermijd bulkinvoegingen of updates, aangezien deze groter kunnen zijn dan de maximaal toegestane schrijfset. Dat kan ook clusterstallingen veroorzaken.

Als u Oracle HA met RAC ontwerpt, moet u er rekening mee houden dat RAC alleen bescherming biedt tegen serverstoringen, en dat u de opslag moet spiegelen en netwerkredundantie moet hebben. Moderne webapplicaties vereisen toegang tot locatie-onafhankelijke dataservices, en vanwege de beperkingen van de opslagarchitectuur van RAC kan het lastig zijn om dit te realiseren. U moet ook een aanzienlijke hoeveelheid tijd besteden om relevante kennis op te doen om de omgeving te beheren; het is een lang proces. Aan de kant van de applicatiebelasting zijn er enkele nadelen. Het distribueren van gescheiden lees- of schrijfbewerkingen op dezelfde dataset is niet optimaal omdat latentie wordt toegevoegd door aanvullende internode-gegevensuitwisseling. Zaken als partitionering, sequentiecache en sorteerbewerkingen moeten worden gecontroleerd voordat u naar RAC migreert.

Redundantie voor meerdere datacenters

Volgens de Oracle-documentatie kan de maximale afstand tussen twee dozen die punt-tot-punt zijn verbonden en synchroon lopen slechts 10 km zijn. Met behulp van gespecialiseerde apparaten kan deze afstand worden vergroot tot 100 km.

Galera Cluster staat bekend om zijn multi-datacenter replicatiemogelijkheden. Het heeft uitgebreide ondersteuning voor Wider Area Networks-netwerkinstellingen. Het kan worden geconfigureerd voor een hoge netwerklatentie door Round-Trip Time (RTT)-metingen uit te voeren tussen clusterknooppunten en de nodige parameters aan te passen. Met de parameters wsrep_provider_options kunt u instellingen configureren zoals suspect_timeout, interactive_timeout, join_retrans_timouts en nog veel meer.

Galera en RAC in de cloud gebruiken

Volgens Oracle-notitie www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf voldoet momenteel geen enkele cloud van derden aan de vereisten van Oracle met betrekking tot native geleverde gedeelde opslag. "Native" betekent in deze context dat de cloudprovider gedeelde opslag moet ondersteunen als onderdeel van hun infrastructuur volgens het ondersteuningsbeleid van Oracle.

Dankzij de shared niets-architectuur, die niet gebonden is aan een geavanceerde opslagoplossing, kan Galera-cluster eenvoudig worden ingezet in een cloudomgeving. Dingen zoals:

• geoptimaliseerd netwerkprotocol,
• topologiebewuste replicatie,
• verkeersversleuteling,
• detectie en automatische verwijdering van onbetrouwbare nodes,

maakt het cloudmigratieproces betrouwbaarder.

Licenties en verborgen kosten

Oracle-licenties zijn een complex onderwerp waarvoor een apart blogartikel nodig is. De clusterfactor maakt het nog moeilijker. De kosten gaan omhoog omdat we enkele opties moeten toevoegen om een ​​volledige RAC-oplossing in licentie te geven. Hier willen we alleen benadrukken wat u kunt verwachten en waar u meer informatie kunt vinden.

RAC is een functie van de Oracle Enterprise Edition-licentie. Oracle Enterprise-licenties zijn opgesplitst in twee typen, per benoemde gebruiker en per processor. Als u Enterprise Edition overweegt met een per core-licentie, dan bedragen de kosten voor één core RAC 23.000 USD + Oracle DB EE 47.500 USD, en moet u nog steeds een ondersteuningsvergoeding van ~ 22% toevoegen. We willen graag verwijzen naar een geweldige blog over prijzen die te vinden is op https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba berekende de prijs van een Oracle RAC met vier knooppunten. Het totale bedrag was 902400 USD plus 595.584 USD extra voor drie jaar DB-onderhoud, en dat is exclusief functies zoals partitionering of in-memory database, en dat alles met 60% Oracle-korting.

Galera Cluster is een open source-oplossing die iedereen gratis kan gebruiken. Er zijn abonnementen beschikbaar voor productie-implementaties waarvoor ondersteuning van leveranciers vereist is. Een goede TCO-berekening is te vinden op https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Conclusie

Hoewel er aanzienlijke verschillen zijn in architectuur, delen beide clusters de belangrijkste principes en kunnen ze vergelijkbare doelen bereiken. Oracle enterprise-product wordt geleverd met alles uit de doos (en zijn prijs). Met een kostprijs van> 1 miljoen USD zoals hierboven te zien, is het een hoogwaardige oplossing die veel ondernemingen zich niet zouden kunnen veroorloven. Galera Cluster kan worden omschreven als een degelijke oplossing met hoge beschikbaarheid voor de massa. In bepaalde gevallen zou Galera wel eens een heel goed alternatief kunnen zijn voor Oracle RAC. Een nadeel is dat je je eigen stack moet bouwen, al kan dat met ClusterControl volledig geautomatiseerd worden. We horen graag uw mening hierover.