Replikation mehrerer DB-Server

Hallo,

ich habe folgende Fragen. Um die Performance beispielsweise von
Internetportalen zu steigern die auf Datenbanken zugreifen wird doch
vielfach so vorgegangen, dass ein Master-DB-Server existiert, an den
alle schreibenden Operationen gerichtet werden und eine beliebige Anzahl
von Slaves an die alle lesenden
Anfragen gestellt werden. Ein Loadbalancer verteilt dabei alle
ankommenden lesenden Anfragen an die Slaves beispielsweise mittels des
Round-Robin-Verfahrens. Alle geänderten Datensätze auf dem Master müssen
nun an alle Slaves asynchron repliziert werden. Wie kann nun
sichergestellt werden, dass alle Clients zum gleichen Zeitpunkt auch
den gleichen Datenbestand haben? Es soll also nicht auftreten können das
eine lesende Anfrage auf einen bestimmten Datensatz die beispielsweise
an Slave1 gestellt wurde einen anderern Wert zurückgibt als die gleiche
Anfrage auf den selben Datensatz von Slave 2, nur weil Slave 1 die
geänderten Daten schon vom Master repliziert hat und Slave 2 nicht. Hat
jemand schon mal so ein Problem gehabt bzw. hat eine Idee wie man so was
lösen kann?

MfG

A.Jahn

Re: Replikation mehrerer DB-Server

=?iso-8859-1?Q?Andr=E9?= Jahn wrote:
>
> ich habe folgende Fragen.

[Replikations-Szenario]

> Wie kann nun
> sichergestellt werden, dass alle Clients zum gleichen Zeitpunkt auch
> den gleichen Datenbestand haben? Es soll also nicht auftreten können das
> eine lesende Anfrage auf einen bestimmten Datensatz die beispielsweise
> an Slave1 gestellt wurde einen anderern Wert zurückgibt als die gleiche
> Anfrage auf den selben Datensatz von Slave 2, nur weil Slave 1 die
> geänderten Daten schon vom Master repliziert hat und Slave 2 nicht.

Kurze Antwort: gar nicht.

Lange Antwort: die Eigenschaft der MySQL-Replikation, daß es keine
Garantie gibt, wann (oder ob überhaupt) eine Änderung auf dem Master
bei einem bestimmten Slave ankommt, steckt in dem Wort "asynchron".
Diese Eigenschaft ist nun gleichzeitig ein Nachteil und ein Vorteil.

Den Nachteil hast du ja schon erkannt: man weiß beim Lesen von einem
Slave nicht, wie "frisch" die Daten sind. Man kann zwar Annahmen machen
wie "mit 99.9% nicht älter als 10 Sekunden", aber wirklich sicher kann
man nie sein.

Der Vorteil ist: so ein System skaliert besser. Wenn der Master bei
jedem Schreibzugriff warten müßte, bis alle Slaves "Vollzug" gemeldet
haben, würde die Performance ganz schön in den Keller gehen.
Und überleg dir mal was passiert, wenn ein Slave gerade busy ist
(z.B. weil der Kollege aus dem Controlling gerade die Auswertung vom
letzten Monat fährt). Der Master müßte nach einem Timeout den Slave
als "tot" erklären und irgendwie aus dem System rauswerfen.
Und später erkennen, daß er "wieder da" ist.

Wenn man synchrone Replikation braucht, muß man ins Portemonnaie
greifen und das Geld für einen richtigen Cluster ausgeben.


Zum Glück sind die Anforderungen bei den meisten Real-World Anwendungen
bei weitem nicht so hoch. Wirklich kritische Daten kann man ja immer
noch vom Master lesen. Und den Rest von den Slaves.

Lesen:
http://blog.koehntopp.de/archives/1349-Leben-mit-Fehlern-der -Schluessel-zum-Scaleout.html


XL

Re: Replikation mehrerer DB-Server

