Pacemaker:Resource nach Failover wieder in aufnehmen

[nieselfriem]

Hallo!

Ich habe ein Cluster mit Corosnyc und Pacemaker aufgebaut. Dieser Prüft hauptsächlich darauf, dass der mysql-Prozess läuft. Das funktioniert so weit gut. Der Failover wenn mysql nicht mehr funktioniert läuft. Das heißt die VIP wird an den anderen Knoten übergeben. Wenn ich jedoch mysql wieder auf dem Knoten herstelle, wird dieser nicht mehr als "ok" in die Resource mit aufgenommen. Ich muss erst Pacemaker und Corosync durchstarten.
Muss dazu noch vorher ein Befehl ausgeführt werden oder in der Pacemakerconfig was angepasst werden, damit dies automatisch geschieht?

Code: Select all

node mdb01 \
        attributes standby="off"
node mdb02 \
        attributes standby="off"
primitive failover-ip ocf:heartbeat:IPaddr2 \
        params ip="xxx.xxx.xxx.9" \
        op monitor interval="5s" timeout="30s" \
        op start interval="0" timeout="20s" \
        op stop interval="0" timeout="20s" \
        meta target-role="Started"
primitive global_ping ocf:pacemaker:ping \
        params dampen="11s" multiplier="1000" host_list="xxx.xxx.xxx.1" \
        op monitor interval="5s" timeout="60s" \
        op start interval="0" timeout="60s" \
        op stop interval="0" timeout="60s"
primitive mysqlstatus ocf:heartbeat:mysql \
        params binary="/usr/bin/mysqld_safe" client_binary="/usr/bin/mysql" config="/etc/my.cnf" datadir="/var/lib/mysql" socket="/var/lib/mysql/mysql.sock" log="/var/log/mysql/mysql-error.err" pid="/var/lib/mysql/mysql.pid" user="mysql" test_user="ha" test_passwd="password" test_table="cluster.dbcheck" \
        op monitor interval="30s" timeout="70s" depth="0" \
        op start interval="0" timeout="120s" \
        op stop interval="0" timeout="120s"
clone cl_global_ping global_ping \
        meta target-role="Started" is-managed="true"
clone cl_mysqlstatus mysqlstatus \
        meta target-role="Started" is-managed="true"
location loc_mysql failover-ip \
        rule $id="loc_mysql-rule" -inf: not_defined pingd or pingd number:lte 0
colocation co_042_mysql_ip inf: failover-ip cl_mysqlstatus
property $id="cib-bootstrap-options" \
        dc-version="1.1.8-7.el6-394e906" \
        cluster-infrastructure="classic openais (with plugin)" \
        expected-quorum-votes="2" \
        no-quorum-policy="ignore" \
        default-resource-stickiness="100" \
        stonith-enabled="false" \
        last-lrm-refresh="1363596190"
#vim:set syntax=pcmk

VG niesel

[ddm3ve]

Das willst Du eigentlich nicht automatisch haben.
Stell dir vor, der Mysqld hatte nur sporadisch ein Problem.
Das will niemand, dass dieser mal zurück switcht.

Was ist mit der Datenkonsistenz?

[nieselfriem]

Ok, wenn das so ok ist. Aber wie nehme ich dann den Knoten wieder richtig auf, ohne die Dienste neu zu starten?

VG niesel

[ddm3ve]

I.d.R. genau so.
Pacemaker ist meines wissens nicht für einen "Höchstverfügbarkeitsbetrieb" gedacht.

Wenn ein System aus fällt will ich die Ursache genau kennen. Im Zweifel ist hier eine Kurze downtime durchaus legitim.
Theoretisch sollte man, kenne den exakten Befehl auch nicht, eine defekte Node wieder aktiv nehmen können.
Da kommen wir aber zum Corosync der aus der Erfahrung leider mit den syncen des Status so seine Probleme hatte.
Wenn ich mich noch richtig erinnere, wurde wegen der Probleme des Corosync das heartbeat Projekt wieder teilweise aufgenommen.
Heute baut meines wissen nur noch RHEL und Centos auf Corosync. Aber auch hier waren die Distributionen vor Version 6.2 sehr buggy.

[nieselfriem]

Was sind die Alternativen?

[dante]

Reproduziere den Failover und siehe dir dann deine aktuelle Cluster-Konfiguration an. Im Normalfall wird fuer eine _kaputte_ Resource ein entsprechendes Location Constraint angelegt, welches das erneute Starten unterbindet.

Wie ddm3ve schon sagt, sollte man das aber so belassen. Wenn du verifiziert hast, dass der Knoten bzw. der Dienst wieder fehlerfrei laeuft, kannst du dieses Constraint loeschen.

Mir ist aufgefallen, dass du MySQL auf beiden Knoten mittels Clone Set betreibst. In der Regel macht das keinen Sinn und kann unter Umstaenden auch zu Fehlverhalten des Clusters fuehren.

[ddm3ve]

Was sind die Alternativen?

PostgreSQL beispielsweise bringt gute Mechanismen mit um eine Hochverfügbarkeit zu realisieren.
z.B. pgpool. Dient hierbei nicht nur zur Lastverteilung, sondern kann auch einen Failover einleiten.

Für Mysql gib es eine recht gute Proxy Lösung.
Alternativ gibt es auch einige Kommerzielle Datenbank Proxylösungen.

Zudem könnte man auf eine Master Master Lösung setzen und vor der Datenbank einen Loadbalancer schalten, z.B. IPVS basierend.

Die Schwierigkeit liegt im wesentlichen immer darin, einen technischen oder logischen defekt zu erkennen und richtig darauf zu reagieren.
Z.B. auch ob ein Knoten aus dem Sync gelaufen ist etc.
Die üblichen Heartbeat checks sind zwar recht zuverlässig aber können auch nicht alle Eventualitäten von Störungen abdecken.