Häufig gestellte Fragen zu MySQL Cluster

A: MySQL Cluster ist eine ACID-konforme, transaktionale Echtzeitdatenbank mit Unterstützung für die Skalierung von Schreibvorgängen, die 99,999% Verfügbarkeit mit den niedrigen Gesamtbetriebskosten einer Open-Source-Lösung verbindet. MySQL Cluster basiert auf einer verteilten Multi-Master-Architektur ohne singuläre Fehlerquelle und wird horizontal auf Standardhardware skaliert, um lese- und schreibintensive Arbeitslasten zu verarbeiten. Der Zugriff erfolgt über SQL- und NoSQL-Schnittstellen.

Das Echtzeitdesign von MySQL Cluster liefert vorhersagbare Reaktionszeiten von wenigen Millisekunden sowie die Fähigkeit, Millionen von Vorgängen pro Sekunde zu verarbeiten. Unterstützung für im Arbeitsspeicher oder auf Festplatte abgelegte Daten, eine automatische Datenpartitionierung (Sharding) mit Lastverteilung und die Möglichkeit zum Hinzufügen von Knoten zu einem laufenden Cluster ohne Ausfallzeit ermöglichen eine lineare Skalierbarkeit der Datenbank, sodass selbst unvorhergesehene Arbeitslasten problemlos verarbeitet werden können.

A: Die MySQL Cluster Carrier Grade Edition (CGE) beinhaltet Werkzeuge für die Verwaltung und Überwachung der MySQL Cluster-Datenbank mit Zugriff auf den Oracle Premier Support. Für MySQL Cluster CGE stehen verschiedene Abonnements bzw. kommerzielle Lizenz- und Supportangebote zur Verfügung.

• Weitere Einzelheiten zu MySQL Cluster CGE
• Bitte lesen Sie unsere Lizenzbedingungen

A: Informationen hierzu finden Sie unter http://www.mysql.de/customers/cluster/.

A: Die aktuelle GA-Version ist MySQL Cluster 7.2. MySQL 5.5 ist in MySQL Cluster integriert und im Lieferumfang enthalten.

A: Nein, MySQL wurde für den Betrieb auf Standardhardware konzipiert. Die Nutzung spezieller Hardware wie SCI Network Interconnects kann aber zu noch höherer Leistungsfähigkeit beitragen.

A:

A: Wenn Sie eine der folgenden Fragen mit "Ja" beantworten können, sollten Sie MySQL Cluster als mögliche Lösung für die Datenbank Ihrer Anwendung in Betracht ziehen:

• Würde ein Ausfall Ihrer Datenbank zu Ausfallzeiten der Anwendung führen, die wiederum Geschäftsunterbrechungen zur Folge hätten?
• Sind Sie mit den aktuellen Failover-Zeiten unzufrieden?
• Ist für die Datenbank Ihrer Anwendung eine integrierte Redundanz erforderlich, die 99,999% Verfügbarkeit mit automatischem Failover und Wiederherstellungsfunktion gewährleistet?
• Stellt Ihre aktuelle Datenbank einen Engpass bei Schreibvorgängen dar? Sind Sie auf der Suche nach Alternativen zur horizontalen Skalierung einer Master-Slave-Architektur und/oder Anwendungspartitionierung?
• Reagiert Ihre Anwendung empfindlich auf Latenzzeiten von Sekundenbruchteilen?
• Müssen Sie für Ihre Anwendungen/Dienste vorhersagbare Reaktionszeiten gewährleisten?
• Stellt Ihre Anwendung unvorhersehbare Skalierbarkeitsanforderungen?
• Nutzen Sie unterschiedliche Anwendungen, für die ein direkter Zugriff auf Daten auch ohne SQL vorteilhaft wäre (z. B. Java- und OpenJPA-Anwendungen, OpenLDAP und C++ sowie Webdienste)?
• Würden Sie von einer Aktiv/Aktiv-Clusteringarchitektur profitieren, mit der eine Vergeudung von Hardwareressourcen vermieden wird?
• Verwendet Ihre Anwendung hauptsächlich Primärschlüssel-Suchen und Tabellen-Joins, die kleine Ergebnismengen zurückgeben?

Bitte schauen Sie sich auch unseren Evaluierungsleitfaden und weitere Produktinformationen an, um sich über MySQL Cluster zu informieren.

A: MySQL Cluster eignet sich insbesondere für folgende Anwendungen:

• Umfangreiches OLTP
• Echtzeitanalysen
• eCommerce und Finanztransaktionen mit Betrugserkennung
• Mobile Anwendungen und Kleinbetragzahlung
• Session Management & Caching
• Feed-Streaming, Analyse und Empfehlungen
• Verwaltung und Bereitstellung von Inhalten
• Massen-Mehrspieler-Online-Gemeinschaftsspiele (MMOG)
• Kommunikations- und Präsenzdienste
• Verwaltung und Berechtigungen von Abonnenten/Benutzerprofilen

Hier erhalten Sie eine vollständige Liste der MySQL Cluster Anwenderberichte und Anwendungen.

A:

• Verfügbarkeit
  • 99,999% (<5 Min. Ausfall / Jahr)
• Leistung
  • Reaktionszeit: unter 5 Millisekunden (mit synchroner Replikation und Zugriff über SQL). Schnellere Reaktionszeiten können durch Einsatz einer der NoSQL-Zugriffsmethoden erzielt werden.
  • Durchsatz von über 250.000 replizierten Aktualisierungsvorgängen / Sek. auf einem Intel-Server mit zwei Sockeln und 24 GB Arbeitsspeicher. 2,5 Mio. Aktualisierungsvorgänge in einem Cluster mit acht Intel-Servern. Weitere Informationen zu den Benchmarks finden Sie hier.
• Failover
  • Ein Failover in Sekundenbruchteilen erlaubt einen unterbrechungsfreien Betrieb.
• Skalierbarkeit
  • Horizontale, vertikale und dynamische Skalierung
  • Für eine kosteneffiziente horizontale Skalierung:
    • Hinzufügen weiterer Speicherknoten (8, 10, 12, ... 48) pro Cluster oder
    • Hinzufügen weiterer CPUs (4, 8 usw.) oder
    • Hinzufügen von weiterem Arbeitsspeicher (16 GB, 32 GB) pro Datenknoten

A: Zu Evaluierungs- und Entwicklungszwecken können alle Knoten auf einem einzigen Host ausgeführt werden. Für eine vollständige Redundanz und Fehlertoleranz benötigen Sie mindestens sechs physische Hosts:

• 2 Datenknoten
• 2 SQL/NoSQL-Anwendungsknoten
• 2 Verwaltungsknoten

Viele Benutzer kombinieren die Verwaltungs- und Anwendungsknoten, wodurch die Anzahl der Knoten auf vier reduziert wird.

A: Ja, solange das Netzwerk die hier beschriebenen Eigenschaften aufweist.

MySQL Cluster bietet seit langem eine geografische Replikation an. Hierbei werden die Cluster auf räumlich getrennte Rechenzentren verteilt, um die Auswirkungen geografisch bedingter Latenzen zu verringern, indem Daten mit einer geringeren Entfernung zu den Benutzern zur Verfügung gestellt werden und nach Ausfällen eine Funktion zur Wiederherstellung bereitgestellt wird.

Die geografische Replikation ist asynchron und kann als Aktiv/Aktiv- oder Aktiv/Passiv-Cluster implementiert werden.

Die geografische Replikation ist das empfohlene Bereitstellungsmodell für Installationen über mehrere Rechenzentren hinweg.

A: Anwendungen können mit beliebigen MySQL Konnektoren entwickelt werden. MySQL Cluster bietet außerdem native NoSQL-Konnektivität über Memcached, C++, Java, JPA und HTTP/REST.

A: Nein, die Schnittstellen sind dieselben.

A: Ja, MySQL Cluster wird von ISVs und Netzwerkgeräteherstellern (Network Equipment Providers, NEPs) häufig als eingebettete Datenbank verwendet. Kundenliste »

