PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Streaming PostgreSQL e replica logica – Confronto

La replica delle informazioni archiviate nel database è essenziale per la distribuzione dei dati e per garantire un backup che può essere utilizzato per il ripristino di emergenza, nel caso qualcosa vada storto.

La replica di PostgreSQL è disponibile in due forme ed entrambe hanno i loro usi di nicchia. Comprendere come applicare uno o entrambi questi metodi di replica dei dati può semplificare i processi di distribuzione dei dati. L'ultima cosa che vuoi è perdere il lavoro cruciale che hai svolto su un database.

Diamo un'occhiata ai pro, ai contro e ai casi d'uso della replica in streaming e della logica in PostgreSQL.

Definizione della replica dei dati in PostgreSQL

Se hai già familiarità con la replica dei dati, puoi andare avanti e scorrere fino alla sezione successiva. Ma nel caso in cui non conosci l'ingegneria dei database, vogliamo gettare le basi molto rapidamente.

Come suggerisce il nome, la replica è il processo di copia frequente dei dati da un database in un server di computer a un altro database in un server diverso, in modo che tutti gli utenti abbiano accesso allo stesso livello di informazioni. In informatica, la replica viene utilizzata per eliminare i guasti in un sistema digitale.

La replica elimina i silos di dati, protegge le informazioni preziose e semplifica lo sviluppo.

In PostgreSQL, ci sono due opzioni per la replica:replica logica e in streaming. Questi metodi sono ottimi per diversi casi d'uso e, come sviluppatore, potresti trovarti più propenso a usarne uno rispetto all'altro. Ma è bene capire come utilizzarli entrambi in modo da poter decidere quale applicare in diversi scenari.

Replica logica in PostgreSQL


La replica in streaming è stata introdotta per l'uso con PostgreSQL v10.0. La replica logica funziona copiando/replicando gli oggetti dati e le relative modifiche in base alla loro identità di replica.

In molti casi, l'identità dei dati è una chiave primaria. In PostgreSQL, offre agli utenti un controllo dettagliato sui dati replicati e sulla sicurezza delle informazioni.

Il termine logico viene utilizzato per distinguerlo dalla replica fisica, che fa uso della replica byte per byte e degli indirizzi di blocco esatti. Leggi di più nella documentazione ufficiale di PostgreSQL qui.

Attraverso un modello di pubblicazione e sottoscrizione, funziona consentendo a uno o più abbonati di iscriversi a una o più pubblicazioni su un nodo editore. Gli abbonati possono estrarre informazioni dalle pubblicazioni e ripubblicare i dati per la replica a cascata o una configurazione più complessa.

La replica logica dei dati può anche assumere la forma di replica transazionale. Se l'ingegnere desidera copiare una tabella, può utilizzare questo metodo di replica per acquisire un'istantanea dei dati dalla parte dell'editore e inviarla al database dell'abbonato.

Quando gli abbonati apportano modifiche ai dati originali, il database dell'editore riceve gli aggiornamenti in tempo reale. Per garantire la coerenza transazionale nelle pubblicazioni con un unico abbonamento, l'abbonato deve applicare i dati nello stesso ordine dell'editore.

Pro della replica logica in PostgreSQL

La replica logica consente agli utenti di utilizzare un server di destinazione per le scritture e consente agli sviluppatori di disporre di indici e definizioni di sicurezza diversi. Ciò fornisce una maggiore flessibilità per il trasferimento di dati tra editori e abbonati.

Supporto per versioni incrociate

Inoltre, viene fornito con il supporto per versioni incrociate e può essere impostato tra diverse versioni di PostgreSQL. Fornisce inoltre un filtro basato sugli eventi. Le pubblicazioni possono avere più abbonamenti, semplificando la condivisione dei dati su un'ampia rete.

Carico minimo del server

Rispetto alle soluzioni basate su trigger, ha un carico minimo del server fornendo al contempo flessibilità di archiviazione attraverso la replica di set più piccoli. Come accennato in precedenza, la replica logica dei dati può persino copiare i dati contenuti nelle tabelle partizionate di base.

È inoltre essenziale ricordare che la replica logica dei dati consente la trasformazione dei dati anche durante la configurazione e consente lo streaming parallelo tra i publisher.

Contro della replica logica in PostgreSQL

La replica logica non copierà sequenze, oggetti di grandi dimensioni, viste materializzate, tabelle radice delle partizioni e tabelle esterne.

In PostgreSQL, la replica logica dei dati è supportata solo dalle operazioni DML. Gli sviluppatori non possono utilizzare DDL o troncare e lo schema deve essere definito in anticipo. Inoltre, non supporta la replica reciproca (bidirezionale).

Se gli utenti entrano in conflitto con i vincoli sui dati replicati in una tabella, la replica si interrompe. L'unico modo per riprendere la replica è se la causa del conflitto viene risolta.

Un conflitto non intenzionale può fermare lo slancio della tua squadra, quindi devi capire come risolvere rapidamente eventuali problemi.

Se il conflitto non viene risolto rapidamente, lo slot di replica si bloccherà nella sua condizione attuale, il nodo publisher inizierà ad accumulare registri di scrittura in anticipo (WAL) e alla fine il nodo finirà per esaurire lo spazio su disco.

Usa dei casi per la replica logica in PostgreSQL

Molti ingegneri utilizzeranno la replica logica per:

  • Distribuzione delle modifiche all'interno di un singolo database o sottoinsieme di database agli abbonati in tempo reale
  • Unire più database in un database centrale (spesso per uso analitico)
  • Creazione di repliche su varie versioni di PostgreSQL
  • Distribuzione di repliche tra istanze PostgreSQL su piattaforme diverse, come Linux su Windows
  • Condivisione dei dati replicati con altri utenti o gruppi
  • Distribuzione di un sottoinsieme di database tra più database

Replica in streaming in PostgreSQL


La replica in streaming è stata introdotta per l'uso con PostgreSQL 9.0. Il processo invia e applica i file WAL (Write-Ahead Logging) da un server di database principale o principale a una replica oa un database ricevente. I WAL vengono utilizzati per la replica e per garantire l'integrità dei dati.

Come funziona la replica in streaming

La replica in streaming funziona per colmare il divario tra i trasferimenti di dati inerente al log shipping basato su file, che attende fino a quando un WAL raggiunge la capacità massima per spedire i dati.

Trasmettendo i record WAL, i server di database trasmettono i record WAL in blocchi per sincronizzare i dati. Il server di standby si connette alla replica e riceve i blocchi WAL man mano che vengono inviati.

Con la replica in streaming, l'utente deve decidere se impostare la replica asincrona o sincrona. Quando la replica in streaming viene inizialmente distribuita, per impostazione predefinita verrà utilizzata la replica asincrona.

Ciò indica che c'è un ritardo tra la modifica iniziale sul primario e il riflesso di tale modifica sulla replica. L'asincronizzazione apre la porta a una potenziale perdita di dati se il master si arresta in modo anomalo prima che le modifiche vengano copiate o se la replica non è sincronizzata così tanto con l'originale da aver già scartato i dati pertinenti per apportare le modifiche.

La replica sincrona è un'opzione molto più sicura perché apporta modifiche in tempo reale. Il trasferimento dal master alla replica è considerato incompleto finché entrambi i server non verificano le informazioni. Una volta confermate le modifiche ai dati, il trasferimento viene registrato sui WAL di entrambi i server.

Indipendentemente dal fatto che utilizzi la replica asincrona o sincrona, le repliche devono essere connesse al master tramite una connessione di rete. Inoltre, è essenziale che gli utenti impostino i privilegi di accesso per i flussi WAL della replica, in modo che le informazioni non vengano compromesse.

I vantaggi della replica in streaming in PostgreSQL

Uno dei vantaggi più significativi dell'utilizzo della replica in streaming è che l'unico modo per perdere dati è se sia il server primario che quello di ricezione si bloccano contemporaneamente. Se stai consegnando informazioni importanti, la replica in streaming garantisce il salvataggio di una copia del tuo lavoro.

Gli utenti possono connettere più di un server di standby al server primario e i registri verranno trasmessi in streaming dal primario a ciascuno degli standby collegati. Se una delle repliche subisce un ritardo o viene disconnessa, lo streaming continuerà sulle altre repliche.

L'impostazione del log shipping tramite la replica in streaming non interferirà con nulla che l'utente stia attualmente eseguendo nel database primario. Se il server di dati primario deve essere spento, attenderà che i record aggiornati siano stati inviati alla replica prima di spegnersi.

Contro della replica in streaming in PostgreSQL

La replica in streaming non copia le informazioni in una versione o un'architettura diversa, modifica le informazioni sui server di standby e non offre una replica granulare.

Soprattutto con la replica asincrona dei dati in streaming, i file WAL meno recenti che non vengono ancora copiati nella replica possono essere riciclati quando l'utente apporta modifiche al master. Per assicurarsi che i file vitali non vengano persi, l'utente può impostare wal_keep_segments su un valore più alto.

Senza le credenziali di autenticazione utente configurate per i server di replica, può essere facile estrarre dati sensibili. Affinché gli aggiornamenti in tempo reale avvengano tra il master e la replica, l'utente deve modificare il metodo di replica dalla replica asincrona predefinita alla replica sincrona.

