MariaDB
 sql >> Database >  >> RDS >> MariaDB

Confronto della soluzione Oracle RAC HA con Galera Cluster per MySQL o MariaDB

Le aziende hanno sempre desiderato trarre informazioni dalle informazioni per prendere decisioni affidabili, più intelligenti, in tempo reale e basate sui fatti. Poiché le aziende fanno più affidamento su dati e database, le informazioni e l'elaborazione dei dati sono il fulcro di molte operazioni e decisioni aziendali. La fiducia nel database è totale. Nessuno dei servizi aziendali quotidiani può essere eseguito senza le piattaforme di database sottostanti. Di conseguenza, la necessità di scalabilità e prestazioni del software del sistema di database è più critica che mai. I principali vantaggi del sistema di database in cluster sono la scalabilità e l'elevata disponibilità. In questo blog cercheremo di confrontare Oracle RAC e Galera Cluster alla luce di questi due aspetti. Real Application Clusters (RAC) è la soluzione premium di Oracle per il clustering di database Oracle e offre alta disponibilità e scalabilità. Galera Cluster è la tecnologia di clustering più popolare per MySQL e MariaDB.

Panoramica dell'architettura

Oracle RAC utilizza il software Oracle Clusterware per associare più server. Oracle Clusterware è una soluzione di gestione dei cluster che si integra con Oracle Database, ma può essere utilizzata anche con altri servizi, non solo il database. Oracle Clusterware è un software aggiuntivo installato su server che eseguono lo stesso sistema operativo, che consente ai server di essere concatenati per funzionare come se fossero un unico server.

Oracle Clusterware controlla l'istanza e la riavvia automaticamente in caso di arresto anomalo. Se la tua applicazione è ben progettata, potresti non riscontrare alcuna interruzione del servizio. Solo un gruppo di sessioni (quelle connesse all'istanza non riuscita) è interessato dall'errore. Il blackout può essere mascherato in modo efficiente per l'utente finale utilizzando funzionalità RAC avanzate come Fast Application Notification e Fast Connection Failover del client Oracle. Oracle Clusterware controlla l'appartenenza al nodo e previene i sintomi del cervello diviso in cui due o più istanze tentano di controllare l'istanza.

Galera Cluster è una tecnologia di clustering di database sincrono attivo-attivo per MySQL e MariaDB. Galera Cluster è diverso da ciò che è noto come Oracle MySQL Cluster - NDB. Il cluster MariaDB si basa sul plug-in di replica multi-master fornito da Codership. Dalla versione 5.5, il plugin Galera (wsrep API) è parte integrante di MariaDB. Anche Percona XtraDB Cluster (PXC) si basa sul plugin Galera. L'architettura del plugin Galera si basa su tre livelli principali:certificazione, replica e framework di comunicazione di gruppo. Il livello di certificazione prepara i set di scrittura ed esegue i controlli di certificazione su di essi, garantendo che possano essere applicati. Il livello di replica gestisce il protocollo di replica e fornisce la capacità totale di ordinazione. Group Communication Framework implementa un'architettura plug-in che consente ad altri sistemi di connettersi tramite lo schema di back-end gcomm.

Per mantenere lo stato identico in tutto il cluster, l'API wsrep utilizza un ID transazione globale. L'identificatore univoco GTID viene creato e associato a ciascuna transazione impegnata nel nodo del database. In Oracle RAC, varie istanze di database condividono l'accesso a risorse come i blocchi di dati nella cache del buffer per accodare i blocchi di dati. L'accesso alle risorse condivise tra le istanze RAC deve essere coordinato per evitare conflitti. Per organizzare l'accesso condiviso a queste risorse, la cache distribuita conserva informazioni come l'ID blocco dati, quale istanza RAC contiene la versione corrente di questo blocco dati e la modalità di blocco in cui ogni istanza contiene il blocco dati.

Concetti chiave sull'archiviazione dei dati

