Re: failover - switch back

Hi leuts,

also das problem ist gelöst. Im prinzip war alles richtig bis auf mein
rsync-kommando. Dort hatte ich ein --exluce *xlog* enthalten. Beim
Zurückspielen der Standby-Kopie muss das wohl mit.

Die nächste herausforderung wäre das ganze ohne downtime zu bewerkstelligen.
Im moment kann man ein fallback nur in einer maintenance-time durchführen.
In dieser zeit können keine daten in die datenbank geschrieben werden.

Bin für jede anregung dankbar.

Viele grüße

hubert

-----Ursprüngliche Nachricht-----
Von: pgsql-de-allgemein-owner(at)postgresql(dot)org
[mailto:pgsql-de-allgemein-owner(at)postgresql(dot)org] Im Auftrag von Andreas
Kretschmer
Gesendet: Freitag, 31. Dezember 2010 13:44
An: pgsql-de-allgemein(at)postgresql(dot)org
Betreff: Re: [pgsql-de-allgemein] failover - switch back

hubert hupe <hubert_hupe(at)gmx(dot)de> wrote:

> Hallo,
>
> 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. 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

Das geht so, wie Du es schon mal gemacht hast:
- auf dem (jetzigen) Master ein Base-Backup machen
- dieses auf den (jetzigen) Slave installieren
(dabei die Daten auf dem alten Slave verwerfen)
- dem jetzigen Master sagen, daß da ein Slave ist (max_wal_senders)
- den Slave im Recovery-Mode starten, ihm auch sagen, wer nun Master ist
- den Slave zum Master machen

So in etwa ...

Ja, das ist alles noch nicht so wirklich schön... es wäre cool, wenn man
einfach sagen könnt: 'hey, du bist jetzt neuer Slave in diesem Cluster,
kümmere Dich selbst' - und das so laufen würde. Und man dann diesen Slave
via Trigger-File oder so zum Master machen könnte. Und der bisherige Master
ab dann als Slave laufen würde. Soweit sind wir (noch) nicht.

> 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:
>
> * The PostgreSQL server failed to start. Please check the log output:
> 2010-12-30 23:23:01 CET LOG: database system was shut down at
> 2010-12-30 22:20:33 CET
> 2010-12-30 23:23:01 CET LOG: could not open file
> "pg_xlog/00000002000000000000001E" (log file 0, segment 30): No such
> file or directory
> 2010-12-30 23:23:01 CET LOG: invalid primary checkpoint record
> 2010-12-30 23:23:01 CET LOG: could not open file
> "pg_xlog/00000002000000000000001E" (log file 0, segment 30): No such
> file or directory
> 2010-12-30 23:23:01 CET LOG: invalid secondary checkpoint record
> 2010-12-30 23:23:01 CET PANIC: could not locate a valid checkpoint
> record
> 2010-12-30 23:23:01 CET LOG: startup process (PID 8827) was
> terminated by signal 6: Aborted
> 2010-12-30 23:23:01 CET LOG: aborting startup due to startup process
> failure

Ich vermute mal, daß da beim Kopieren was schief lief...

>
> Leider konnte ich auf dem alten standby das commando psql -c "SELECT
> pg_start_backup('label', true)" nicht erfolgreich abschließen:
>
> ERROR: WAL level not sufficient for making an online backup
> HINT: wal_level must be set to "archive" or "hot_standby" at server
start.
>
> Das wal_level ist auf hot_standby...

Hrm...

>
> Frage: hat jemand erfolreich dieses oder ein ähnliches szenario am
> laufen? Mich interessiert, wie man das generell designen sollte und
> natürlich auch die einzelnen schritte (falls nicht zu viel verlangt).

So grob gesehen hast Du das wohl richtig gemacht, irgend etwas lief aber ned
wirklich richtig. Das pg_start_backup() auf dem (neuen) Master sollte
erfolgreich laufen.

Zu beachten ist, daß ein paar Variablen in der postgresql.conf auf beiden
Seiten gleich bzw. auf einer Seite höher als auf der anderen Seite sein
müssen, sonst knallt es. Leider liegen die Unterlagen dazu auf meinem
Schreibtisch in der Firma...

>
> In jedem fall wünsche ich euch einen guten rutsch und viele erfolg mit
> euren projekten in 2011

Ich Dir auch - und berichte, wenn Du das Problem gelöst hast.

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein