4 Soluzioni per la Replicazione Sincrona Attiva-Attiva di MySQL

MySQL è un sistema di gestione di database relazionali open source ampiamente utilizzato per la gestione e lo storage di dati strutturati. È noto per la sua semplicità, facilità d'uso e scalabilità, il che lo rende una scelta popolare per varie applicazioni, dalle piccole scale web ai grandi imprese.

Per la sincronizzazione dei dati in tempo reale, l'esigenza principale è implementarla basandosi sui log, il che consente una sincronizzazione quasi in tempo reale. Ciò non impone ulteriori vincoli sul design e sull'implementazione del database stesso. Lo scopo della replicazione sincrona attiva-attiva di MySQL è garantire la disponibilità continua e la tolleranza ai guasti. Ecco 4 metodi per raggiungere la replicazione sincrona attiva-attiva di MySQL.

Replica master-master basata sulla funzione di replica nativa del database MySQL

È tipicamente adatta per distribuzioni di piccole e medie dimensioni.

In questa architettura, due nodi possono adottare una modalità a doppio master semplice e utilizzare una connessione dedicata. In caso di guasto del nodo master_A, le connessioni dell'applicazione possono passare rapidamente al nodo master_B e viceversa.

Per evitare scenari di divisione del cervello, in cui entrambi i nodi scrivono dati in conflitto, è importante impostare valori diversi per auto-increment-increment e auto-increment-offset sui due nodi. Questo perché se il nodo master si blocca inaspettatamente o diventa non disponibile, c'è la possibilità che alcuni eventi binlog non vengano replicati al nodo slave. In tali casi, possono sorgere conflitti tra il valore auto-increment generato sul slave e il valore originale sul master.

Tuttavia, se esiste un meccanismo di tolleranza ai guasti appropriato per risolvere i conflitti di ID auto-incremento tra master e slave, è possibile evitare l'uso di tale metodo. Nelle versioni aggiornate 5.7+ di MySQL, l'utilizzo della replica multithread può ridurre significativamente la latenza della replica. Inoltre, un'altra soluzione alternativa particolarmente sensibile alla latenza della replica è la replica semisincrona, che offre praticamente nessun ritardo. Tuttavia, ciò potrebbe comportare una diminuzione delle prestazioni di concorrenza delle transazioni, specialmente in scrittura bidirezionale. È necessaria una valutazione complessiva per prendere una decisione.

Soluzione basata sulla replica Galera

Galera è un meccanismo di replica di sincronizzazione dei dati multi-master fornito da Codership. Abilita la replica sincrona dei dati nonché le operazioni di lettura e scrittura tra più nodi, garantendo alta disponibilità e coerenza dei dati nel database. Le principali soluzioni di alta disponibilità basate su Galera sono MariaDB Galera Cluster e Percona XtraDB Cluster (PXC).

Attualmente, PXC è più comunemente utilizzato e fornisce una coerenza dei dati rigorosa, il che lo rende particolarmente adatto al commercio elettronico. Tuttavia, PXC ha anche le sue limitazioni. In scenari con volumi elevati di transazioni concorrenti, si raccomanda l'uso di una rete InfiniBand per ridurre la latenza della rete. Questo perché PXC può soffrire di amplificazione delle scritture ed effetto di collo di bottiglia, causando una significativa perdita di efficienza concorrente. Simile alla replica semisincrona, la replica Galera è tipicamente limitata a tre nodi. Inoltre, l'instabilità della rete può causare problemi di prestazioni e stabilità.

Soluzione basata su Group Replication

MGR (MySQL Group Replication) è una soluzione di alta disponibilità ufficialmente introdotta da MySQL. Fornisce forti garanzie di coerenza dei dati tra i nodi di un cluster di database attraverso il protocollo Paxos. MGR si basa sulla tecnologia di replica nativa e viene offerto come plugin. Consente a tutti i nodi del cluster di essere scrivibili, risolvendo le limitazioni di prestazioni di un singolo cluster, risolvendo il problema delle divisioni cerebrali indotte dalle partizioni di rete e migliorando la affidabilità dei dati replicati.

Tuttavia la realtà è un po' crudele. Attualmente non ci sono molti precoci adottatori di MGR. Inoltre supporta solo tabelle InnoDB e richiede che ogni tabella abbia una chiave primaria per la rilevazione dei conflitti del set di scrittura. La funzionalità GTID deve essere abilitata e il formato del log binario deve essere impostato su ROW per l'elezione del leader e il set di scrittura. 