Oracle RAC si basa su un'architettura disco distribuita. I file di database, i file di controllo ei log di ripristino in linea per il database devono essere accessibili a ciascun nodo del cluster. Esistono diversi modi per configurare lo storage condiviso, inclusi dischi collegati direttamente, Storage Area Networks (SAN) e Network Attached Storage (NAS) e Oracle ASM. I due più popolari sono OCFS e ASM. Oracle Cluster File System (OCFS) è un file system condiviso progettato specificamente per Oracle RAC. OCFS elimina il requisito che i file di database Oracle siano collegati alle unità logiche e consente a tutti i nodi di condividere un singolo dispositivo Oracle Home ASM, RAW. Oracle ASM è la soluzione consigliata per la gestione dello storage di Oracle che fornisce un'alternativa ai tradizionali gestori di volumi, file system e dispositivi non elaborati. Oracle ASM fornisce un livello di virtualizzazione tra il database e lo storage. Tratta più dischi come un unico gruppo di dischi e ti consente di aggiungere o rimuovere dinamicamente unità mantenendo i database online.

Non è necessario creare un sofisticato storage su disco condiviso per Galera, poiché ogni nodo ha la sua copia completa dei dati. Tuttavia, è buona norma rendere affidabile l'archiviazione con cache di scrittura con batteria tampone.

Oracle RAC, Storage cluster Replica Galera, dischi collegati ai nodi del database

Comunicazione nodi cluster e cache

Oracle Real Application Clusters ha un'architettura cache condivisa, utilizza Oracle Grid Infrastructure per consentire la condivisione di server e risorse di storage. La comunicazione tra i nodi è l'aspetto critico dell'integrità del cluster. Ogni nodo deve avere almeno due schede di rete o schede di interfaccia di rete:una per l'interfaccia di rete pubblica e una per l'interconnessione. Ciascun nodo del cluster è connesso a tutti gli altri nodi tramite una rete privata ad alta velocità, riconosciuta anche come interconnessione del cluster.

Oracle RAC, architettura di rete

La rete privata è in genere formata con Gigabit Ethernet, ma per ambienti ad alto volume, molti fornitori offrono soluzioni a bassa latenza e larghezza di banda elevata progettate per Oracle RAC. Linux estende anche un mezzo per collegare più NIC fisiche in un'unica NIC virtuale per fornire maggiore larghezza di banda e disponibilità.

Sebbene l'approccio predefinito alla connessione dei nodi Galera sia l'utilizzo di una singola scheda NIC per host, è possibile avere più di una scheda. ClusterControl può aiutarti con tale configurazione. La differenza principale è il requisito di larghezza di banda sull'interconnessione. Oracle RAC spedisce blocchi di dati tra le istanze, quindi pone un carico maggiore sull'interconnessione rispetto ai set di scrittura Galera (che consistono in un elenco di operazioni).

Con l'utilizzo dell'interconnessione ridondante in RAC, è possibile identificare più interfacce da utilizzare per la rete del cluster privato, senza la necessità di utilizzare bonding o altre tecnologie. Questa funzionalità è disponibile a partire da Oracle Database 11gR2. Se utilizzi la funzione di interconnessione eccessiva di Oracle Clusterware, devi utilizzare gli indirizzi IPv4 per le interfacce (l'UDP è un'impostazione predefinita).

Per gestire la disponibilità elevata, a ogni nodo del cluster viene assegnato un indirizzo IP virtuale (VIP). In caso di guasto del nodo, l'indirizzo IP del nodo guasto può essere riassegnato a un nodo sopravvissuto per consentire alle applicazioni di continuare a raggiungere il database tramite lo stesso indirizzo IP.

È necessaria una configurazione di rete sofisticata per la tecnologia Oracle Cache Fusion per accoppiare la memoria fisica in ciascun host in un'unica cache. Oracle Cache Fusion fornisce i dati archiviati nella cache di un'istanza Oracle a cui può accedere qualsiasi altra istanza trasportandoli attraverso la rete privata. Protegge inoltre l'integrità dei dati e la coerenza della cache trasmettendo informazioni di blocco e sincronizzazione supplementari oltre i nodi del cluster.

Oltre alla configurazione di rete descritta, puoi impostare un unico indirizzo di database per la tua applicazione:Single Client Access Name (SCAN). Lo scopo principale di SCAN è fornire facilità di gestione della connessione. Ad esempio, puoi aggiungere nuovi nodi al cluster senza modificare la stringa di connessione del client. Questa funzionalità è dovuta al fatto che Oracle distribuirà automaticamente le richieste di conseguenza in base agli IP SCAN che puntano ai VIP sottostanti. I listener di scansione fanno il ponte tra i client e i listener locali sottostanti che dipendono da VIP.

Per Galera Cluster, l'equivalente di SCAN sarebbe l'aggiunta di un proxy di database davanti ai nodi Galera. Il proxy sarebbe un unico punto di contatto per le applicazioni, può inserire nella blacklist i nodi guasti e instradare le query a nodi sani. Il proxy stesso può essere reso ridondante con Keepalived e Virtual IP.

Failover e recupero dati

La principale differenza tra Oracle RAC e MySQL Galera Cluster è che Galera non ha un'architettura condivisa. Invece dei dischi condivisi, Galera utilizza la replica basata sulla certificazione con comunicazione di gruppo e ordinamento delle transazioni per ottenere la replica sincrona. Un cluster di database dovrebbe essere in grado di sopravvivere alla perdita di un nodo, sebbene ciò sia ottenuto in modi diversi. Nel caso di Galera, l'aspetto critico è il numero di nodi, Galera richiede un quorum per rimanere operativo. Un cluster a tre nodi può sopravvivere all'arresto anomalo di un nodo. Con più nodi nel tuo cluster, la tua disponibilità aumenterà. Oracle RAC non richiede un quorum per rimanere operativo dopo un arresto anomalo del nodo. È a causa dell'accesso allo storage distribuito che mantiene informazioni coerenti sullo stato del cluster. Tuttavia, l'archiviazione dei dati potrebbe essere un potenziale punto di errore nel piano di disponibilità elevata. Sebbene sia un compito ragionevolmente semplice avere i nodi del cluster Galera distribuiti tra i data center di geolocalizzazione, non sarebbe così facile con RAC. Oracle RAC richiede un mirroring del disco di fascia alta aggiuntivo, tuttavia, è possibile ottenere una ridondanza RAID di base all'interno di un gruppo di dischi ASM.

Tipo di gruppo di dischi Livelli di mirroring supportati Livello di mirroring predefinito
Ridondanza esterna Non protetto (nessuno) Non protetto
Ridondanza normale Bidirezionale, a tre vie, non protetto (nessuno) Bidirezionale
Elevata ridondanza A tre vie A tre vie
Ridondanza flessibile Bidirezionale, a tre vie, non protetto (nessuno) Bidirezionale (di nuova creazione)
Ridondanza estesa Bidirezionale, a tre vie, non protetto (nessuno) Bidirezionale
Ridondanza del gruppo di dischi ASM

Schemi di blocco

In un database a utente singolo, un utente può modificare i dati senza preoccuparsi che altre sessioni modifichino gli stessi dati contemporaneamente. Tuttavia, in un ambiente multinodo di database multiutente, questo diventa più complicato. Un database multiutente deve fornire quanto segue:

  • Concorrenza dati:la garanzia che gli utenti possano accedere ai dati contemporaneamente
  • Coerenza dei dati:la garanzia che ogni utente veda una visualizzazione coerente dei dati.

Le istanze del cluster richiedono tre tipi principali di blocco della concorrenza:

  • La simultaneità dei dati legge su diverse istanze,
  • La simultaneità dei dati legge e scrive su diverse istanze,
  • La concorrenza dei dati scrive su istanze diverse.

