[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pacemaker und der Failover



Hallo,

Michael Weber <michael.weber@fh-stralsund.de>:

>>    crm resource migrate<Gruppenname>  <Knoten>
>
>In der Tat habe ich es genau so versucht. Doch leider hat das System mir 
>einen Strich durch die Rechnung gemacht. Ich vermute mal, dass es an 
>meiner Contraint liegt. Diese besagt, dass das Multi-State-Cloneset mit 
>der Gruppe zusammengehört.

Ich glaube nicht, dass das ein Problem ist.

>Nichts desto trotz, übermittle ich einfach mal die Ausgabe.

Bei meinen prinzipiell vergleichbaren Clustern sieht das fast genau gleich
aus. Zwei Sachen sind mir aufgefallen:

>primitive postgresql lsb:postgresql \
>	op monitor interval="10" timeout="15" start-delay="0" \
>	meta is-managed="true" target-role="Started"

Die Monitoring Timer erscheinen mir sehr kurz. Eine PostgreSQL Datenbank
kann durchaus eine Weile brauchen, bis sie vollständig gestartet ist. Ich
vermute, dass das start-delay die Ursache für den Fehler ist.

>group gr_fs_ip_postgresql ip_postgresql fs_r0 postgresql \
>	meta target-role="Started"

>colocation col_gr_on_drbd inf: gr_fs_ip_postgresql ms_drbd_r0:Master

Auf meinen Clustern lautet das immer umgekehrt, also sinngemäß:

  colocation col_gr_on_drbd inf: ms_drbd_r0:Master gr_fs_ip_postgresql

Ich bin mir aber nicht sicher, ob die Reihenfolge hier relevant ist, da sie
ja in dem Order Contraint nochmal explizit festgelegt ist.

>order ord_gr_after_drbd inf: ms_drbd_r0:promote gr_fs_ip_postgresql:start


>Mich würde an dieser Stelle noch interessieren, wie das Erstellen von 
>Orderings gemacht wird, wenn ich drei Ressource in einer genau 
>definierten Reihenfolge haben möchte.

Die Reihenfolge wird durch die Gruppendefinition bestimmt:

>group gr_fs_ip_postgresql ip_postgresql fs_r0 postgresql \
>       meta target-role="Started"

Gemäß dieser Definition wird immer zuerst die IP-Adresse vergeben, dann das
Filesystem gemountet und zuletzt PostgreSQL gestartet.

Leider kann man die DRBD Resource nicht (mehr) in eine Gruppendefinition
aufnehmen, da hier keine Master-Slave Resources erlaubt sind.

Eine weitere denkbare Fehlerquelle könnte sein, dass die PostgreSQL
Konfiguration auf dem DRBD Filesystem liegt. In diesem Fall kann Pacemaker
den Status der Resource postgresql nicht korrekt abfragen, wenn das
Filesystem nicht gemountet ist. Das Ergebnis wäre, dass die Resource in den
"unmanaged" Zustand übergeht. Daher sollte die Konfiguration immer im
lokalen Filesystem liegen.

Gruß, Harald


Reply to: