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

Confronto dell'elevata disponibilità del database - Replica MySQL/MariaDB e Oracle Data Guard

Nello "Stato del mercato dei DBMS open source, 2018", Gartner prevede che entro il 2022 il 70% delle nuove applicazioni interne sarà sviluppato su un database open source. E il 50% dei database commerciali esistenti sarà convertito. Quindi, i DBA Oracle, preparatevi a iniziare a distribuire e gestire nuovi database open source, insieme alle vostre istanze Oracle legacy. A meno che tu non lo stia già facendo.

Quindi, in che modo la replica di MySQL o MariaDB si confronta con Oracle Data Guard? In questo blog confronteremo i due dal punto di vista di una soluzione di database ad alta disponibilità.

Cosa cercare

Una moderna architettura di replica dei dati si basa su progetti flessibili che consentono la replica dei dati unidirezionale e bidirezionale, nonché un failover rapido e automatizzato sui database secondari in caso di interruzione del servizio non pianificata. Il failover dovrebbe anche essere facile da eseguire e affidabile in modo che nessuna transazione impegnata andrebbe persa. Inoltre, il passaggio o il failover dovrebbero idealmente essere trasparenti per le applicazioni.

Le soluzioni di replica dei dati devono essere in grado di copiare i dati con una latenza molto bassa per evitare colli di bottiglia nell'elaborazione e garantire l'accesso in tempo reale ai dati. È possibile distribuire copie in tempo reale su un database diverso in esecuzione su hardware a basso costo.

Se utilizzato per il ripristino di emergenza, il sistema deve essere convalidato per garantire l'accesso dell'applicazione al sistema secondario con un'interruzione minima del servizio. La soluzione ideale dovrebbe consentire test regolari del processo di ripristino di emergenza.

Argomenti principali di confronto

  • Disponibilità e coerenza dei dati
    • Gtid, scm
    • Menzione Replica su più modelli standby, asincroni e sincronizzati
    • Isolamento dello standby da errori di produzione (es. replica ritardata per mysql)
    • Evita la perdita di dati (replica della sincronizzazione)
  • Utilizzo dei sistemi in standby
    • Utilizzo dello standby
  • Failover, Switchover e ripristino automatico
    • Failover del database
    • Failover trasparente dell'applicazione (TAF vs ProxySQL, MaxScale)
  • Sicurezza
  • Facilità di utilizzo e gestione (gestione unificata dei componenti preintegrati)

Disponibilità e coerenza dei dati

GID MySQL

La replica di MySQL 5.5 era basata su eventi di log binari, in cui tutto ciò che uno slave conosceva era l'evento preciso e la posizione esatta che aveva appena letto dal master. Qualsiasi singola transazione da un master potrebbe essere terminata in vari registri binari di diversi slave e la transazione in genere avrebbe posizioni diverse in questi registri. Era una soluzione semplice con limitazioni, le modifiche alla topologia potevano richiedere a un amministratore di interrompere la replica sulle istanze coinvolte. Queste modifiche potrebbero causare altri problemi, ad esempio, uno slave non può essere spostato lungo la catena di replica senza una ricostruzione dispendiosa in termini di tempo. La correzione di un collegamento di replica interrotto richiederebbe la determinazione manuale di un nuovo file di registro binario e la posizione dell'ultima transazione eseguita sullo slave e la ripresa da lì, oppure una ricostruzione totale. Abbiamo tutti dovuto aggirare queste limitazioni mentre sognavamo un identificatore di transazione globale.

MySQL versione 5.6 (e MariaDB versione 10.0.2) ha introdotto un meccanismo per risolvere questo problema. GTID (Global Transaction Identifier) ​​fornisce una migliore mappatura delle transazioni tra i nodi.

Con GTID, gli slave possono vedere una transazione univoca in arrivo da diversi master e questo può essere facilmente mappato nell'elenco di esecuzione degli slave se è necessario riavviare o riprendere la replica. Quindi, il consiglio è di usare sempre GTID. Nota che MySQL e MariaDB hanno implementazioni GTID diverse.

Oracle SCN

Nel 1992 con la versione 7.3 Oracle ha introdotto una soluzione per mantenere una copia sincronizzata di un database in standby, nota come Data Guard dalla versione 9i versione 2. Una configurazione di Data Guard è composta da due componenti principali, un singolo database primario e un database in standby (fino a 30). Le modifiche al database primario vengono trasmesse al database di standby e queste modifiche vengono applicate al database di standby per mantenerlo sincronizzato.

Oracle Data Guard viene inizialmente creato da un backup del database primario. Data Guard sincronizza automaticamente il database primario e tutti i database in standby trasmettendo il ripristino del database primario, le informazioni utilizzate da ogni database Oracle per proteggere le transazioni, e applicandole al database in standby. Oracle utilizza un meccanismo interno chiamato SCN (System Change Number). Il numero di modifica del sistema (SCN) è l'orologio di Oracle, ogni volta che ci impegniamo, l'orologio aumenta. L'SCN segna un punto nel tempo coerente nel database che è un checkpoint che è l'atto di scrivere blocchi sporchi (blocchi modificati dalla cache del buffer al disco). Possiamo confrontarlo con GTID in MySQL.

I servizi di trasporto di Data Guard gestiscono tutti gli aspetti della trasmissione di redo da un database primario a uno standby. Quando gli utenti eseguono il commit delle transazioni sul primario, i record di ripristino vengono generati e scritti in un file di registro online locale. I servizi di trasporto di Data Guard trasmettono simultaneamente lo stesso redo direttamente dal buffer di registro del database primario (memoria allocata all'interno dell'area globale del sistema) al database in standby dove viene scritto in un file di registro di ripristino in standby.

Esistono alcune differenze principali tra la replica di MySQL e Data Guard. La trasmissione diretta di Data Guard dalla memoria evita il sovraccarico di I/O del disco sul database primario. È diverso da come funziona MySQL:la lettura dei dati dalla memoria riduce l'I/O su un database primario.

Data Guard trasmette solo il ripristino del database. È in netto contrasto con il mirroring remoto dello storage che deve trasmettere ogni blocco modificato in ogni file per mantenere la sincronizzazione in tempo reale.

Modelli asincroni + sincronizzazione

Oracle Data Guard offre tre diversi modelli per l'applicazione di ripristino. Modelli adattivi dipendenti dall'hardware disponibile, dai processi e, in definitiva, dalle esigenze aziendali.

  • Prestazioni massime:modalità operativa predefinita, che consente di eseguire il commit di una transazione non appena i dati di ripristino necessari per recuperare tale transazione vengono scritti nel registro di ripristino locale sul master.
  • Massima protezione:nessuna perdita di dati e il massimo livello di protezione. I dati di ripristino necessari per migliorare ogni operazione devono essere scritti sia nel registro di ripristino in linea locale sul registro di ripristino master che in standby su almeno un database di standby prima del commit della transazione (Oracle consiglia almeno due standby). Il database primario si spegnerà se un errore gli impedisce di scrivere il suo flusso di ripristino in almeno un database di standby sincronizzato.
  • Disponibilità massima:simile alla protezione massima, ma il database primario non si spegne se un errore gli impedisce di scrivere il flusso di ripristino.

Quando si tratta di scegliere la configurazione della replica MySQL, è possibile scegliere tra replica asincrona o replica semisincrona.

  • L'applicazione asincrona del binlog è il metodo predefinito per la replica di MySQL. Il master scrive gli eventi nel suo log binario e gli slave li richiedono quando sono pronti. Non vi è alcuna garanzia che un evento raggiungerà mai uno schiavo.
  • Il commit semisincrono sul primario viene ritardato fino a quando il master non riceve un riconoscimento dallo slave semisincrono che i dati sono stati ricevuti e scritti dallo slave. Tieni presente che la replica semisincrona richiede l'installazione di un plug-in aggiuntivo.

Utilizzo dei sistemi in standby

MySQL è noto per la sua semplicità e flessibilità di replica. Per impostazione predefinita, puoi leggere o persino scrivere sui tuoi server standby/slave. Fortunatamente, MySQL 5.6 e 5.7 hanno apportato molti miglioramenti significativi a Replication, inclusi Global Transaction ID, checksum degli eventi, slave multi-thread e slave/master a prova di crash per renderlo ancora migliore. I DBA abituati alle letture e alle scritture della replica MySQL si aspetterebbero una soluzione simile o addirittura più semplice dal fratello maggiore, Oracle. Purtroppo non per impostazione predefinita.