A: Die geografische Replikation ermöglicht eine asynchrone Replikation über räumlich getrennte Cluster. Sie wird häufig zur Wiederstellung bei Ausfall eines gesamten Standorts eingesetzt.

A: Ja, in MySQL Cluster CGE werden sowohl die unidirektionale als auch die bidirektionale Replikation unterstützt. Bei Einsatz der bidirektionalen geografischen Replikation wird ein Mechanismus zur Konfliktermittlung und -lösung für Transaktionen bereitgestellt.

A: Bei MySQL Cluster-Konfigurationen gibt es normalerweise 2 Kopien sämtlicher Daten, die auf verschiedenen Hosts abgelegt sind. Um einen vollständigen Systemausfall abzudecken, werden Transaktionsprotokolle und Prüfpunktdateien mit konfigurierbarer Häufigkeit auf der Festplatte gespeichert. Zusätzlich dazu können nicht indizierte Daten auf Festplatte gespeichert werden.

A: MySQL Cluster bietet eine festplattenlose Option sowie eine protokolllose Option.

Für die Verwendung ohne Festplatte gelten folgende Einschränkungen:

1. Keine Festplattendaten
2. Datenverlust bei Clusterausfall
3. Keine Datensicherung

Bei der protokolllosen Option erstellt MySQL Cluster weiterhin Protokolldateien, für die Daten gibt es auf der Festplatte jedoch keine Prüfpunkte.

A: Nein. MySQL Cluster Manager ist nur als Bestandteil der kommerziellen MySQL Cluster Carrier Grade Edition-Datenbank (CGE) verfügbar. Um Lizenzen für MySQL Cluster CGE zu erwerben, wenden Sie sich an das MySQL Vertriebsteam.

A: MySQL Cluster Manager ist eine Software zur vereinfachten Erstellung und Verwaltung der MySQL Cluster-Datenbank, indem gängige Verwaltungsaufgaben automatisiert werden.

A: Durch den Einsatz von MySQL Cluster Manager wird die Produktivität von Datenbank- und Systemadministratoren gesteigert, die sich nun auf strategische IT-Initiativen konzentrieren und schneller auf sich ändernde Benutzeranforderungen reagieren können. Gleichzeitig kann das Risiko von Datenbankausfallzeiten, die aufgrund von Fehlern bei der manuellen Konfiguration auftreten, erheblich gesenkt werden.

A: Verwaltungsvorgänge, die Rolling-Neustarts einer MySQL Cluster-Datenbank erfordern und für die zuvor 46 manuelle Befehle¹ ausgeführt werden mussten und 2,5 Stunden Arbeitszeit für den DBA² anfielen, können nun über einen einzigen Befehl ausgeführt und mit MySQL Cluster Manager vollständig automatisiert werden. Dies bedeutet:

• Senkung von Verwaltungskomplexität und -overhead
• Senkung des Risikos von Ausfallzeiten durch die Automatisierung von Konfigurations- und Änderungs-Management-Prozessen
• Weniger kundenspezifisches Scripting von Verwaltungsbefehlen oder Entwicklung und Verwaltung von internen Verwaltungstools

A: Administratoren können vollständige Cluster erstellen und löschen oder den Cluster über einen einzigen Befehl starten, anhalten und neu starten sowie im laufenden Betrieb Knoten hinzufügen. Folglich müssen Administratoren die Datenknoten nicht länger einzeln und in der richtigen Reihenfolge manuell neu starten oder kundenspezifische Skripts zur Automatisierung des Prozesses schreiben.

Mit MySQL Cluster Manager werden Online-Verwaltungsvorgänge (u. a. das Upgrade, Downgrade und die Neukonfiguration laufender Cluster) automatisiert, ohne dass dies zu Unterbrechungen für Anwendungen oder Clients führt, die auf die Datenbank zugreifen. Administratoren müssen Konfigurationsdateien nicht länger manuell bearbeiten und auf alle anderen Clusterknoten verteilen. Auch muss nicht mehr ermittelt werden, ob Rolling-Neustarts erforderlich sind. MySQL Cluster Manager übernimmt all diese Aufgaben und stellt so die Verwendung von optimalen Vorgehensweisen sicher. Vorgänge im laufenden Betrieb werden erheblich vereinfacht und beschleunigt, und auch die Fehleranfälligkeit wird deutlich gesenkt.

