Leistungsfeatures von Azure Database for MySQL – Flexibler Server

  • 6 Minuten

Sie können Azure Database for MySQL flexible Server basierend auf einer von drei Dienstebenen erstellen: burstfähig, universell und unternehmenskritisch. Die Dienstebenen bieten eine zunehmende Compute- und Speichergröße sowie die unterstützte Anzahl der maximalen Verbindungen und E/A-Vorgänge pro Sekunde (IOPS). Ein flexibler MySQL-Server kann mehrere Datenbanken hosten. Sie können die Leistungsmetriken Ihres flexiblen MySQL-Servers wie CPU- und Speicherauslastung, E/A-Leistung, Abfragemetriken und vieles mehr überwachen, um fundierte Kapazitätsentscheidungen zu treffen.

Computegröße: RAM und Kerne

Jede der drei Dienstebenen stellt unterschiedliche zugrunde liegende VM-SKUs bereit. Die Ebene „Burstfähig“ verwendet VMs der B-Serie, die Ebene "Universell“ verwendet VMs der D-Serie, und die unternehmenskritische Ebene verwendet E-Serien-VMs. Die verwendete VM-Serie bestimmt die Anzahl der auf dem Server verfügbaren virtuellen Kerne und den verfügbaren Arbeitsspeicher.

Sie können die Computeebene, die Computegröße und die Speichergröße nach dem Erstellen eines Servers ändern. Das Ändern der Computeebene oder der Computegröße erfordert einen Neustart, der in der Regel zwischen ein bis zwei Minuten dauert, bis die Berechnung abgeschlossen ist. Das Ändern der Speichergröße erfordert keinen Neustart.

Bei Nicht-Produktionsworkloads (Entwicklung, Staging, Test usw.) sollten Sie Server auf der Ebene „Burstfähig“ verwenden, die eine kostengünstige Lösung für Workloads bietet, die nicht kontinuierlich die vollständige CPU verwenden. Während Zeiten geringer Nutzung sammeln Server, die VMs der B-Serie verwenden, CPU-Guthaben, das in Zeiten hoher Nutzung verwendet werden kann, um die Leistung über die Basislinie zu steigern („burst“). Wenn Ihr Basisplan zu hoch ist oder zu viele Auslastungssteigerungen vorhanden sind, sollten Sie ein Upgrade auf die Stufe "universell" oder "unternehmenskritisch" erwägen, um Leistungsbeeinträchtigungen zu vermeiden.

Computegrößen der Dienstebene

Jede der drei Dienstebenen bietet unterschiedliche Computeleistungsebenen. Während die burstfähige Ebene bis zu 20 vCores und die universelle Ebene bis zu 64 vCores unterstützen kann, mit Unterstützung für bis zu 96 vCores bietet die unternehmenskritische Ebene die höchste Computeleistung. Die Stufe "unternehmenskritisch" bietet auch die VMs der Ev5-Serie, die bis zu 30 % mehr QPS und 50 % niedrigere Latenz als die VMs der Ev4-Serie aufweisen.

IOPS: Vorabbereitstellung im Vergleich zur Autoskalierung

Die Anzahl der Lese- und Schreibvorgänge, die pro Sekunde ausgeführt werden können, wird als Speicher-IOPS (E/A-Vorgänge pro Sekunde) bezeichnet. Höhere IOPS-Einstellungen bieten eine bessere Speicherleistung: Mehr gleichzeitige Lese-/Schreibvorgänge führen zu schnelleren Datenabrufen, Datenpersistenz, Indexaktualisierungen und gesamter Datenbankeffizienz. Wenn die IOPS-Einstellungen zu niedrig sind, kann die Datenbank zu Verzögerungen bei der Verarbeitung und beeinträchtigter Leistung führen. Wenn die IOPS-Einstellungen jedoch zu hoch sind, können Ihre Kosten ohne ihre Leistungsverbesserungen steigen.