Oracle ti consente di scegliere la politica per il blocco, pessimista o ottimista, a seconda delle tue esigenze. Per ottenere il blocco della concorrenza, RAC dispone di due buffer aggiuntivi. Sono Global Cache Service (GCS) e Global Enqueue Service (GES). Questi due servizi coprono il processo di Cache Fusion, i trasferimenti di risorse e le escalation di risorse tra le istanze. GES include blocchi della cache, blocchi del dizionario, blocchi delle transazioni e blocchi delle tabelle. GCS mantiene le modalità di blocco e i trasferimenti a blocchi tra le istanze.

Nel cluster Galera, ogni nodo ha il suo spazio di archiviazione e i suoi buffer. Quando viene avviata una transazione, vengono coinvolte le risorse del database locali in quel nodo. Al momento del commit, le operazioni che fanno parte di tale transazione vengono trasmesse come parte di un write-set al resto del gruppo. Poiché tutti i nodi hanno lo stesso stato, il write-set avrà esito positivo su tutti i nodi o avrà esito negativo su tutti i nodi.

Galera Cluster utilizza il controllo della concorrenza ottimistica a livello di cluster, che può apparire nelle transazioni che comportano l'interruzione di un COMMIT. Il primo impegno vince. Quando si verificano interruzioni a livello di cluster, Galera Cluster genera un errore di deadlock. Ciò può influire o meno sull'architettura dell'applicazione. Un numero elevato di righe da replicare in una singola transazione inciderebbe sulle risposte dei nodi, sebbene esistano tecniche per evitare tale comportamento.

Requisiti hardware e software

La configurazione dell'hardware di entrambi i cluster non richiede risorse potenti. La configurazione minima del cluster Oracle RAC verrebbe soddisfatta da due server con due CPU, memoria fisica di almeno 1,5 GB di RAM, una quantità di spazio di scambio pari alla quantità di RAM e due NIC Gigabit Ethernet. La configurazione minima del nodo di Galera è di tre nodi (uno dei nodi può essere un arbitro, gardb), ciascuno con CPU single-core da 1GHz, 512 MB di RAM, scheda di rete da 100 Mbps. Sebbene questi siano i minimi, possiamo tranquillamente affermare che in entrambi i casi probabilmente vorresti avere più risorse per il tuo sistema di produzione.

Ogni nodo memorizza il software, quindi è necessario preparare diversi gigabyte di spazio di archiviazione. Oracle e Galera hanno entrambi la possibilità di patchare individualmente i nodi eliminandoli uno alla volta. Questa patch in sequenza evita un'interruzione completa dell'applicazione poiché sono sempre disponibili nodi di database per gestire il traffico.

Ciò che è importante ricordare è che un cluster Galera di produzione può essere eseguito facilmente su VM o bare metal di base, mentre RAC richiederebbe investimenti in sofisticati storage condivisi e comunicazioni in fibra.

Monitoraggio e gestione

Oracle Enterprise Manager è l'approccio preferito per il monitoraggio di Oracle RAC e Oracle Clusterware. Oracle Enterprise Manager è un sistema di gestione unificato basato sul Web Oracle per il monitoraggio e l'amministrazione dell'ambiente di database. Fa parte di Oracle Enterprise License e deve essere installato su un server separato. Il monitoraggio e la gestione del controllo del cluster avviene tramite una combinazione di comandi crsctl e srvctl che fanno parte dei file binari del cluster. Di seguito puoi trovare un paio di comandi di esempio.

Controllo dello stato delle risorse del cluster:

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

Esempio:

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

Verifica lo stato dello stack Oracle Clusterware:

    crsctl check cluster

Esempio:

$ 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

Verifica lo stato di Oracle High Availability Services e dello stack Oracle Clusterware sul server locale:

    crsctl check crs

Esempio:

$ 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

Arresta Oracle High Availability Services sul server locale.

    crsctl stop has

Arresta Oracle High Availability Services sul server locale.

    crsctl start has

Visualizza lo stato delle applicazioni del nodo:

    srvctl status nodeapps

Visualizza le informazioni di configurazione per tutti gli SCAN VIP

    srvctl config scan

