Ich sehe also viele widersprüchliche Ansichten über die Verwendung von STONITH mit einem 2-Knoten-DRBD/Pacemaker/Corosync-Cluster zur Replikation von MySQL-Daten. Das Beispiel, das ich auf der Pacemaker-Websitescheint es auszuschalten, aber an vielen anderen Stellen heißt es, man solle es eingeschaltet lassen... Mein Setup besteht aus 2 Knoten mit 2 Schnittstellen, eine physisch mit der anderen Maschine verbunden, die andere mit einem Switch. Ist STONITH in diesem Fall erforderlich, wenn ich redundante Kommunikation habe? Wenn ein Server beide Netzwerkverbindungen verliert, empfängt er ohnehin keine MySQL-Daten, und wenn er wieder hochfährt, plane ich, die Stickyness auf unendlich einzustellen, damit er (nicht) versucht, der Master zu werden. Ist STONITH in diesem Fall erforderlich oder sogar ratsam?
Antwort1
Am besten testen Sie, was bei unterschiedlichen Fehlermodi tatsächlich passiert, um sicherzustellen, dass es keinen einzelnen Fehler gibt, der dazu führen könnte, dass beide MySQL-Server versuchen, die Rolle des Master-Servers zu übernehmen.
Testen Sie, indem Sie die Internetverbindung auf einem Server deaktivieren. Sehen Sie, was auf beiden Servern passiert, und beobachten Sie, was passiert, wenn Sie die Verbindung wieder herstellen.
Machen Sie dasselbe für alle redundanten Verbindungen. Machen Sie dann dasselbe, indem Sie ALLE Netzwerkverbindungen auf einmal deaktivieren.
Ein Grund, STONITH auf einem Cluster mit zwei Knoten nicht auszuführen, besteht darin, dass es ziemlich leicht passieren kann, dass beide Knoten versuchen, den anderen zu beenden, und das auch erfolgreich ist. Sie müssen Ihr Setup testen, um sicherzustellen, dass nicht beide heruntergefahren werden oder beide weiterhin als Master ausgeführt werden und Ihre Datenbank dadurch nicht mehr synchron ist.
Noch etwas empfehle ich, während Sie es testen, bevor es in Produktion geht: Machen Sie es absichtlich kaputt. Tun Sie etwas, das dazu führt, dass MySQL und DRBD nicht mehr synchron sind, und lernen Sie, wie Sie es reparieren können. Schreiben Sie auf, was Sie tun mussten, um es zu reparieren. Denn es ist viel besser, das zu wissen, BEVOR Sie es wirklich tun müssen.