Replica in streaming PostgreSQL e replica logica

Mi considero un po' un esploratore. In certe cose che è. Di solito ordino sempre lo stesso cibo da un ristorante familiare perché la paura di una delusione supera la mia apprensione nel provare qualcosa di nuovo.

E, naturalmente, un essere umano affamato tende a mangiare giusto?

Tuttavia, quando si tratta di tecnologia, in particolare SQL (PostgreSQL), tendo a inciampare a tutta velocità (la mia definizione di esplorazione) in aree spesso sconosciute, con la speranza di imparare. Quale modo migliore per imparare dell'esperienza?

Quindi cosa diavolo ha a che fare questo divagazione con la replica logica e in streaming in PostgreSQL?

Sono un principiante assoluto in queste aree con zero conoscenze. Sì, in quest'area di Postgres ho la stessa comprensione che ho in astrofisica.

Ho detto che non avevo alcuna conoscenza?

Pertanto, in questo post del blog, cercherò di assimilare le differenze in questi tipi di replica. Senza l'esperienza pratica nel mondo reale, non posso prometterti il ​​"Sii tutto alla fine ' manoscritto per la replica.

Probabilmente, altri meno esperti in questa particolare area (come me) trarrebbero vantaggio da questo post sul blog.

Utenti esperti e sviluppatori insieme per il viaggio, spero di vederti nei commenti qui sotto.

Un paio di definizioni di base

In senso lato, cosa significa Replicazione?

La replica come definita su Wikizionario ha questo da dire:

"Processo mediante il quale un oggetto, una persona, un luogo o un'idea può essere copiato imitato o riprodotto."

Tuttavia, il quinto elemento elencato è più applicabile a questo post del blog e credo che dovremmo esaminarlo anche noi:

"(informatica) Il processo di copia di dati elettronici frequenti da un database in un computer o server a un database in un altro in modo che tutti gli utenti condividano lo stesso livello di informazioni. Utilizzato per migliorare la tolleranza agli errori del sistema."

Ora c'è qualcosa in cui possiamo entrare. La menzione di copiare i dati da un server o database a un altro? Ora siamo in un territorio familiare...

Quindi, aggiungendo ciò che sappiamo da quella definizione, quali sono le definizioni di replica in streaming e replica logica?

Vediamo cosa ha da offrire PostgreSQL Wiki:

Streaming Replication:"fornisce la capacità di inviare e applicare continuamente i record WAL XLOG a un certo numero di server in standby per mantenerli aggiornati.

E la documentazione di PostgreSQL ha questa definizione per la replica logica:

"La replica logica è un metodo per replicare gli oggetti dati e le loro modifiche, in base alla loro identità di replica (di solito una chiave primaria). Utilizziamo il termine logico in contrasto con la replica fisica, che utilizza indirizzi di blocco esatti e replica byte per byte. "

Anche il capitolo 19.6 La replica dalla documentazione ufficiale è piena zeppa di chicche, quindi assicurati di visitare quella fonte.

Di seguito, cercherò di trasmettere le differenze in parole povere. (Ricorda, se inciampo, sono un novizio.) Questa è una panoramica di "alto livello" estremo.

Replica logica

Un database di "origine" crea una PUBBLICAZIONE utilizzando il comando CREATE PUBLICATION. (Penso a questo in termini semplici come al 'mittente'.)

La documentazione lo definisce come editore.

Questo database dell'editore contiene i dati che desideriamo replicare. Tuttavia, dobbiamo avere qualcosa su cui replicare ed è qui che entrano in gioco le controparti dell'editore. L'"abbonato". Nota che ho inserito una forma plurale alternativa perché da quello che ho trovato attraverso le ricerche online, è una configurazione pratica per avere più abbonati.

Un "sottoscrittore" (potrebbe anche essere pensato come il database di replica) crea un ABBONAMENTO a un database "di origine" (editore) che definisce le informazioni di connessione e tutte le pubblicazioni a cui si iscrive.

È possibile che un abbonato sia anche un editore, creando la propria PUBBLICAZIONE a cui possono iscriversi altri abbonati.

Cosa succede adesso?

Eventuali modifiche ai dati che si verificano sull'editore vengono inviate all'abbonato. Che out of the box, è tutto, ma può essere configurato o limitato a determinate operazioni (es. INSERT, UPDATE o DELETE).

Esempio di alto livello:

Supponiamo di aggiornare una o più righe su una determinata tabella nel publisher, tali aggiornamenti e modifiche vengono replicati, sull'istanza dell'abbonato o su più abbonati se quel tipo di configurazione è implementato.

Ecco alcune cose da ricordare che mi sono sentito degno di menzionare:

