failover - switch back

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 stre=
aming replication im hot_standby modus zusammen - klappt super.
Die anforderung soll eine hochverfügbarkeit sein - ist auch gegeben, d=
enn ein touch /tmp/triggerfile.5432 veranlasst den standby rechner als mast=
er 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 j=
a nun zum master geworden ist).
Ich habe versucht das data-verzeichnis des alten standbys auf den alten mas=
ter 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 2=
2:20:33 CET
2010-12-30 23:23:01 CET LOG: could not open file "pg_xlog/0000000200000000=
0000001E" (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/0000000200000000=
0000001E" (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 failu=
re

Leider konnte ich auf dem alten standby das commando psql -c "SELECT pg_sta=
rt_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...

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

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

Gruß

hubert


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

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 applikati=
on
vollkommen transparent ist.

Gruß

hubert

-----Ursprüngliche Nachricht-----
Von: Olaf Radicke [mailto:briefkasten@olaf-radicke.de]=20
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=20
> streaming replication im hot_standby modus zusammen - klappt super.
> Die anforderung soll eine hochverfügbarkeit sein - ist auch gegeben,=
=20
> denn ein touch /tmp/triggerfile.5432 veranlasst den standby rechner=20
> 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=20
> (der ja nun zum master geworden ist).
> Ich habe versucht das data-verzeichnis des alten standbys auf den=20
> alten master zu kopieren, also eine basiskopie und dann den alten=20
> 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


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

Re: failover - switch back

hubert hupe wrote:

> Hallo,
>=20
> 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:
>=20
> * 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/000000020000=
00000000001E" (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/000000020000=
00000000001E" (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 rec=
ord
> 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 f=
ailure


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

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

Hrm...


>=20
> 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...


>=20
> In jedem fall wünsche ich euch einen guten rutsch und viele erfolg mi=
t
> euren projekten in 2011

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




Andreas
--=20
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=
°

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: failover - switch back

hubert hupe wrote:

> Hallo,
>=20
> 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
> master geworden ist).

http://pgpool.projects.postgresql.org/contrib_docs/simple_sr _setting/inde=
x.html

Ungetestet. Aber vielleicht versuchst Du das da mal?


Andreas
--=20
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=
°

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

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 bewerkstell=
igen.
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=20

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

hubert hupe wrote:

> Hallo,
>=20
> silvester und man sitzt hier und rackert mit psql... aber zu meinem
> problem: habe zwei ubuntu-rechner mit postgresql 9.0.2. die beiden=20
> arbeiten als streaming replication im hot_standby modus zusammen -=20
> klappt super. Die anforderung soll eine hochverfügbarkeit sein - ist=
=20
> auch gegeben, denn ein touch /tmp/triggerfile.5432 veranlasst den=20
> standby rechner als master zu agieren. ABER, wie stellt man den=20
> normalen zustand wieder her? Also das der "alte" primary wieder der=20
> 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 Sla=
ve
via Trigger-File oder so zum Master machen könnte. Und der bisherige Mast=
er
ab dann als Slave laufen würde. Soweit sind wir (noch) nicht.



> master geworden ist). Ich habe versucht das data-verzeichnis des=20
> alten standbys auf den alten master zu kopieren, also eine basiskopie=20
> und dann den alten master zu starten... das ging nicht:
>=20
> * 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=20
> 2010-12-30 22:20:33 CET
> 2010-12-30 23:23:01 CET LOG: could not open file=20
> "pg_xlog/00000002000000000000001E" (log file 0, segment 30): No such=20
> 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=20
> "pg_xlog/00000002000000000000001E" (log file 0, segment 30): No such=20
> 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=20
> record
> 2010-12-30 23:23:01 CET LOG: startup process (PID 8827) was=20
> terminated by signal 6: Aborted
> 2010-12-30 23:23:01 CET LOG: aborting startup due to startup process=20
> failure


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

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

Hrm...


>=20
> Frage: hat jemand erfolreich dieses oder ein ähnliches szenario am=20
> laufen? Mich interessiert, wie man das generell designen sollte und=20
> 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...


>=20
> In jedem fall wünsche ich euch einen guten rutsch und viele erfolg mit=
=20
> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein


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

Re: failover - switch back

On Jan 5, 2011, at 15:59 , hubert hupe wrote:

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

Failback ohne Downtime geht nicht; mit pgbouncer und sonstiger Middleware k=
annst du den Prozess für Clients etwas transparenter gestalten aber kompl=
ett unterbrechnungsfrei wird's das nie spielen.

lg,
Michael
--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: failover - switch back

