MySQL Cluster - Versionsgeschichte

InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert. #IABot (v2.0beta14)

2019-05-02T18:54:36Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert. #IABot (v2.0beta14)

← Nächstältere Version		Version vom 2. Mai 2019, 20:54 Uhr
Zeile 8:		Zeile 8:

	== Einsatzgebiete ==		== Einsatzgebiete ==
	MySQL Cluster wird oft als DBMS (Database Management System) im Web-Umfeld eingesetzt, wo es darauf ankommt, viele Lesezugriffe in Kombination mit einer hohen Ausfallsicherheit zu erreichen. Für solche Anforderungen hat MySQL Cluster bei Tests schon bessere Zugriffszeiten bewiesen als Oracle, DB2 und MS SQL.<ref>[http://www.computerwoche.de/heftarchiv/2006/45/1216635/ ''MySQL-Zeichen stehen auf Enterprise''], Computerwoche 45/2006</ref>		MySQL Cluster wird oft als DBMS (Database Management System) im Web-Umfeld eingesetzt, wo es darauf ankommt, viele Lesezugriffe in Kombination mit einer hohen Ausfallsicherheit zu erreichen. Für solche Anforderungen hat MySQL Cluster bei Tests schon bessere Zugriffszeiten bewiesen als Oracle, DB2 und MS SQL.<ref>{{Webarchiv\|url=http://www.computerwoche.de/heftarchiv/2006/45/1216635/ \|wayback=20120714074522 \|text=''MySQL-Zeichen stehen auf Enterprise'' \|archiv-bot=2019-05-02 18:54:36 InternetArchiveBot }}, Computerwoche 45/2006</ref>

	== Architektur ==		== Architektur ==

Invisigoth67: form

2018-10-01T22:24:08Z

form

← Nächstältere Version		Version vom 2. Oktober 2018, 00:24 Uhr
Zeile 14:		Zeile 14:
	; Datenknoten (Ndbd): Datenknoten speichern alle zu MySQL Cluster gehörenden Daten. Die Daten werden im Normalfall zwischen den Datenknoten des Clusters [[Replikation (Datenverarbeitung)\|repliziert]], um sicherzustellen, dass diese bei Ausfall eines oder mehrerer Knoten ununterbrochen verfügbar sind. Datenknoten verwalten außerdem [[Transaktion (Informatik)\|Datenbanktransaktionen]]. Bei mehr als zwei Datenknoten werden die Knoten in sogenannte ''Nodegroups'' (Knotengruppen) unterteilt. Eine Nodegroup muss aus mindestens zwei Datenknoten bestehen. Innerhalb einer Nodegroup werden die Daten repliziert. Beim Einfügen eines neuen Satzes bildet das System einen Hash aus dem Primärschlüssel (die NDB-Engine erzeugt automatisch einen Primärschlüssel, falls keiner definiert ist). Der Wert des Hashs bestimmt, in welcher Nodegroup der Satz abgelegt wird. Dadurch wird eine statistische Gleichverteilung erreicht. Diese Methode der Datenverteilung wird auch als ''Partitionierung'' bezeichnet.		; Datenknoten (Ndbd): Datenknoten speichern alle zu MySQL Cluster gehörenden Daten. Die Daten werden im Normalfall zwischen den Datenknoten des Clusters [[Replikation (Datenverarbeitung)\|repliziert]], um sicherzustellen, dass diese bei Ausfall eines oder mehrerer Knoten ununterbrochen verfügbar sind. Datenknoten verwalten außerdem [[Transaktion (Informatik)\|Datenbanktransaktionen]]. Bei mehr als zwei Datenknoten werden die Knoten in sogenannte ''Nodegroups'' (Knotengruppen) unterteilt. Eine Nodegroup muss aus mindestens zwei Datenknoten bestehen. Innerhalb einer Nodegroup werden die Daten repliziert. Beim Einfügen eines neuen Satzes bildet das System einen Hash aus dem Primärschlüssel (die NDB-Engine erzeugt automatisch einen Primärschlüssel, falls keiner definiert ist). Der Wert des Hashs bestimmt, in welcher Nodegroup der Satz abgelegt wird. Dadurch wird eine statistische Gleichverteilung erreicht. Diese Methode der Datenverteilung wird auch als ''Partitionierung'' bezeichnet.
	:* Datenspeicherung: Bis Version 5 wurden alle Daten im Hauptspeicher gehalten und periodisch auf die Platte geschrieben. Grob gesprochen hieß dies, dass die Datenknoten insgesamt soviel Hauptspeicher haben mussten, wie die Größe der Datenbank betrug; das mitgelieferte Skript „ndb_size.pl“ erlaubte es, den voraussichtlichen Speicherbedarf für eine existierende Datenbank abzuschätzen. Ab Version 6 gibt es den Tabellentyp „storage disk“, bei dem Indexfelder im Hauptspeicher und die restlichen Felder auf der Platte gespeichert werden.		:* Datenspeicherung: Bis Version 5 wurden alle Daten im Hauptspeicher gehalten und periodisch auf die Platte geschrieben. Grob gesprochen hieß dies, dass die Datenknoten insgesamt soviel Hauptspeicher haben mussten, wie die Größe der Datenbank betrug; das mitgelieferte Skript „ndb_size.pl“ erlaubte es, den voraussichtlichen Speicherbedarf für eine existierende Datenbank abzuschätzen. Ab Version 6 gibt es den Tabellentyp „storage disk“, bei dem Indexfelder im Hauptspeicher und die restlichen Felder auf der Platte gespeichert werden.
	:* Rollen: Genau ein Ndb-Knoten im Cluster ist der '''Master'''. Diese Rolle wird beim Start vom Arbitrator zugeteilt. Der Master hat die primäre Information über den Zustand des Clusters. Ohne Master ist der Cluster arbeitsunfähig. Bei Ausfall kann ein anderer Knoten diese Rolle übernehmen - allerdings nur mit Zustimmung des Arbitrators oder der absoluten Mehrheit der Ndb-Knoten. Falls Teile des Clusters ihre Verbindung verlieren, aber noch arbeitsfähig sind ([[Split Brain (Informatik)\|split brain scenario]]), entscheidet der '''Arbitrator''' (Schiedsrichter), wer Master sein soll. Per Default ist der Manager der Arbitrator; es ist aber möglich, eine Hierarchie zu konfigurieren; dabei wird oft eine ungerade Zahl gewählt, um die Mehrheitsfähigkeit zu erhalten. Als Arbitrator können Management- oder SQL-Knoten dienen.		:* Rollen: Genau ein Ndb-Knoten im Cluster ist der '''Master'''. Diese Rolle wird beim Start vom Arbitrator zugeteilt. Der Master hat die primäre Information über den Zustand des Clusters. Ohne Master ist der Cluster arbeitsunfähig. Bei Ausfall kann ein anderer Knoten diese Rolle übernehmen – allerdings nur mit Zustimmung des Arbitrators oder der absoluten Mehrheit der Ndb-Knoten. Falls Teile des Clusters ihre Verbindung verlieren, aber noch arbeitsfähig sind ([[Split Brain (Informatik)\|split brain scenario]]), entscheidet der '''Arbitrator''' (Schiedsrichter), wer Master sein soll. Per Default ist der Manager der Arbitrator; es ist aber möglich, eine Hierarchie zu konfigurieren; dabei wird oft eine ungerade Zahl gewählt, um die Mehrheitsfähigkeit zu erhalten. Als Arbitrator können Management- oder SQL-Knoten dienen.
	; Managementknoten: Ein Managementknoten ist für die Systemkonfiguration, die Knotenverwaltung und die Aufzeichnung der Aktivitäten im Cluster zuständig. Es können ein oder mehrere Managementknoten aus Verfügbarkeitsgründen gleichzeitig eingesetzt werden. Im laufenden Betrieb wird dieser Knoten nur benötigt, wenn sich ein ausgefallener anderer Knoten wieder am Cluster anmelden will. Wenn der Managementknoten zusätzlich Arbitrator (Default) ist, muss er auch verfügbar sein, wenn der Master ausfällt. Da Ausfälle nicht vorhersehbar sind, sollte dieser Knoten daher immer laufen.		; Managementknoten: Ein Managementknoten ist für die Systemkonfiguration, die Knotenverwaltung und die Aufzeichnung der Aktivitäten im Cluster zuständig. Es können ein oder mehrere Managementknoten aus Verfügbarkeitsgründen gleichzeitig eingesetzt werden. Im laufenden Betrieb wird dieser Knoten nur benötigt, wenn sich ein ausgefallener anderer Knoten wieder am Cluster anmelden will. Wenn der Managementknoten zusätzlich Arbitrator (Default) ist, muss er auch verfügbar sein, wenn der Master ausfällt. Da Ausfälle nicht vorhersehbar sind, sollte dieser Knoten daher immer laufen.
	; SQL-Knoten: Ein SQL-Knoten entspricht einem MySQL-Datenbanksystem, das mit Datenknoten kommunizieren kann. Die SQL-Knoten können einzeln oder über [[Lastverteilung (Informatik)\|Lastverteilung]] unter einer Sammel-IP angesprochen werden.		; SQL-Knoten: Ein SQL-Knoten entspricht einem MySQL-Datenbanksystem, das mit Datenknoten kommunizieren kann. Die SQL-Knoten können einzeln oder über [[Lastverteilung (Informatik)\|Lastverteilung]] unter einer Sammel-IP angesprochen werden.

62.204.160.68: Bei der Availability fehlte eine weitere 9 hinter dem Komma. Ist sowohl aus der angegebenen Quelle ersichtlich, als auch aus der aufs Jahr gerechneten Minutenzahl von unter 6. Scheint also einfach ein Vertipper gewesen zu sein.

2018-06-28T11:20:07Z

Bei der Availability fehlte eine weitere 9 hinter dem Komma. Ist sowohl aus der angegebenen Quelle ersichtlich, als auch aus der aufs Jahr gerechneten Minutenzahl von unter 6. Scheint also einfach ein Vertipper gewesen zu sein.

← Nächstältere Version		Version vom 28. Juni 2018, 13:20 Uhr
Zeile 1:		Zeile 1:
	'''MySQL Cluster''' ist eine Speicher-Engine des [[Freie Software\|freien]] [[Datenbanksystem]]s ''[[MySQL]]'' in der aktuell verfügbaren Version 7.2. Sie ermöglicht die Installation der Datenbank auf einem [[Computercluster]], der in einer [[Shared Nothing Architecture]] aufgebaut ist. Das bedeutet, dass jeder Rechner-Knoten seine eigenen Festplatten und Arbeitsspeicher hat. Wenn die einzelnen Rechner-Knoten mit einem genügend großen Arbeitsspeicher ausgestattet sind, dann können alle Daten im Arbeitsspeicher gehalten werden (bis Version 5.0 war das zwingend, ab Version 5.1 gibt es auch plattenresidente Tabellen).		'''MySQL Cluster''' ist eine Speicher-Engine des [[Freie Software\|freien]] [[Datenbanksystem]]s ''[[MySQL]]'' in der aktuell verfügbaren Version 7.2. Sie ermöglicht die Installation der Datenbank auf einem [[Computercluster]], der in einer [[Shared Nothing Architecture]] aufgebaut ist. Das bedeutet, dass jeder Rechner-Knoten seine eigenen Festplatten und Arbeitsspeicher hat. Wenn die einzelnen Rechner-Knoten mit einem genügend großen Arbeitsspeicher ausgestattet sind, dann können alle Daten im Arbeitsspeicher gehalten werden (bis Version 5.0 war das zwingend, ab Version 5.1 gibt es auch plattenresidente Tabellen).

	Nach eigenen Angaben bietet die Cluster-Technologie von [[MySQL]] eine [[Hochverfügbarkeit\|Verfügbarkeit]] von 99,~~999~~ %.<ref>[http://www.mysql.de/products/database/cluster/ MySQL-Website]</ref><ref>{{Literatur\|Titel=Computerwoche\|Nummer=45\|Jahr=2006\|Seiten=24}}</ref> Das bedeutet eine jährliche Ausfallzeit von weniger als sechs Minuten.		Nach eigenen Angaben bietet die Cluster-Technologie von [[MySQL]] eine [[Hochverfügbarkeit\|Verfügbarkeit]] von 99,9999 %.<ref>[http://www.mysql.de/products/database/cluster/ MySQL-Website]</ref><ref>{{Literatur\|Titel=Computerwoche\|Nummer=45\|Jahr=2006\|Seiten=24}}</ref> Das bedeutet eine jährliche Ausfallzeit von weniger als sechs Minuten.

	Die ''NDB-Speicher-Engine'' (Network-Database-Speicher-Engine) ist eine unabhängige Komponente, die persistente Speicherung von Daten ermöglicht und für die Koordinierung aller Zugriffe auf Datenknoten in einem MySQL-Cluster zuständig ist. Anwendungen können direkt auf die NDB-Speicher-Engine über verschiedene [[NoSQL]]-Schnittstellen oder über einen MySQL-Knoten per SQL zugreifen.		Die ''NDB-Speicher-Engine'' (Network-Database-Speicher-Engine) ist eine unabhängige Komponente, die persistente Speicherung von Daten ermöglicht und für die Koordinierung aller Zugriffe auf Datenknoten in einem MySQL-Cluster zuständig ist. Anwendungen können direkt auf die NDB-Speicher-Engine über verschiedene [[NoSQL]]-Schnittstellen oder über einen MySQL-Knoten per SQL zugreifen.

Aka: doppelten Link entfernt

2017-11-15T16:27:15Z

doppelten Link entfernt

← Nächstältere Version		Version vom 15. November 2017, 18:27 Uhr
Zeile 5:		Zeile 5:
	Die ''NDB-Speicher-Engine'' (Network-Database-Speicher-Engine) ist eine unabhängige Komponente, die persistente Speicherung von Daten ermöglicht und für die Koordinierung aller Zugriffe auf Datenknoten in einem MySQL-Cluster zuständig ist. Anwendungen können direkt auf die NDB-Speicher-Engine über verschiedene [[NoSQL]]-Schnittstellen oder über einen MySQL-Knoten per SQL zugreifen.		Die ''NDB-Speicher-Engine'' (Network-Database-Speicher-Engine) ist eine unabhängige Komponente, die persistente Speicherung von Daten ermöglicht und für die Koordinierung aller Zugriffe auf Datenknoten in einem MySQL-Cluster zuständig ist. Anwendungen können direkt auf die NDB-Speicher-Engine über verschiedene [[NoSQL]]-Schnittstellen oder über einen MySQL-Knoten per SQL zugreifen.

	''NDB Cluster'' wurde 2003 von [[MySQL AB]] mit Erwerb des Unternehmens Alzato (einem Ericsson-Ableger) übernommen. 2008 wurde [[MySQL AB]] von [[Sun Microsystems]] übernommen. 2010 wiederum wurde Sun von Oracle übernommen.		''NDB Cluster'' wurde 2003 von [[MySQL AB]] mit Erwerb des Unternehmens Alzato (einem Ericsson-Ableger) übernommen. 2008 wurde MySQL AB von [[Sun Microsystems]] übernommen. 2010 wiederum wurde Sun von Oracle übernommen.

	== Einsatzgebiete ==		== Einsatzgebiete ==

134.169.7.61: /* Einsatzgebiete */

2016-02-18T06:55:53Z

Einsatzgebiete

← Nächstältere Version		Version vom 18. Februar 2016, 08:55 Uhr
Zeile 8:		Zeile 8:

	== Einsatzgebiete ==		== Einsatzgebiete ==
	MySQL Cluster wird oft als DBMS im Web-Umfeld eingesetzt, wo es darauf ankommt, viele Lesezugriffe in Kombination mit einer hohen Ausfallsicherheit zu erreichen. Für solche Anforderungen hat MySQL Cluster bei Tests schon bessere Zugriffszeiten bewiesen als Oracle, DB2 und MS SQL.<ref>[http://www.computerwoche.de/heftarchiv/2006/45/1216635/ ''MySQL-Zeichen stehen auf Enterprise''], Computerwoche 45/2006</ref>		MySQL Cluster wird oft als DBMS (Database Management System) im Web-Umfeld eingesetzt, wo es darauf ankommt, viele Lesezugriffe in Kombination mit einer hohen Ausfallsicherheit zu erreichen. Für solche Anforderungen hat MySQL Cluster bei Tests schon bessere Zugriffszeiten bewiesen als Oracle, DB2 und MS SQL.<ref>[http://www.computerwoche.de/heftarchiv/2006/45/1216635/ ''MySQL-Zeichen stehen auf Enterprise''], Computerwoche 45/2006</ref>

	== Architektur ==		== Architektur ==

176.0.91.76 am 6. April 2015 um 11:46 Uhr

2015-04-06T11:46:47Z

← Nächstältere Version		Version vom 6. April 2015, 13:46 Uhr
Zeile 33:		Zeile 33:

	''Sicherheit'':		''Sicherheit'':
	Der Datenverkehr innerhalb des Clusters ist ~~'''~~nicht~~'''~~ kryptographisch abgesichert. Es ist Verantwortung des Betreibers, den Cluster abzuschirmen, z. B. durch Firewallregeln oder ein eigenes Tunnelnetz.		Der Datenverkehr innerhalb des Clusters ist nicht kryptographisch abgesichert. Es ist Verantwortung des Betreibers, den Cluster abzuschirmen, z. B. durch Firewallregeln oder ein eigenes Tunnelnetz.

	== Plattformen ==		== Plattformen ==

176.0.91.76 am 6. April 2015 um 11:44 Uhr

2015-04-06T11:44:54Z

46.114.179.189 am 27. Dezember 2014 um 19:28 Uhr

2014-12-27T19:28:57Z

← Nächstältere Version		Version vom 27. Dezember 2014, 21:28 Uhr
Zeile 8:		Zeile 8:

	== Einsatzgebiete ==		== Einsatzgebiete ==
	MySQL Cluster wird oft als DBMS im Web-Umfeld eingesetzt, wo es darauf ankommt, ~~dass~~ viele Lesezugriffe ~~schnell ausgeführt werden~~ ~~und~~ ~~dass~~ ~~eine~~ ~~hohe~~ Ausfallsicherheit ~~gewährleistet~~ ~~wird~~. Für solche Anforderungen hat MySQL Cluster bei Tests schon bessere Zugriffszeiten bewiesen als Oracle, DB2 und MS SQL.<ref>[http://www.computerwoche.de/heftarchiv/2006/45/1216635/ ''MySQL-Zeichen stehen auf Enterprise''], Computerwoche 45/2006</ref>		MySQL Cluster wird oft als DBMS im Web-Umfeld eingesetzt, wo es darauf ankommt, viele Lesezugriffe in Kombination mit einer hohen Ausfallsicherheit zu erreichen. Für solche Anforderungen hat MySQL Cluster bei Tests schon bessere Zugriffszeiten bewiesen als Oracle, DB2 und MS SQL.<ref>[http://www.computerwoche.de/heftarchiv/2006/45/1216635/ ''MySQL-Zeichen stehen auf Enterprise''], Computerwoche 45/2006</ref>

	== Architektur ==		== Architektur ==

91.119.143.62: Rechtschreibung

2014-12-16T22:00:30Z

Rechtschreibung

← Nächstältere Version		Version vom 17. Dezember 2014, 00:00 Uhr
Zeile 17:		Zeile 17:
	; Managementknoten: Ein Managementknoten ist für die Systemkonfiguration, die Knotenverwaltung und die Aufzeichnung der Aktivitäten im Cluster zuständig. Es können ein oder mehrere Managementknoten aus Verfügbarkeitsgründen gleichzeitig eingesetzt werden. Im laufenden Betrieb wird dieser Knoten nur benötigt, wenn sich ein ausgefallener anderer Knoten wieder am Cluster anmelden will. Wenn der Managementknoten zusätzlich Arbitrator (Default) ist, muss er auch verfügbar sein, wenn der Master ausfällt. Da Ausfälle nicht vorhersehbar sind, sollte dieser Knoten daher immer laufen.		; Managementknoten: Ein Managementknoten ist für die Systemkonfiguration, die Knotenverwaltung und die Aufzeichnung der Aktivitäten im Cluster zuständig. Es können ein oder mehrere Managementknoten aus Verfügbarkeitsgründen gleichzeitig eingesetzt werden. Im laufenden Betrieb wird dieser Knoten nur benötigt, wenn sich ein ausgefallener anderer Knoten wieder am Cluster anmelden will. Wenn der Managementknoten zusätzlich Arbitrator (Default) ist, muss er auch verfügbar sein, wenn der Master ausfällt. Da Ausfälle nicht vorhersehbar sind, sollte dieser Knoten daher immer laufen.
	; SQL-Knoten: Ein SQL-Knoten entspricht einem MySQL Datenbanksystem, das mit Datenknoten kommunizieren kann. Die SQL-Knoten können einzeln oder über [[Lastverteilung (Informatik)\|Lastverteilung]] unter einer Sammel-IP angesprochen werden.		; SQL-Knoten: Ein SQL-Knoten entspricht einem MySQL Datenbanksystem, das mit Datenknoten kommunizieren kann. Die SQL-Knoten können einzeln oder über [[Lastverteilung (Informatik)\|Lastverteilung]] unter einer Sammel-IP angesprochen werden.
	Das MySQL Datenbanksystem erlaubt die Verwendung von Datenbank-Managementsystemen mit verschiedenen Konzepten: mit und ohne Durchführung von Transaktionen, mit und ohne ~~persistente~~ Speicherung, mit und ohne den Einsatz von gespeicherten Prozeduren, mit synchroner oder asynchroner Replikation usw.		Das MySQL Datenbanksystem erlaubt die Verwendung von Datenbank-Managementsystemen mit verschiedenen Konzepten: mit und ohne Durchführung von Transaktionen, mit und ohne persistenter Speicherung, mit und ohne den Einsatz von gespeicherten Prozeduren, mit synchroner oder asynchroner Replikation usw.

	Der grobe Ablauf einer Benutzeranfrage ist wie folgt:		Der grobe Ablauf einer Benutzeranfrage ist wie folgt:

Millbart: Änderungen von 95.116.220.62 (Diskussion) auf die letzte Version von Robb zurückgesetzt

2014-06-12T12:05:19Z

Änderungen von 95.116.220.62 (Diskussion) auf die letzte Version von Robb zurückgesetzt

← Nächstältere Version		Version vom 12. Juni 2014, 14:05 Uhr
Zeile 34:		Zeile 34:
	''Sicherheit'':		''Sicherheit'':
	Der Datenverkehr innerhalb des Clusters ist '''nicht''' kryptographisch abgesichert. Es ist Verantwortung des Betreibers, den Cluster abzuschirmen, z. B. durch Firewallregeln oder ein eigenes Tunnelnetz.		Der Datenverkehr innerhalb des Clusters ist '''nicht''' kryptographisch abgesichert. Es ist Verantwortung des Betreibers, den Cluster abzuschirmen, z. B. durch Firewallregeln oder ein eigenes Tunnelnetz.

	== Verwaltung ==
	Seit Juni 2014 gibt es ein eigenes Framework zur Verwaltung des Clusters.<ref>[http://www.informatik-aktuell.de/aktuelle-meldungen/einzelansicht/archive/2014/juni/article/mysql-cluster-werkzeug-zur-verwaltung.html Informatik Aktuell]</ref> MySQL Fabric ist der Name des Werkzeugsets. Es wurde als freie Software unter der GPLv2 lizenziert. Oracle bietet zudem eine kommerzielle Lizenz mit Support für die Enterprise-Version von MySQL an.<ref>[http://www.informatik-aktuell.de/aktuelle-meldungen/einzelansicht/archive/2014/juni/article/mysql-cluster-werkzeug-zur-verwaltung.html Informatik Aktuell]</ref>

	== Plattformen ==		== Plattformen ==

← Nächstältere Version		Version vom 6. April 2015, 13:44 Uhr
Zeile 1:		Zeile 1:
	'''MySQL Cluster''' ist eine Speicher-Engine des [[Freie Software\|freien]] [[Datenbanksystem]]s ''[[MySQL]]'' in der aktuell verfügbaren Version 7.2. Sie ermöglicht die Installation der Datenbank auf einem [[Computercluster]], ~~das~~ in einer [[Shared Nothing Architecture]] aufgebaut ist. Das bedeutet, dass jeder Rechner-Knoten seine eigenen Festplatten und Arbeitsspeicher hat. Wenn die einzelnen Rechner-Knoten mit einem genügend großen Arbeitsspeicher ausgestattet sind, dann können alle Daten im Arbeitsspeicher gehalten werden (bis Version 5.0 war das zwingend, ab Version 5.1 gibt es auch plattenresidente Tabellen).		'''MySQL Cluster''' ist eine Speicher-Engine des [[Freie Software\|freien]] [[Datenbanksystem]]s ''[[MySQL]]'' in der aktuell verfügbaren Version 7.2. Sie ermöglicht die Installation der Datenbank auf einem [[Computercluster]], der in einer [[Shared Nothing Architecture]] aufgebaut ist. Das bedeutet, dass jeder Rechner-Knoten seine eigenen Festplatten und Arbeitsspeicher hat. Wenn die einzelnen Rechner-Knoten mit einem genügend großen Arbeitsspeicher ausgestattet sind, dann können alle Daten im Arbeitsspeicher gehalten werden (bis Version 5.0 war das zwingend, ab Version 5.1 gibt es auch plattenresidente Tabellen).

	Nach eigenen Angaben bietet die Cluster-Technologie von [[MySQL]] eine [[Hochverfügbarkeit\|Verfügbarkeit]] von 99,999 %.<ref>[http://www.mysql.de/products/database/cluster/ MySQL-Website]</ref><ref>{{Literatur\|Titel=Computerwoche\|Nummer=45\|Jahr=2006\|Seiten=24}}</ref> Das bedeutet eine jährliche Ausfallzeit von weniger als sechs Minuten.		Nach eigenen Angaben bietet die Cluster-Technologie von [[MySQL]] eine [[Hochverfügbarkeit\|Verfügbarkeit]] von 99,999 %.<ref>[http://www.mysql.de/products/database/cluster/ MySQL-Website]</ref><ref>{{Literatur\|Titel=Computerwoche\|Nummer=45\|Jahr=2006\|Seiten=24}}</ref> Das bedeutet eine jährliche Ausfallzeit von weniger als sechs Minuten.

	Die ''NDB'' ''(Network Database~~)''~~-Speicher-Engine ist eine unabhängige Komponente, die persistente Speicherung von Daten ermöglicht und für die ~~Koordination~~ aller Zugriffe auf Datenknoten in einem MySQL Cluster zuständig ist. Anwendungen können direkt auf die NDB-Speicher-Engine über verschiedene [[NoSQL]]-Schnittstellen oder über einen MySQL-Knoten ~~via~~ SQL zugreifen.		Die ''NDB-Speicher-Engine'' (Network-Database-Speicher-Engine) ist eine unabhängige Komponente, die persistente Speicherung von Daten ermöglicht und für die Koordinierung aller Zugriffe auf Datenknoten in einem MySQL-Cluster zuständig ist. Anwendungen können direkt auf die NDB-Speicher-Engine über verschiedene [[NoSQL]]-Schnittstellen oder über einen MySQL-Knoten per SQL zugreifen.

	NDB Cluster wurde 2003 von [[MySQL AB]] mit Erwerb des Unternehmens Alzato (einem Ericsson-Ableger) übernommen. 2008 wurde [[MySQL AB]] von [[Sun Microsystems]] übernommen. 2010 wiederum wurde Sun von Oracle übernommen.		''NDB Cluster'' wurde 2003 von [[MySQL AB]] mit Erwerb des Unternehmens Alzato (einem Ericsson-Ableger) übernommen. 2008 wurde [[MySQL AB]] von [[Sun Microsystems]] übernommen. 2010 wiederum wurde Sun von Oracle übernommen.

	== Einsatzgebiete ==		== Einsatzgebiete ==
Zeile 13:		Zeile 13:
	Im MySQL Cluster werden drei Arten von Knoten unterschieden:<ref>{{Literatur\|Autor=Larissa Janssen\|Titel=Hochleistungs-Datenbanksysteme: Theorie und Praxis\|Verlag=Books on Demand GmbH\|Jahr=2008\|Seiten=188–189\|ISBN=3-8334-9326-7}}</ref>		Im MySQL Cluster werden drei Arten von Knoten unterschieden:<ref>{{Literatur\|Autor=Larissa Janssen\|Titel=Hochleistungs-Datenbanksysteme: Theorie und Praxis\|Verlag=Books on Demand GmbH\|Jahr=2008\|Seiten=188–189\|ISBN=3-8334-9326-7}}</ref>
	; Datenknoten (Ndbd): Datenknoten speichern alle zu MySQL Cluster gehörenden Daten. Die Daten werden im Normalfall zwischen den Datenknoten des Clusters [[Replikation (Datenverarbeitung)\|repliziert]], um sicherzustellen, dass diese bei Ausfall eines oder mehrerer Knoten ununterbrochen verfügbar sind. Datenknoten verwalten außerdem [[Transaktion (Informatik)\|Datenbanktransaktionen]]. Bei mehr als zwei Datenknoten werden die Knoten in sogenannte ''Nodegroups'' (Knotengruppen) unterteilt. Eine Nodegroup muss aus mindestens zwei Datenknoten bestehen. Innerhalb einer Nodegroup werden die Daten repliziert. Beim Einfügen eines neuen Satzes bildet das System einen Hash aus dem Primärschlüssel (die NDB-Engine erzeugt automatisch einen Primärschlüssel, falls keiner definiert ist). Der Wert des Hashs bestimmt, in welcher Nodegroup der Satz abgelegt wird. Dadurch wird eine statistische Gleichverteilung erreicht. Diese Methode der Datenverteilung wird auch als ''Partitionierung'' bezeichnet.		; Datenknoten (Ndbd): Datenknoten speichern alle zu MySQL Cluster gehörenden Daten. Die Daten werden im Normalfall zwischen den Datenknoten des Clusters [[Replikation (Datenverarbeitung)\|repliziert]], um sicherzustellen, dass diese bei Ausfall eines oder mehrerer Knoten ununterbrochen verfügbar sind. Datenknoten verwalten außerdem [[Transaktion (Informatik)\|Datenbanktransaktionen]]. Bei mehr als zwei Datenknoten werden die Knoten in sogenannte ''Nodegroups'' (Knotengruppen) unterteilt. Eine Nodegroup muss aus mindestens zwei Datenknoten bestehen. Innerhalb einer Nodegroup werden die Daten repliziert. Beim Einfügen eines neuen Satzes bildet das System einen Hash aus dem Primärschlüssel (die NDB-Engine erzeugt automatisch einen Primärschlüssel, falls keiner definiert ist). Der Wert des Hashs bestimmt, in welcher Nodegroup der Satz abgelegt wird. Dadurch wird eine statistische Gleichverteilung erreicht. Diese Methode der Datenverteilung wird auch als ''Partitionierung'' bezeichnet.
	:* Datenspeicherung: Bis Version-5 wurden alle Daten im Hauptspeicher gehalten und periodisch auf die Platte geschrieben. Grob gesprochen hieß dies, dass die Datenknoten insgesamt soviel Hauptspeicher haben mussten, wie die Größe der Datenbank betrug; das mitgelieferte Skript „ndb_size.pl“ erlaubte es, den voraussichtlichen Speicherbedarf für eine existierende Datenbank abzuschätzen. Ab Version-6 gibt es den Tabellentyp „storage disk“, bei dem Indexfelder im Hauptspeicher und die restlichen Felder auf der Platte gespeichert werden.		:* Datenspeicherung: Bis Version 5 wurden alle Daten im Hauptspeicher gehalten und periodisch auf die Platte geschrieben. Grob gesprochen hieß dies, dass die Datenknoten insgesamt soviel Hauptspeicher haben mussten, wie die Größe der Datenbank betrug; das mitgelieferte Skript „ndb_size.pl“ erlaubte es, den voraussichtlichen Speicherbedarf für eine existierende Datenbank abzuschätzen. Ab Version 6 gibt es den Tabellentyp „storage disk“, bei dem Indexfelder im Hauptspeicher und die restlichen Felder auf der Platte gespeichert werden.
	:* Rollen: Genau ein Ndb-Knoten im Cluster ist der '''Master'''. Diese Rolle wird beim Start vom Arbitrator zugeteilt. Der Master hat die primäre Information über den Zustand des Clusters. Ohne Master ist ~~das~~ Cluster arbeitsunfähig. Bei Ausfall kann ein anderer Knoten diese Rolle übernehmen - allerdings nur mit Zustimmung des Arbitrators oder der absoluten Mehrheit der Ndb-Knoten. Falls Teile des Clusters ihre Verbindung verlieren, aber noch arbeitsfähig sind ([[Split Brain (Informatik)\|split brain scenario]]), entscheidet der '''Arbitrator''' (Schiedsrichter), wer Master sein soll. Per Default ist der Manager der Arbitrator; es ist aber möglich, eine Hierarchie zu konfigurieren; in ~~diesem~~ ~~Fall sollte man~~ eine ungerade Zahl ~~wählen~~, um ~~'mehrheitsfähig'~~ zu ~~bleiben~~. Als Arbitrator können Management- oder SQL-Knoten dienen.		:* Rollen: Genau ein Ndb-Knoten im Cluster ist der '''Master'''. Diese Rolle wird beim Start vom Arbitrator zugeteilt. Der Master hat die primäre Information über den Zustand des Clusters. Ohne Master ist der Cluster arbeitsunfähig. Bei Ausfall kann ein anderer Knoten diese Rolle übernehmen - allerdings nur mit Zustimmung des Arbitrators oder der absoluten Mehrheit der Ndb-Knoten. Falls Teile des Clusters ihre Verbindung verlieren, aber noch arbeitsfähig sind ([[Split Brain (Informatik)\|split brain scenario]]), entscheidet der '''Arbitrator''' (Schiedsrichter), wer Master sein soll. Per Default ist der Manager der Arbitrator; es ist aber möglich, eine Hierarchie zu konfigurieren; dabei wird oft eine ungerade Zahl gewählt, um die Mehrheitsfähigkeit zu erhalten. Als Arbitrator können Management- oder SQL-Knoten dienen.
	; Managementknoten: Ein Managementknoten ist für die Systemkonfiguration, die Knotenverwaltung und die Aufzeichnung der Aktivitäten im Cluster zuständig. Es können ein oder mehrere Managementknoten aus Verfügbarkeitsgründen gleichzeitig eingesetzt werden. Im laufenden Betrieb wird dieser Knoten nur benötigt, wenn sich ein ausgefallener anderer Knoten wieder am Cluster anmelden will. Wenn der Managementknoten zusätzlich Arbitrator (Default) ist, muss er auch verfügbar sein, wenn der Master ausfällt. Da Ausfälle nicht vorhersehbar sind, sollte dieser Knoten daher immer laufen.		; Managementknoten: Ein Managementknoten ist für die Systemkonfiguration, die Knotenverwaltung und die Aufzeichnung der Aktivitäten im Cluster zuständig. Es können ein oder mehrere Managementknoten aus Verfügbarkeitsgründen gleichzeitig eingesetzt werden. Im laufenden Betrieb wird dieser Knoten nur benötigt, wenn sich ein ausgefallener anderer Knoten wieder am Cluster anmelden will. Wenn der Managementknoten zusätzlich Arbitrator (Default) ist, muss er auch verfügbar sein, wenn der Master ausfällt. Da Ausfälle nicht vorhersehbar sind, sollte dieser Knoten daher immer laufen.
	; SQL-Knoten: Ein SQL-Knoten entspricht einem MySQL Datenbanksystem, das mit Datenknoten kommunizieren kann. Die SQL-Knoten können einzeln oder über [[Lastverteilung (Informatik)\|Lastverteilung]] unter einer Sammel-IP angesprochen werden.		; SQL-Knoten: Ein SQL-Knoten entspricht einem MySQL-Datenbanksystem, das mit Datenknoten kommunizieren kann. Die SQL-Knoten können einzeln oder über [[Lastverteilung (Informatik)\|Lastverteilung]] unter einer Sammel-IP angesprochen werden.
	Das MySQL Datenbanksystem erlaubt die Verwendung von Datenbank-Managementsystemen mit verschiedenen Konzepten: mit und ohne Durchführung von Transaktionen, mit und ohne persistenter Speicherung, mit und ohne den Einsatz von gespeicherten Prozeduren, mit synchroner oder asynchroner Replikation usw.		Das MySQL-Datenbanksystem erlaubt die Verwendung von Datenbank-Managementsystemen mit verschiedenen Konzepten: mit und ohne Durchführung von Transaktionen, mit und ohne persistenter Speicherung, mit und ohne den Einsatz von gespeicherten Prozeduren, mit synchroner oder asynchroner Replikation usw.

	Der grobe Ablauf einer Benutzeranfrage ist wie folgt:		Der grobe Ablauf einer Benutzeranfrage ist wie folgt:
Zeile 23:		Zeile 23:
	# Der SQL-Knoten leitet die Anfragen an die Datenknoten weiter.		# Der SQL-Knoten leitet die Anfragen an die Datenknoten weiter.
	# Ein Datenknoten verarbeitet die Anfrage und sendet das Ergebnis an den SQL-Knoten zurück.		# Ein Datenknoten verarbeitet die Anfrage und sendet das Ergebnis an den SQL-Knoten zurück.
	# Der SQL-Knoten übergibt das Ergebnis an ~~Benutzer~~.		# Der SQL-Knoten übergibt das Ergebnis an das anfragende Objekt.

	Auf jedem der Knoten des MySQL Clusters ist mindestens ein Prozess gestartet. Bei SQL-Knoten heißt der zuständige Prozess ''mysqld'', bei Datenknoten ''ndbd'' und bei Verwaltungsknoten ''ndb-mgmd''. Auf Rechnerknoten mit mehreren Prozessoren können mehrere MySQL Cluster-Prozesse gleichzeitig laufen. Beispielsweise auf einem Datenknoten mit zwei CPUs können zwei ndbd-Prozesse parallel ausgeführt werden. Es ist ebenfalls möglich, Prozesse verschiedener MySQL Cluster-Knotentypen auf einem Rechnerknoten mit mehreren CPUs einzusetzen. Zum Beispiel kann auf einem Rechner ein Prozess des SQL-Knotens (mysqld) und ein Prozess des Datenknotens (ndbd) gestartet sein.		Auf jedem der Knoten des MySQL Clusters ist mindestens ein Prozess gestartet. Bei SQL-Knoten heißt der zuständige Prozess ''mysqld'', bei Datenknoten ''ndbd'' und bei Verwaltungsknoten ''ndb-mgmd''. Auf Rechnerknoten mit mehreren Prozessoren können mehrere MySQL Cluster-Prozesse gleichzeitig laufen. Beispielsweise auf einem Datenknoten mit zwei CPUs können zwei ndbd-Prozesse parallel ausgeführt werden. Es ist ebenfalls möglich, Prozesse verschiedener MySQL Cluster-Knotentypen auf einem Rechnerknoten mit mehreren CPUs einzusetzen. Zum Beispiel kann auf einem Rechner ein Prozess des SQL-Knotens (mysqld) und ein Prozess des Datenknotens (ndbd) gestartet sein.