A: Beides ist möglich. MySQL Cluster Manager ermöglicht die Verwaltung des gesamten Clusters als eine einzige Entität oder eine sehr granulare Steuerung bis hin zur Ebene einzelner Prozesse innerhalb des Clusters selbst.

A: Mit MySQL Cluster Manager kann der Clusterzustand auf Betriebssystem- und Prozessebene überwacht werden, indem die einzelnen Clusterknoten automatisch abgefragt werden. Mit dieser Lösung kann ermittelt werden, ob ein Prozess oder Serverhost verfügbar ist oder nicht, sodass eine schnellere Ermittlung und Behandlung von Problemen bzw. eine Wiederherstellung möglich ist.

A: MySQL Cluster Manager ermöglicht die Integration und Erweiterung vorhandener Verwaltungsfunktionalität durch die Automatisierung von Aufgaben, die ein Administrator zuvor manuell ausführen musste. Wie im oben stehenden Beispiel aufgezeigt, kann ein Prozess, für den zuvor 46 manuelle Befehle ausgeführt werden mussten, in einem einzigen Befehl zusammengefasst werden. Dabei werden sämtliche Prozessschritte vollständig automatisiert.

Im Hinblick auf das Scripting oder sogar die Entwicklung eines kundenspezifischen Verwaltungssystems muss berücksichtigt werden, dass das manuelle Entwickeln, Testen und Verwalten solcher Projekte zeitaufwendig, kostenintensiv und potenziell fehleranfällig ist. Viele dieser Verwaltungsaktivitäten werden durch den Einsatz von MySQL Cluster Manager überflüssig.

Durch die Automatisierung vereinfacht MySQL Cluster Manager die Clusterverwaltung und senkt gleichzeitig Kosten, Risiken und Arbeitsaufwand.

A: Ja. MySQL Cluster bietet bei Ausfällen eine Funktion zur Selbstreparatur, bei der ausgefallene Datenknoten ohne manuelle Eingriffe automatisch neu gestartet werden. MySQL Cluster Manager erweitert diese Funktionalität, indem SQL- und Verwaltungsknoten ebenfalls überwacht und automatisch wiederhergestellt werden. Dies ermöglicht eine nahtlosere und umfassendere Selbstreparatur des Clusters, um Vorgänge und Kapazität für Anwendungen vollständig wiederherzustellen.

A: Ja, mit Ausnahme von Anwendungsknoten, die die native NDB-Schnittstelle verwenden (z. B. Knoten, die auf den Cluster über die direkten Schnittstellen von C++, MySQL Cluster-Konnektor für Java, OpenLDAP usw. zugreifen).

A: Nein. Um einen hochverfügbaren Betrieb sicherzustellen, wird MySQL Cluster Manager von den eigentlichen Datenbankprozessen getrennt ausgeführt. Wenn ein Verwaltungs-Agent angehalten oder aktualisiert wird, hat dies daher keinerlei Auswirkungen auf die ausgeführte Datenbank. Wenn ein Agent oder der zugehörige Host nicht verfügbar ist, wird MySQL Cluster Manager für die übrigen verfügbaren Knoten weiterhin ausgeführt.

A: MySQL Cluster Manager wird als Gruppe von Agenten implementiert. Auf jedem physischen Host, der zu verwaltende MySQL Cluster-Knoten (Prozesse) umfasst, wird ein Agent ausgeführt. Der Administrator verbindet den normalen mysql-Client mit diesen Agenten, sodass alle Agenten miteinander kommunizieren und eingesetzt werden können, um für sämtliche Knoten des Clusters Vorgänge auszuführen.

