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

Referenzinformationen › Appliance-Katalog-Referenzhandbuch › Systemkatalog › Datenbank-Appliances › MYSQLR, MYSQLR64 - für die Replikation geeignete MySQL-Datenbank-Appliance › N-Tier-Anwendung, die auf unterschiedlichen Einrichtungen ausgeführt werden (für Lastenausgleich und Failover geeignet)

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

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

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

Eigenschaftsname	Value	Hinweise
auto_create	1	Datenbank erstellen, wenn die Volumes leer sind.
error_log_filename	master-db.error	Name der Fehlerprotokolldatei, die auf dem Protokolldaten-Volume gespeichert werden soll.
error_log_level	Fehler	Fehlerprotokollierungs-Ebene
server_id	1	Masterserver (muss nicht 1 sein, sollte einen anderen Wert als die server_id auf dem Slave haben)
rpl_mode	master	Binäre Protokolle schreiben, um die Replikation zu ermöglichen

master vpn

Eigenschaftsname	Value	Hinweise
mode	server	Als Server funktionieren.
tunnel	certificates	Verwendung von SSL-Zertifikaten.
tcp_ports	3306,22	Von MYSQLR64 benötigte Ports zulassen.
ip_addr	master_vpn_ip	IP-Adresse des VPN in der Master-Anwendung.
remote_host	slave_vpn_ip	IP-Adresse des VPN in der Slave-Anwendung.

slave

Eigenschaftsname	Value	Hinweise
auto_create	1	Datenbank erstellen, wenn die Volumes leer sind.
error_log_filename	slave-db.error	Name der Fehlerprotokolldatei, die auf dem Protokolldaten-Volume gespeichert werden soll.
error_log_level	Fehler	Fehlerprotokollierungs-Ebene
server_id	2	Masterserver (muss nicht 2 sein, sollte einen anderen Wert als die server_id auf dem Slave haben)
rpl_mode	slave	Verbindung mit Master herstellen

slave vpn

Eigenschaftsname	Value	Hinweise
mode	Client	Als Client funktionieren.
tunnel	certificates	Verwendung von SSL-Zertifikaten.
auth_path	"client1"	Pfad zur SSL-Zertifikatdatei.
ip_addr	slave_vpn_ip	IP-Adresse des VPN in der Slave-Anwendung.
remote_host	master_vpn_ip	IP-Adresse des VPN in der Master-Anwendung.

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

Software	Version	Geändert	Lizenz	Hinweise
aspell	0.60.3-7.1	Nein	LGPLv2.1	N/A
aspell-En	6.0-2.1	Nein	LGPLv2.1	N/A
curl	7.15.5-2	Nein	MIT	N/A
device-mapper-event	1.02.32-1	Nein	GPLv2	N/A
freetype	1.02.32-1	Nein	FTL	N/A
gmp	4.1.4-10.el5	Nein	LGPLV2.1	N/A
libidn	0.6.5-1.1	Nein	LGPLv2.1	N/A
libjpeg	6b-37	Nein	Distributable	N/A
libpng	1.2.10-7.0.2	Nein	zlib/libpng	N/A
lvm2	2.6.26-2.1.2.8	Nein	GPLv2.0	N/A
mysql	5.0.77-3.el5	Nein	GPL	N/A
mysql-server	5.0.77-3.el5	Nein	GPLv2	N/A
perl-DBD-MySQL	3.0007-2.el5	Nein	Artistic	N/A
perl-DBI	1.52-2.el5	Nein	Artistic	N/A
php-cli	5.1.6-23.el5	Nein	PHPv3.01	N/A
php-common	5.1.6-23.el5	Nein	PHPv3.01	N/A
php-gd	5.1.6-23.el5	Nein	PHPv3.01	N/A
php-mbstring	5.1.6-23.el5	Nein	PHPv3.01	N/A
php-mysql	5.1.6-23.el5	Nein	PHPv3.01	N/A
php-pdo	5.1.6-23.el5	Nein	PHPv3.01	N/A
rsync	2.6.8-3.1	Nein	GPLv2	N/A
samba-client	3.0.28-1.el5_2.1	Nein	GPLv2	N/A
samba-common	3.0.28-1.el5_2.1	Nein	GPLv2	N/A
sudo	1.6.8p12-10	Nein	ISC	N/A
lighttpd	1.4.18-1.el5.rf	Nein	BSD	N/A
perl-IPC-Run	0.84-1.el5.rf	Nein	Artistic	N/A
perl-Time-Duration	1.06-1.el5.rf	Nein	Artistic	N/A
phpMyAdmin	2.11.10-1	Nein	GPLv2	N/A

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:

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.

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

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.