Axel Schwenke schrieb:
> =?iso-8859-1?Q?Andr=E9?= Jahn wrote:
>> ich habe folgende Fragen.
>
> [Replikations-Szenario]
>
>> Wie kann nun
>> sichergestellt werden, dass alle Clients zum gleichen Zeitpunkt auch
>> den gleichen Datenbestand haben? Es soll also nicht auftreten können das
>> eine lesende Anfrage auf einen bestimmten Datensatz die beispielsweise
>> an Slave1 gestellt wurde einen anderern Wert zurückgibt als die gleiche
>> Anfrage auf den selben Datensatz von Slave 2, nur weil Slave 1 die
>> geänderten Daten schon vom Master repliziert hat und Slave 2 nicht.
>
> Kurze Antwort: gar nicht.
>

Zusatz: Es gibt eine Variable welche man abfragen kann, um
festzustellen, wieviele Sekunden der Slave hinter seinem Master zurück
ist. Wenn man die z.B. alle 2 Sekunden in einem Thread abfragt, kann man
die Lese-Zugriffe auf den Master umleiten.

Ein Nicht-HDD-Lese-Zugriff auf diese Variable pro 2 Sekunden sollte das
System ohne Performanceeinbuße durchführen können.

Grüße

Dirk

Re: Replikation mehrerer DB-Server

Dirk Brosowski!

> Zusatz: Es gibt eine Variable welche man abfragen kann, um
> festzustellen, wieviele Sekunden der Slave hinter seinem Master zurück
> ist. Wenn man die z.B. alle 2 Sekunden in einem Thread abfragt, kann man
> die Lese-Zugriffe auf den Master umleiten.

Womit man sich dann natürlich wieder den Vorteil zunichte macht, den die
Replikation eigentlich bringen sollte. Also auch ein typischer Fall von
eigentlich einen richtigen Cluster wollen.


Gruß
Daniel

Re: Replikation mehrerer DB-Server

Daniel Fischer schrieb:
> Dirk Brosowski!
>
>> Zusatz: Es gibt eine Variable welche man abfragen kann, um
>> festzustellen, wieviele Sekunden der Slave hinter seinem Master zurück
>> ist. Wenn man die z.B. alle 2 Sekunden in einem Thread abfragt, kann man
>> die Lese-Zugriffe auf den Master umleiten.
>
> Womit man sich dann natürlich wieder den Vorteil zunichte macht, den die
> Replikation eigentlich bringen sollte. Also auch ein typischer Fall von
> eigentlich einen richtigen Cluster wollen.
>
Wieso? Du kannst das gerne soweit weiterdenken, dass man statt auf den
Master auf einen anderen Slave ausweicht.

Einen echten Cluster gibt es doch bisher bei MySQL noch gar nicht, oder?
Aktuell wird doch der Datenbestand noch komplett in-Memory gehalten, oder?


Ausserdem gibt es im Zweifelsfall andere Datenbanksysteme, die einen
echten Clusterbetrieb ermöglichen. Dann wird es aber teuer, verkehrt
muss das aber nicht sein. Letztlich kommt es darauf an, wieviel
Performance braucht man Realtime.

Grüße

Dirk

Re: Replikation mehrerer DB-Server

Wobei bei einem richtigen Cluster wieder die Probleme der synchronen
Replikation gegeben sind (bzw. eventuelle Performanceeinbußen dadurch). Außer
den Einsatz von MySQL Cluster ist es ja nun mit MySQL nicht möglich bzw. mir
nicht bekannt das eine synchrone Replikation zwischen zwei oder mehreren MySQL
Servern möglich ist. Weiterhin wurde in der Newsgroup geschrieben das die
Nutzung einer Datenbank durch mehrere MySQL Server auch nicht möglich ist.
Somit wäre die einzige richtige Clusterlösung MySQL Cluster wenn ich das
richtig sehe oder?

Gruß
André

Daniel Fischer schrieb:

> Dirk Brosowski!
>
> > Zusatz: Es gibt eine Variable welche man abfragen kann, um
> > festzustellen, wieviele Sekunden der Slave hinter seinem Master zurück
> > ist. Wenn man die z.B. alle 2 Sekunden in einem Thread abfragt, kann man
> > die Lese-Zugriffe auf den Master umleiten.
>
> Womit man sich dann natürlich wieder den Vorteil zunichte macht, den die
> Replikation eigentlich bringen sollte. Also auch ein typischer Fall von
> eigentlich einen richtigen Cluster wollen.
>
> Gruß
> Daniel

Re: Replikation mehrerer DB-Server

=?iso-8859-1?Q?Andr=E9?= Jahn wrote:

> Wobei bei einem richtigen Cluster wieder die Probleme der synchronen
> Replikation gegeben sind (bzw. eventuelle Performanceeinbußen dadurch).

Jein. Im Prinzip *muß* 2-Phase-Commit negative Effekte für die
Performance haben, weil Kommunikation zwischen den Cluster-Knoten
ja nicht in Nullzeit abläuft. Aber das betrifft nur die Latenzzeit
einer Einzeloperation. Der Gesamtdurchsatz wird eher höher,
zumindest wenn man verteilt schreibt.

> Außer
> den Einsatz von MySQL Cluster ist es ja nun mit MySQL nicht möglich bzw. mir
> nicht bekannt das eine synchrone Replikation zwischen zwei oder mehreren MySQL
> Servern möglich ist.

Es gibt noch http://www.continuent.com/
Vormals m/Cluster
Vormals Emic Cluster

Das ist ein aufgebohrtes, kommerzielles MySQL, das im Prinzip um
verteilte Transaktionen erweitert wurde. Wenn ich mich richtig
erinnere (ich habe mit den Emic-Leuten mal auf ner Messe geredet)
ist das auch shared-nothing. D.h. jeder Knoten hat eine komplette
Kopie aller Daten. Lesezugriffe werden verteilt und laufen komplett
unabhängig. Den exakten Ablauf für Schreibzugriffe kenne ich nicht.
Aber entweder spielt ein Knoten Master für alle Schreibzugriffe,
oder die werden auch verteilt. Ersteres ist viel leichter sauber
hinzubekommen (man denke mal an race conditions) letzteres bringt
mehr Performance.


XL

Re: Replikation mehrerer DB-Server

André Jahn!

[TOFU]
> Weiterhin wurde in der Newsgroup geschrieben das die
> Nutzung einer Datenbank durch mehrere MySQL Server auch nicht möglich ist.
[mehr TOFU]

Doch, ein MySQL-Server kann auch auf Tabellen eines anderen
MySQL-Servers zugreifen (mit Federated). Damit kannst du halt auch keine
Last verteilen, da jeder Zugriff auf eine Federated-Tabelle auch Zugriffe
auf den Master verursacht.

Theoretisch kannst du das auch umdrehen und benutzen, um synchrone
Replikation zu simulieren: Der Master greift via federated auf die Tabelle
auf dem Slave zu und gibt Änderungen in einem Trigger weiter. Davon
würde ich aber in einem produktiven Umfeld abraten, ich wollte es nur mal
erwähnen, weil ich es niedlich finde :-) Also: Synchrone Replikation
zwischen zwei MySQL-Servern ist möglich, aber nicht zu empfehlen.


Gruß
Daniel

Re: Replikation mehrerer DB-Server

Daniel Fischer wrote:
> André Jahn!
>
> [TOFU]
>> Weiterhin wurde in der Newsgroup geschrieben das die
>> Nutzung einer Datenbank durch mehrere MySQL Server auch nicht möglich ist.
> [mehr TOFU]
>
> Doch, ein MySQL-Server kann auch auf Tabellen eines anderen
> MySQL-Servers zugreifen (mit Federated). Damit kannst du halt auch keine
> Last verteilen, da jeder Zugriff auf eine Federated-Tabelle auch Zugriffe
> auf den Master verursacht.

Das war nicht die ursprüngliche Frage. André verwendet wohl die
Begriffe "Datenbank" und "Datenfiles der Datenbank" synonym.

(An dieser Stelle ein ironisches "Dankeschön" an die Schnarchnasen in
Redmond, die diesen Sprachgebrauch eingeführt haben. Zusammen mit der
Auffassung, Systemabstürze wären etwas unvermeidliches und "Neustart"
bzw. "Neuinstallation" wären valide Problemlösungsstrategien)

Ursprünglich gings darum, das MySQL Datadir auf ein Netzwerk-Share
zu legen und mit mehreren MySQL-Instanzen drauf zuzugreifen. Das
ist ein sehr effizienter Weg, seine Daten zu zerschießen...


XL