Synchronisation zwischen zwei Datenbanken

Hiho, ich habe mich hier schon ein bisschen durchgewühlt und schon ein paar Beiträge zum Thema gelesen aber die meisten Lösungen scheinen mir zu aufwendig für mein simples Anliegen.

Ich habe zwei Datenbanken an zwei verschiedenen Orten welche sich halt immer synchron halten sollen. Problem ist das die Internetverbindung nicht all zu berauschend ist. Es steht gerade eine DSL 1000 Leitung zur Synchronisation zur Verfügung.

Momentan haben wir eine Datenbank auf einem Server, die Verbindungsgeschwindigkeit ist aber extrem langsam. Daher die Überlegung an jedem Standort eine Datenbank zu installieren welche sich dann selbst synchronisieren. Zumindest die Lesezugriffe sollten dann wieder angemessene Geschwindigkeit haben.

Ist das möglich dass sich 2 Datenbanken synchronisieren?
PGCluster hatte ich mir schon angeguckt, ist dieser für mein Vorhaben überhaupt geeignet?

Was Du suchst klingt nach Multi-Master-Replikation über eine lahme Leitung, und die Antwort ist NEIN, da gibt es meines Wissens nach nix.

Slony ist eine Single-Master to Multiple Slave - Replikation.

Es gibt ein Projekt, welches eine Multimaster-Replikation verspricht: http://www.postgres-r.org/
der Maintainer davon ist, tätä, ein deutsch-sprechender. (Markus Schiltknecht). Du kannst auch mal auf http://www.postgresql.at/ gehen, die haben angeblich eine funktionierende Multi-Master-Lösung, auch http://www.enterprisedb.com/ hat da wohl was.
Aber ich bin mir recht sicher, daß all das an Deiner Leitung scheitern wird. Und es sind wohl kommerzielle Lösungen, kosten also was, falls das bei Dir eine Rolle spielt.


Was vielleicht gehen wird: Eine Master und eine Read-Only-Slave-DB. Dann mußt Du aber Sorge tragen, daß auf dem Slave wirklich nix geschrieben wird. Das wäre dann eine Sache für Slony.


Aber mal eine Frage:

Du sprichst von lahmen Lesegeschwindigkeiten: vielleicht kann man ja auch die Abfragen optimieren. Aber dazu müßte man etwas mehr über das Szenario wissen und genau schauen, wo der Flaschenhals ist.

Andreas

nja, bei uns läuft eine JavaSoftware welche mittels JDBC Kundendaten etc. verarbeitet.
Wenn jemand alleine arbeitet ist die Geschwindigkeit OK aber bei 20 Mann wirds dann sehr langsam so das man fast 30 Sekunden warten muss bis einem ein simpler Brief angezeigt wird. Bei den Abfragen habe ich schon so weit mir möglich alles vereinfacht und in Sichten ausgelagert.

Also dadurch, das du etwas in Sichten (Views) auslagerst, hast du exakt gar nichts für die Datenbank vereinfacht.

Ein View ist nichts anderes als ein gespeicherter Query, im Endeffekt wird also der gleiche Query wie vorher ausgeführt, nur siehst du in deiner Applikation davon nicht mehr so viel.

Ich möchte fast wetten, eure Probleme sind anderer Natur. Wie groß ist so ein Brief, wieviele Datenmengen müssen dafür effektiv übertragen werden? Und über eine DSL 1000 Leitung passen selbst über den Rückkanal wieviele Bytes in der Sekunde? Genau … da stimmt etwas nicht.

Kann es sein, das hier vielleicht zu viele Anfragen gestellt werden, das einzelne Anfragen optimiert werden können, das zu viele Daten zurück übertragen werden (SELECT * als Beispiel, statt nur benötigte Daten zu selecten). Versuch doch mal herauszufinden, welche Daten wirkllich übertragen werden und welche davon benötigt werden.

Dann umgehst du vielleicht auch dein Problem, alles syncronisieren zu müssen.

Ach, noch eine Idee: akretschmer hat ja schon geschrieben, das Master-Slave Lösungen gut funktionieren. Wenn man also viel liest und nur wenig schreibt, könnte man in der Zentrale einen Master stehen haben, der Änderungen an den Slave schiebt. Die Aussenstelle liest halt vom Slave und schreibt Änderungen auf den Master.

Ich meinte ja dass ich Sichten benutze also mir so eh nur die Daten hole die ich auch nur benötige. Der reine Datentransfer zwischen Client und Datenbank habe ich schon soweit optimiert das wirklich nur die Daten transferiert werden die wirklich benötigt werden.
Sicherlich könnte man bei den eigentlichen Abfragen noch einiges optimieren aber die Geschwindigkeit in der die Datenbank die Daten liefert ist mehr als ausreichend.
Das mit dem Brief war jetzt auch nen bisschen übertrieben aber teilweise müssen eben schon große Datenmengen abgefragt werden, im Gegensatz dazu eher weniger Daten gespeichert.
Ich glaube ich werde also versuchen solch ein Master/Slave System aufzubauen, werde mich also gleich mal schlau machen was ich dazu alles brauche.
Kennt vieleicht jemand ein schönes Tutorial welches den Werdegang einfach beschreibt?

http://linuxfinances.info/info/slonyadmin.html

Andreas

Besten Dank :slight_smile:
Ging ja schneller als selber suchen hrrhrr

So … bin jetzt beim installieren und konfigurieren und hab mal noch ne Frage zur Synchronisation.
Synchronisieren sich die Datenbanken nur wenn folgender Befehl ausgeführt wird?

subscribe set ( id = 1, provider = 1, receiver = 2, forward = no );

Oder kann man das auch so hinbiegen das nach jeder Änderung am Master automatisch mit dem Slave abgeglichen wird?

Um zu wissen, was zu tun ist, muß das halt definiert werden.
Man definiert Sets, fügt diesen tables zu (set add table) und meldet diese an (subscribe set ).

Slony arbeitet Trigger-basiert, diese Trigger müssen erst mal für die zu replizierenden Tabellen erzeugt werden. Dazu dienen halt u.a. diese Kommandos.

Andreas

So … ich nähere mich meinem Ziel immer mehr, eine funktionierende Replikation hab ich schon am laufen :slight_smile:

Eine Frage noch zu den Angaben bei den Adressen für Master/Slave, ist es möglich dort dynamische Adressen zu verwenden?

Beispiel:

node 1 admin conninfo = 'dbname=database host=master.dyndns.org user=foo';

Wenn sich jetzt während des Betriebes die IP ändert wird die dynamsiche Adresse ja aktualisiert, verwendet Slony ab diesen Zeitpunkt auch die neue IP oder wird die direkt beim initialiseren einmal aufgelöst und dann während der ganzen Laufzeit verwendet?

Kann mir da einer was zu sagen?

Aus dem Bauch heraus denke ich mal, daß das einmalig erfolgt. Es wäre von der Performance wohl eher schlecht, bei jedem zu übertragenem Paket erst einen DNS zu befragen…

Slony über instabile Leitungen gilt als, ähm, naja…
Wenn es merkt, daß es eine Trennung gab, zieht das IMHO ein TRUNCATE auf dem Slave und ein komplettes Neuübertragen der Tables nach sich.

Andreas

Oh Nein :frowning:

Hmpf, dann ists wohl leider doch nicht die richtige Lösung für mich weil ja dann bei jedem 24h Reset die komplette Datenbank übertragen wird und das sind mit 7zip komprimiert schon 85 MB.

Mist … naja … man kann nicht alles haben ;(

Dann ist Slony wirklich nicht das richtige für dich.

Sind die Daten, die sich ändern, für beide Standorte relevant?

Ansonsten fällt mir noch ein, sich zu merken, was sich ändert und diese Daten in größeren Häppchen alle paar Sekunden/Minuten zu übertragen. Das wird aber nicht klappen, wenn die Daten potentiell auf beiden Seiten geändert werden.

Ach ja, was ist aus meiner Frage geworden, ob man nur auf einem Server schreiben kann, und die Lesezugriffe auf die verschiedenen Server verteilt? Würde das funktionieren?

Hiho, da ich jetzt mal wieder hier bin möcht ich gleich noch nen bisschen was berichten :slight_smile:

Also wir habens damals dann doch so eingerichtet mit slony und haben uns von der T-Com ne feste IP verpassen lassen. Für Business-Kunden sogar kostenlos!
Allerdings hatte diese dann immernoch eine 24h Trennung, was aber nicht weiter schlimm war denn wenn die Verbindung unterbrochen wird und wieder zustande kommt übermittelt Slony nicht alle Daten nocheinmal neu sondern übermittelt an den Slave nur die Änderungen die zwischenzeitlich auf der Master-DB vollzogen wurden! Das mit TRUNCATE wird nur beim ersten initialisieren des Clusters gemacht.

Alles in allem hat es bis jetzt auch sehr gut funktioniert, manchmal ist uns der Slon-Daemon verreckt was aber eher am System lag. Ansonsten gab es aber keine größeren Probleme.

MFG