A: Bei Verwendung von MySQL Cluster Manager für die Verwaltung einer MySQL Cluster-Installation muss der Administrator die Konfigurationsdateien (z. B. config.ini und my.cnf) nicht länger bearbeiten; diese Dateien werden stattdessen von den Agenten erstellt und verwaltet. Wenn diese Dateien manuell bearbeitet werden, werden die Änderungen mit den Konfigurationsinformationen überschrieben, die in den Agenten gespeichert sind.

Sämtliche Prozesse der MySQL Cluster-Installation werden von MySQL Cluster Manager gestartet, neu gestartet und angehalten. Dies umfasst die Datenknoten, Verwaltungsknoten und MySQL Server-Knoten.

Der Administrator muss Verwaltungsaktionen bei Verwendung von MySQL Cluster Manager nicht mehr über den ndb_mgm-Befehl ausführen. (Dieser Befehl stellt eine direkte Verbindung mit dem Verwaltungsknoten her, sodass die Agenten selbst keinen Einblick in die ausgeführten Vorgänge erhalten.)

A: Durch die Einführung von MySQL Cluster Manager wird die Notwendigkeit von Verwaltungsknoten nicht aufgehoben. Diese Knoten werden weiterhin für eine Reihe äußerst wichtiger Funktionen eingesetzt:

• Beim Start (oder Neustart) von Datenknoten verbinden sich diese mit den Verwaltungsknoten, um die jeweiligen Konfigurationsdaten abzurufen (die Verwaltungsknoten wiederum rufen diese Daten aus den von den Agenten erstellten Konfigurationsdateien ab).
• Beim Anhalten oder Neustarten eines Datenknotens über MySQL Cluster Manager wird die Statusänderung durch den Verwaltungsknoten durchgeführt.
• Ein Verwaltungsknoten kann weiterhin als Arbitrator fungieren (um ein Split-Brain-Szenario zu verhindern). Daher ist es wichtig, diese Prozesse weiterhin auf separaten, von den Datenknoten getrennten Hosts auszuführen.
• Einige Reporting-Informationen (z. B. zur Arbeitsspeichernutzung) sind in MySQL Cluster Manager noch nicht verfügbar und können weiterhin über das ndb_mgm-Tool abgerufen werden.

A: Für die Agenten selbst ist kein "Angel Prozess" verfügbar. Daher kann der Administrator für ein Höchstmaß an Verfügbarkeit einen Prozessmonitor nutzen, um den Ausfall von Agenten zu ermitteln und einen automatischen Neustart auszuführen (z. B. durch die Erstellung eines Skripts in /etc/init.d).

A: Ja. Beim Neustart von Verwaltungs-Agenten werden diese automatisch mit den anderen ausgeführten Verwaltungs-Agenten synchronisiert, um eine konsistente Konfiguration für den gesamten Cluster sicherzustellen (ohne Eingriffe durch den Administrator).

A: Ja. Sämtliche MySQL Cluster-Konfigurationsinformationen und Prozessbezeichner werden persistent auf Festplatte geschrieben. So sind diese Daten nach einem Systemausfall oder Neustart von MySQL Cluster Manager weiterhin verfügbar.

A: MySQL Cluster Manager unterstützt die asynchrone Kommunikation zwischen den einzelnen Verwaltungs-Agenten, um Anforderungen zur Neukonfiguration zuverlässig weiterzuleiten. Dadurch wird eine konsistente Konfiguration auf allen Knoten innerhalb des Clusters sichergestellt.

Änderungen werden erst übernommen, wenn alle Knoten den Empfang der Anforderung zur Neukonfiguration bestätigt haben. Wenn einer oder mehrere Knoten die Anforderung nicht empfangen, wird eine Fehlermeldung an den Client zurückgegeben. Durch die Automatisierung der Koordinierung von Anforderungen zur Neukonfiguration werden potenzielle Fehler bei der manuellen Verteilung von Konfigurationsdateien eliminiert.

A: Einzelheiten finden Sie auf der Webseite zu unterstützten Plattformen.

A: MySQL Cluster 6.3 und höher

A: Einzelheiten finden Sie in den folgenden Informationsquellen:

• Whitepaper zu MySQL Cluster Manager