Re: DB-replikation vs. HA-Cluster (war: failover - switch back)

Hi,

downtime... eigentlich gar keine. Ich habe nur den standby zum master
gemacht. Dann den postgresql "ex-master" gestoppt, und dann die basis-kopie
zum ex-master vom ex-standby kopiert (mittels rsync), um dann gleich den
datenbankservice neuzustarten, sodass der ex-master die daten vom
(ex)standby hat.
Vorteil von failover auf applikationsebene? Keine. Ich hoffe ich bastel
gerade an einer "vollwertigen HA-Cluster-Lösung", die für die applikation
vollkommen transparent ist.

Gruß

hubert

-----Ursprüngliche Nachricht-----
Von: Olaf Radicke [mailto:briefkasten(at)olaf-radicke(dot)de]
Gesendet: Freitag, 31. Dezember 2010 13:16
An: hubert hupe
Betreff: [pgsql-de-allgemein] DB-replikation vs. HA-Cluster (war: failover -
switch back)

Am Fr, 31.12.2010, 12:30 schrieb hubert hupe:
> silvester und man sitzt hier und rackert mit psql... aber zu meinem
> problem:
> habe zwei ubuntu-rechner mit postgresql 9.0.2. die beiden arbeiten als
> streaming replication im hot_standby modus zusammen - klappt super.
> Die anforderung soll eine hochverfügbarkeit sein - ist auch gegeben,
> denn ein touch /tmp/triggerfile.5432 veranlasst den standby rechner
> als master zu agieren.

Wie lange war dier down time, wenn ich mal fragen darf?

> ABER, wie stellt man den normalen zustand wieder her? Also das der "alte"
> primary wieder der primary ist und der "alte" standby wieder standby
> (der ja nun zum master geworden ist).
> Ich habe versucht das data-verzeichnis des alten standbys auf den
> alten master zu kopieren, also eine basiskopie und dann den alten
> master zu starten... das ging nicht:

Leider hab ich keine Antwort auf das kokrete Problem zu bieten.

Ich würde die Diskusion aber gerne etwas generalisieren: Welchen Vorteil
bringt mir der failover auf Aplikationsebene im Vergleich zu einer
vollwertigen HA-Cluster-Lösung? Das ist mir zum jetzigen Zeitpunkt nicht
wirklich klar.

Gruß

Olaf