Replikation / Migration mit älteren PG Versionen

Guten Morgen zusammen!

Ich habe auf der Arbeit mit folgendem zu kämpfen:
Es gibt 2 Postgres-Server auf denen Version 8.2.5 der Software läuft. Ebenso scheint es einmal eine Replikation der beiden mit Slony-I in Version 1.2.16 gegeben zu haben.
Diese Replikation läuft derzeit jedoch nicht. Ebenso gibt es keine Ansprechpartner und keine Doku mehr für das System. Die Datenbank darin ist relativ groß (140 GB auf Dateisystemebene) und eine Eigenentwicklung.

Ich habe nun zwei Ziele:

1. Da es letztens einen Ausfall des primären Servers gegeben hat, ist aufgefallen, das die Replikation nicht läuft und man nicht auf den anderen Server zurückgreifen kann. Leider gab es hierfür auch noch kein Monitoring. Es sollte nun zunächst die Replikation zwischen diesen beiden Systemen wieder hergestellt werden.
2. Da die Postgres-Version ja wirklich uralt ist, soll in einem zweiten Schritt diese auf die aktuelle im Debian- oder Arch-Repository enthaltene (9.1 / 9.3) angehoben werden.

Wie immer natürlich: Nach Möglichkeit ohne Downtime, da es (noch) die einzige Datenbank in einer produktiven Applikation ist, in der sich kein Wartungsfenster einbauen lässt.

Ein Satz zu mir: Ich habe wenig bis keine PostgreSQL Erfahrung; Slony-I habe ich vor zwei Wochen das erste Mal gesehen. Ich halte mich aber für schnell lernend und blicke auf eine 10 jährige Erfahrung als genereller Linux-Admin zurück und bin LPIC-2 zertifiziert.
Daher: Seht mir dumme Fragen bitte nach

Mein Plan ist, die vorhandene Replikation auf dem anderen Server zu ignorieren und von 0 mit Slony-I neu aufzubauen, da der letzte Stand “da hat irgendwann mal irgendwas nicht funktioniert, deswegen wurde abgeschaltet” ist. Wenn diese Replikation zwischen den beiden Software-Identischen Systemen steht, möchte ich einen 2-Node-Cluster aus aktuellerer Hard- und Software mit Postgres-9.3 oder 9.1 daneben stellen und diese ebenfalls als weitere Subscriber die Datenbank “holen” lassen.
Anschließend möchte ich einen der beiden als neuen Origin definieren, die alten Postgres-8.2 Systeme abschalten und fortan nur noch mit diesen beiden aktuellen Versionen arbeiten.

Soweit der Plan. Hier zunächst die ersten Fragen:

• Macht dieser Plan soweit Sinn, bzw. ist das technisch ohne Downtime (den letzten Switch ausgenommen) mit dieser Art abweichenden Versionen überhaupt möglich?
• Ist Slony-I-1.x und Slony-I-2.x miteinander kompatibel, so das ich Slony-I-2.x auf den neuen laufen lassen kann? Zumindest die alten Server benötigen ja zwingend noch Slony-I-1.x, da 2.x erst Postgres ab Version 8.3 unterstützt …

Weiter in dem, was ich bisher gemacht habe:
Diese produktiven Server einmal außen vorgelassen, habe ich mir auf meiner Workstation zwei virtuelle Maschinen angelegt und dort ein altes Debian-Lenny, sowie eine zu den Produktivservern identisch kompilierte Version von Postgres und Slony-I installiert. Anschließend habe ich sichergestellt, das die simple 3-Tabellen-Datenbank aus dem Buch “PostgreSQL Administration” von O’Reilly mit Slony erfolgreich repliziert werden kann.
Als nächstes wollte ich das ganze mit einer etwas komplexeren Datenbank testen: Damit ich irgendetwas habe mit dem ich das ganze testen kann (ich wollte ungern direkt mit der 140-GB DB anfangen, zumal es davon keine gescheiten Backups gibt), habe ich dort einfach mit phpBB3 eine Datenbank angelegt. Und hier komme ich leider nicht mehr weiter: Hatte die Demo Datenbank noch ausschließlich Tabellen mit Primärschlüsseln, hat die phpBB3 Datenbank viele Tabellen ohne diese. Soweit ich Slony-I verstanden habe, muss eine replizierbare Tabelle jedoch entweder einen Primärschlüssel oder einen anderweitig eindeutigen Index haben. Beides kann ich aber z.B. für die phpBB3 Tabelle “phpbb_acl_groups” nicht finden.
Ich komme daher hier nicht mehr weiter und würde mich über Hilfe sehr freuen!

