Skalierung von Leseworkloads in Azure Database for MySQL

Veröffentlicht am 4 März, 2019

Program Manager, Azure OSS Databases

Wenn Sie Workloads mit vielen Lesevorgängen hochskalieren möchten, können Sie die Lesereplikate verwenden, die ab jetzt für alle Benutzer von Azure Database for MySQL allgemein verfügbar sind. Mithilfe von Lesereplikaten können Sie Workloads einfach über einen einzelnen Datenbankserver hinaus horizontal hochskalieren. Für Workloads für die BI-Berichterstellung und Webanwendungen ist dieses Verfahren besonders nützlich, da diese in der Regel mehr Lese- als Schreibvorgänge aufweisen.

Dieses Feature unterstützt jetzt die fortlaufende asynchrone Replikation von Daten von einem Azure Database for MySQL-Server (der „Masterserver“) auf bis zu fünf Azure Database for MySQL-Server (die „Server für Lesereplikate“) in derselben Region. So können Sie Workloads mit vielen Lesevorgängen nach Bedarf auf den Replikatservern verteilen. Replikatserver sind schreibgeschützt. Das gilt jedoch nicht für Schreibvorgänge, die für Datenänderungen am Master repliziert werden.

Welche Vorgänge werden für Lesereplikate unterstützt?

Sie können Replikatserver den Anforderungen Ihrer Workload entsprechend erstellen oder löschen. Ein Masterserver unterstützt bis zu fünf Replikatserver innerhalb derselben Azure-Region. Wenn Sie die Replikation auf einen Replikatserver beenden, wird daraus ein eigenständiger Server für Lese- und Schreibvorgänge.

Sie können Ihre Replikatserver über das Azure-Portal und die Azure CLI verwalten.

Über das Azure-Portal:

Registerkarte „Replikation“ im Azure-Portal, über die Replikatserver verwaltet werden

Verwenden Sie Azure Monitor, um die Replikation anhand der Metrik „replication lag in seconds“ (Replikationsverzögerung in Sekunden) nachzuverfolgen:

Nachverfolgung der Replikation mit Azure Monitor

Über die Azure CLI:

az mysql server replica create -n mydemoreplica1 -g myresourcegroup -s mydemomaster

Im Folgenden finden Sie einige Anwendungsmuster, die von unseren Kunden und Partnern verwendet werden, die bereits Lesereplikate für die Skalierung von Workloads einsetzen.

BI-Berichterstellung

Daten aus unterschiedlichen Datenquellen werden in Abständen von wenigen Minuten verarbeitet und auf den Masterserver geladen. Der Masterserver ist für das Laden und Verarbeiten von Daten vorgesehen, stellt diese den BI-Benutzern jedoch nicht direkt für die Berichtstellung und Analysen zur Verfügung, damit eine vorhersagbare Leistung sichergestellt werden kann. Die Berichterstellungsworkload wird auf mehrere Lesereplikate hochskaliert, damit viele Benutzer parallel mit niedriger Latenz verwaltet werden können.

Verarbeiten von Daten aus unterschiedlichen Datenquellen mit Lesereplikaten für die Skalierung

Microservices

In diesem Architekturmuster wird die Anwendung in mehrere Microservices aufgeteilt. Dabei werden APIs für die Datenänderung mit dem Masterserver und Berichterstellungs-APIs mit den Lesereplikaten verknüpft. Den APIs für die Datenänderung wird „Set-“ vorangestellt, während den Berichterstellungs-APIs „Get-“ vorangestellt wird. Der Lastenausgleich wird je nach API-Präfix zum Weiterleiten des Datenverkehrs verwendet.

Lastenausgleich: Datenänderungen bei Lese- und Schreibvorgängen mit Webdiensten

Nächste Schritte