L'implementazione di standby fisico standard per Oracle è chiusa per qualsiasi operazione di lettura-scrittura. In effetti, Oracle offre variazioni logiche ma presenta molte limitazioni e non è progettato per HA. La soluzione a questo problema è una funzionalità aggiuntiva a pagamento chiamata Active Data Guard, che puoi utilizzare per leggere i dati dallo standby mentre applichi i registri di ripristino.

Active Data Guard è una soluzione aggiuntiva a pagamento per il software di ripristino di emergenza gratuito Data Guard di Oracle disponibile solo per Oracle Database Enterprise Edition (licenza a costo più elevato). Fornisce l'accesso in sola lettura, applicando continuamente le modifiche inviate dal database primario. In quanto database in standby attivo, aiuta a scaricare le query di lettura, i report ei backup incrementali dal database primario. L'architettura del prodotto è progettata per consentire ai database in standby di essere isolati dagli errori che possono verificarsi nel database primario.

Una caratteristica interessante del database Oracle 12c e qualcosa che mancherebbe a Oracle DBA è la convalida del danneggiamento dei dati. I controlli di danneggiamento di Oracle Data Guard vengono eseguiti per garantire che i dati siano esattamente allineati prima che i dati vengano copiati in un database in standby. Questo meccanismo può essere utilizzato anche per ripristinare i blocchi di dati sul database primario direttamente dal database in standby.

Failover, passaggio e ripristino automatico

Per mantenere stabile e funzionante la configurazione della replica, è fondamentale che il sistema sia resiliente ai guasti. I guasti sono causati da bug del software, problemi di configurazione o problemi hardware e possono verificarsi in qualsiasi momento. Nel caso in cui un server si interrompa, è necessaria una notifica di allarme sull'installazione degradata. Il failover (promozione di uno slave a master) può essere eseguito dall'amministratore, che deve decidere quale slave promuovere.

L'amministratore ha bisogno di informazioni sull'errore, lo stato di sincronizzazione in caso di perdita di dati e, infine, i passaggi per eseguire l'azione. Idealmente, tutto dovrebbe essere automatizzato e visibile da un'unica console.

Esistono due approcci principali al failover di MySQL, automatico e manuale. Entrambe le opzioni hanno i suoi fan, descriviamo i concetti in un altro articolo.

Con GTID, il failover manuale diventa molto più semplice. Consiste in passaggi come:

  • Arresta il modulo ricevitore (STOP SLAVE IO_THREAD)
  • Cambia master (CAMBIA MASTER IN )
  • Avvia il modulo ricevitore (START SLAVE IO_THREAD)

Oracle Data Guard viene fornito con una soluzione di failover/switchover dedicata:Data Guard Broker. Il broker è un framework di gestione distribuito che automatizza e centralizza la creazione, la manutenzione e il monitoraggio delle configurazioni di Oracle Data Guard. Con l'accesso allo strumento broker DG, puoi eseguire modifiche alla configurazione, switchover, failover e persino test a secco della tua configurazione ad alta disponibilità. Le due azioni principali sono:

  • Il comando SWITCHOVER TO viene utilizzato per eseguire l'operazione di commutazione. Dopo l'operazione di passaggio riuscita, le istanze del database cambiano posizione e la replica continua. Non è possibile effettuare il passaggio quando lo standby non risponde o è inattivo.
  • Il comune FAILOVER TO viene utilizzato per eseguire il failover. Dopo l'operazione di failover, il server primario precedente richiede una ricreazione, ma il nuovo server primario può sostenere il carico di lavoro del database.

Parlando di failover, dobbiamo considerare quanto può essere semplice il failover dell'applicazione. In caso di interruzione pianificata/non pianificata, l'efficienza con cui le sessioni utente possono essere indirizzate a un sito secondario, con un'interruzione minima dell'attività.

L'approccio standard per MySQL sarebbe quello di utilizzare uno dei Load Balancer disponibili. A partire da HAProxy, ampiamente utilizzato per il failover HTTP o TCP/IP su Maxscale o ProxySQL con riconoscimento del database.

