Replica di alcune tabelle da un database postgres a un altro


9

Ho la seguente situazione: ho tre macchine che eseguono database postgresql. Una macchina contiene informazioni sull'account client (chiama questa macchina C), le altre due macchine contengono informazioni di registrazione client (chiama queste L1 e L2). Il motivo della divisione è il caricamento separato su più macchine (quindi alcuni client inviano le informazioni di registrazione a L1, alcune a L2 ... e forse a volte L3, L4, ...).

Quando si recuperano le informazioni di registrazione, in linea di principio mi piacerebbe poter UNIRE tra le tabelle di registrazione su Ln e le tabelle degli account client su C. In realtà non posso fare JOIN in questo modo (e anche se potessi, vorrei per evitare di caricare C).

Il mio pensiero è di replicare le tabelle su C su ciascuna di L1, L2, ... in modo che io possa fare i join. Per quanto riguarda le tabelle di C, C è master e L1, L2, ... sono slave. Ma per le altre tabelle su L1, L2, ... queste macchine sono maestri. Non è esattamente la replica master-master e non è esattamente master-slave.

La replica di postgres (sto eseguendo 9.1) può essere persuasa a fare questo, o se non ci sono altri pacchetti che farebbero il lavoro. In ultima analisi, posso scrivere del codice periodicamente sincronizzare le tabelle (posso tollerare qualche ritardo), ma sarebbe bello non farlo!

Grazie in anticipo.


1
Forse usi FDW sui logger per accedere a C? Tuttavia, ciò comporterebbe un calo delle prestazioni su C. Viste materializzate potrebbero ridurre il riscontro delle prestazioni, ma non sono del tutto sicuro di come PostgreSQL rilevi gli aggiornamenti della tabella esterna. Se lo fa automaticamente (cosa che la conclusione della documentazione di Materialized View sembra suggerire), questo potrebbe risolvere completamente il tuo problema. Queste sono funzioni 9.3, tuttavia. Anche la mailing list molto attiva potrebbe essere di aiuto.
jpmc26

Risposte:


4

Su PostgreSQL 9.3, puoi usare postgres_fdwper interrogare in modo trasparente la tabella esterna sull'altro computer.

Nelle versioni precedenti, dblinkpuò essere un'opzione come menzionato da Andrew.

Un'altra opzione è quella di utilizzare uno strumento come Londiste o Slony-I per replicare le tabelle desiderate. Raccomando di usare Londiste per questo, sarà molto più semplice. Crea trigger sulla tabella per rilevare l'inserimento / aggiornamento / eliminazione e li replica utilizzando il proprio client / server e un sistema di accodamento sull'altro database, dove inserisce / aggiorna / elimina. Lo uso in produzione su diversi siti client e funziona molto bene.

Un'opzione futura (si spera in PostgreSQL 9.5) sarà la replica logica dello streaming dei log, l'estrazione del changeset logico e la replica bidirezionale, che consentirà di replicare singoli database o tabelle a livello SQL. Parte del lavoro per questo è stato affidato a PostgreSQL 9.4, ma non abbastanza per renderlo utile per quello che vuoi fare.


3

A tale scopo, è necessario utilizzare dblink e viste materializzate. Entrambe le funzionalità sono integrate nelle ultime versioni di Postgres:

http://www.postgresql.org/docs/9.3/static/rules-materializedviews.html

http://www.postgresql.org/docs/9.3/static/dblink.html

Fondamentalmente si crea un Mview su ogni database L1, L2 ... con i dati estratti dalle tabelle su C, quindi si utilizza Mview refresh per aggiornare periodicamente i Mvview con la frequenza necessaria. I dati vengono archiviati localmente, quindi accedervi è molto veloce. Questo è adatto solo se i dati sono relativamente statici e non ti dispiace che i database locali occasionalmente abbiano informazioni leggermente obsolete. È necessario impostare le frequenze di aggiornamento per gestirlo in modo appropriato e, se non è accettabile, utilizzare semplicemente un collegamento al database e gestire la lentezza risultante.

Se sono necessarie funzionalità aggiuntive, il progetto snapshot offre funzionalità avanzate come aggiornamenti rapidi e registri snapshot:

http://pgfoundry.org/projects/snapshot/

Con questo puoi fare in modo che gli aggiornamenti aggiornino solo le righe che devono essere aggiornate, il che può renderle estremamente veloci per set di dati di grandi dimensioni, non elastici, riducendo al minimo l'interruzione dell'app. Per impostazione predefinita, le visualizzazioni video vengono completamente eliminate e ricreate in Postgres, il che può essere molto negativo per le prestazioni per ovvi motivi.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.