MariaDB Server offre la replica asincrona e sincrona. Può essere configurato per avere una replica multi-sorgente o con una configurazione multi-master.
Per un'applicazione ad alta intensità di lettura e scrittura, un'impostazione master-slave è comune, ma può differire in base allo stack sottostante necessario per creare un ambiente di database ad alta disponibilità.
Avere una configurazione di replica master-slave potrebbe non soddisfare le tue esigenze, specialmente in un ambiente di produzione. Un server MariaDB da solo (configurazione master-slave) non è sufficiente per offrire un'elevata disponibilità in quanto ha ancora un singolo punto di errore (SPOF).
MariaDB ha introdotto un prodotto aziendale (piattaforma MariaDB) per risolvere questo problema di alta disponibilità. Include vari componenti:una versione enterprise di MariaDB, MariaDB ColumnStore, MaxScale e MariaDB Connectors leggeri. Rispetto ad altri fornitori con la stessa offerta di soluzioni aziendali, potrebbe essere un'opzione conveniente, tuttavia non tutti hanno bisogno di questo livello di complessità.
In questo blog, ti mostreremo come utilizzare MariaDB Server utilizzando la replica in un ambiente a disponibilità elevata con la possibilità di scegliere tra l'utilizzo di tutti gli strumenti gratuiti o il nostro software di gestione efficiente in termini di costi per l'esecuzione e monitora la tua infrastruttura del server MariaDB.
Impostazione della topologia ad alta disponibilità di MariaDB
Una configurazione usuale per una topologia master-slave con MariaDB Server utilizza un approccio asincrono o sincrono con un solo master che riceve scritture, quindi replica le sue modifiche agli slave proprio come il diagramma seguente:
Ma ripeto, questo non serve ad alcuna disponibilità elevata e ha un unico punto di insuccesso. Se il master muore, il client dell'applicazione non funziona più. Ora, è necessario aggiungere lo stack per avere un meccanismo di failover automatico per evitare SPOF e offre anche il bilanciamento del carico per la suddivisione delle operazioni di lettura e scrittura e in modo round robin. Quindi, per ora, finiremo per avere il tipo di topologia,
Ora, questa topologia offre maggiore sicurezza in termini di SPOF. MaxScale eseguirà la suddivisione in lettura e scrittura sui nodi del database dal tuo master rispetto agli slave. MaxScale ha un approccio perfetto quando si tratta di questo tipo di configurazione. MaxScale ha anche il rilevamento automatico integrato. Pertanto, qualunque modifica si verifichi sullo stato dei nodi del database, rileverà e agirà di conseguenza. MaxScale ha la disponibilità per procedere a un failover o addirittura a un passaggio. Per saperne di più sul suo meccanismo di failover, leggi il nostro blog precedente che affronta il meccanismo del failover di MariaDB MaxScale.
Tieni presente che anche il meccanismo di failover MaxScale con MariaDB Monitor ha i suoi limiti. È meglio applicato solo per una configurazione master-slave senza una configurazione eccessivamente complicata. Ciò significa che una configurazione master-master non è supportata. Tuttavia, MaxScale ha più cose da offrire. Non solo esegue un po' di bilanciamento del carico mentre esegue le suddivisioni in lettura e scrittura, ma dispone di SmartRouter integrato che invia la query al nodo più performante. Sebbene ciò non aggiunga la caratteristica di essere altamente disponibile, ma aiuta i nodi a rimanere bloccati nel traffico ed evitare che alcuni nodi di database abbiano prestazioni insufficienti che possono causare timeout o un server totalmente non disponibile causato da un'attività ad alta intensità di risorse in corso .
Un avvertimento sull'utilizzo di MaxScale, stanno usando BSL (Business Source LIcense). Potrebbe essere necessario rivedere le domande frequenti prima di adottare questo software.
Un'altra opzione tra cui scegliere è utilizzare un approccio più conveniente. Può essere conveniente per te scegliere l'utilizzo di ClusterControl e avere proxy nel mezzo utilizzando HaProxy, MaxScale o ProxySQL, per il quale quest'ultimo può essere configurato da una configurazione leggera a una più a livello di produzione che esegue il routing delle query, filtraggio delle query, firewall o sicurezza. Vedi l'illustrazione qui sotto:
Ora, sopra di loro c'è ClusterControl. ClusterControl è impostato con un'elevata disponibilità ovvero CMON HA. In alternativa, il livello proxy può essere scelto da HaProxy, un'opzione molto leggera tra cui scegliere, MaxScale, come accennato in precedenza, o ProxySQL che ha un set di parametri più raffinato se si desidera maggiore flessibilità e configurazione ideale per un impostazione della produzione. ClusterControl gestirà il rilevamento automatico in termini di stato di integrità dei nodi, in particolare il master che è il nodo principale per determinare se richiede un failover o meno. Ora, questo può essere più autosufficiente ma aggiunge più costi a causa di un numero di nodi necessari per implementare questa configurazione e anche dell'utilizzo del failover automatico di ClusterControl che si applica alla nostra licenza avanzata ed aziendale. Ma d'altra parte, ti fornisce tutta la sicurezza, la protezione e l'osservabilità verso la tua infrastruttura di database. In realtà è più un'implementazione aziendale a basso costo rispetto alle soluzioni disponibili nel mercato globale.
Distribuzione della replica master-slave MariaDB per un'elevata disponibilità
Supponiamo che tu abbia una configurazione master-slave esistente di MariaDB. Per questo esempio, utilizzeremo ClusterControl utilizzando l'edizione gratuita della community che puoi installare e utilizzare gratuitamente. Rende il tuo lavoro facile e veloce da configurare. Per fare ciò, devi solo importare il tuo cluster di replica MariaDB esistente. Dai un'occhiata al nostro blog precedente su come gestire MariaDB con ClusterControl. Per questo blog, inizialmente ho la seguente configurazione come cluster di replica MariaDB, come mostrato di seguito:
Ora, usiamo MaxScale qui come soluzione alternativa dalla piattaforma MariaDB che anche offre alta disponibilità. Per fare ciò, è molto facile da usare con ClusterControl con pochi clic, quindi puoi configurare il tuo MaxScale che è in esecuzione sopra il tuo cluster di replica MariaDB esistente. Per farlo, vai su Gestisci → Bilanciamento del carico → MaxScale e sarai in grado di impostare e fornire i valori appropriati come mostrato di seguito,
Quindi abilita o fai clic sull'opzione della casella di controllo per selezionare quali server devono essere aggiunto come parte del monitoraggio MaxScale. Vedi sotto,
Supponendo che tu abbia più di un nodo MaxScale da aggiungere, ripeti semplicemente il stessi passaggi.
Infine, imposteremo Keepalived per mantenere i nostri nodi MaxScale sempre disponibili quando necessario. Questo è solo molto veloce con semplici passaggi utilizzando ClusterControl. Ancora una volta, devi andare su Gestisci → Bilanciamento del carico, ma invece, seleziona Mantieni vivo,
Come hai notato, ho posizionato il mio Keepalived insieme a MaxScale sullo stesso nodo del mio schiavo (192.168.10.30). Considerando che, d'altra parte, il secondo (2°) Keepalived è in esecuzione su 192.168.10.40 insieme a Maxscale sullo stesso host.
Il risultato della topologia è pronto per la produzione, in grado di fornire instradamento delle query, disponibilità elevata e con failover automatico dotato di monitoraggio e osservabilità estensivi mediante ClusterControl. Vedi sotto,
Conclusione
L'utilizzo della sola replica del server MariaDB non offre un'elevata disponibilità. L'estensione e l'utilizzo di strumenti di terze parti ti consentirà di avere il tuo stack di database altamente disponibile non solo facendo affidamento sui prodotti MariaDB o persino utilizzando la piattaforma MariaDB.
Ci sono modi per raggiungere questo obiettivo e gestirlo in modo che sia più conveniente. Tuttavia, c'è un'enorme differenza nell'utilizzare queste soluzioni disponibili sul mercato come ClusterControl poiché ti offre velocità, meno problemi e, naturalmente, la massima osservabilità con eventi in tempo reale e aggiornati non solo la salute ma anche gli eventi che si verificano nel tuo cluster di database.
