Come replicare i dati PostgreSQL su siti remoti

In un ambiente di database affollato con database di dimensioni maggiori, la necessità di replicare i dati in tempo reale è un evento comune. Le applicazioni spesso richiedono che i dati di produzione vengano replicati in tempo reale su siti remoti per esigenze di analisi e altre operazioni aziendali critiche.

I DBA devono anche garantire che i dati vengano replicati continuamente nei siti remoti per soddisfare vari requisiti. Questi requisiti, tuttavia, potrebbero non essere sempre la replica dell'intero database; può anche essere necessario replicare solo un sottoinsieme di dati (come una tabella o un insieme di tabelle o dati da più tabelle utilizzando un SQL per analisi, report ecc.)

In questo blog ci concentreremo su come replicare le tabelle in database remoti in tempo reale.

Che cos'è la replica a livello di tabella?

La replica a livello di tabella è il meccanismo per replicare i dati di una tabella specifica o di un insieme di tabelle da un database (origine) a un altro database (destinazione) ospitato in remoto in un ambiente distribuito. La replica a livello di tabella garantisce che i dati della tabella siano distribuiti continuamente e rimangano coerenti tra i siti replicati (di destinazione).

Perché utilizzare la replica a livello di tabella?

La replica a livello di tabella è un'esigenza essenziale in ambienti più grandi, complessi e altamente distribuiti. Nella mia esperienza, c'era sempre la necessità di replicare un insieme di tabelle da un database di produzione a un data warehousing per scopi di reporting. I dati devono essere replicati continuamente per garantire che i report ottengano i dati più recenti. In ambienti critici, non è possibile tollerare l'obsolescenza dei dati, pertanto le modifiche ai dati che si verificano in produzione devono essere replicate immediatamente nel sito di destinazione. Questa può essere una vera sfida per il DBA che deve prevedere vari fattori per garantire una replica efficiente e regolare delle tabelle.

Esaminiamo alcuni requisiti risolti dalla replica a livello di tabella:

• I report possono essere eseguiti su un database in un ambiente diverso dalla produzione, come il data warehousing
• Un ambiente di database distribuito con applicazioni distribuite che estraggono dati da più siti. In caso di applicazioni Web o mobili distribuite, la copia degli stessi dati dovrebbe essere disponibile in più posizioni per soddisfare le diverse esigenze applicative per le quali la replica a livello di tabella potrebbe essere una buona soluzione
• Le applicazioni del libro paga che richiedono che i dati di vari database situati in diversi data center geograficamente distribuiti o istanze cloud siano disponibili in un database centralizzato

Vari fattori che influiscono sulla replica a livello di tabella:cosa cercare

Come accennato in precedenza, i DBA devono prendere in considerazione una varietà di componenti e fattori in tempo reale per progettare e implementare un efficace sistema di replica a livello di tabella.

Struttura del tavolo

Il tipo di tabella di dati adatta ha un grande impatto sulle prestazioni di replica. Se la tabella ospita una colonna BYTEA con dati binari di dimensioni maggiori, le prestazioni di replica possono subire un impatto. L'impatto della replica su rete, CPU e disco deve essere valutato attentamente.

Dimensione dei dati

Se la tabella da migrare è troppo grande, la migrazione iniziale dei dati richiederebbe risorse e tempo, i DBA devono assicurarsi che il database di produzione non venga influenzato.

Risorse infrastrutturali

L'infrastruttura deve disporre di risorse adeguate per garantire la creazione di un sistema di replica affidabile e stabile. Quali componenti dell'infrastruttura devono essere considerati?

CPU

La replica dei dati fa molto affidamento sulle CPU. Durante la replica dalla produzione, le CPU non devono esaurirsi, il che può influire sulle prestazioni di produzione.

Rete

È fondamentale per le prestazioni di replica. La latenza di rete tra i database di origine e di destinazione deve essere valutata mediante stress test per garantire che la larghezza di banda sia sufficiente per una replica più veloce. Inoltre, la stessa rete potrebbe essere utilizzata da altri processi o applicazioni. Quindi, la pianificazione della capacità deve essere eseguita qui.

Memoria

Deve essere disponibile memoria adeguata per garantire che i dati siano memorizzati nella cache per una replica più rapida.

