RootForum Community

Hallo :)

es geht um einige Erfahrungswerte bei folgendem Setup:

2 Maschinen - in einem DRBD Verbund der per Heartbeat automatisch für HA-Failover sorgt.

Auf das DRBD soll noch ein PostgreSQL kommen dass ebenfalls geschwenkt wird, wenn eine der beiden Maschinen wegfault.

Ich hatte das Ganze schon mit 2 VM's nachgestellt, eine 5 GB Datenbank hochgezogen und per for Schleife einige INSERT's und UPDATE's getriggert, dann eine der VM's ausgeknippst so dass es zur Schaltung kam.
DRBD hat geschwenkt, PostgreSQL kam wieder hoch und der Client hatte natürlich eine Fehlermeldung. Tabellen waren dabei wohl keine beschädigt (MySQL + REPAIR TABLE ;) )

Hat da jemand Erfahrungswerte wie es im realen Einsatz aussieht mit einem solchen Setup ? Soweit ich gelesen habe sorgt PostgreSQL hier für Konsistenz (fsync etc.)
DRBD soll laut Postgres Wiki möglich sein und ist ohnehin schon produktiv dort vorhanden, wo es hin soll.

Geht nur darum dass der HA Schwenk automatisiert passieren soll und nicht jedes Mal manuell ein Eingriff nötig ist.

Besten Dank

Aus eigener Erfahrung baue ich kein PostgreSQL System mehr mit Heartbeat und DRBD auf.
Postgresql kann das im wesentlichen selbst hervorragend.

Die Postgresql Replikation ist absolut Perfekt geeignet. Bei Last und temporären Netzwerkproblemen kann DRBD ganz schöne Zicken machen bishin zu Write Blockaden auf dem Storage, die ziemlich lange andauern könne - bis sich nicht mehr lösen.
Das hauptsächlich dann ein Problem wenn man das drbd Device auf beiden Systemen als primary einbindet, auch wenn es nur auf einem System eingemountet ist.

PostgreSQL ermöglich seit 9.1, oder ggf. auch erst seit 9.2 eine synchrone Replikation. Das läuft wirklich stabil und unterscheidet sich von der Mysql Replikation. Hält also die Daten wirklich konsistent.

Für einen automatischen Failover gibt es pgbouncer oder meinetwegen auch pgpool.
Ein schwenk findet dann nahezu unterbrechungsfrei statt.
Aktive Session werden halt gekillt ein reconnect ist aber sofort möglich.
http://wiki.postgresql.org/wiki/Replica ... on_Pooling
Die Defekte Node wird aus der Replikation / Betrachtung von pgpool genommen und der nächsten replizierten Node (Slave) das Signal gegeben, Du bist nun der Master.
Ebenfalls soll sich geändert haben, dass ein PostgreSQL Server innerhalb eines solche Replikationsverbundes: z.B. 1 Master 2 Salves ohne viel Aufwand der 2. Slave an den 1. Slave verbindet der die Rolle das Master übernommen hat, und die Replikation fort führt.
-> Ich hab mich selber noch nicht weiter darum gekümmert. Eventuell ist das auch erst nur ein Plan das zu realisieren.

Aus meiner Erfahrung heraus funktioniert das mit Postgresql Replikation weit besser als eine Heartbeat DRBD Lösung und Du hast die einfache Möglichkeit Leselast zu verteilen, sofern notwendig.

Dann vielleicht doch so. In MySQL Zeiten wurde dass per Master <- -> Master Replica (ich kenne die Nachteile) abgewickelt und per HA die jeweilige IP die an den Client rausgereicht wird geschwenkt.
Ist dann per pgpool ganz ähnlich. :)

Danke

Bei Postgresql musst Du dir über Master Master keine Gedanken machen. PGPool-II und auch der pgbouncer kommen damit gut klar und die Datenbank selbst reagiert auf ein "Werde Master" innerhalb von wenigen Millisekunden, schneller als Deine Applikation reconnecten kann.

Schreiblast ist häufig gar nicht mal das Problem. Sondern ehr die Leselast, weswegen eine Lastenverteilung lesend oft ausreichend ist.
Naja und seit 9.1 oder spätestens 9.2 kann Postgreql auch sehr zuverlässige eine synchrone Replizierung.
Damit kaufst Du dir eben die Master Master Nachteile auch nicht mit ein.