In Oracle, questo problema viene affrontato da TAF (Transparent Application Failover). Una volta che si verifica il passaggio o il failover, l'applicazione viene automaticamente indirizzata al nuovo primario. TAF consente all'applicazione di riconnettersi automaticamente e in modo trasparente a un nuovo database, se l'istanza del database a cui viene stabilita la connessione non riesce.

Sicurezza

La sicurezza dei dati è un problema caldo per molte organizzazioni in questi giorni. Per coloro che devono implementare standard come PCI DSS o HIPAA, la sicurezza del database è un must. Gli ambienti cross WAN potrebbero causare preoccupazioni in merito alla privacy e alla sicurezza dei dati, soprattutto perché sempre più aziende devono conformarsi alle normative nazionali e internazionali. I log binari MySQL utilizzati per la replica possono contenere dati sensibili di facile lettura. Con la configurazione standard, rubare i dati è un processo molto semplice. MySQL supporta SSL come meccanismo per crittografare il traffico sia tra server MySQL (replica) che tra server e client MySQL. Un modo tipico per implementare la crittografia SSL consiste nell'utilizzare certificati autofirmati. Nella maggior parte dei casi, non è necessario ottenere un certificato SSL emesso dall'autorità di certificazione. Puoi utilizzare openssl per creare certificati, esempio di seguito:

$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pem

Quindi modifica la replica con i parametri per SSL.

….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';

Per un'opzione più automatizzata, puoi utilizzare ClusterControl per abilitare la crittografia e gestire le chiavi SSL.

In Oracle 12c, il trasporto redo di Data Guard può essere integrato con un set di funzionalità di sicurezza dedicate denominate Oracle Advanced Security (OAS). La sicurezza avanzata può essere utilizzata per abilitare i servizi di crittografia e autenticazione tra il sistema primario e quello di standby. Ad esempio, l'abilitazione dell'algoritmo di crittografia Advanced Encryption Standard (AES) richiede solo alcune modifiche ai parametri nel file sqlnet.ora per eseguire la crittografia di ripetizione (simile a MySQL binlog). Non è richiesta alcuna configurazione di certificato esterno e richiede solo il riavvio del database di standby. Le modifiche in sqlnet.ora e wallet sono semplici come:

Crea una directory del portafoglio

mkdir /u01/app/wallet

Modifica sqlnet.ora

ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=file)
   (METHOD_DATA=
    (DIRECTORY=/u01/app/wallet)))

Crea un keystore

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;

Apri negozio

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

Crea una chiave maestra

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

In attesa

copia i file p12 e .sso nella directory del portafoglio e aggiorna il file sqlnet.ora in modo simile al nodo primario.

Per ulteriori informazioni, segui il white paper TDE di Oracle, puoi imparare dal white paper come crittografare il file di dati e rendere il portafoglio sempre aperto.

Facilità di utilizzo e gestione

Quando gestisci o distribuisci la configurazione di Oracle Data Guard, potresti scoprire che ci sono molti passaggi e parametri da cercare. Per rispondere a questa domanda, Oracle ha creato DG Broker.

Puoi sicuramente creare una configurazione Data Guard senza implementare DG Broker ma può renderti la vita molto più confortevole. Quando viene implementata, l'utilità della riga di comando del broker - DGMGRL è probabilmente la scelta principale per il DBA. Per coloro che preferiscono la GUI, Cloud Control 13c ha un'opzione per accedere a DG Broker tramite l'interfaccia web.

Le attività che Broker può svolgere sono l'avvio automatico del ripristino gestito, un comando per il failover/switchover, il monitoraggio della replica DG, la verifica della configurazione e molti altri.

DGMGRL> show configuration 
Configuration - orcl_s9s_config 

Protection Mode: MaxPerformance
  Members:

s9sp  - Primary database
    s9ss - Physical standby database 

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 12 seconds ago

MySQL non offre una soluzione simile a Oracle DG Broker. Tuttavia, puoi estenderne le funzionalità utilizzando strumenti come Orchestrator, MHA e bilanciatori di carico (ProxySQL, HAProxy o Maxscale). La soluzione per gestire database e bilanciatori di carico è ClusterControl. ClusterControl Enterprise Edition ti offre un set completo di funzionalità di gestione e ridimensionamento oltre alle funzioni di implementazione e monitoraggio offerte come parte della Community Edition gratuita.