Replica multi-master utilizzabile per Postgres?

16

  1. Ho provato Postgres-XC e non implementa ancora SQL completo (come SERIAL)

  2. Postgres-R sembra interessante ma secondo gli sviluppatori "non è pronto per la produzione".

Quindi ho usato pgpool-II 3.0.1. Sì, funziona bene. Ma per quanto posso vedere è solo per 2 nodi PG.

Esiste qualcosa che sia effettivamente pronto per la produzione E in grado di lavorare con più nodi PG?

replication  postgresql 
— mrkafk
fonte
Qualche anno fa abbiamo riscontrato lo stesso problema. Alla fine abbiamo trasferito tutte le nostre cose su Oracle. Spero che tu possa trovare repliche multimaster utilizzabili in questi giorni, non ho guardato ... Buona fortuna, comunque.
— Grufftech,
2
La documentazione di PostgreSQL afferma di utilizzare un'applicazione middleware :) .. " Replica multimaster sincrona . PostgreSQL non offre questo tipo di replica, sebbene il commit in due fasi PostgreSQL (PREPARE TRANSACTION e COMMIT PREPARED) possa essere utilizzato per implementarlo in codice dell'applicazione o middleware "
— warren
Non sei limitato a due nodi.
— foocorpluser
— Neil McGuigan

Risposte:

6

Hai considerato Bucardo ? È multimaster asincrono. Non ha completamente preso piede e non è una soluzione generale, ma potrebbe valere la pena provarlo.

— Peter Eisentraut
fonte
1
Apparentemente non ero abbastanza specifico: ho bisogno della replica sincrona. Inoltre, qual è il significato di questo nelle FAQ? "Bucardo è in grado di replicare tra più di due padroni? No. Attualmente, Bucardo supporta solo padrone per padrone (oltre che padrone di molti schiavi, ovviamente)." Quindi è multi-master o no?
— mrkafk,
4
Solo se la tua definizione di "multi" è "2"!
— hmallett,
Si noti che a partire da Bucardo 5 è stata eliminata la limitazione di soli 2 master
— Joril
3

Sono d'accordo con la valutazione di Peter: al momento non esiste una buona replica multi-master per Postgres. (Fare una vera replica multi-master è un problema molto difficile e non sono innamorato di nessuna delle soluzioni disponibili.)

Cribbando l'elenco di potenziali soluzioni che potresti voler esaminare su Wikipedia:

PostgreSQL offre molteplici soluzioni per la replica multi-master, comprese soluzioni basate sul commit a due fasi. Ci sono Bucardo, Rubyrep, PgPool e PgPool-II, PgCluster e Sequoia e alcune soluzioni proprietarie. Un altro approccio promettente, che implementa una replica entusiasta (sincrona) è Postgres-R, tuttavia è ancora in fase di sviluppo. Un altro progetto che implementa la replica sincrona è Postgres-XC. Anche Postgres-XC è ancora in fase di sviluppo.

— voretaq7
fonte
Caspita, la sola lettura di quell'elenco mi provoca shock e terrore. :)
— Peter Eisentraut,
Per me è depressione e disgusto :-)
— voretaq7
Penserei che sarebbe possibile utilizzare un sistema simile a etcd per la configurazione e le comunicazioni, magari eseguendo qualsiasi istruzione di aggiornamento all'interno del commit in due fasi ... una parte difficile sarebbe tenere fuori un nodo fino a quando non viene raggiunto e corrisponde ad altri nodi .. Mi piacerebbe davvero una soluzione quasi automagica per questo
— Tracker1
3

Questo è fortemente orientato a Java, ma le API client del database nativo possono essere collegate alle origini dati JDBC. Tungsten Myosotis è un esempio di MySQL nativo del bridge JDBC.

  • Tungsten Enterpriese è ottimo per i multi-master asincroni. Penso che funzioni per MySQL, PostgreSQL e Oracle. Può funzionare autonomamente o incorporato in un'applicazione Java. L'ho visto funzionare per MySQL, ma sostengono PostgreSQL. Il componente Replicator è open-source, ma la soluzione completa ha più parti e richiede costi di licenza. Originariamente, Continuing aveva Sequoia per sincrono multi-master, ma lo abbandonarono e crearono Tungsten invece per asincrono multi-master: considerano scalare un business più strategico della coerenza ACID sincrona. Tungsten è scritto in Java, quindi è per questo che offrono Myosotis per colmare i client di database nativi.

  • SymmetricDS è ottimo per i server asincroni multi-master. È open-source. Installa / disinstalla i trigger per acquisire gli aggiornamenti, invece della registrazione bin. Può funzionare autonomamente o incorporato in un'applicazione Java.

  • HA-JDBC è buono per sincrono multi-master. Sostituisce i vecchi software defunti come C-JDBC e Sequoia. È open-source. Utilizza il commit in due fasi e funziona con PostgreSQL, MySQL, Oracle, SQL Server, Derby, Sybase e molti altri tramite dialetti. È principalmente per embedded, quindi incorporalo in un'applicazione Java per collegarlo a PostgreSQL. I blocchi distribuiti, le sequenze, l'ora, il rand e così via sono gestiti da jGroups di Redhat / JBoss. Una bella funzionalità è la modalità di transazione "seriale" anziché "parallela", se l'app ha subito deadlock e non supporta il rollback. Ho usato con successo questa modalità "seriale" per aggiornare un'app legacy che non era a conoscenza del cluster DB, quindi mancava il codice di tentativo di transazione. La modalità seriale ha salvato la giornata ed evitato una brutta riscrittura.

  • H2 è buono per sincrono multi-master. È open-source. Supporta database o cluster autonomi che utilizzano il commit a due fasi, simile all'architettura HA-JDBC, ma è tutto in uno invece di richiedere un componente aggiuntivo per il commit a due fasi. Non sono sicuro che esegua i blocchi distribuiti o dipende da terze parti come jGroups o Hazelcast.