• La configurazione wal_level del database dell'editore deve essere impostata su logica.
• La replica logica non ha alcun comando DDL (Data Definition Language).
• Dalla pagina Conflitti nella documentazione:"La replica logica si comporta in modo simile alle normali operazioni DML in quanto i dati verranno aggiornati anche se sono stati modificati localmente sul nodo dell'abbonato. Se i dati in entrata violano qualsiasi vincolo, la replica si interromperà. Questo viene definito conflitto. Quando si replicano le operazioni UPDATE o DELETE, i dati mancanti non produrranno un conflitto e tali operazioni verranno semplicemente ignorate."
• Le tabelle del publisher devono avere un modo per identificarsi (denominato "identità di replica") per replicare correttamente le operazioni DML (UPDATE e DELETE) in qualsiasi replica per le righe interessate. Se la tabella ha una chiave primaria questa è l'impostazione predefinita (mi sembra la scelta del suono), ma in assenza di una chiave primaria, sono disponibili altre opzioni di configurazione. L'intera riga potrebbe essere utilizzata se non esiste un'altra chiave candidata (definita "completa"), sebbene la documentazione menzioni che in genere non è una soluzione efficiente. (Vedi la sezione REPLICA IDENTITY nei documenti per una descrizione di livello inferiore su come impostarla)

Restrizioni

La documentazione nella sezione 31.4. Restrictions contiene alcuni promemoria chiave sulle restrizioni su cui trascurerò. Assicurati e controlla la pagina collegata sopra per la verbosità esatta.

• Lo schema del database e tutti i comandi DDL non sono supportati nella replica. Si suggerisce che forse pg_dump potrebbe essere utilizzato inizialmente, ma comunque, dovresti aggiornare tu stesso eventuali ulteriori modifiche e progressi nello schema per tutte le repliche.
• I dati nelle colonne della sequenza verranno replicati. Ma la sequenza stessa rifletterebbe solo il valore iniziale. Per le letture, va bene. Ma se questo è il tuo punto di riferimento per il failover, dovresti AGGIORNARE tu stesso al valore corrente. I documenti suggeriscono pg_dump qui.
• Il troncamento non è ancora supportato.
• La replica di oggetti di grandi dimensioni non è supportata.
• Le viste, le viste materializzate, le tabelle radice delle partizioni o le tabelle esterne non sono supportate né dall'editore né dall'abbonato.

Casi d'uso comuni segnalati

• Sei interessato solo a determinati dati e modifiche ai dati che effettivamente replichi anziché replicare solo l'intero database.
• Quando hai bisogno di repliche per operazioni di sola lettura, come uno scenario di analisi.
• Consentire agli utenti oa diversi sottoinsiemi di utenti l'accesso limitato o monitorato ai dati.
• Distribuzione dei dati.
• Compatibilità con altre versioni di PostgreSQL.

Replica in streaming

Dalla ricerca, lettura e studio della replica in streaming, una cosa che ho capito subito è la scelta di impostare la replica asincrona (l'impostazione predefinita) o sincrona.

Ah, termini più sconosciuti eh?

Ecco la mia definizione di "alto livello" di entrambi:

Con la replica asincrona, dopo il commit di una transazione sul server primario, si verifica un leggero ritardo quando viene eseguito il commit della stessa transazione e scritta sulla replica. Esiste la possibilità di perdita di dati con questo tipo di configurazione.

• Uno, supponiamo che il master vada in crash.
• Due, le repliche sono così indietro rispetto al master che ha scartato i dati e le informazioni necessari affinché le repliche fossero addirittura "correnti".

Tuttavia, nella replica sincrona, nessuna transazione è considerata completa, fino a quando non viene confermata sia dal server principale che da quello di replica. Che avrà scritto un commit su entrambi i server WAL.

In termini che ho capito, questo significa che le scritte sul master sono state confermate e scritte anche sulla replica.

Ecco la spiegazione ufficiale della sezione 26.2.8. Replica sincrona nella documentazione ufficiale:

“Quando si richiede la replica sincrona, ogni commit di una transazione di scrittura attende fino a quando non viene ricevuta la conferma che il commit è stato scritto nel registro write-ahead sul disco sia del server primario che di quello di standby. “

Un altro passaggio della documentazione ha una bella carrellata di ciò che deve essere (secondo me), un enorme vantaggio:"L'unica possibilità che i dati possano andare persi è se sia il primario che lo standby subiscono arresti anomali contemporaneamente."

Anche se nulla è impossibile, è comunque una buona garanzia che non rimarrai senza una copia dei tuoi dati.

Ok, sappiamo che dobbiamo scegliere una di queste configurazioni di installazione, ma qual è l'essenza generale?

In poche parole, Streaming Replication invia e applica file WAL (Write Ahead Log) da un server di database (master o primario) a una "replica" (database di ricezione).

Ma c'è un avvertimento qui da tenere a mente. Potenzialmente, i file WAL del master possono essere riciclati prima che lo standy li abbia ottenuti. Un modo per mitigare questo è aumentare l'impostazione wal_keep_segments a un valore più alto.

Punti sulla replica in streaming

• Per impostazione predefinita, la replica in streaming è asincrona, il che significa che c'è un ritardo (forse piccolo) tra le transazioni impegnate sul master e la loro visibilità sulla replica.
• Le repliche si connettono al master tramite una connessione di rete.
• Fai attenzione all'autenticazione. Vedi qui dalla documentazione:"È molto importante che i privilegi di accesso per la replica siano impostati in modo che solo gli utenti fidati possano leggere il flusso WAL perché è facile estrarre da esso informazioni privilegiate"

Quando utilizzare la replica in streaming

• Un uso comune (soprattutto nell'analisi) fornisce una replica di "sola lettura" per alleggerire il server primario.
• Hai bisogno di un ambiente ad alta disponibilità.
• Impostazione utile per il failover sul server hot standby in caso di guasto del server principale.