Casi d'uso di Galera
La replica con Galera replication funziona per una varietà di casi d'uso, eccone alcuni comuni che abbiamo identificato nella comunità open source:
| Master di Lettura | Topologia tradizionale master-slave di MySQL master-slave, ma con Galera tutti i nodi "slave" hanno le capacità di un master in ogni momento, è solo l'applicazione a trattarli come degli slave. La replica con Galera può garantire un ritardo pari a 0 in tali installazioni, e grazie all'uso degli slave paralleli un traffico migliore in tutto il cluster. |
|---|---|
| Scalabilità della Scrittura | Le operazioni di scrittura distribuite nel cluster sfruttano la potenza della CPU dei nodi slave per elaborare le transazioni dei client. Grazie alla replica basata sulle righe, vengono replicate solo le modifiche eseguite all'interno delle transazioni nei client, e applicare il risultato di questo processo negli slave è molto più performante che eseguire la transazione originale. Pertanto il cluster può distribuire la pesante elaborazione delle transazioni client su molti nodi master, e le prestazioni delle modifiche migliorano notevolmente. |
| WAN Clustering | La replica sincrona funziona bene su una rete WAN. Vi è un ritardo, che è proporzionale al round trip time (RTT) della rete, ma esso riguarda solo l'operazione commit. |
| Recupero dei disastri | Il recupero dei disastri è una sottoclasse della replica WAN. In questo caso un data center svolge un ruolo passivo e riceve soltanto gli eventi della replica, ma non elabora alcuna transazione client. Questo data center remoto verrà aggiornato di volta in volta e non potrà verificarsi alcuna perdita di dati. Durante il recupero, lo spare site viene considerato primario e l'applicazione può continuare a funzionare normalmente con un ritardo minimo. |
| Eliminazione della Latenza | Nella topologia della replica WAN, i nodi del cluster possono trovarsi vicino ai client. Perciò le operazioni di lettura e di scrittura saranno estremamente veloci nella connessione al nodo locale. Il ritardo dovuto al RTT si verifica soltanto in fase di commit, e anche in quel contesto è generalmente accettabile per l'utente finale: generalmente a rovinare l'esperienza utente è un tempo di visualizzazione lento, e le operazioni di lettura si svolgono il più velocemente possibile. |
Vedi anche
Content reproduced on this site is the property of its respective owners,
and this content is not reviewed in advance by MariaDB. The views, information and opinions
expressed by this content do not necessarily represent those of MariaDB or any other party.