Esempio:

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:

L'utility di verifica del cluster (CVU) esegue i controlli del sistema in preparazione per l'installazione, gli aggiornamenti delle patch o altre modifiche al sistema:

    cluvfy comp ocr

Esempio:

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.

I nodi Galera e il cluster richiedono che l'API wsrep riporti diversi stati, che sono esposti. Ci sono attualmente 34 variabili di stato dedicate che possono essere visualizzate con l'istruzione SHOW STATUS.

mysql> SHOW STATUS LIKE 'wsrep_%';
wsrep_apply_oooe
wsrep_apply_oool
wsrep_cert_deps_distance
wsrep_cluster_conf_id
wsrep_cluster_size
wsrep_cluster_state_uuid
/> wsrep_cluster_status
wsrep_connected
wsrep_flow_control_paused
wsrep_flow_control_paused_ns
wsrep_flow_control_recv
wsrep_local_send_queue_avg
wsrep_local_state_uuid
wsrep_protocol_version
wsrep_provider_name
wsrep_provider_vendor
wsrep_provider_version
ws wsrepuid br /> wsrep_last_committed
wsrep_local_bf_aborts
wsrep_local_cert_failures
wsrep_local_commits
wsrep_local_index
wsrep_local_recv_queue
wsrep_local_recv_queue_avg
wsrep_local_replays
wsrep_local_send_queue
wsrep_ready
wsrep_received_bytes
wsrep_replicated
wsrep_replicated_bytes
wsrep_thread_count

L'amministrazione di MySQL Galera Cluster sotto molti aspetti è molto simile. Esistono solo poche eccezioni come il bootstrap del cluster dal nodo iniziale o il ripristino dei nodi tramite operazioni SST o IST.

Cluster di bootstrap:

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

La soluzione equivalente basata sul Web pronta all'uso per la gestione e il monitoraggio di Galera Cluster è ClusterControl. Fornisce un'interfaccia basata sul Web per distribuire cluster, monitorare le metriche chiave, fornire consulenti di database e occuparsi di attività di gestione come backup e ripristino, applicazione di patch automatiche, crittografia del traffico e gestione della disponibilità.

Restrizioni sul carico di lavoro

Oracle fornisce la tecnologia SCAN che abbiamo trovato mancante in Galera Cluster. Il vantaggio di SCAN è che le informazioni di connessione del client non devono essere modificate se si aggiungono o si rimuovono nodi o database nel cluster. Quando si utilizza SCAN, il database Oracle si connette in modo casuale a uno dei listener SCAN disponibili (in genere tre) in modo round robin e bilancia le connessioni tra di loro. È possibile configurare due tipi di bilanciamento del carico:lato client, bilanciamento del carico del tempo di connessione e lato server, bilanciamento del carico del tempo di esecuzione. Sebbene non ci sia nulla di simile all'interno del cluster Galera stesso, la stessa funzionalità può essere gestita con software aggiuntivo come ProxySQL, HAProxy, Maxscale combinato con Keepalived.

Quando si tratta di progettazione del carico di lavoro dell'applicazione per Galera Cluster, dovresti evitare aggiornamenti in conflitto sulla stessa riga, poiché porta a deadlock nel cluster. Evita gli inserimenti o gli aggiornamenti in blocco, poiché potrebbero essere maggiori del set di scrittura massimo consentito. Ciò potrebbe anche causare lo stallo del cluster.

Progettando Oracle HA con RAC è necessario tenere presente che RAC protegge solo dai guasti del server e che è necessario eseguire il mirroring dello storage e disporre della ridondanza della rete. Le moderne applicazioni Web richiedono l'accesso a servizi di dati indipendenti dalla posizione e, a causa delle limitazioni dell'architettura di archiviazione di RAC, può essere difficile da raggiungere. È inoltre necessario dedicare una notevole quantità di tempo per acquisire conoscenze rilevanti per la gestione dell'ambiente; è un lungo processo. Sul lato del carico di lavoro dell'applicazione, ci sono alcuni inconvenienti. La distribuzione di operazioni di lettura o scrittura separate sullo stesso set di dati non è ottimale perché la latenza viene aggiunta dallo scambio di dati internodi supplementari. Cose come il partizionamento, la cache di sequenza e le operazioni di ordinamento devono essere esaminate prima di migrare a RAC.

