I database possono fallire senza preavviso, a causa di un arresto anomalo causato da un bug del software o dei componenti hardware sottostanti. Il cloud porta un'altra dimensione al problema, a causa della natura effimera delle risorse di calcolo e storage. Per isolare la nostra infrastruttura di database da questi guasti, costruiamo la ridondanza nei nostri sistemi. Se un'istanza diventa non disponibile, un sistema in standby dovrebbe essere in grado di sostenere il carico di lavoro e continuare da lì. La replica è un metodo ben noto e ampiamente adottato per creare copie ridondanti di un database master.
In questo post, confronteremo la funzionalità di replica nei due sistemi di database più popolari al mondo (secondo db-engines):Oracle e MySQL. Esamineremo in particolare la replica logica Oracle 12c e MySQL 5.7. Entrambe le tecnologie offrono sistemi di standby affidabili per scaricare i carichi di lavoro di produzione e aiutare in caso di disastro. Daremo un'occhiata alle loro diverse architetture, analizzeremo pro e contro e seguiremo i passaggi su come configurare la replica con Oracle e MySQL.
Architettura Oracle Data Guard:come funziona
Oracle Data Guard garantisce disponibilità elevata, protezione dei dati e ripristino di emergenza dei dati. Probabilmente è la prima scelta di un DBA Oracle per la replica dei dati. La tecnologia è stata introdotta nel 1990 (versione 7.0) con un'applicazione essenziale dei log di archivio su database in standby. Data Guard si è evoluto nel corso degli anni e ora fornisce una serie completa di servizi per la creazione, la manutenzione, la gestione e il monitoraggio dei database in standby.
Data Guard mantiene i database in standby come copie del database di produzione. Se il database primario smette di rispondere, Data Guard può passare qualsiasi standby al ruolo di produzione, quindi tempi di inattività. Data Guard può essere utilizzato per le tecniche di backup, ripristino e cluster per fornire un elevato livello di protezione e disponibilità dei dati.
Data Guard è una tecnologia Ship Redo / Apply Redo, "redo" è l'informazione necessaria per recuperare le transazioni. Un database di produzione denominato database primario esegue nuovamente le trasmissioni su una o più repliche denominate database in standby. Quando viene eseguito un inserimento o un aggiornamento in una tabella, questa modifica viene acquisita dal writer di registro in un registro di archivio e replicata nel sistema di standby. I database in standby sono in una fase continua di ripristino, verifica e applicazione di ripristino per mantenere la sincronizzazione con il database primario. Un database in standby si risincronizza automaticamente anche se viene temporaneamente disconnesso dal database primario a causa di interruzioni di corrente, problemi di rete, ecc.
Oracle Data Guard Net Services I servizi di trasporto di Data Guard Redo regolano la trasmissione di operazioni di ripristino dal database primario al database di standby. Il processo LGWR (log writer) invia i dati di ripristino a uno o più processi del server di rete (LNS1, LSN2, LSN3, ...LSNn). LNS sta leggendo dal buffer di ripristino nell'SGA (Area globale condivisa) e passa il ripristino a Oracle Net Services per la trasmissione al database di standby. È possibile scegliere gli attributi LGWR:modalità sincrona (LogXptMode ='SYNC') o asincrona (LogXptMode ='ASYNC'). Con tale architettura è possibile consegnare i dati redo a più database in standby o utilizzarli con Oracle RAC (Real Application Cluster). Il processo Remote File Server (RFS) riceve il redo da LNS e lo scrive in un file normale chiamato file di standby redo log (SRL).
Esistono due tipi principali di Oracle Data Guard. Fisico con applicazione redo e database in standby logico con applicazione SQL.
Architettura di replica logica Oracle Dataguard L'applicazione SQL richiede più elaborazione rispetto a quella di ripristino, il processo prima legge l'SRL e "mina" il ripristino convertendolo in record di modifiche logiche, quindi crea transazioni SQL prima di applicare l'SQL al database di standby. Ci sono più parti mobili, quindi richiede più CPU, memoria e I/O, quindi applica nuovamente.
Il vantaggio principale di "SQL apply" è che il database è aperto per la lettura-scrittura, mentre il processo di applicazione è attivo.
Puoi persino creare viste e indici locali. Questo lo rende ideale per gli strumenti di reporting. Il database in standby non deve essere una copia uno a uno del database principale e pertanto potrebbe non essere il miglior candidato per scopi di ripristino di emergenza.
Le caratteristiche principali di questa soluzione sono:
- Un database in standby aperto per la lettura-scrittura mentre l'applicazione SQL è attiva
- Possibile blocco di modifica dei dati che viene mantenuto dall'SQL si applica
- In grado di eseguire aggiornamenti continui del database
Ci sono degli svantaggi. Oracle utilizza una registrazione supplementare per chiave primaria o vincolo univoco/indice per riconoscere logicamente una riga modificata nel database di standby logico. Quando è abilitata la registrazione supplementare per chiave primaria a livello di database e vincolo univoco/indice, ogni istruzione UPDATE scrive anche i valori di colonna necessari nel log di ripristino per identificare in modo univoco la riga modificata nel database di standby logico. Oracle Data Guard supporta la replica concatenata, che qui viene chiamata "cascata", ma non è tipica a causa della complessità della configurazione.
Oracle consiglia di aggiungere una chiave primaria o un indice univoco non null alle tabelle nel database primario, ove possibile, per garantire che SQL Apply possa applicare in modo efficiente gli aggiornamenti dei dati di ripristino al database di standby logico. Ciò significa che non funziona su nessuna configurazione, potrebbe essere necessario modificare l'applicazione.
Architettura Oracle Golden Gate:come funziona
Con Data Guard, quando i blocchi vengono modificati nel database, i record vengono aggiunti al log di ripristino. Quindi, in base alla modalità di replica in esecuzione, questi record di registro verranno immediatamente copiati in standby o estratti per i comandi SQL e applicati. Golden Gate funziona in modo diverso.
Golden Gate replica le modifiche solo dopo il commit della transazione, quindi se hai una transazione di lunga durata, la replica può richiedere del tempo. Il "processo di estrazione" del Golden Gate mantiene in memoria le modifiche transazionali.
Un'altra grande differenza è che Oracle Golden Gate consente lo scambio e la manipolazione dei dati a livello di transazione tra piattaforme multiple ed eterogenee. Non sei limitato solo al database Oracle. Ti offre la flessibilità di estrarre e replicare record di dati selezionati, modifiche transazionali e modifiche a DDL (linguaggio di definizione dei dati) in una varietà di topologie.
Architettura Oracle Golden Gate Il tipico flusso Golden Gate mostra i dati del database nuovi e modificati che vengono acquisiti dal database di origine. I dati acquisiti vengono scritti in un file chiamato percorso di origine. Il trail viene quindi letto da un data pump, inviato attraverso la rete e scritto in un file trail remoto dal processo di raccolta. La funzione di consegna legge il trail remoto e aggiorna il database di destinazione. Ciascuno dei componenti è gestito dal processo Manager.
Replica logica MySQL:come funziona
La replica in MySQL esiste da molto tempo e si è evoluta nel corso degli anni. Esistono diversi modi per abilitare la replica di MySQL, tra cui Group Replication, Galera Clusters, "Master to Slave" asincrono. Per confrontare l'architettura Oracle e MySQL, ci concentreremo sui formati di replica in quanto sono la base per tutti i vari tipi di replica.
Innanzitutto, i diversi formati di replica corrispondono al formato di registrazione binario specificato nel file di configurazione my.cnf. Indipendentemente dal formato, i log sono sempre archiviati in modo binario, non visualizzabile con un normale editor. Esistono tre tipi di formato:basato su riga, basato su istruzioni e misto. Misto è la combinazione dei primi due. Daremo un'occhiata alle dichiarazioni e alle righe.
Basato sull'affermazione:in questo caso si tratta delle domande scritte. Non tutte le istruzioni che modificano i dati (come INSERT DELETE, UPDATE e REPLACE) possono essere replicate utilizzando la replica basata su istruzioni. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() ecc. non verranno replicati.
Basato su righe:in questo caso, si tratta di modifiche ai record. Tutte le modifiche possono essere replicate. Questa è la forma più sicura di replica. Dalla versione 5.7.7, è l'opzione predefinita.
Ora diamo un'occhiata a cosa sta succedendo sotto il cofano quando la replica è abilitata.
Architettura di replica MySQL Prima di tutto, il database master scrive le modifiche in un file chiamato binary log o binlog. La scrittura nel log binario è in genere un'attività leggera perché le scritture sono memorizzate nel buffer e sequenziali. Il file di registro binario memorizza i dati che uno slave di replica elaborerà in seguito, l'attività del master non dipende da essi. All'avvio della replica, mysql attiverà tre thread. Uno sul padrone, due sullo schiavo. Il master ha un thread, chiamato dump thread, che legge il log binario del master e lo consegna allo slave.
Sullo slave, un processo chiamato IO thread si connette al master, legge gli eventi di log binari dal master appena entrano e li copia in un file di log locale chiamato relay log. Il secondo processo slave, il thread SQL, legge gli eventi da un registro di inoltro archiviato localmente sullo slave di replica e quindi li utilizza.
MySQL supporta la replica concatenata, che è molto facile da configurare. Gli slave che sono anche master devono essere in esecuzione con i parametri --log-bin e --log-slave-update.
Per controllare lo stato della replica e ottenere informazioni sui thread, esegui sullo slave:
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 339
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 635
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 339
Relay_Log_Space: 938
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos: 0-1-8
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
1 row in set (0.00 sec)Configurazione della replica logica di Data Guard in Oracle
-
Crea un database di standby fisico
Per creare un database in standby logico, devi prima creare un database in standby fisico e quindi trasferirlo a un database in standby logico.
-
Interrompi l'applicazione di ripetizione sul database Physical Standby
L'arresto di Redo Apply è necessario per evitare di applicare le modifiche.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
Prepara il database principale per supportare un database di standby logico
Modifica l'attributo VALID_FOR nell'originale LOG_ARCHIVE_DEST_1 e aggiungi LOG_ARCHIVE_DEST_3 per il database logico.
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLECrea un dizionario nei dati di ripristino
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
Converti in un database di standby logico
Per continuare ad applicare i dati di ripristino al database in standby fisico fino a quando non è pronto per la conversione in un database in standby logico, emetti la seguente istruzione SQL:
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
Regola i parametri di inizializzazione per il database di standby logico
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_2= 'SERVICE=severalnines ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines_remote/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE -
Apri il database di standby logico
SQL> ALTER DATABASE OPEN RESETLOGS;Verifica che il database di standby logico funzioni correttamente
v$data_guard_stats vista
SQL> COL NAME FORMAT A20 SQL> COL VALUE FORMAT A12 SQL> COL UNIT FORMAT A30 SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; NAME VALUE UNIT -------------------- ------------ ------------------------------ apply finish time +00 00:00:00 day(2) to second(1) interval apply lag +00 00:00:00 day(2) to second(0) interval transport lag +00 00:00:00 day(2) to second(0) intervalv$logstdby_process view
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE HIGH_SCN ----- ------- ----------- ---------------- ---------- 48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 9 rows selected.
Questi sono i passaggi necessari per creare la replica logica di Oracle Data Guard. Le azioni saranno leggermente diverse se esegui questa operazione con un set di compatibilità non predefinito o database in esecuzione in ambiente Oracle RAC.
Configurazione della replica MySQL
-
Configura database principale. Imposta server_id univoco, specifica diversi log di replica –log-basename (MariaDB) , attiva il log binario. Modifica il file my.cnf con le informazioni seguenti.
log-bin server_id=1 log-basename=master1Accedi al database master e concedi all'utente di replica di accedere ai dati master.
GRANT REPLICATION SLAVE ON *.* TO replication_user -
Avvia entrambi i server con i GTID abilitati.
gtid_mode=ON enforce-gtid-consistency=true -
Configura lo slave per utilizzare il posizionamento automatico basato su GTID.
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
Se vuoi aggiungere lo slave al master con i dati, devi eseguire il backup e ripristinarlo sul server slave.
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlAccedi al database slave ed esegui:
slave> tee dump_replication_insert.log slave> source dump_replication.sql slave> CHANGE MASTER TO MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="password ", MASTER_PORT=port, MASTER_AUTO_POSITION = 1;