Qualsiasi replica basata su JDBC per PostgreSQL e altri database richiede un bridge nativo per JDBC, a meno che l'applicazione non sia già scritta in Java. Per MySQL, Tungsten Enterprise offre un componente opzionale chiamato Myosotis. Ho usato con successo questo per collegare PHP / Perl / C / mysqlclient a JDBC, dove l'origine dati JDBC è risultata essere un'origine dati proxy HA-JDBC che punta a un cluster MySQL / InnoDB a 4 nodi.

Tungsten supporta PostgreSQL nei componenti Replicator e Router, ma non è sicuro del componente Myosotis. Può essere. I componenti del replicatore / router di tungsteno sono per i server asincroni multi-master, ma Myosotis può collegarti a un back-end JDBC alternativo come HA-JDBC o H2 per sincrono.

Se esiste un bridge PostgreSQL nativo al bridge JDBC, mi piacerebbe saperlo. In teoria, qualsiasi database con un driver JDBC di tipo 4 può essere collegato. JDBC di tipo 4 parla del protocollo del database nativo proprio come l'interfaccia client nativa per quel database, quindi dovrebbe esserci un mapping uno-a-uno delle chiamate native alle chiamate JDBC.

— Justin
fonte
2

La risposta è un clamoroso no.

— Peter Eisentraut
fonte
sono passati alcuni anni da quando ho fatto ricerche, ma la mia azienda è arrivata a questa conclusione quando abbiamo provato.
— Grufftech,
1

Ho usato londiste negli ultimi 2 anni per la replica multi-master in postgresql.

Metti le tue tabelle in coda usando pg_queue e puoi iscrivere quanti altri database vuoi ad ogni coda, la replica è atomica per coda ed è molto resiliant.

Puoi leggere di londiste qui ( http://pgfoundry.org/projects/skytools/ ), questo è ciò che i ragazzi di Skype usano per il loro cluster, anche loro lo hanno creato, quindi è il doppio del bello :)

— lynxman
fonte
Hmm è interessante, ma secondo quello che ho visto qui: wiki.postgresql.org/wiki/… , Londiste è Master-Slave e Asincrono? Quindi, come può essere multi-master? Inoltre, ho davvero bisogno della replica sincrona: la transazione dovrebbe fallire se uno dei nodi del cluster (attivo) fallisce.
— mrkafk,
Questa replica è post-transazionale altrimenti sarebbe piuttosto lenta
— lynxman il
Non intendo sembrare un dolore nel culo (nitpicking), ma ... 1. Ho usato pgpool-II e le transazioni sono passate abbastanza rapidamente (anche se non ho fatto benchmark), e 2. anche se la singola transazione potrebbe essere più lenta, non vedo una buona ragione per cui il throughput complessivo delle transazioni sia basso. Ad ogni modo, forse il punto più importante è come è il multi-master Londiste? Posso scrivere sul server pg 1 e farlo replicare su 2, scrivere sul server pg 2 e farlo replicare sul server 1?
— Mrkafk,
-2

Ho trovato un sistema di replica "multi-master" utilizzabile:

  1. get RabbitMQ http://www.rabbitmq.com/ - è un middleware per messaggi.

  2. configurare un cluster Rabbit MQ in Rabbit.

  3. creare una coda per ciascun nodo in un cluster e collegarli allo scambio di tipi "fanout".

In questo modo un messaggio inviato a qualsiasi nodo e qualsiasi coda viene replicato in tutti gli altri nodi. Ho un codice funzionante per questo!

— mrkafk
fonte
2
@mrafk - pubblicheresti / collegheresti il ​​"codice di lavoro" che hai?
— Warren,
2
Cosa c'entra questo con la replica con Postgres? Questo distribuirà i messaggi, ma dove stai ricevendo i messaggi di dati / gli aggiornamenti dal DB e come sta aggiornando i nodi che ricevono i messaggi sulla coda dei messaggi?
— monksy
3
Questo può essere una soluzione al problema fondamentale che si trovasse di fronte, ma è non è una risposta a questa domanda.
— Tom Anderson
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.