Am Donnerstag, den 06.01.2011, 15:41 +0100 schrieb Michael Renner:
> On Jan 5, 2011, at 15:59 , hubert hupe wrote:
>=20
> > Die nächste herausforderung wäre das ganze ohne downtime zu b=
ewerkstelligen.
> > Im moment kann man ein fallback nur in einer maintenance-time durchf=C3=
=BChren.
> > In dieser zeit können keine daten in die datenbank geschrieben wer=
den.
>=20
> Failback ohne Downtime geht nicht; mit pgbouncer und sonstiger Middleware=
=20
> kannst du den Prozess für Clients etwas transparenter gestalten aber=
=20
> komplett unterbrechnungsfrei wird's das nie spielen.

Zudem bin ich nach wie vor der Meinung, das eine HA-Lösung auf OS-Ebene
wesentlich robuster ist und bedeutend flexibler. Mit einer sauberen
Cluster-Lösung schuppst du den DB-Cluster-Dienst mit einem einzigen
Befehl, von einem Node zum Anderen, ohne das die Clents was mitbekommen
(außer, das die Antwortzeit kurzzeitig in den Keller geht).=20

Wenn du dich für ein Shared Root Cluster
(http://de.wikipedia.org/wiki/Diskless_Shared_Root_Cluster)
entscheidest, brauchst du noch nicht mal die Daten auf den Nodes
spiegeln.

P.S.
Michael Renner, kannst du dein Apple Mail noch eine Zeilenlänge von 80
Zeichen bei bringen, dann muss ich beim Zitieren die Zeilenumbrüche
nicht händisch setzen. Danke.

Gruß

Olaf



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

Re: failover - switch back

On 01/06/2011 04:06 PM, Olaf Radicke wrote:
> Am Donnerstag, den 06.01.2011, 15:41 +0100 schrieb Michael Renner:
>> On Jan 5, 2011, at 15:59 , hubert hupe wrote:
>>
>>> Die nächste herausforderung wäre das ganze ohne downtime zu=
bewerkstelligen.
>>> Im moment kann man ein fallback nur in einer maintenance-time durchf=C3=
=BChren.
>>> In dieser zeit können keine daten in die datenbank geschrieben w=
erden.
>>
>> Failback ohne Downtime geht nicht; mit pgbouncer und sonstiger Middlew=
are
>> kannst du den Prozess für Clients etwas transparenter gestalten a=
ber
>> komplett unterbrechnungsfrei wird's das nie spielen.
>
> Zudem bin ich nach wie vor der Meinung, das eine HA-Lösung auf OS-=
Ebene
> wesentlich robuster ist und bedeutend flexibler. Mit einer sauberen
> Cluster-Lösung schuppst du den DB-Cluster-Dienst mit einem einzige=
n
> Befehl, von einem Node zum Anderen, ohne das die Clents was mitbekommen
> (außer, das die Antwortzeit kurzzeitig in den Keller geht).
>
> Wenn du dich für ein Shared Root Cluster
> (http://de.wikipedia.org/wiki/Diskless_Shared_Root_Cluster)
> entscheidest, brauchst du noch nicht mal die Daten auf den Nodes
> spiegeln.

"ohne das die clients was mitbekommen"? Wie auch immer dein=20
Failoverszenario aussieht du musst pg auf dem neuen Node neu starten und=20
damit werden alle Verbindungen der Clients abgebrochen und müssen ne=
u=20
aufgebaut werden.




Stefan

--=20
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein@postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Re: failover - switch back

Am Donnerstag, den 06.01.2011, 18:18 +0100 schrieb Stefan Kaltenbrunner:
> "ohne das die clients was mitbekommen"? Wie auch immer dein=20
> Failoverszenario aussieht du musst pg auf dem neuen Node neu starten
> und=20
> damit werden alle Verbindungen der Clients abgebrochen und müssen ne=
u=20
> aufgebaut werden.=20

Das ist richtig. Ich sage ja: eine Lösung auf OS-Ebene. "Client" ist
etwas unscharf. Mit "Client" kann der Rechner oder das
DB-Client-Programm gemeint sein. Der Client-Rechner merkt nicht das er
auf ein mal mit einem anderen Cluster-Node spricht. Er merkt nur eine
Verzögerung bei der Antwortzeit. Die pg-Sitzung reist natürlich a=
b. Aber
in der Regel werden die Client-Programme damit umgehen können. In dem
sie sich neu anmelden und den Query solange schicken bis sie eine
Bestätigung des Servers bekommen. Das die Netzwerkverbindung währ=
end des
Query abreist, kann auch wegen anderen Problemen passieren. Mit so was
sollte eine Applikation umgehen können.

Gruß

Olaf


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