Im folgenden die Daten mit denen ich arbeite:

Funktionierende Replikation Tabelle “buch” (O’Reilly Beispieltabelle):
Slony-I Perl-Tools Config
Create Script DB “buch”

Ausstehende Tabelle “phpbb3db” (phpBB3 Beispieltabelle):
Create Script DB “phpbb3db” (der User “phpbb3user” wird benötigt)

Das wird alles schwer. 8.2 ist schon seit einigen Jahren tot. (Dezember 2011) Mittlerweile freuen wir uns auf 9.4. Slony: auch da hat sich viel getan. Ich glaube nicht, daß es sinnvoll/machbar ist, via Slony von 8.2 auf 9.X zu migrieren. Du kommst wahrscheinlich besser, Dir 9.x zu installieren und zu versuchen, mit dessen pg_dump(all) einen Dump der 8.2 zu bekommen. Das kann aber u.U. auch scheitern - probier es. Bedenke, daß sich einiges getan hat, in 8.3 fielen eine ganze Reihe implizieter Casts weg - sehr wahrscheinlich müßt ihr da in Eurer Applikation vielen fixen. Replikation heutzutage macht man eher mit Streaming Replication und nicht mit Slony, damit kannst dann auch Tabellen ohne PK replizieren und jede Schemaänderung wird auch gleich repliziert. Insgesamt erheblich robuster als Slony.

Insgesamt wird das für Dich ein größeres Projekt …

Hi akretschmer,

danke schonmal für diese erste Antwort!

Das PG 8.2 uralt ist und heutzutage keinesfalls mehr Version der Wahl sein sollte, ist mir völlig klar. Dennoch halte ich es, im Hinblick auf die Produktivapplikation, für den sinnvollsten Upgrade-Pfad zunächst die 8.2er Replikation wieder herzustellen, ehe wir mit den Upgrade - Bemühungen beginnen. Das unsere Entwickler mit den neueren Versionen erst vieeeel testen müssen ist auch klar; aber das ist nur ein weiteres Argument für mich zunächst mal mit Slony die beschriebene Struktur herzustellen. Erst so ergibt sich ja ein Upgrade-Pfad mit Fallback, dann doch wieder auf die alte Version zu gehen, wenn etwas nicht klappt. Im Moment gibt es ja nur diesen einen Server …

Daher sehe ich es nach wie vor als ersten Schritt, die Frage zu klären, wie man mit Slony-I 1.2 Tabellen ohne Primärschlüssel repliziert; am liebsten am angehangenem Beispiel der phpBB3 Datenbank.

PS: Streaming Replication steht mir in der 8.2 nicht zur Verfügung, nicht? Von daher bringt mir dieses leider nichts.

IIRC ist ein PK zwingend erforderlich. Zwingend. Sind die Tabellen mit OID angelegt? Bei solchen Altlasten würde ich fast davon ausgehen, das könnte der Trick sein.

PS: Streaming Replication steht mir in der 8.2 nicht zur Verfügung, nicht? Von daher bringt mir dieses leider nichts.

Richtig. Das war auch als Tipp für die Zukunft gedacht.

OK, danke dafür. Wo kommt der “IIRC ist ein PK zwingend erforderlich…” - Teil deines Quotes her? O.O

PEBKAC

Ah, OK

Was den zwingenden PK und Slony-I angeht: Slony-I bringt ja die perl-tools mit. Deren Konfigurationsdatei sieht die Optionen “pkeyedtables” und “keyedtables” vor:

• pkeyedtables definert eine Liste von zu replizierenden Tabellen, die über einen PK verfügen.
• keyedtables definert eine Liste von zu replizierenden Tabellen, die über keinen PK, dafür jedoch über einen anderen eindeutigen Schlüssel verfügen (z.B.: Ein Autoint-Feld “id”, das nicht als PK gekennzeichnet ist). Dieses finde ich aber z.B. direkt im Beispiel der phpBB3db , Tabelle “phpbb_acl_groups” nicht. Lese ich das nur falsch, oder hat diese keine Unique - Row?
• “Früher” gab es wohl auch mal die Option “serialtables”; hilft mir das ggf weiter?

Diese Tabelle gehört nicht zu meinem Bekanntenkreis.

• “Früher” gab es wohl auch mal die Option “serialtables”; hilft mir das ggf weiter?

Sagt mix exakt gar nichts. Aber früher hatten alle Tabellen eine OID-Spalte.