Ridondanza multi data center

Secondo la documentazione Oracle, la distanza massima tra due scatole collegate in modo punto a punto e funzionanti in modo sincrono può essere di soli 10 km. Utilizzando dispositivi specializzati, questa distanza può essere aumentata a 100 km.

Galera Cluster è noto per le sue capacità di replica multi-datacenter. Ha un ricco supporto per le impostazioni di rete di reti geografiche. Può essere configurato per un'elevata latenza di rete effettuando misurazioni del tempo di andata e ritorno (RTT) tra i nodi del cluster e regolando i parametri necessari. I parametri wsrep_provider_options ti consentono di configurare impostazioni come sospetto_timeout, interactive_timeout, join_retrans_timouts e molti altri.

Utilizzo di Galera e RAC in Cloud

In base alla nota Oracle www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf nessun cloud di terze parti attualmente soddisfa i requisiti Oracle relativi allo storage condiviso fornito in modo nativo. "Nativo" in questo contesto significa che il provider cloud deve supportare lo storage condiviso come parte della propria infrastruttura secondo la policy di supporto di Oracle.

Grazie alla sua architettura shared nulla, che non è legata a una sofisticata soluzione di storage, il cluster Galera può essere facilmente implementato in un ambiente cloud. Cose come:

  • protocollo di rete ottimizzato,
  • replica compatibile con la topologia,
  • Crittografia del traffico,
  • rilevamento ed eliminazione automatica di nodi inaffidabili,

rende il processo di migrazione al cloud più affidabile.

Licenze e costi nascosti

La licenza Oracle è un argomento complesso e richiederebbe un articolo di blog separato. Il fattore cluster lo rende ancora più difficile. Il costo aumenta poiché dobbiamo aggiungere alcune opzioni per concedere in licenza una soluzione RAC completa. Qui vogliamo solo evidenziare cosa aspettarci e dove trovare maggiori informazioni.

RAC è una funzionalità della licenza Oracle Enterprise Edition. La licenza Oracle Enterprise è suddivisa in due tipi, per utente designato e per processore. Se consideri Enterprise Edition con licenza per core, il costo per core singolo è RAC ​​23.000 USD + Oracle DB EE 47.500 USD e devi comunque aggiungere una tariffa di supporto di circa il 22%. Vorremmo fare riferimento a un ottimo blog sui prezzi che si trova su https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba ha calcolato il prezzo di un Oracle RAC a quattro nodi. L'importo totale era di 902.400 USD più ulteriori 595.584 USD per tre anni di manutenzione del DB, e ciò non include funzionalità come il partizionamento o il database in memoria, il tutto con uno sconto Oracle del 60%.

Galera Cluster è una soluzione open source che chiunque può eseguire gratuitamente. Gli abbonamenti sono disponibili per le implementazioni di produzione che richiedono il supporto del fornitore. Un buon calcolo del TCO può essere trovato su https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Conclusione

Sebbene vi siano differenze significative nell'architettura, entrambi i cluster condividono i principi fondamentali e possono raggiungere obiettivi simili. Il prodotto aziendale Oracle viene fornito con tutto pronto (e il suo prezzo). Con un costo nell'intervallo>1M USD come visto sopra, è una soluzione di fascia alta che molte aziende non sarebbero in grado di permettersi. Galera Cluster può essere descritto come una soluzione decente ad alta disponibilità per le masse. In alcuni casi, Galera potrebbe essere un'ottima alternativa a Oracle RAC. Uno svantaggio è che devi creare il tuo stack, anche se può essere completamente automatizzato con ClusterControl. Ci piacerebbe sentire la tua opinione in merito.