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

Re: MySQL HA mit Log-Replication oder DRBD?



Hallo,

Klaus Umbach <treibholz@sozial-inkompetent.de>:

>> MySQL Replikation ist nicht als HA Lösung vorgesehen und auch nur bedingt
>> dazu geeignet. Inbesondere wenn du nebenläufige Schreibzugriffe auf beiden
>> Seiten hast

>Ich will keine Schreibzugriffe auf beiden Seiten haben. Das ist weder aber
>auch weder mit der Replikation noch mit DRBD sinnvoll abbildbar. Es geht
>hier nur um Ausfallsicherheit.

Das ist bei einem Heartbeat-Cluster nicht vollständig zu vermeiden.
Denke dir eine Tabelle mit einem Auto-Increment Feld. Auf der aktiven
Seite geschieht ein Schreibzugriff, der den Counter erhöht. Danach
stürzt der aktive Knoten ab, ohne dass die Transaktion bereits repliziert
ist. Mittels Heartbeat wird die andere Seite aktiv. Der nächste
Schreibzugriff führt nun dazu, dass die selbe Auto-Increment Id erneut
verwendet wird.

Ich kenne Installationen, wo das Replikationskonstrukt seit Jahren
zuverlässig läuft. Aber man muss sich trotzdem immer dessen bewusst
sein, dass Replikation dafür nicht gedacht ist und dass es irgendwann
knallen kann.

>DRBD kann doof werden, weil beim Crash des
>aktiven Nodes eventuell auch das Dateisystem mit kaputt geht (mit XFS hatte
>ich da schon tolle Effekte...) Und dann ist Feierabend mit
>Ausfallsicherheit. Man hat da halt nur EIN Dateisystem, das kaputt gehen
>kann. Bei der Replikation hätte ich zwei.

Das ist richtig. Man kann aber das Risiko auf Kosten der Performance
minimieren, beispielsweise durch Verwendung von ext3, Mountoption
data=journal und der MySQL Einstellung flush=on.

Meinen Kunden empfehle ich häufig eine kombinierte Lösung: das Cluster
selber läuft als Heartbeat-Cluster auf Shared Storage (externes
SAN-Storagesystem oder DRBD); auf einer dritten Maschine läuft eine
Standalone MySQL Instanz, die per (unidirektionaler) Replikation alle Daten
nochmals spiegelt. In extremen Fällen (z.B. Tod des Speichersystems)
kann man innerhalb kurzer Zeit von Hand auf die dritte Maschine umschalten,
muss später aber (z.B. in einem nächtlichen Wartungsfenster) das
Cluster neu mit Daten befüllen, zurückschalten und dann die Replikation
neu aufsetzen. Dieser Extremfall ist zum Glück sehr selten.

Gruß, Harald


Reply to: