MySQL Storage und Leistungssteigerung

Hallo,
hat jemand Erfahrungen mit einem Storage System (SAN) und MySQL? Wir denken
z.Z. darüber nach unsere Systeme weiter zu vereinheitlichen. Zur Zeit läuft
es so das 8 DB Server permanent Berechnungen durchführen und die berechneten
Daten auf einen Frontend Server "kopieren". Kopieren in Form von INSERTS und
REPLACE. Auf dem Frontend Server werden Daten durch die Benutzer abgefragt.
Unschön hierbei ist, dass der Frontend Server nur einmal vorhanden ist. Wir
haben diesen schon mal auf einen Slave repliziert, was aber auch nicht
sonderlich gut ist. Einmal muss der Slave genauso performant sein und
außerdem muss dieser im Grunde genauso alles mitmachen was der Master auch
schon gemacht hat.
Besser wäre es wenn mehrere Frontend Server auf einen Storage zugreifen
können. Ich frage mich nur, wie das funktionieren kann, wenn z.B. zwei
Frontend Server auf der gleichen Datenbank arbeiten.
Das MySQL Cluster ist keine Lösung da zu viele Punkte nicht passen, z.B.
sind die DBs weit größer als 100 GB, wir brauchen Features die das Cluster
nicht kennt.

Christian

Re: MySQL Storage und Leistungssteigerung

"Christian Schmelzer" wrote:

> hat jemand Erfahrungen mit einem Storage System (SAN) und MySQL?

Ja. Allerdings ist das komplett transparent. So richtig große Vorteile
hat das aber nicht. Das beste dürfte sein, daß synchrone Schreibzugriffe
(z.B. auf das REDO-Log) schneller fertig werden, weil das SAN batterie-
gepufferten Cache hat und deswegen nicht auf die Platte warten muß.

> Zur Zeit läuft
> es so das 8 DB Server permanent Berechnungen durchführen und die berechneten
> Daten auf einen Frontend Server "kopieren". Kopieren in Form von INSERTS und
> REPLACE. Auf dem Frontend Server werden Daten durch die Benutzer abgefragt.
> Unschön hierbei ist, dass der Frontend Server nur einmal vorhanden ist. Wir
> haben diesen schon mal auf einen Slave repliziert, was aber auch nicht
> sonderlich gut ist. Einmal muss der Slave genauso performant sein und
> außerdem muss dieser im Grunde genauso alles mitmachen was der Master auch
> schon gemacht hat.
> Besser wäre es wenn mehrere Frontend Server auf einen Storage zugreifen
> können. Ich frage mich nur, wie das funktionieren kann, wenn z.B. zwei
> Frontend Server auf der gleichen Datenbank arbeiten.

Gar nicht. "Shared Storage" ist auch in SANs ein besonderer Betriebs-
modus. In der überwiegenden Zahl der Fälle heißt "shared" auch "entweder
oder". Es greift also immer nur ein Host auf das gemeinsame Volume zu.
"Richtiges" Sharing, wo mehrere Hosts praktisch gleichzeitig auf das
gleiche Volume zugreifen, erfordert aufwendiges Lock-Management.

MySQL kann das schon mal nicht.

> Das MySQL Cluster ist keine Lösung da zu viele Punkte nicht passen, z.B.
> sind die DBs weit größer als 100 GB, wir brauchen Features die das Cluster
> nicht kennt.

Schade. Für schreib-intensive Sache ist Cluster die beste Lösung.
Wie du selber bemerkst hast, bringt Replikation nichts bei schreib-
intensiver Last.


XL

Re: MySQL Storage und Leistungssteigerung

Hallo,

Gibt es überhaupt ein Datenbankmanagementsystem bzw. Softwarekomponenten die einen
konkurierenden Zugriff mehrerer DB-Server auf eine einzige Datenbank, welche sich
auf einem SAN befindet, unterstützen. Also quasi eine Implementation eines
Lock-Management wie du es geschrieben hast. Weiterhin wäre es noch interessant
wenn das oben geschriebene überhaupt funktionieren würde, ob es eine
Performancesteigerung auch bei schreibenden Transaktionen zur Folge hätte?

Außerdem hast du erwähnt, dass der Einsatz von MySQL Cluster auch bei schreibenden
Vorgängen zu Performancesteigerungen führen würde. Welche Anpassungen an einer
bereits existierenden Datenbank müßten gemacht werden um MySQL Cluster zu nutzen.
Ich habe gelesen das eine spezielle Speicher Engine zum Einsatz kommt. Welche
Änderungen sind an den vorhandenen Tabellen notwendig? Was ist noch zusätzlich zu
beachten?

MfG
André Jahn

Axel Schwenke schrieb:

> "Christian Schmelzer" wrote:
>
> > hat jemand Erfahrungen mit einem Storage System (SAN) und MySQL?
>
> Ja. Allerdings ist das komplett transparent. So richtig große Vorteile
> hat das aber nicht. Das beste dürfte sein, daß synchrone Schreibzugriffe
> (z.B. auf das REDO-Log) schneller fertig werden, weil das SAN batterie-
> gepufferten Cache hat und deswegen nicht auf die Platte warten muß.
>
> > Zur Zeit läuft
> > es so das 8 DB Server permanent Berechnungen durchführen und die berechneten
> > Daten auf einen Frontend Server "kopieren". Kopieren in Form von INSERTS und
> > REPLACE. Auf dem Frontend Server werden Daten durch die Benutzer abgefragt.
> > Unschön hierbei ist, dass der Frontend Server nur einmal vorhanden ist. Wir
> > haben diesen schon mal auf einen Slave repliziert, was aber auch nicht
> > sonderlich gut ist. Einmal muss der Slave genauso performant sein und
> > außerdem muss dieser im Grunde genauso alles mitmachen was der Master auch
> > schon gemacht hat.
> > Besser wäre es wenn mehrere Frontend Server auf einen Storage zugreifen
> > können. Ich frage mich nur, wie das funktionieren kann, wenn z.B. zwei
> > Frontend Server auf der gleichen Datenbank arbeiten.
>
> Gar nicht. "Shared Storage" ist auch in SANs ein besonderer Betriebs-
> modus. In der überwiegenden Zahl der Fälle heißt "shared" auch "entweder
> oder". Es greift also immer nur ein Host auf das gemeinsame Volume zu.
> "Richtiges" Sharing, wo mehrere Hosts praktisch gleichzeitig auf das
> gleiche Volume zugreifen, erfordert aufwendiges Lock-Management.
>
> MySQL kann das schon mal nicht.
>
> > Das MySQL Cluster ist keine Lösung da zu viele Punkte nicht passen, z.B.
> > sind die DBs weit größer als 100 GB, wir brauchen Features die das Cluster
> > nicht kennt.
>
> Schade. Für schreib-intensive Sache ist Cluster die beste Lösung.
> Wie du selber bemerkst hast, bringt Replikation nichts bei schreib-
> intensiver Last.
>
> XL

Re: MySQL Storage und Leistungssteigerung

=?iso-8859-1?Q?Andr=E9?= Jahn wrote:
>
> Gibt es überhaupt ein Datenbankmanagementsystem bzw. Softwarekomponenten die einen
> konkurierenden Zugriff mehrerer DB-Server auf eine einzige Datenbank, welche sich
> auf einem SAN befindet, unterstützen. Also quasi eine Implementation eines
> Lock-Management wie du es geschrieben hast.

Ja. z.B. Oracle RAC implementiert das. Und jeder andere Shared-Disk
Cluster auch irgendwie. Wenn es ein Filesystem sein darf: Linux kommt
seit einiger Zeit mit OCFS2 und GFS2. Das sind Filesysteme, bei denen
mehrere Clusterknoten das gleiche Volume parallel mounten können. Auch
da ist ein Distributed Lock Manager im Spiel.

http://en.wikipedia.org/wiki/Distributed_lock_manager

> Weiterhin wäre es noch interessant
> wenn das oben geschriebene überhaupt funktionieren würde, ob es eine
> Performancesteigerung auch bei schreibenden Transaktionen zur Folge hätte?

Solange die Schreibzugriffe auf dem Medium verteilt sind, können Knoten
auch unabhängig voneinander schreiben. Wie gut das funktioniert, hängt
im wesentlichen davon ab, mit welcher Granularität der DLM arbeitet.
Wenn die Locks auf einzelne Records vergeben werden, können mehr Knoten
gleichzeitig schreiben, allerdings wird das Locking aufwendiger.

MySQL Cluster hat das Problem nicht, weil das ein shared-nothing Cluster
ist. Es gibt keine geteilte Ressource für die man Locks bräuchte.

> Außerdem hast du erwähnt, dass der Einsatz von MySQL Cluster auch bei schreibenden
> Vorgängen zu Performancesteigerungen führen würde.

Der wesentliche Vorteil von MySQL Cluster aka NDB Storage Engine ist
hier, daß die Daten in M-Trees direkt im RAM gehalten werden. Ansonsten
sind Tabellen über Nodegroups partitioniert, im statistischen Mittel
verteilen sich die Schreibzugriffe gleichmäßig über die Nodegroups.

> Welche Anpassungen an einer
> bereits existierenden Datenbank müßten gemacht werden um MySQL Cluster zu nutzen.

Du kannst keins der Features verwenden, das es für NDB nicht gibt.
Das wären z.B. referentielle Constraints oder Fulltext Indizes.

Schau halt selber:
http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-limitat ions.html

(ein paar Einschränkungen sind in 5.1 aufgehoben, auch kann man da
BLOBs auf Platte halten)

> Ich habe gelesen das eine spezielle Speicher Engine zum Einsatz kommt. Welche
> Änderungen sind an den vorhandenen Tabellen notwendig? Was ist noch zusätzlich zu
> beachten?

Du solltest deine Spalten knapper dimensionieren. Großzügigkeit a'la
"machen wir alle VARCHARs gleich 255 Zeichen groß" ist fehl am Platz,
wenn alle Daten ins RAM passen müssen.

Ansonsten ist die Migration einer Tabelle in den Cluster einfach:
ALTER TABLE foo ENGINE NDB;

Das Ding steht zum freien Download bereit. Das Handbuch ist auch da.
Also los und selber probieren!


XL