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

Differenza tra replica di flusso e replica logica

TL;DR :la replica logica invia le modifiche riga per riga, la replica fisica invia le modifiche ai blocchi del disco. La replica logica è migliore per alcune attività, la replica fisica per altre.

Si noti che in PostgreSQL 12 (attuale al momento dell'aggiornamento) la replica logica è stabile e affidabile, ma piuttosto limitata. Usa la replica fisica se stai ponendo questa domanda.

La replica in streaming può essere replica logica. È tutto un po' complicato.

Spedizione WAL vs streaming

Esistono due modi principali per inviare i dati dal master alla replica in PostgreSQL:

  • Spedizione WAL o archiviazione continua , dove i singoli file di registro write-ahead vengono copiati da pg_xlog dal archive_command in esecuzione sul master in un'altra posizione. Un restore_command configurato nel recovery.conf della replica viene eseguito sulla replica per recuperare gli archivi in ​​modo che la replica possa riprodurre il WAL.

    Questo è ciò che viene utilizzato per la replica point-in-time (PITR), che viene utilizzato come metodo di backup continuo.

    Non è richiesta alcuna connessione di rete diretta al server master. La replica può avere lunghi ritardi, specialmente senza un archive_timeout impostare. La spedizione WAL non può essere utilizzata per la replica sincrona.

  • replica in streaming , in cui ogni modifica viene inviata a uno o più server di replica direttamente tramite una connessione TCP/IP nel momento in cui si verifica. Le repliche devono avere una connessione di rete diretta configurata dal master nel loro recovery.conf primary_conninfo di opzione.

    La replica in streaming ha un ritardo minimo o nullo fintanto che la replica è abbastanza veloce da tenere il passo. Può essere utilizzato per la replica sincrona . Non è possibile utilizzare la replica in streaming per PITR, quindi non è molto utile per il backup continuo. Se elimini una tabella sul master, oops, viene eliminata anche sulle repliche.

Pertanto, i due metodi hanno scopi diversi.

Streaming asincrono vs sincrono

Inoltre, c'è il sincrono e asincrono replica in streaming:

  • Nella replica in streaming asincrona le repliche possono rimanere indietro rispetto al master nel momento in cui il master è più veloce/occupato. Se il master si arresta in modo anomalo, potresti perdere dati che non sono stati ancora replicati.

    Se la replica asincrona è troppo indietro rispetto al master, il master potrebbe eliminare le informazioni necessarie alla replica se max_wal_size (in precedenza era chiamato wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's pg_wal(was pg_xlog) potrebbe riempirsi e interrompere il funzionamento del master fino a quando lo spazio su disco non viene liberato se max_wal_size è troppo alto o è stato utilizzato uno slot.

  • Nella replica sincrona il master non termina il commit fino a quando una replica non ha confermato di aver ricevuto la transazione. Non perdi mai dati se il master si arresta in modo anomalo e devi eseguire il failover su una replica. Il master non eliminerà mai i dati necessari alla replica né riempirà il suo xlog e non esaurirà lo spazio su disco a causa dei ritardi della replica. In cambio, può causare un rallentamento del master o addirittura smettere di funzionare se le repliche hanno problemi e ha sempre un impatto sulle prestazioni del master a causa della latenza della rete.

    Quando sono presenti più repliche, solo una è sincrona alla volta. Vedi synchronous_standby_names .

Non puoi avere il log shipping sincrono.

Puoi effettivamente combinare il log shipping e la replica asincrona per evitare di dover ricreare una replica se è troppo indietro, senza rischiare di influenzare il master. Questa è una configurazione ideale per molte distribuzioni, combinata con il monitoraggio di quanto la replica è indietro rispetto al master per assicurarsi che rientri nei limiti di ripristino di emergenza accettabili.

Logico vs fisico

Oltre a quello abbiamo logico vs fisico replica in streaming, come introdotto in PostgreSQL 9.4:

  • In replica fisica in streaming le modifiche vengono inviate quasi a livello di blocco del disco, come "all'offset 14 della pagina del disco 18 della relazione 12311, ha scritto tupla con valore esadecimale 0x2342beef1222....".

    La replica fisica invia tutto :il contenuto di ogni database nell'installazione di PostgreSQL, tutte le tabelle in ogni database. Invia le voci dell'indice, invia i dati della tabella completamente nuovi quando VACUUM FULL , invia i dati per le transazioni di cui è stato eseguito il rollback, ecc. Quindi genera molto "rumore" e invia molti dati in eccesso. Richiede inoltre che la replica sia completamente identica, quindi non puoi fare nulla che richieda una transazione, come la creazione di tabelle temporanee o non registrate. L'esecuzione di query sulla replica ritarda la replica, pertanto è necessario annullare le query lunghe sulla replica.

In cambio, è semplice ed efficiente applicare le modifiche alla replica e la replica è affidabile esattamente come il master. DDL viene replicato in modo trasparente, proprio come tutto il resto, quindi non richiede una gestione speciale. Può anche eseguire lo streaming di grandi transazioni mentre accadono, quindi c'è poco ritardo tra il commit sul master e il commit sulla replica anche per grandi modifiche.

La replica fisica è matura, ben testata e ampiamente adottata.

  • replica flusso logico , nuovo in 9.4, invia le modifiche a un livello superiore e in modo molto più selettivo.

Replica un solo database alla volta. Invia solo modifiche di riga e solo per transazioni impegnate, e non deve inviare dati di vuoto, modifiche all'indice, ecc. Può inviare selettivamente dati solo per alcune tabelle all'interno di un database. Questo rende la replica logica molto più efficiente in termini di larghezza di banda.

Operare a un livello superiore significa anche che è possibile eseguire transazioni sui database di replica. È possibile creare tabelle temporanee e non registrate. Anche tavoli normali, se vuoi. Puoi utilizzare involucri di dati esterni, viste, creare funzioni, qualunque cosa tu voglia. Non è nemmeno necessario annullare le query se durano troppo a lungo.

La replica logica può essere utilizzata anche per creare una replica multi-master in PostgreSQL, cosa che non è possibile utilizzando la replica fisica.

In cambio, tuttavia, non può (attualmente) trasmettere in streaming grandi transazioni mentre accadono. Deve aspettare finché non si impegnano. Quindi può esserci un lungo ritardo tra il commit di una grande transazione sul master e l'applicazione alla replica.

Riproduce le transazioni rigorosamente in ordine di commit, quindi piccole transazioni veloci possono rimanere bloccate dietro una grande transazione ed essere ritardate per un bel po'.

DDL non viene gestito automaticamente. È necessario mantenere sincronizzate le definizioni delle tabelle tra master e replica, oppure l'applicazione che utilizza la replica logica deve disporre delle proprie strutture per farlo. Può essere complicato farlo bene.

Il processo di applicazione in sé è più complicato di "scrivere alcuni byte dove mi viene detto". Richiede anche più risorse sulla replica rispetto alla replica fisica.

Le attuali implementazioni della replica logica non sono mature, ampiamente adottate o particolarmente facili da usare.

Troppe opzioni, dimmi cosa fare

Uff. Complicato, eh? E non sono nemmeno entrato nei dettagli di replica ritardata, slot, max_wal_size , timeline, come funziona la promozione, Postgres-XL, BDR e multimaster, ecc.

Quindi cosa dovresti fare ?

Non esiste un'unica risposta giusta. Altrimenti PostgreSQL supporterebbe solo in un modo. Ma ci sono alcuni casi d'uso comuni:

Per backup e ripristino di emergenza usa pgbarman per eseguire backup di base e conservare WAL per te, fornendo backup continuo facile da gestire. Dovresti comunque prendere pg_dump periodici backup come assicurazione extra.

Per alta disponibilità con zero rischi di perdita di dati usa la replica sincrona in streaming.

Per elevata disponibilità con basso rischio di perdita di dati e prestazioni migliori dovresti usare la replica di streaming asincrona. O avere l'archiviazione WAL abilitata per il fallback o utilizzare uno slot di replica. Monitora quanto la replica è dietro il master utilizzando strumenti esterni come Icinga.

Riferimenti