Ja hab schon einiges gelesen. Bin mir aber in gewissen Sachen noch unsicher gewesen.
Ja, BDR bedient sich dieser Funktionen. Aber pglogical in aktuellen Versionen ist keine Open Source mehr.
Aus der Doku:
pglogical3 supports transparent DDL replication, where schema change commands run on provider node(s) are automatically captured and replicated to subscriber node(s) without the need for wrapper functions like pglogical.replicate_ddl_command or external schema management tools.
ok vielen Dank.
Ein umstellen auf aktuelle PostgreSQL Versionen ist leider im Moment nicht möglich.
Für pglogical habe ich folgendes gefunden das wohl auch mit 9.6 läuft.
Ich werde wohl mich erstmal nochmal durch die Doku kämpfen und schauen was für uns letzendlich möglich ist.
Postgres ist eine wirklich tolle Datenbank (und ich arbeite wirklich ungern mit anderen Systemen) aber leider muss man sagen, dass es bei den Replikationsmöglichkeiten seinem Ruf als “most advanced open source database” nicht so ganz gerecht wird.
1 „Gefällt mir“
Ich habe nun versucht mich in PG_BASEBACKUP einzulesen und in WAL-FILES.
Wäre dies eine Möglichkeit die Daten von dem einen Server auf einen anderen zu bekommen?
Jein. pg_basebackup & WAL brauchst Du für eine streaming replication, Du willst aber eine logical replication. Was Du aber u.a. machen mußt ist das wal_level passend einzustellen.
Ok vielen Dank für deine Geduld.
Leider fällt die logical Replication ja bei 9.6 erstmal raus.
Was ich mich Frage ist mit unserem Klient kann ich einen Export machen und dies dann an einem anderen Rechner mit einem lokalen Server wieder importieren und dort wird das dann in die Datenbank eingespielt ohne dass man Probleme hat.
Darum wundert es mich, dass ich dies direkt auf der Datenbank nun nicht so wirklich hinbekommen kann.
Noch mal ganz langsam…
Du gibst heute den Datensatz
4711, Andreas
ein. Das exportierst Du und lädst das auf den anderen. Läuft.
Morgen gibts Du zusätzlich ein:
0815, Max
Du exportierst wieder die Tabelle, diese enthält nun:
4711, Andreas
0815, Max
Diesen Export tüdelst Du wieder auf dem anderen ein, und es macht Bumm, weil
4711, Andreas
da bereits existiert.
DIESES Problem existiert (neben weiteren …), und das mußt Du lösen.
Ok nein das soll anders sein.
Ich exportiere heute 4711 Andreas und lade es rein.
Tag 2:
Exportiere ich nur 0815 Max und lade es rein
Tag3:
Exportiere ich nur Max1234 und lade es rein.
Es wird an jedem Standort ein extra Server erstellt der nur das “neue”(aktuelle) beinhaltet was ich dann importieren will. Das wird manuell in den Server geladen. Soll dann nach D geschickt werden und dort dann importiert werden.
Die Daten sollten also immer unterschiedlich sein.
So sieht zum Beispiel ein table aus.
Genau. Das mußt Du irgendwie hinbekommen. Mit etwas Fleiß kann man das natürlich schaffen, z.B.
- jeder Standort vergibt eigene ID’s (UUID, offset-Methode, Nummernkreise, …)
- z.B. via TRIGGER loggst Du alle Änderungen des Tages in eine extra Tabelle, diese exportierst Du täglich und löscht dann den Inhalt
mal so als Idee… ist aber 'nen Haufen Aufwand.
Ok vielen Dank.
Da dies nur vorrübergehend sein soll da in ein paar Monaten eine generelle Lösung kommen soll wird das wohl dann nichts.
Unsere alternative ist dann wohl nur für jeden Standort einen extra Server einzurichten und dies über streaming Replication machen.
Ja, aber beachte: ein Standby ist bei Streaming Replication ReadOnly.
1 „Gefällt mir“
Also eventuell können wir auf ein höheres PostgreSQl umsteigen und dann die logical Replication verwenden und so den Inhalt von mehreren Servern auf einen spiegeln.
Ich hab noch eine Frage zum Backup. Ich habe im PG Admin das Ganze mal mit Restore ausprobiert. So kann man ja auch nur von einem Schema ein backup machen und dies dann auf einen anderen Server wiederherstellen.
Nun habe ich folgendes ausprobiert.
-
Backup mit Restore in Schema einfügen → Alle Daten waren da
-
Änderung in Datenbank (z.B eine Zeile löschen und etwas hinzufügen)
-
nochmal Restore mit demselben Dumb ausführen → nichs passiert alle Änderungen sind noch da
-
nochmal Restore diesmal mit Option “Clear before Restore” an → alles geänderte Weg und das “alte” vom Dump wieder da
Gibt es die Möglichkeit in ein Schme Dump Nr. 1 einzuspielen, dann Dump Nr.2 einspielen und so sind alle Daten vorhanden. (also wenn wir davon ausgehen dass die Daten zu 100 % unterschiedlich sind)
Machbar. Schaue Dir die Optionen von pg_dump an, verwende am besten die Kommandozeile,
1 „Gefällt mir“
danke werde ich machen 
Ich hab jetzt nochmal eine Frage.
Wie kann ich denn auf einem Rechner mehrere Standbyserver haben die ich für die Replication mehrerer Standorte benutze?
Muss ich für jeden Standbysever PostgresSQL extra installieren?
Du kannst mehrere Instanzen starten, alle mit derselben Version, aber in unterschiedlichen Verzeichnissen und mit unterschiedlichen Ports.
1 „Gefällt mir“
ok vielen Dank
Gibt dazu eine Beschreibung wie man da vor geht oder finde ich das unter einem bestimmten Begriff in der Doku?
Google?
1 „Gefällt mir“
ok ja danke hab ich nebenher gemacht und das auch gefunden.