Use Case per la replica in streaming in PostgreSQL

Molti ingegneri utilizzeranno la replica in streaming per:

  • Creazione di un backup per il loro database primario in caso di guasto del server o perdita di dati
  • Promuovere una soluzione ad alta disponibilità con il minor ritardo di replica possibile
  • Scaricare query di grandi dimensioni per alleviare parte dello stress sul sistema principale
  • Distribuzione dei carichi di lavoro del database su più macchine, specialmente per i formati di sola lettura

Cosa c'è in serbo per il futuro?

Il PostgreSQL Global Development Group ha annunciato il rilascio di PostgreSQL 14 il 30 settembre 2021. La nuova versione è stata caricata con aggiornamenti sia in streaming che nelle repliche logiche attraverso la piattaforma.

Per la replica in streaming, la versione 14 consente agli utenti di:

  • Imposta il parametro del server log_recovery_conflict_waits per segnalare automaticamente i lunghi tempi di attesa del conflitto di ripristino
  • Sospendere il ripristino su un server hot standby quando si alterano i parametri su un server primario (invece di spegnere immediatamente lo standby)
  • Usa la funzione pg_get_wal_replay_pause_state() per segnalare lo stato di recupero in modo più dettagliato
  • Fornire un parametro del server di sola lettura in_hot_standby
  • Tronca rapidamente le tabelle piccole durante il ripristino su cluster con un numero elevato di buffer condivisi
  • Consenti la sincronizzazione del file system all'inizio del ripristino del crash tramite Linux
  • Usa la funzione pg_xact_commit_timestamp_origin() su una transazione specificata per restituire il timestamp del commit e l'origine della replica
  • Usa la funzione pg_last_committed_xact() per aggiungere l'origine della replica al record restituito
  • Utilizza controlli standard per i permessi delle funzioni per alterare le funzioni di origine della replica (l'impostazione predefinita limita ancora l'accesso ai superutenti)

Per la replica logica, la versione 14 consente agli utenti di:

  • Trasmetti lunghe transazioni in corso agli abbonati con l'API di replica logica
  • Consenti più transazioni durante le repliche di tabelle
  • Genera sottotransazioni WAL-log immediate e associazioni XID di primo livello
  • Usa la funzione pg_create_logical_replication_slot() per migliorare le API di decodifica logica per commit a due fasi
  • Aggiungi messaggi di invalidamento della cache al WAL durante il completamento del comando per consentire lo streaming logico delle transazioni in corso
  • Controlla quali messaggi di decodifica logica vengono inviati al flusso di replica
  • Utilizza la modalità di trasferimento binario per repliche più rapide
  • Filtra la decodifica per XID

PostgreSQL sta già lavorando alla versione 15, che dovrebbe essere rilasciata nel terzo trimestre del 2022. Uno dei problemi relativi alla replica da affrontare nella versione più recente include la prevenzione dell'uso di variabili ereditate dall'ambiente server nella replica in streaming. Ma poiché più utenti si adattano alla versione 14, PostgreSQL probabilmente aggiungerà più attività per migliorare le funzioni di replica.

Un rapido confronto tra replica PostgreSQL:replica logica e replica in streaming

Replica logica Replica in streaming
Modello Da editore a abbonato Master da replicare
Replica transazionale No
Lacune nella replica Un conflitto interromperà la replica Asincrono – può causare un ritardo tra il trasferimento dei dati tra il primario e la replica; sincrono:i dati vengono persi solo se tutti i server collegati si bloccano contemporaneamente
Replica su diverse piattaforme o versioni di PostgreSQL No
Sicurezza L'accesso ai dati è limitato agli abbonati Deve impostare le credenziali di accesso per mantenere i dati al sicuro
Dimensioni delle repliche Meglio per repliche granulari Meglio per repliche su larga scala
Particolarmente utile per Unire più sistemi in un database Creazione di un database di backup

Conclusione

Ci auguriamo che questa guida sia utile durante l'impostazione delle funzioni di replica. Se hai domande o altro che vorresti sapere su come ScaleGrid può aiutarti con le tue implementazioni PostgreSQL, contatta uno dei nostri numerosi esperti di database.

Ti interessa saperne di più su ScaleGrid?

Per saperne di più su come ScaleGrid può aiutarti a gestire i tuoi database, contattaci e ti mostreremo tutto ciò che il nostro DBaaS ha da offrire. Scopri di più su come ScaleGrid ti consente di concentrarti maggiormente sullo sviluppo del tuo prodotto e meno sulla gestione dei database.