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

Referenzinformationen › Appliance-Katalog-Referenzhandbuch › Systemkatalog › Datenbank-Appliances › MYSQLR, MYSQLR64 - für die Replikation geeignete MySQL-Datenbank-Appliance › N-Ebenen-Anwendung mit Master-Master-Replikation (für Lastenausgleich geeignet)

N-Ebenen-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

Eigenschaftsname	Value	Hinweise
auto_create	1	Datenbank erstellen, wenn die Volumes leer sind.
error_log_filename	db1.error	Name der Fehlerprotokolldatei, die auf dem Protokolldaten-Volume gespeichert werden soll.
error_log_level	error	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_and_slave	Master und Slave

db2

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

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.