Aggiornamenti della tabella delle fonti

Se le modifiche ai dati nella tabella di origine sono pesanti, il sistema di replica deve essere in grado di sincronizzare le modifiche ai siti remoti il ​​prima possibile. La replica finirà per inviare un numero elevato di richieste di sincronizzazione al database di destinazione che può richiedere molte risorse.

Anche il tipo di infrastruttura (data center o cloud) può influire sulle prestazioni di replica e può porre delle sfide. Anche l'attuazione del monitoraggio potrebbe essere una sfida. Se c'è un ritardo e alcuni dati mancano nel database di destinazione, potrebbe essere difficile da monitorare e non può essere sincrono

Come implementare la replica delle tabelle

La replica a livello di tabella in PostgreSQL può essere implementata utilizzando una varietà di strumenti esterni (commerciali o open source) disponibili sul mercato o utilizzando flussi di dati personalizzati.

Diamo un'occhiata ad alcuni di questi strumenti, alle loro caratteristiche e capacità...

Slone

Slony è uno degli strumenti più popolari utilizzati per replicare in modo asincrono singole tabelle o tabelle specifiche in tempo reale da un database PostgreSQL a un altro. Questo è uno strumento basato su Perl che esegue la replica basata su trigger delle modifiche ai dati di una tabella (o set di tabelle) da un database da un sito all'altro. È abbastanza affidabile e ha anni di storia di sviluppo. Sebbene altamente affidabile, essendo uno strumento basato su trigger, può diventare complesso gestire le impostazioni di replica.

Diamo un'occhiata ad alcune capacità di Slony...

Vantaggi dell'utilizzo di Slony

• Supporta la metodologia di replica da master a slave o più slave che aiuta a migliorare la scalabilità di lettura orizzontale. In altre parole, gli schiavi non sono scrivibili
• È possibile configurare più slave su un unico master e supportare anche la metodologia di replica a cascata
• Supporta i meccanismi di switchover e failover
• Un numero elevato di tabelle può essere replicato in gruppi, in parallelo
• Possiamo replicare tra diverse versioni principali delle istanze PostgreSQL, il che rende Slony un'ottima opzione per gli aggiornamenti del database
• Semplice da installare

Svantaggi dell'utilizzo di Slony

• Non supporta la replica DDL
• Alcune modifiche allo schema possono interrompere la replica
• Gli eventi di replica vengono registrati all'interno del database in tabelle di registro specifiche di Slony che possono comportare un sovraccarico di manutenzione.
• Se è necessario replicare un numero enorme di tabelle con set di dati di grandi dimensioni, le prestazioni e la manutenzione potrebbero rappresentare seri problemi
• Trattandosi di una replica basata su trigger, le prestazioni possono risentirne

Bucardo

Bucardo è un altro sistema di replica open source basato su Perl per PostgreSQL che supporta la replica asincrona di dati di tabelle specifici tra due o più istanze di PostgreSQL. Ciò che rende Bucardo diverso da Slony è che supporta anche la replica multi-master.

Diamo un'occhiata ai diversi tipi di meccanismi di replica che bucardo aiuta a implementare...

• Replica multi-master:le tabelle possono essere replicate in entrambe le direzioni tra due o più istanze PostgreSQL e i dati transazionali verranno sincronizzati in modo bidirezionale
• Master-slave:i dati delle tabelle in master verranno replicati in slave in modo asincrono e lo slave è disponibile per le operazioni di lettura
• Modalità di copia completa (Master-slave):Bucardo -/replica tutti i dati dal master al nodo slave cancellando tutti i dati dallo slave

Vantaggi dell'utilizzo di Bucardo

• Semplice da installare
• Supporta le modalità di replica multi-master, master-slave e copia completa
• Può essere utilizzato per aggiornare i database
• La replica può essere eseguita tra diverse versioni di PostgreSQL

Svantaggi dell'utilizzo di Bucardo

• Trattandosi di una replica basata su trigger, le prestazioni possono essere una sfida
• Le modifiche allo schema come i DDL possono interrompere la replica
• La replica di un numero elevato di tabelle può comportare un sovraccarico di manutenzione
• Le risorse dell'infrastruttura devono essere ottimizzate per una replica con buone prestazioni, altrimenti non è possibile ottenere la coerenza.