Mit Azure Database for MySQL – Flexible Server können Sie IOPS vorab bereitstellen oder das Feature "IOPS autoskalieren" verwenden.

  • Mit vorab bereitgestellten IOPS weisen Sie eine bestimmte Anzahl von IOPS zu, um eine konsistente und vorhersagbare Leistung bereitzustellen, was gut funktioniert, wenn sich die Last nicht dem Schwellenwert nähert, an dem E/A-Vorgänge gedrosselt werden. Sie können zwar immer zusätzliche IOPS zuordnen, da ihre Arbeitsauslastung zunimmt, dies erfordert jedoch manuellen Eingriff.

  • Mit aktivierter Funktion zur automatischen Skalierung der IOPS skalieren Sie ihre IOPS auf der Grundlage der Workloadaktivität und zahlen basierend auf dem Verbrauch. Da sich die Arbeitsauslastung erhöht, skaliert der Server die E/A-Leistung nahtlos, sodass Ihre Instanz Workloadspitzen verarbeiten kann, ohne für nicht verwendete Kapazität zu zahlen, wenn der Datenverkehr niedrig ist.

In beiden Fällen können IOPS das Maximum des Servers nicht überschreiten. Informationen zu den maximalen IOPS anhand der Computegröße finden Sie im Artikel Compute- und Speicherdokumentation.

Lesereplikate

Wenn der Datenverkehr ihrer Datenbank zunimmt, können Sie die Kapazität horizontal oder "nach außen" (Anzahl der Computeknoten) oder vertikal oder "nach oben" (Größe der Computeknoten) skalieren. Lesereplikate bieten eine horizontale Skalierung.

Ein Lesereplikat ist eine schreibgeschützte Kopie einer Datenbank, die mithilfe der binären Protokollreplikation (Binlog) von MySQL synchronisiert bleibt. Wenn Anwendungen wachsen, müssen sie Compute- und Speicherressourcen (z. B. die Datenbank) skalieren. Die Skalierung von Anwendungskomponenten wird vereinfacht, indem neue VMs mit Azure Kubernetes Service (AKS), Virtual Machine Scale Sets und App Service bereitgestellt werden. Während diese Computeressourcen skaliert werden und gespeicherte Daten wachsen, erhöhen sie die Belastung für die Datenbank, was häufig zu einem Engpass in der Architektur der Anwendung kommt.

Mithilfe eines Lesereplikats können Sie schreibgeschützte Vorgänge auf sekundäre Datenbanken umleiten, sodass der primäre Server Lese-/Schreibvorgänge unterstützt. Azure Database for MySQL stellt verwaltete Lesereplikate bereit. Sie können einen Quellserver auf bis zu zehn Replikate replizieren. Dies kann bei Anwendungsfällen wie Berichterstellung und Analyse helfen, die häufig große Datenmengen abfragen.

Die Verwendung eines Lesereplikats ist besonders hilfreich, wenn aus einem Grund oder einer anderen Abfrage keine Indizes verwendet werden können. Es kann unpraktisch oder sogar störend sein, Indizes für alle Abfragemuster hinzuzufügen, da sie zusätzliche Last auf dem Server platziert (Verarbeitung, Datenträger-E/A, Speicher, Transaktionszeit usw.). Wenn ein Data Warehouse nicht verfügbar ist oder Sie Daten benötigen, die neuer als der Aktualisierungszyklus sind, ist die Verwendung eines Lesereplikats eine hervorragende Möglichkeit, "große" Abfragen auszuführen, ohne kritische Lese-/Schreibvorgänge zu unterbrechen.

Lesereplikate sind nicht sofort synchron wie bei einer Hochverfügbarkeitskonfiguration. Lesereplikate führen nicht die Transaktionslatenz ein, die einer Hochverfügbarkeitslösung zugeordnet ist, aber es kann eine leichte Verzögerung geben, da die Daten das Replikat aus der primären Datenbank erreichen.