Referenzinformationen › Appliance-Katalog-Referenzhandbuch › Systemkatalog › Datenbank-Appliances › MYSQLR, MYSQLR64 - für die Replikation geeignete MySQL-Datenbank-Appliance

MYSQLR, MYSQLR64 - für die Replikation geeignete MySQL-Datenbank-Appliance

Sehen Sie sich das Video an

Funktionsübersicht

MYSQLR64 ist eine Datenbank-Appliance, die auf dem MySQL-Datenbankmodul (http://www.mysql.org) basiert. Sie bietet eine einfache Möglichkeit, eine Datenbank zu jeder beliebigen Anwendung hinzuzufügen. Die Appliances können auch in komplexen MYSQL-Replikationsszenarien verwendet werden. Die Appliances basieren auf MYSQL5 gestellt (CentOS 6.3/MySQL 5), sind aber auch für die Datenbankreplikation verantwortlich.

Die Datenbankreplikation ermöglicht die Replikation von Daten von einem MySQL-Datenbankserver ("Master" genannt) auf einen oder mehrere MySQL-Datenbankserver ("Slaves" genannt). Die MYSQLR64-Appliances können für die Master-Slave- wie auch für die Master-Master-Replikation und die Replikation mit mehr als zwei Mastern eingerichtet werden.

Die Replikationseinrichtung, -verwaltung und -überwachung erfolgt über eine Webschnittstelle. Die Webschnittstelle ermöglicht das einfach Starten der Replikation mit nahezu keinen Ausfallzeiten auf dem Master. Ferner kann sie zur Behebung eines Replikationsfehlers verwendet werden. Die Webschnittstelle kann für das Kopieren von Datenbanken aus älteren Datenbank-Appliances wie MYSQL und MYSQL5 verwendet werden. MYSQLR64 ermöglicht auch das problemlose Verwalten und Durchsuchen Ihrer Datenbank (basierend auf phpMyAdmin).

Die Replikation ist in einigen Fällen nützlich:

• Scale-Out-Lösungen - Vereilen der Last auf mehrere Knoten zur Leistungssteigerung ("Master-Master"-Konfiguration)
• Failover-Lösungen - Verwenden mehrerer Knoten bei der Master-Master-Replikation, sodass jede Appliance nur zur Versorgung der Anwendung verwendet werden kann, für den Fall, dass die andere(n) ausfallen. (MYSQLR64 behebt nicht automatisch Fehler; wenn ein MySQL-Server fehlschlägt, sollte Ihre Anwendung das erkennen und diesen Server nicht mehr verwenden. )
• Sicherungslösungen - Zwei (oder mehr) Knoten, einer wird als Master ausgeführt, die übrigen als Slaves. Die Anwendung verwendet nur den Master, die Slaves werden für die Sicherung (in diesem Fall kann die Datenbank angehalten werden, um eine konsistente Sicherung zu gewährleisten) oder für arbeitsintensive Datenanalysen (Berichte, Zusammenfassungen oder Analysen, bei denen die Daten nicht verändert werden) eingesetzt werden, ohne dass der Master geladen werden muss. Dadurch wird die Leistung der Anwendung nicht beeinträchtigt. (MYSQLR64 sichert Ihre Datenbank nicht automatisch, die Sicherung müssen Sie selbst verwalten. )

In seiner Standardkonfiguration funktioniert MYSQLR64 genau wie eine MYSQL5-Appliance mit einer Webschnittstelle für die Verwaltung. Für den Einsatz bei Replikationsszenarien benötigen Sie mindestens zwei MYSQLR64-Appliances mit einer entsprechenden Konfiguration (siehe Typische Verwendung).

MYSQLR64 speichert die Datenbank auf einem anwendungsdefinierten Volume, das auf jeder MYSQL64-Instanz konfiguriert werden kann. MYSQLR64 erstellt automatisch eine leere Datenbank, wenn es mit einem leeren Volume gestartet wird.

Wichtig! Sie sollten 32-Bit- und 64-Bit-MYSQLR-Appliances nicht mischen, wenn Sie beim Kopieren von Datenbankdateien vom Master zum Slave Replikation verwenden. Ferner sollten Sie keine Daten-Volumes aus der 32-Bit Version der Appliance mit einer 64-Bit-Version der gleichen Appliance verwenden (und umgekehrt). Zum Migrieren einer Datenbank zwischen den 32-Bit- und 64-Bit-MYSQLR-Versionen sichern Sie die Datenbanken auf einen Host und importieren Sie sie auf dem anderen Host, wie im Abschnitt Migrieren nach oder von MySQL beschrieben. Um auf den Abschnitt zuzugreifen, klicken Sie hier.

Ressourcen

Terminals

Die Standardschnittstelle. Sie ist für Diagnostik und Fehlersuche vorgesehen (über SSH). Künftige Versionen dieser Appliance können den SSH-Zugriff möglicherweise deaktivieren.

Wichtig! Die Terminals "rin" und "rout" werden für SSH (tcp 22)- und für MYSQL (tcp 3306)-Daten verwendet. Wenn Gateways/VPN für den Anschluss an diese Terminals verwendet wird, müssen die Firewalls so konfiguriert werden, dass beide Ports zugelassen sind.

Benutzer-Volumes

Das Daten-Volume kann optional die Datei my.cnf in seinem Verzeichnis der obersten Ebene enthalten, die MYSQL-Konfigurationsoptionen enthält Nähere Informationen hierzu finden Sie im Abschnitt "Benutzerdefinierte Konfiguration". Diese Funktion ist in MYSQLR64 1.6.1 oder höher verfügbar.

Wichtig!

• Das Daten-Volume muss ausschließlich für die MYSQL-Instanz dediziert sein (kann nicht mit anderen Appliances genutzt werden).
• Das Daten-Volume sollte mit keinem Dateisystem formatiert werden, weil es zur Erstellung eines LVM-Volume verwendet wird. Wenn Sie ein Volume verwenden, das mit einem Dateisystem formatiert wurde (möglicherweise mit Dateien aus einer alten MYSQL-Appliance), kann die Appliance nicht gestartet werden, um das Löschen Ihrer Datenbank/Dateien zu verhindern.
• Um eine Datenbank von einer alten Appliance (MYSQL, MYSQL5, MYSQL64), eine Datenbank von einem physischen Server oder eine Datenbank von MYSQLR zu migrieren (beim Migrieren von der 32-Bit zur 64-Bit-Version der Appliance), gehen Sie zum Abschnitt 'Datenbank von einer anderen Appliance migrieren'.

Eigenschaften

Wichtig!

• Ab MYSQLR64 1.6.8 wurde die Eigenschaft "use_old_passwords" entfernt. Wenn Sie old_passwords aktivieren müssen, erstellen Sie, wie unten beschrieben, eine benutzerdefinierte Konfiguration.
• Die MYSQLR-Appliance wird nicht gestartet, wenn "error_log_filename" angegeben wird sowie das Protokollterminal nicht angeschlossen ist oder das Dateisystem nicht bereitgestellt werden kann.

Erweiterte Eigenschaften (Verwendung in Replikationsszenarien)

Benutzerdefinierte Konfiguration

Diese Funktion ist in MYSQLR64 1.6.1 oder höher verfügbar.

In MYSQLR64 ist die Verwendung einer benutzerdefinierten MYSQL-Konfigurationsdatei möglich, die zusätzliche Konfigurationsoptionen enthalten oder eine bestehende, in /etc/my.cnf festgelegte Konfiguration überschreiben kann.

Um eine benutzerdefinierte Konfiguration zu verwenden, erstellen Sie eine Datei namens my.cnf und fügen sie auf dem Daten-Volume in das Verzeichnis der obersten Ebene ein. Das Format der Datei muss der Syntax der MYSQL-Optionsdatei entsprechen, wie in der MYSQL-Dokumentation beschrieben.

Das folgende Beispiel zeigt, wie die Leistung von MYSQLR64 bei Verwendung von InnoDB gesteigert werden kann (die MYSQLR64-Standardkonfiguration wird für MyISAM optimiert). Das Beispiel beruht auf der Verwendung eines Speichers von 512 M (Standard für MYSQLR64).

[mysqld]
# Shrink down MyISAM buffers
key_buffer = 512K
myisam_sort_buffer_size = 512K

# Make InnoDB the default storage engine (optional)
default-storage-engine = INNODB

# Set InnoDB buffer size
innodb_buffer_pool_size=350M
innodb_log_file_size=128M
innodb_log_buffer_size=4M
innodb_thread_concurrency=8

# If you do not have too many tables use this option, so you will not have uncontrolled innodb main tablespace growth which you can’t reclaim.
innodb_file_per_table=1

Wichtig! Bei Verwendung im Replikationsmodus synchronisiert MYSQLR64 auch die Datei "my.cnf" auf dem Daten-Volume, wenn Sie die Replikation reparieren/initiieren. Auf diese Weise verfügen Slave und Master über identische Daten.

Webschnittstelle

MYSQLR64 stellt eine Webschnittstelle bereit, auf die sowohl vom Terminal "ui" als auch von der Standardschnittstelle aus über die (Web)-Anmeldeoption im CA AppLogic®-Editor zugegriffen werden kann. Bei Verwendung der Webschnittstelle ist eine HTTP-Authentifizierung erforderlich. Lassen Sie den Benutzernamen leer, und verwenden Sie den Wert von "web_pwd" als Kennwort. Die Schnittstelle hat die folgenden Funktionen:

• Serverstatus anzeigen
  • MySQL-Server-Dienst starten/anhalten/erneut starten
  • MySQL-Serverstatus und -Betriebszeit
  • Mysql-Replikationsstatus (nur für diese Appliance)
  • Neueste MySQL-Protokolleinträge
  • Appliance-Betriebszeit
  • Appliance-Speicherauslastung
  • Appliance-Festplattenverwendung
• Replikation anzeigen/verwalten
  • Mysql-Replikationsstatus (nur für diese Appliance)
  • Replikation initiieren/reparieren In diesem Fall wird die Datenbank auf der Appliance gelöscht, und die Replikation wird vom Master komplett neu gestartet. Dies wirkt sich nicht auf die Datenbank auf dem Master aus (keine Daten werden auf dem Master gelöscht), und es gibt keine Ausfallzeiten der MYSQLR64-Master-Appliance. Während der Reparatur ist die Appliance offline und sollte nicht verwendet werden.
  • Snapshot löschen - löscht einen Datenbank-Snapshot, der auf dieser Appliance erstellt wurde, um die Replikation auf dem zugehörigen Slave zu initiieren/zu reparieren. Im Normalbetrieb verbleiben keine Snapshots auf der Appliance. Wenn die Schaltfläche zum Löschen des Snapshots angezeigt wird, bedeutet das, dass entweder ein Slave eine Replikation von dieser Appliance initiiert oder ein vorheriger Versuch, eine Replikation zu initiieren, fehlgeschlagen ist. Stellen Sie sicher, dass der Snapshot vor dem Löschen von keinem Slave verwendet wird. Diese Option wird nicht angezeigt, wenn auf der Appliance kein Snapshot vorhanden ist.
  • Master-Protokollposition zurücksetzen - Wenn Sie auf der aktuellen Appliance eine Replikationsinitiierung/-reparatur durchgeführt haben und nun einen neuen Server in eine Master-Master-Replikation mit mehreren Knoten einfügen möchten, müssen Sie sich bei der Webschnittstelle der Appliance anmelden, die über das Terminal "rout" mit dieser Appliance verbunden ist, und auf die entsprechende Schaltfläche zum Zurücksetzen der Master-Protokollposition klicken.
• Datenbank verwalten
  • Durchsuchen und bearbeiten Sie Ihre Datenbanken mithilfe von PhPMyAdmin.

Master-Slave-Replikationen zu MYSQLR64-Appliances hinzufügen

Mit CA AppLogic® können Sie Master-Slave-Replikationen ohne Datenverlust zu vorhandenen MYSQLR64-Appliances hinzufügen.

So fügen Sie Master-Slave-Replikationen zu MYSQLR64-Appliances hinzu:

1. Legen Sie für "rpl_mode" den Wert "master" auf der vorhandenen Appliance fest.
2. Fügen Sie eine neue MYSQLR64-Appliance Ihrer Anwendung mit einem leeren Daten-Volume hinzu. Schließen Sie das zughörigen Terminal "rout" an das Terminal "rin" der aktuellen Appliance an.
3. (Optional) Wenn er in einer Master-Master-Replikation verwendet werden soll, schließen Sie das beseitigte Terminal auf der aktuellen Appliance an das Terminal "rin" der neuen Appliance an.
4. Starten Sie die Anwendung neu.
5. Melden Sie sich bei der Webschnittstelle der neuen Appliance an, und wählen Sie die Option zum Initiieren/Reparieren der Replikation auf der Registerkarte zum Verwalten der Replikation aus. Der für die Protokollierung erforderliche Zeitaufwand variiert je nach der Größe der Daten auf dem Master. Wenn Sie INSSLR für den Zugriff auf MYSQLR64 verwenden, vergewissern Sie sich, dass die timeout-Eigenschaft auf einen hohen Wert (36000) festgelegt worden ist, um Zeitüberschreitungen zu vermeiden. Überzeugen Sie sich auch davon, dass in den Proxys auf der Client-Seite keine Zeitüberschreitungen vorliegen (besser gar keine Proxys verwenden).
6. Wenn Sie die Replikation initiiert haben, melden Sie sich bei der Webschnittstelle auf beiden MYSQLR64-Appliances an, und überprüfen Sie den Replikationsstatus. Innerhalb von 5 Minuten oder weniger sollte die Replikation auf beiden Appliances ausgeführt werden.

MYSQLR64-Appliances zu Master-Slave-Replikationen hinzufügen

Mit CA AppLogic® können Sie neue MYSQLR64-Appliances ohne Datenverlust zu vorhandenen Master-Master-Replikationen hinzufügen.

So fügen Sie MYSQLR64-Appliances zu Master-Slave-Replikationen hinzu:

1. Fügen Sie eine neue MYSQLR64-Appliance Ihrer Anwendung mit einem leeren Daten-Volume hinzu. Beispielsweise dbN, vorausgesetzt, Sie verfügen bereits über N-1-MYSQLR64-Appliances (3 <= N <= 10) und jede Appliance hat ein eigenes Terminal "rout", der an das Terminal "rin" der nächsten Appliance in einem kreisförmigen Setup angeschlossen ist (db1 rout ist mit db2 rin verbunden usw.).
2. Legen Sie für "rpl_mode" den Wert "master_and_slave" von dbN fest.
3. Schließen Sie das Terminal "rout" der dbN-1-Appliance an das Terminal "rin" der dbN-Appliance an.
4. Schließen Sie das Terminal "rout" der dbN-Appliance an das Terminal "rin" der db1-Appliance an.
5. Starten Sie die Anwendung neu, damit die Änderungen wirksam werden. Nach dem Neustart ist die Replikation erst am Ende des Vorgangs synchronisiert. Daten, die auf eine Appliance geschrieben werden, dürfen während des Vorgangs nicht auf allen anderen Appliances repliziert werden.
6. Melden Sie sich bei der Webschnittstelle der dbN-Appliance an, und wählen Sie die Option zum Initiieren/Reparieren der Replikation auf der Registerkarte zum Verwalten der Replikation aus. Der für die Protokollierung erforderliche Zeitaufwand variiert je nach der Größe der Daten auf dem Master. Wenn Sie INSSLR für den Zugriff auf MYSQLR64 verwenden, vergewissern Sie sich, dass die timeout-Eigenschaft auf einen hohen Wert (36000) festgelegt worden ist, um Zeitüberschreitungen zu vermeiden. Überzeugen Sie sich auch davon, dass in den Proxys auf der Client-Seite keine Zeitüberschreitungen vorliegen (besser gar keine Proxys verwenden).
7. Wenn Sie die Replikation initiiert haben, melden Sie sich bei der Webschnittstelle von dbN-1 an, und wählen Sie die Option zum Zurücksetzen der Master-Protokollposition. Durch die Protokollierung liest die Anwendung dbN-1 und die binären Protokolle von dbN vom Anfang.
8. Melden Sie sich bei der Webschnittstelle aller MYSQLR64-Appliances an, und überprüfen Sie den Replikationsstatus. Die Replikation sollte innerhalb von 5 Minuten oder weniger auf allen Appliances ausgeführt werden.

Replikation in Master-Slave-Konfigurationen reparieren

Mit CA AppLogic® können Sie Replikationen in einer Master-Slave-Einstellung ohne Datenverlust reparieren.

So reparieren Sie Replikationen in Master-Slave-Konfigurationen:

1. Melden Sie sich bei der Webschnittstelle des Slaves an, und wählen Sie die Option zum Initiieren/Reparieren der Replikation. Der für die Protokollierung erforderliche Zeitaufwand variiert je nach der Größe der Daten auf dem Master. Während des Vorgangs wird der mysql-Dienst auf dem Slave angehalten. Auf dem Master werden keine Ausfallzeiten verursacht. Dieser Vorgang entspricht dem Vorgang zum Hinzufügen einer neuen Appliance zu einer vorhandenen MYSQLR64-Appliance. Wenn Sie INSSLR für den Zugriff auf MYSQLR64 verwenden, vergewissern Sie sich, dass die timeout-Eigenschaft auf einen hohen Wert (36000) festgelegt worden ist, um Zeitüberschreitungen zu vermeiden. Überzeugen Sie sich auch davon, dass in den Proxys auf der Clientseite keine Zeitüberschreitungen vorliegen (besser gar keine Proxys verwenden).
2. Wenn Sie die Replikation initiiert haben, melden Sie sich bei der Webschnittstelle auf der MYSQLR64-Slave-Appliances an, und überprüfen Sie den Replikationsstatus. Die Replikation sollte innerhalb von 5 Minuten oder weniger auf allen Appliances ausgeführt werden.

Replikation in Master-Master-Konfigurationen reparieren

Mit CA AppLogic® können Sie Replikationen in einer Master-Master-Einstellung ohne Datenverlust reparieren.

So reparieren Sie Replikationen in Master-Master-Konfigurationen:

1. Melden Sie sich bei der Webschnittstelle der Appliance an, die meldet, dass die Replikation fehlgeschlagen ist, und wählen Sie die Option zum Initiieren/Reparieren der Replikation. Der für die Protokollierung erforderliche Zeitaufwand variiert je nach der Größe der Datenbank auf dem Master. Während des Vorgangs wird der mysql-Dienst auf der Appliance angehalten. Auf dem Master werden keine Ausfallzeiten verursacht. Die Datenbank ist erst nach Abschluss der Reparatur auf allen Mastern synchronisiert. Die Datenbankaktualisierungen dürfen während der Reparatur auf allen anderen MYSQLR64-Appliances nicht repliziert werden.

   Wichtig! Alle Daten auf dieser Appliance werden vom Master aus initialisiert. Aktualisierungen der Datenbank auf der aktuellen Appliance gehen verloren, da die Replikation unterbrochen wurde. In diesem Fall müssen Sie das Problem manuell lösen.

2. Melden Sie sich bei der Webschnittstelle der Appliance an, dessen Terminal "rout" an die Appliance angeschlossen ist, auf der die Replikationsreparatur ausgeführt wird. Wählen Sie die Option zum Zurücksetzen der Master-Protokollposition aus, um sicherzustellen, dass die Anwendung die binären Protokolle der reparierten Appliance von Beginn an liest. Wenn Sie INSSLR für den Zugriff auf MYSQLR64 verwenden, vergewissern Sie sich, dass die timeout-Eigenschaft auf einen hohen Wert (36000) festgelegt worden ist, um Zeitüberschreitungen zu vermeiden. Überzeugen Sie sich auch davon, dass in den Proxys auf der Clientseite keine Zeitüberschreitungen vorliegen (besser gar keine Proxys verwenden).
3. Melden Sie sich bei der Webschnittstelle aller MYSQLR64-Appliances an, und überprüfen Sie den Replikationsstatus. Innerhalb von 5 Minuten oder weniger sollte die Replikation auf allen Appliances ausgeführt werden.

Replikationsüberwachung

Es gibt einen Cron-Job, der die Replikation zwischen MYSQLR64-Appliances überwacht. Falls die Replikation aktiviert wird, wird der Cron-Job alle zwei Minuten ausgeführt und sendet in den folgenden Fällen Warnungen an das Grid-Dashboard:

• Replikation wird nicht ausgeführt (auf dem Grid-Dashboard wird folgende Meldung angezeigt: Replication of master server is not running, please check!)
• Replikation wird ausgeführt, liegt jedoch zu weit hinter dem Master zurück (auf dem Grid-Dashboard wird folgende Meldung angezeigt: Replication is too much behind master, please check!)
• Festplattenspeicher auf dem Daten-Volume ist niedrig (< 20 % frei). Dies wird unabhängig davon überprüft, ob die Replikation aktiviert ist (auf dem Grid-Dashboard wird folgende Meldung angezeigt: Free space on the data volume is running low, please check!)
• Festplattenspeicher auf dem Binlogs-Volume ist niedrig (< 20 % frei). Dies wird unabhängig davon überprüft, ob die Replikation aktiviert ist (auf dem Grid-Dashboard wird folgende Meldung angezeigt: Free space on the binlogs volume is running low, please check!)

In solchen Fällen sollte der Benutzer das Problem manuell lösen.

Wenn die Replikation fehlschlägt, können Sie sie über die Webschnittstelle reparieren, wie im Abschnitt oben beschrieben.

Benutzerdefinierte Zähler

Die MYSQLR64-Appliance meldet die folgenden benutzerdefinierten Zähler über das Terminal "mon".

Die folgenden Indikatoren gehören zur MySql-Indikatorgruppe:

Fehlermeldungen

Die folgenden Meldungen können entweder in der Appliance-Protokolldatei oder im Systemprotokoll der Grid-Steuerung angezeigt werden, wenn die Appliance nicht startet:

Zudem können die folgenden Fehler auf dem Grid-Dashboard angezeigt werden, während die Appliance ausgeführt wird:

Einfache Zwei-Ebenen-Anwendung (Keine Replikation)

Das folgende Diagramm zeigt eine typische Verwendung der MYSQLR64-Appliance in einer Zwei-Ebenen-Webanwendung:

Verwendete Appliances:

• user - Eingabe-Gateway
• web - Webserver
• db - MYSQLR64-Datenbankappliance
• logs - NAS-Appliance zum Speichern von Protokolldateien
• content - NAS-Appliance zum Speichern von Webserver-Inhalt
• admin - Eingabe-Gateway zum Anzeigen von Protokolldateien
• mon - MON-Appliance

Clientanfrage trifft am Benutzer-Gateway ein. Das Gateway leitet die Anfragen an den Webserver weiter, der die Anfrage verarbeitet. Wenn Skripte (z. B. Perl oder PHP) auf den Webservern auf persistente Daten zugreifen müssen, wird die db-Appliance über das out-Terminal des Webservers verwendet. Die db-Appliance wird so konfiguriert, dass sie ihre Protokolldateien innerhalb des Stammverzeichnisses der von logs zur Verfügung gestellten Freigabe speichern.

Mithilfe eines Browsers können Administratoren eine Verbindung zum admin-Gateway herstellen, um die mysql- oder Webserver-Protokolldateien anzuzeigen. Das admin-Gateway leitet die Anfragen an die Protokoll-NAS-Appliance weiter.

Beispiel-Eigenschaftskonfiguration (Eigenschaften, die nicht aufgelistet werden, sollten mit den Standardwerten belassen werden):

Hinweis: Das Daten-Volume muss auch auf der db-appliance und auf den Appliances logs, content und mon konfiguriert werden. Informationen zum Erstellen von Anwendungsvolumes, die hier verwendet werden können, finden Sie im Benutzerhandbuch zu Grid.

Skalierbare Zwei-Ebenen-Anwendung (Keine Replikation)

Das folgende Diagramm zeigt eine typische Verwendung der MYSQLR64-Appliance in einer Zwei-Ebenen-Webanwendung, bei der die Datenbank für die gemeinsame Verwendung von Status und Daten zwischen mehreren Webservern mit Lastenausgleich dient. Außerdem wird in diesem Beispiel eine getrennte Eingabe für die Wartung verwendet, über die ein Administrator sich anmelden und auf die Datenbank für die Wartung zugreifen kann, sowie eine Eingabe, über die ein Administrator sich anmelden und das MySql-Fehlerprotokoll anzeigen kann.

Verwendete Appliances:

• user - Eingabe-Gateway für Benutzeranfragen
• web_lb - Web-Lastenausgleichsmodul für Benutzeranfragen
• web1, web2 - Webserver mit aktivem Inhalt (zum Beispiel CGI-Skripte)
• db - Datenbank
• logs - Speicher für Datenbank- und Webserver-Fehlerprotokolldateien und Zugriff auf sie
• content - Speicherplatz für Webserverinhalte
• maint - Eingabe-Gateway für den Wartungszugriff
• admin - ein generischer vom Administrator verwendeter Linux6-Server
• gway - eine Netzwerk-Gateway für den Internetzugriff des Administrators
• mon - MON-Appliance

Clientanfrage trifft am Benutzer-Gateway ein. Die Gateway leitet die Anfrage an das Lastenausgleichsmodul "web_lb" weiter, das die Anfrage an einen der Webserver "web1" und "web2" leitet. Die Webserver greifen auf die db-Datenbank zu.

Die db-Datenbank und web1- und web2-Server schreiben ihre Protokolldateien über die Protokoll-Terminals in die logs-Appliance. Außerdem kann sich ein Administrator über das maint-Gateway bei der logs-Appliance anmelden und die Datenbankfehler-Protokolldateien anzeigen.

Zusätzlich kann sich ein Administrator über SSH und das maint-Gateway beim admin-Server anmelden (private/öffentliche Schlüssel müssen konfiguriert werden). Vom Server admin kann der Administrator auf die Datenbank db zugreifen, um Statistikdaten anzuzeigen oder das Datenbankschema zu ändern. Der Server admin kann über das Gateway gway auf das Internet zugreifen, um zum Beispiel eine neuere Bibliotheksversion oder das Datenbankschema herunterzuladen.

Beispiel-Eigenschaftskonfiguration (Eigenschaften, die nicht aufgelistet werden, sollten mit den Standardwerten belassen werden):

Hinweise:

• Das Daten-Volume muss auch auf den Appliances db, logs, content und mon konfiguriert werden.
• Die Appliances maint, admin, gway, mon und log werden nicht zur Ausführung der Zwei-Ebenen-Anwendung benötigt. Wenn vorhanden, kann der Server admin cronjobs zum Bereinigen der Datenbank, Senden von E-Mail und so weiter ausführen.

N-Tier-Anwendung mit Master-Slave-Replikation (für Sicherungen geeignet)

Das folgende Diagramm zeigt eine typische Verwendung der MYSQL-Appliance in einer Webanwendung, bei der die Datenbank für einen Slaveserver repliziert wird. Der Slaveserver kann verwendet werden, um konsistente Sicherungen der Daten zu machen, ohne den Masterserver anzuhalten, wodurch keine Ausfallzeiten entstehen.

Verwendete Appliances:

• user - Eingabe-Gateway für Benutzeranfragen
• admin - Eingabe-Gateway für Protokolldateizugriff und Webzugriff auf die MYSQLR64-Appliance
• sw - HTTP-Datenverkehr auf einzelne MYSQLR64-Appliances aufteilen
• web_lb - Web-Lastenausgleichsmodul für Benutzeranfragen
• web1, web2 - Webserver mit aktivem Inhalt (zum Beispiel CGI-Skripte)
• master - MYSQLR64 konfiguriert als Master
• slave - MYSQLR64 konfiguriert als Slave
• content - Speicherplatz für Webserverinhalte
• logs - Speicher für Datenbank- und Webserverprotokolldateien
• mon - MON-Appliance

Clientanfrage trifft am Benutzer-Gateway ein. Die Gateway leitet die Anfrage an das Lastenausgleichsmodul "web_lb" weiter, das die Anfrage an einen der Webserver "web1" und "web2" leitet. Die Webserver greifen auf die Masterdatenbank zu.

Die Slave-Appliance ist mit dem Master verbunden und repliziert seine Daten. Der Slave kann jederzeit angehalten werden, um konsistente Sicherungen der SQL-Daten oder komplexe Analytikvorgänge auszuführen, ohne die Leistung der Master-Appliance und den Rest der Anwendung zu beeinträchtigen.

Webzugriff auf Master und Slave ist verfügbar über das admin-Gateway auf Port 8080 und 8081.

Die Appliances master, slave, web1 und web2 werden so konfiguriert, dass sie ihre Protokolldateien innerhalb des Stammverzeichnisses der von logs zur Verfügung gestellten Freigabe speichern. Überdies können Administratoren über das Admin-Gateway Protokolldateien anzeigen.

Beispiel-Eigenschaftskonfiguration (Eigenschaften, die nicht aufgelistet werden, sollten mit den Standardwerten belassen werden):

master

slave

Hinweise:

• Das Daten-Volume muss auf den Appliances logs, content und mon konfiguriert werden.
• Die Daten- und binlogs-Volumes müssen sowohl auf dem Master als auch auf dem Slave konfiguriert sein. Sie sollten genug Speicherplatz aufweisen, um Daten und Protokolle zu verarbeiten.
• Jede Appliance sollte ein eigenes Volume verwenden (es kann nicht von den Appliances gemeinsam genutzt werden).
• Die Appliances admin, mon und log werden nicht zur Durchführung der Replikation benötigt.

N-Tier-Anwendung mit Master-Master-Replikation (für Lastenausgleich geeignet)

Das folgende Diagramm zeigt eine typische Verwendung der MYSQLR64-Appliance in einer Webanwendung, bei der die Datenbank für zwei Server in einem Master-Master-Replikatonsszenario repliziert wird. In diesem Verwendungsfall verwendet die Anwendung sowohl WEB- als auch MYSQLR64-Server für den Lastenausgleich. Auch in dem Fall, in dem eine der WEB/MYSQLR64-Instanzen fehlschlägt, kann die andere WEB/MYSQLR64-Instanz verwendet werden, um Anwendungsausfallzeit zu verhindern.

Verwendete Appliances:

• user - Eingabe-Gateway für Benutzeranfragen
• admin - Eingabe-Gateway für Protokolldateizugriff
• sw - HTTP-Datenverkehr auf einzelne MYSQLR64-Appliances aufteilen
• web_lb - Web-Lastenausgleichsmodul für Benutzeranfragen
• web1, web2 - Webserver mit aktivem Inhalt (zum Beispiel CGI-Skripte)
• db1 und db2 - MYSQLR64-Appliances, die gleichzeitig Master und Slave sein können
• content - Speicherplatz für Webserverinhalte
• logs - Speicher für Datenbank- und Webserverprotokolldateien
• mon - MON-Appliance

Clientanfrage trifft am Benutzer-Gateway ein. Die Gateway leitet die Anfrage an das Lastenausgleichsmodul "web_lb" weiter, das die Anfrage an einen der Webserver "web1" und "web2" leitet. web1 verwendet die db1-Datenbank-Appliance, web2 verwendet die db2-Datenbank-Appliance. db1 und db2 werden verbunden, um die Aktualisierungen zu replizieren, die die Webserver an der Datenbank vornehmen. Jede MYSQLR64-Appliance verwendet ein Offset (das ihrer server_id entspricht) für ihre auto_increment-Spalten, sodass keine doppelten Einträge auftreten.

Webzugriff auf db1 und db2 ist verfügbar über das admin-Gateway auf Port 8080 und 8081.

Die Appliances db1, db2, web1 und web2 werden so konfiguriert, dass sie ihre Protokolldateien innerhalb des Stammverzeichnisses der von logs zur Verfügung gestellten Freigabe speichern. Überdies können Administratoren über das Admin-Gateway Protokolldateien anzeigen.

Beispiel-Eigenschaftskonfiguration (Eigenschaften, die nicht aufgelistet werden, sollten mit den Standardwerten belassen werden):

db1

db2

Hinweise:

• Das Daten-Volume muss auf den Appliances logs, content und mon konfiguriert werden.
• Die Daten- und binlogs-Volumes müssen sowohl auf db1 als auch auf db2 konfiguriert sein. Jede Appliance sollte ein eigenes Volume verwenden (es kann nicht von den Appliances gemeinsam genutzt werden).
• Wenn Sie eine Master-Master-Replikation vornehmen, müssen Sie mit leeren Daten-Volumes anfangen.
• Die Appliances admin, mon und log werden nicht zur Durchführung der Replikation benötigt.

N-Ebenen-Anwendung mit Master-Master-Replikation über mehrere Knoten (für Lastenausgleich geeignet)

Das folgende Diagramm zeigt eine typische Verwendung der MYSQLR64-Appliance in einer Webanwendung, bei der die Datenbank für vier Server in einem Master-Master-Replikatonsszenario repliziert wird. In diesem Verwendungsfall verwendet die Anwendung alle WEB- und MYSQLR64-Server für den Lastenausgleich. Auch in dem Fall, in dem eine der WEB/MYSQLR64-Instanzen fehlschlägt, kann die andere WEB/MYSQLR64-Instanz verwendet werden, um Anwendungsausfallzeit zu verhindern (MYSQLR64 ist nicht für Fehler zuständig).

Verwendete Appliances:

• user - Eingabe-Gateway für Benutzeranfragen
• admin - Eingabe-Gateway für Protokolldateizugriff
• sw - HTTP-Datenverkehr auf einzelne MYSQLR64-Appliances aufteilen
• web_lb - Web-Lastenausgleichsmodul für Benutzeranfragen
• web1, web2, web3, web4 - Webserver mit aktivem Inhalt (zum Beispiel CGI-Skripte)
• db1, db2, db3, db4 - MYSQLR64-Appliances, die gleichzeitig Master und Slave sein können
• content - Speicher für Datenbank-Fehlerprotokolldateien, Webinhalt und Webprotokolle
• logs - Speicher für Datenbank- und Webserverprotokolldateien
• mon - MON-Appliance

Clientanfrage trifft am Benutzer-Gateway ein. Die Gateway leitet die Anfrage an das Lastenausgleichsmodul "web_lb" weiter, das die Anfrage an den Webserver "web1", "web2", "web3" oder "web4" umleitet. Jeder Webserver verwendet seine eigene Datenbank-Appliance. Alle Datenbank-Appliances werden zirkulär verbunden, um die Aktualisierungen zu replizieren, die die Webserver von der Datenbank machen. So wird beispielsweise eine Aktualisierung von db1 nach db2, db3 und db4 repliziert. Jede MYSQLR64-Appliance verwendet ein Offset (das ihrer server_id entspricht) für ihre auto_increment-Spalten, sodass keine doppelten Einträge auftreten.

Der Webzugriff auf db1, db2, db3 und db4 erfolgt über admin-Gateway auf Port 8080, 8081, 8082 und 8083.

Die Appliances db1, db2, web1 und web2 werden so konfiguriert, dass sie ihre Protokolldateien innerhalb des Stammverzeichnisses der von logs zur Verfügung gestellten Freigabe speichern. Überdies können Administratoren über das Admin-Gateway Protokolldateien anzeigen.

Beispiel-Eigenschaftskonfiguration (Eigenschaften, die nicht aufgelistet werden, sollten mit den Standardwerten belassen werden):

db1

db2

db3

db4

Hinweise:

• Das Daten-Volume muss auf den Appliances logs, content und mon konfiguriert werden.
• Das Daten- und Binlogs-Volume muss auch auf allen db-Appliances konfiguriert werden. Jede Appliance sollte ein eigenes Volume verwenden (es kann nicht von den Appliances gemeinsam genutzt werden).
• Bei der Multi-Master-Replikation müssen Sie mit leeren Daten-Volumes beginnen.
• Die Appliances admin, mon und log werden nicht zur Durchführung der Replikation benötigt.

N-Tier-Anwendung, die auf unterschiedlichen Einrichtungen ausgeführt werden (für Lastenausgleich und Failover geeignet)

Das folgende Diagramm zeigt eine typische Verwendung der MYSQLR64-Appliance in einer Webanwendung, die in mehr als einer Einrichtung ausgeführt wird. Bei diesem Setup können Sie zwei oder mehr identische Anwendungen in unterschiedlichen Einrichtungen ausführen, wobei die Datenbank auf alle Anwendungen im Master-Master-Setup repliziert wird. Dies ist in zwei Fällen nützlich:

• Geografischer Lastenausgleich - Richten Sie zwei (oder mehr) solcher Anwendungen ein, sodass Benutzer die Anwendung verwenden können, die ihrer geografischen Region am nächsten ist (Lastenausgleich wird mit DNS durchgeführt). Auf diese Weise werden bessere Antwortzeiten erzielt.
• Failover - Richten Sie zwei (oder mehr) solcher Anwendungen ein. Wenn dann die gesamte Einrichtung, in der eine Anwendung ausgeführt wird, ausfällt (oder wenn die Anwendung selbst ausfällt), können mithilfe der anderen Anwendungen Ausfallzeiten vermieden werden.

Master-Anwendung

Slave-Anwendung

Verwendete Appliances:

• user - Eingabe-Gateway für Benutzeranfragen
• admin - Eingabe-Gateway für Protokolldateizugriff
• sw - Weiterleitung von Port 8080 von admin an ui auf Master oder Slave
• vpn - Eingabe für die Remote-Anwendung zum Anschließen an die Master=/=Slave-Appliance, um die Datenbank zu replizieren
• web_lb - Web-Lastenausgleichsmodul für Benutzeranfragen
• web1, web2 - Webserver mit aktivem Inhalt (zum Beispiel CGI-Skripte)
• master - als Master konfigurierte MYSQLR64
• slave - als Slave konfigurierte MYSQLR64
• content - Speicher für Datenbank-Fehlerprotokolldateien, Webinhalt und Webprotokolle
• logs - Speicher für Datenbank-Fehlerprotokolldateien

Clientanfrage kommt auf der Benutzer-Gateway an. Die Gateway leitet die Anfrage an das Lastenausgleichsmodul "web_lb" weiter, das die Anfrage an einen der Webserver "web1" und "web2" leitet. Die Webserver greifen auf die Masterdatenbank zu. Die master-Appliance ist mit der Remote-(Slave-)Anwendung verbunden (die eine identische Kopie ist, der einzige Unterschied besteht in der server_id "slave" und der Netzwerkeinrichtung), um die Datenbank zu replizieren. Die Remote-Anwendung ist mit der Master-Appliance über das vpn-Gateway verbunden, das so konfiguriert ist, dass nur der Anschluss vom vpn-Gateway der Remote-Anwendung möglich ist. Die Master- und Slave-Appliances in den beiden Anwendungen werden in einer Master-Master-Einrichtung ausgeführt, sodass sie immer über identische Daten verfügen.

Beispiel-Eigenschaftskonfiguration (Eigenschaften, die nicht aufgelistet werden, sollten mit den Standardwerten belassen werden):

Der Webzugriff erfolgt über admin-Gateway auf Port 8080.

master

master vpn

slave

slave vpn

Die Remote-Anwendung ist eine genaue Kopie, der einzige Unterschied besteht in der Netzwerkeinrichtung der Benutzer-, Admin- und VPN-Appliances, Verbindungen zwischen der VPN-Appliance und Master=/=Slave und der server_id und Master=/=Slave-Appliance (sollte eindeutig sein).

Migrieren von MYSQLR nach MYSQLR64 (und umgekehrt)

Wenn Sie von MYSQLR nach MYSQLR64 migrieren müssen (und umgekehrt), sollten Sie nicht nur die Volumes von der 32-Bit-Appliance auf einer 64-Bit-Version (oder umgekehrt) verwenden, da dies Datenbeschädigungen verursachen könnte. Es wird empfohlen, die Datenbank auf der alten Appliance zu sichern, die gesicherte Datei auf die neue Appliance zu übertragen und die Datenbank dann in die neue Appliance zu importieren.

Der gleiche Vorgang kann verwendet werden, um eine Datenbank aus einer älteren Datenbank-Appliance (MYSQL, MYSQL5, MYSQL64) oder eine MySQL-Datenbank zu migrieren, die nicht auf einer CA AppLogic®-Appliance ausgeführt werden.

So migrieren Sie die Datenbank:

• (optional) Verhindern Sie den Zugriff auf die alte Datenbank - dies ist optional und soll lediglich sicherstellen, dass die Datenbank während der Sicherung nicht geändert wird. Eine Möglichkeit besteht darin, die Appliance zu starten, ohne dass etwas an den Eingabe-Terminals angeschlossen ist.
• Sichern Sie alle Datenbanken auf der alten Appliance. Stellen Sie zuvor sicher, dass genug Speicherplatz auf dem Daten-Volume verfügbar ist (Sie können das Daten-Volume anpassen, wenn nicht genug Speicherplatz vorhanden ist). Starten Sie dazu die Appliance, melden Sie sich bei der Appliance an, und führen Sie den folgenden Befehl aus:
  • mysqldump --all-databases --lock-all-tables | gzip > /mnt/data/my_dump.sql.gz
• Halten Sie die Anwendung an.
• Erstellen Sie ein neues Anwendungs-Volume, in dem die Datenbank für die neue Appliance (ext3-Snapshot) speichern wird. Überprüfen Sie, ob das Volume groß genug ist für die Datenbanksicherungsdatei (/mnt/data/my_dump.sql.gz) und die Datenbank selbst.
• Übertragen Sie die Datenbanksicherungsdatei auf das neu erstellte Volume (nachfolgend ist nur eine Methode zum Kopieren der Datenbank mit 2 Filern mit externem Internetzugriff beschrieben; wenn sich diese Methode für Ihre Konfiguration nicht eignet, können Sie die Datenbank auch mithilfe von scp vom Raster auf einen externen Server und dann zurück zum Ziel-Volume kopieren):
  • Verwalten Sie jedes Volume getrennt mit zwei Filern (eins für jedes Volume) mithilfe des Befehls "vol manage". Stellen Sie sicher, dass Sie die externen IP-Informationen an der Befehlszeile "vol manage" weitergeben, sodass jeder Filer auf andere Filer zugreifen kann, um die Datenbank zwischen den zwei Volumes zu kopieren. Weitere Informationen zum Festlegen der Einstellungen für das externe Netzwerk finden Sie in der Hilfe für "vol manage".
  • Führen Sie im Filer für das Quell-Volume den folgenden Befehl aus: cat /etc/ssh/ssh_host_rsa_key.pub >> /root/.ssh/authorized_keys
  • Führen Sie im Filer für das Ziel-Volume den folgenden Befehl aus: scp -pr -i /etc/ssh/ssh_host_rsa_key IP_address_to_source_filer:/mnt/vol/my_dump.sql.gz /mnt/vol/
  • Wenn die Datenbank kopiert wurde, können Sie beide Filer verlassen.
• Bearbeiten Sie die Anwendung, und fügen Sie eine neue Instanz von MYSQLR/MYSQLR64 hinzu, parametrieren Sie diese, verbinden Sie sie, und weisen Sie das neu erstellte Volume der neuen Instanz zu. Nun kann die alte MYSQLR/MYSQLR64-Instanz aus der Anwendung gelöscht werden (möglicherweise möchten Sie sie für Sicherungszwecke aufbewahren, bis Sie überprüft haben, ob die Datenbank korrekt auf die neue Instanz übertragen wurde).
• Importieren Sie die Datenbank - Starten Sie die neue Appliance, melden Sie sich an, und führen Sie den folgenden Befehl aus:
  • zcat /mnt/data/my_dump.sql.gz | mysql
• Die Datenbank wird jetzt übertragen und die Appliance ist auf Verwendung vorbereitet.

Hinweise

Beachten Sie Folgendes:

• MYSQLR64-Leistung wird für das MyISAM-Speichermodul optimiert, das standardmäßig verwendet wird. Wenn Sie die Leistung für Innodb steigern oder einfach den MYSQL-Service für Ihre Anwendung feinabstimmen möchten, finden Sie im Abschnitt Benutzerdefinierte Konfiguration Einzelheiten zum Hinzufügen von Konfigurationsparametern zur vorhandenen Konfiguration. Diese Funktion ist in MYSQLR64 1.6.1 oder höher verfügbar.
• MYSQLR64 verwendet nur asynchrone Replikation (synchrone Replikation wird nicht von MySQL unterstützt).
• MYSQLR64 erkennt innerhalb von 2 Minuten Replikationsfehler und benachrichtigt den Benutzer durch Anzeigen einer Meldung auf dem Dashboard des Grid. Der Benutzer kann dann die MYSQLR64-GUI zur Problembehebung verwenden (in MYSQLR64 ist keine automatische Wiederherstellung verfügbar).
• Wenn MYSQLR64 gestartet wird, wird in die Appliance-Protokolldatei eine Meldung geschrieben, dass chmod den Eigentümer für die mysql-Protokolldatei nicht ändern konnte. Dies ist erwartungsgemäß und beeinträchtigt die Funktion MYSQLR64-Appliance nicht.
• Die theoretische maximale Anzahl von MYSQLR64-Appliances in einer einzelnen Replikation beträgt 10. Da Daten zirkulär repliziert werden, benötigen Slaves zum Aktualisieren ihrer Datenbanken mehr Zeit, wenn Sie die Anzahl von MYSQLR64-Appliances erhöhen. Das eigentliche maximale Anzahl von Appliances in einer Replikation kann niedriger je nach Anwendung, Lasten und Bedarf niedriger sein (sofortige Aktualisierung von Slaves ist in einigen Szenarien möglicherweise nicht so kritisch wie Datensicherung).

Wichtig! Stellen Sie bei der Erstellung von Benutzern für die Datenbank sicher, dass alle Benutzer ohne Einschränkungen auf dem Host erstellt werden, von dem aus sie sich verbinden. Zum Beispiel:

mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
    ->     IDENTIFIED BY 'some_pass' WITH GRANT OPTION;

• Volume-Anforderungen
  • Die Volumegröße sollte 100 MB oder größer sein - derzeit ist das InnoDB-Modul aktiviert und besetzt ca. 22 MB auf dem Daten-Volume. In dieser Version kann diese Funktion nicht deaktiviert werden, auch wenn Sie InnoDB nicht für die Datenspeicherung verwenden.
  • Das Daten-Volume sollte mit keinem Dateisystem formatiert werden, weil es zur Erstellung eines LVM-Volume (das Volume sollte nicht formatiert sein) verwendet wird. Wenn Sie ein Volume verwenden, das mit einem Dateisystem formatiert wurde (möglicherweise mit Dateien aus einer alten MYSQL-Appliance), kann die Appliance nicht gestartet werden, um das Löschen von Dateien zu verhindern.
  • 20 % des Speicherplatzes des Daten-Volumes sind für die Initiierung/Fehlerbehebung der Replikation reserviert, die übrigen 80 % des Volume-Speicherplatzes sind für die Datenbankspeicherung reserviert.
  • Wenn Sie MYSQLR64 in Replikationsszenarien als Master, Slave oder master_and_slave verwenden, müssen Sie ein Binlogs-Volume angeben. Binäre Protokolle werden auf 100 MB rotiert und 2 Tage lang nach der Rotation aufbewahrt, danach werden sie gelöscht. Wenn die Appliance auch als Slave ausgeführt wird, werden Relay-Protokolle ebenfalls auf dem Binlogs-Volume gespeichert. Sie benötigen mindestens 500 MB Binlogs-Speicherplatz, um eine Master-Master-Replikation auszuführen. Die tatsächliche Größe hängt von der Intensität der ausgeführten MySQL-Aktualisierungs-/Einfügeabfragen ab. Sie benötigen für das Binlogs-Volume einige GB, damit eine Anwendung normal ausgeführt werden kann.
• Die mit MYSQLR64 verbundene Appliance ist für die Erstellung einer eigenen Datenbank und eigener Tabellen verantwortlich, sofern diese nicht vorhanden sind. Alternativ können Sie manuell die Anfangsdatenbank auf dem Daten-Volume kopieren.
• Die Appliance oder der Server, die/der mit der Eingabe "in" von MYSQLR64 verbunden ist, sollte über die MySQL-Client-Bibliothek verfügen, um auf den MySQL-Server zugreifen und Anfragen senden zu können. Auf allen im Appliance-Katalog bereitgestellten virtuellen Servern ist die MySQL-Client-Bibliothek installiert, einschließlich des generischen LINUX-Servers.
• Referenzen:
  • http://www.mysql.com -- MySQL-Website
  • http://dev.mysql.com/doc/refman/5.0/en/index.html -- MySQL-5.0-Dokumentation

In der Appliance verwendete Open-Source-Software von Drittanbietern

MYSQLR64 verwendet zusätzlich zu den Drittanbieter-Open-Source-Paketen der jeweiligen Basisklasse LUX64 die folgenden Drittanbieter-Open-Source-Pakete.

MYSQLR-Fehlerbehebung

MYSQLR-Appliance "hängt" beim Neustart

Ab MYSQLR 1.6.2 können Sie ein Kennwort für das Stammdatenbankkonto festlegen/ändern. Allerdings hat die MSYQLR-Appliance ein paar Stammkonten mit unterschiedlichen Hostnamen. Zum Festlegen/Ändern eines Kennworts sollten Sie immer das Konto "root@%" verwenden. Das Konto "root@%" ist das Konto, das Appliances, die mit dem Eingabe-Terminal von MYSQLR verbunden sind, für die Authentifizierung verwenden. Die anderen Stammkonten werden nur von lokalen Benutzern verwendet. Für diese Konten sollte niemals ein Kennwort festgelegt werden, da die MYSQLR-Appliance anderenfalls nicht gestartet werden kann.

Hinweis: Wenn Sie für das Konto "root@localhost" kein Kennwort festlegen, stellt dies kein Sicherheitsproblem dar, weil dieses Konto nur von lokalen Benutzern auf der Appliance verwendet werden kann und jeder Benutzer mit Zugriff auf die Appliance das Kennwort ändern kann.

Wiederherstellen einer MYSQLR-Appliance, die nach dem Ändern des Stammdatenbankkennworts nicht gestartet werden kann

Um eine Appliance wiederherzustellen, die durch Ändern des Kennworts für die Stammdatenbank nicht gestartet werden kann, führen Sie die folgenden Schritte aus:

1. Starten Sie die Appliance oder Anwendung im Debug-Modus.

   Befehl zum Starten der Appliance

   comp start main.MYSQLR --debug 
   

   Befehl zum Starten der Anwendung

   app start --debug 
   

   Einige Minuten nach dem Starten der Appliance sollte die Anmeldung bei der Appliance möglich sein. Sie müssen warten, bis das Zeitlimit für die Appliance einsetzt.

2. Melden Sie sich über SSH bei die Appliance an, und führen Sie die folgenden Befehle aus:

   mysql -p -e "update mysql.user set Password='' where User='root'" 
   mysqladmin -p flush-privileges 
   mysql -e 'update mysql.user set password=PASSWORD("NEWPASSWORD") where User="root" and Host="%"' 
   mysqladmin flush-privileges
   

3. Starten Sie die Appliance neu, um zu überprüfen, ob sie neu gestartet wird und ob für die mysql-Verbindungen auf dem Eingabe-Terminal für den Benutzerstamm ein Kennwort benötigt wird.