Replica logica PostgreSQL

La replica logica è una funzionalità incorporata rivoluzionaria di PostgreSQL che aiuta a replicare singole tabelle tramite record WAL. Essendo una replica basata su WAL (simile a Streaming Replication) pg logical si distingue rispetto ad altri strumenti di replica di tabelle. La replica dei dati tramite record WAL è sempre il modo più affidabile e performante per replicare i dati sulla rete. Quasi tutti gli strumenti sul mercato forniscono la replica basata su trigger ad eccezione della replica logica.

Vantaggi dell'utilizzo della replica logica PostgreSQL

• L'opzione migliore quando desideri replicare una singola tabella o un insieme di tabelle
• È una buona opzione se il requisito è migrare tabelle specifiche da vari database a un unico database (come data warehousing o database di reporting) per scopi di reporting o analitici
• Nessun problema di trigger

Svantaggi dell'utilizzo della replica logica PostgreSQL

• La cattiva gestione dei file WAL/file di archivio WAL può rappresentare una sfida per la replica logica
• Non possiamo replicare tabelle senza chiavi primarie o univoche
• DDL e TRUNCATE non vengono replicati
• Il ritardo di replica potrebbe aumentare se i WAL vengono rimossi. Ciò significa che la replica e la gestione WAL devono completarsi a vicenda per garantire che la replica non si interrompa
• Gli oggetti di grandi dimensioni non possono essere replicati

Ecco alcune altre risorse per aiutarti a comprendere meglio la replica logica di PostgreSQL e le differenze tra essa e la replica in streaming.

Wrapper di dati esteri

Sebbene i Foreign Data Wrapper non replichino effettivamente i dati, volevo evidenziare questa funzionalità di PostgreSQL perché può aiutare i DBA a ottenere qualcosa di simile alla replica senza replicare effettivamente i dati. Ciò significa che i dati non vengono replicati dall'origine alla destinazione e le applicazioni possono accedere ai dati dal database di destinazione. Il database di destinazione ha solo una struttura di tabella con un collegamento contenente i dettagli dell'host e del database della tabella di origine e quando l'applicazione esegue una query sulla tabella di destinazione, i dati vengono trasferiti dal database di origine al database di destinazione in modo simile a Database Links. Se gli FDW possono essere d'aiuto, è possibile evitare completamente il sovraccarico della replica dei dati sulla rete. Molte volte ci troviamo in una situazione in cui i rapporti possono essere eseguiti su un database di destinazione remoto senza che i dati siano presenti fisicamente.

Gli FDW sono un'ottima opzione nelle seguenti situazioni -

• Se nel database di origine sono presenti tabelle piccole e statiche, non vale davvero la pena replicare i dati su
• Può essere davvero vantaggioso, se hai tabelle molto grandi nel database di origine e stai eseguendo query aggregate sul database di destinazione.

Vantaggi dell'utilizzo di wrapper di dati esterni

• La replica dei dati può essere completamente evitata, risparmiando tempo e risorse
• Semplice da implementare
• I dati trasferiti sono sempre gli ultimi
• Nessuna manutenzione generale

Svantaggi dell'utilizzo di wrapper di dati esterni

• Le modifiche strutturali alla tabella di origine possono influire sulla funzionalità dell'applicazione nel database di destinazione
• Fa molto affidamento sulla rete e può avere un sovraccarico di rete significativo a seconda del tipo di report in esecuzione
• È previsto un sovraccarico di prestazioni quando le query vengono eseguite più volte poiché ogni volta che viene eseguita una query, i dati devono essere trasferiti sulla rete dal database di origine e possono anche comportare un sovraccarico di prestazioni sul database di origine
• Qualsiasi carico sull'origine può influire sulle prestazioni delle applicazioni sul database di destinazione

Conclusione

• La replica delle tabelle può servire a vari scopi critici per l'azienda
• Può supportare query parallele distribuite in ambienti distribuiti
• L'implementazione della modalità sincrona è quasi impossibile
• Le infrastrutture devono essere adeguatamente capacitate, il che comporta dei costi
• Un'ottima opzione per creare un database centralizzato integrato per scopi analitici e di reporting