COMMIT può potenzialmente fallire, simile a scenari di fallimento nel livello di isolamento snapshot. Attualmente, un cluster MGR (MySQL Group Replication) supporta un massimo di 9 nodi. Non supporta chiavi esterne e funzionalità di punto di salvataggio, impedendo controlli di vincoli globali e rollback parziali. Il log binario non supporta il checksum degli eventi binlog.

Soluzione basata su Canal

Per la sincronizzazione in tempo reale dei database, Alibaba ha un progetto open-source dedicato chiamato Otter, che consente la replica sincrona di database distribuiti. L'idea centrale di Otter è ancora basata sulla cattura dei log di dati incrementali dei database per raggiungere una replica quasi in tempo reale. Otter si basa su un altro progetto open-source chiamato Canal, che si concentra sulla cattura delle informazioni di log di sincronizzazione incrementale del database.

Attualmente, Otter si concentra sul raggiungimento della replica sincrona tra i database MySQL Utilizza tecnologie simili per ottenere la replica sincrona bidirezionale tra due database MySQL È importante notare che il termine bidirezionale qui significa che i dati possono essere sincronizzati da A a B o da B a A, ma potrebbe essere unidirezionale in un determinato momento.

Il processo di replica master-slave può essere diviso in tre fasi:

1. Il master registra le modifiche nel log binario, note come eventi del log binario. Questi eventi possono essere visualizzati utilizzando il comando "show binlog events".

2. Lo schiavo copia gli eventi del log binario dal master al proprio log di relay.

3. Lo schiavo eseguirà sequenzialmente gli eventi registrati nel log di relay per applicare le modifiche dal master ai propri dati.

Per quanto riguarda il principio del Canale, è relativamente semplice:

1. Canal simula il protocollo di interazione di uno schiavo MySQL mascherandosi come uno schiavo MySQL e inviando una richiesta di dump al master MySQL.

2. Al ricevere la richiesta di dump, il master MySQL inizia a inviare i log binari allo slave (che è Canal).

3. Canal analizza quindi gli oggetti del log binario (inizialmente in formato flusso di byte) per estrarre le informazioni pertinenti.

Fare il backup dei database MySQL con Vinchin Backup & Recovery

Per proteggere meglio i dati, si consiglia di fare il backup dei propri database. Vinchin Backup & Recovery fornisce funzionalità potenti per proteggere i database sia nelle macchine virtuali che nei server fisici. Collaborando efficacemente con i backup a livello di VM, viene fornita una doppia assicurazione agli utenti degli ambienti virtuali per i loro dati e sistemi informativi aziendali chiave.

Vinchin Backup & Recovery supporta la protezione di Oracle DB, MySQL, SQL Server, PostgreSQL, Postgres Pro e MariaDB installati su macchine fisiche e virtuali con potenti funzionalità di backup e ripristino del database. Fornisce inoltre strategie di backup completo, differenziale, incrementale e dei log delle transazioni per consentire la configurazione del proprio piano di backup su richiesta.

Vinchin Backup & Recovery supporta l'efficiente backup caldo senza influire sull'operazione normale dei database e è facile creare un processo di backup personalizzato del database.

1 Seleziona il database di destinazione

2 Seleziona il dispositivo di archiviazione dei backup

3 Seleziona le strategie di backup

4 Invia il lavoro

Puoi iniziare a utilizzare questo potente sistema con una prova gratuita a pieno titolo di 60 giorni. Basta fare clic sul pulsante per ottenere il pacchetto di installazione. Puoi fare clic qui per saperne di più su come eseguire il backup di MySQL con Vinchin Backup & Recovery.

Conclusione

La replica sincrona attiva-attiva di MySQL è progettata per fornire alta disponibilità e flessibilità. Consente a più istanze di MySQL di essere attive simultaneamente e di sincronizzare i dati tra loro, abilitando operazioni di lettura e scrittura bidirezionali. Garantisce una disponibilità continua, bilanciamento del carico, coerenza dei dati e flessibilità. Tuttavia, una configurazione e gestione corrette sono fondamentali e la scelta delle soluzioni e degli strumenti di implementazione dipende dalle esigenze specifiche.

Per proteggere efficacemente i dati del database puoi scegliere Vinchin Backup & Recovery per eseguire facilmente il backup e la ripristino del database Non perdere la versione di prova gratuita.