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

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 geladen 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.

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.

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.

So reparieren Sie Replikationen in Master-Master-Konfigurationen:

1. 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. Durch Festlegen des Master-Protokolls liest die Anwendung die binären Protokolle der festen Appliance vom Anfang. 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. 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 Linux5-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.