Dienstebenen für Azure Database for MySQL – Flexibler Server

Sie können eine flexible Serverinstanz von Azure Database for MySQL in einer von drei Dienstgattungen erstellen: Burstable, General Purpose und Business Critical. Die zugrunde liegenden VM-SKU werden durch die Dienstebenen unterschieden, die die B-Serie, die D-Serie und die E-Serie verwenden. Die Auswahl von Computeebene und -größe bestimmt den auf dem Server verfügbaren Arbeitsspeicher und die Anzahl der virtuellen Kerne (vCores). Über sämtliche Dienstebenen hinweg wird die genaue Speichertechnologie verwendet. Alle Ressourcen werden auf der Azure Database for MySQL, flexible Serverinstanzebene, bereitgestellt. Ein Server kann über eine oder mehrere Datenbanken verfügen.

** Mit Ausnahme von 64.80 und 96 vCores, die jeweils 504 GiB, 504 GiB und 672 GiB Speicher haben.

* Ev5 Compute weist unter allen VM-Serien im Hinblick auf QPS und Latenz die beste Leistung auf. Weitere Informationen zur Leistung und regionalen Verfügbarkeit von Ev5 Compute finden Sie hier.

Dienstebenen für flexible Server

Um eine Computeebene auszuwählen, verwenden Sie die folgende Tabelle als Ausgangspunkt.

Nachdem Sie einen Server erstellt haben, können Sie die Computeebene, die Computegröße und die Speichergröße ändern. Die Computeskalierung erfordert einen Neustart und dauert 60 bis 120 Sekunden, die Speicherskalierung jedoch nicht. Sie können den Aufbewahrungszeitraum für Sicherungen auch unabhängig nach oben oder unten anpassen. Weitere Informationen finden Sie im Abschnitt Skalieren von Ressourcen.

Dienstebenen, Größe und Servertypen

Computeressourcen können basierend auf Ebene und Größe ausgewählt werden. Dies bestimmt die Anzahl der virtuellen Kerne und die Größe des Arbeitsspeichers. Virtuelle Kerne stellen die logische CPU der zugrunde liegenden Hardware dar.

Burstfähig

Detaillierte Spezifikationen der verfügbaren Servertypen für die Dienstebene „Burstfähig“.

Universell

Detaillierte Spezifikationen der verfügbaren Servertypen für die Dienstebene „Universell“.

Unternehmenskritisch

Detaillierte Spezifikationen der verfügbaren Servertypen für die Dienstebene „Unternehmenskritisch“.

Standardzonenresilienz in Azure Database for MySQL – flexibler Server, Tarif „Unternehmenskritisch“: Ab Mitte Dezember 2024 werden alle neuen Server im Tarif „Unternehmenskritisch“ von Azure Database for MySQL – flexibler Server ohne zusätzliche Kosten mit integrierter Zonenresilienz bereitgestellt! Dies bedeutet, dass Ihre Daten und Protokolldateien automatisch auf zonenredundantem Speicher gespeichert werden, wodurch eine schnelle Wiederherstellung nach Zonenausfällen sichergestellt wird. Auch ohne Hochverfügbarkeit profitieren Sie mit zonenredundanten Sicherungen von einem nahtlosen Schutz. Übersicht über die Geschäftskontinuität mit Azure Database for MySQL – flexibler Server

Speicherverwaltung in Azure Database for MySQL – Flexible Server

In MySQL spielt der Speicher eine wesentliche Rolle bei verschiedenen Vorgängen. Hierzu zählen unter anderem Abfrageverarbeitung und Zwischenspeicherung. Azure Database for MySQL – Flexible Server optimiert die Speicherzuweisung für den MySQL-Serverprozess (mysqld), um sicherzustellen, dass sie ausreichende Speicherressourcen für eine effiziente Abfrageverarbeitung, Zwischenspeicherung, Clientverbindungsverwaltung und Threadverarbeitung erhält. Weitere Informationen zur Speicherverwendung von MySQL finden Sie hier.

Größe des physischen Speichers (GB)

Die Größe des physischen Speichers (GB) in der folgenden Tabelle stellt den verfügbaren Arbeitsspeicher (Random Access Memory, RAM) Ihrer Instanz von Azure Database for MySQL – Flexible Server in Gigabytes (GB) dar.

Gesamtspeichergröße (GB)

Azure Database for MySQL – Flexible Server stellt eine Gesamtspeichergröße (GB) bereit. Diese stellt den gesamt verfügbaren Arbeitsspeicher für Ihren Server dar. Dabei handelt es sich um eine Kombination aus dem physischen Speicher und einer bestimmten Menge des temporären Speichers (SSD-Komponente). Diese einheitliche Ansicht wurde entwickelt, um die Ressourcenverwaltung zu optimieren. So können Sie sich nur auf den Gesamtspeicher konzentrieren, der für Ihren Azure MySQL-Server-Prozess (mysqld) zur Verfügung steht. Die Metrik „Arbeitsspeicher in Prozent“ (memory_percent) stellt den Prozentsatz des Arbeitsspeichers dar, der vom Azure MySQL-Serverprozess (mysqld) belegt wird. Diese Metrik wird auf der Grundlage der Gesamtspeichergröße (GB) berechnet. Wenn die Metrik „Arbeitsspeicher in Prozent“ also beispielsweise den Wert 60 hat, beansprucht Ihr Azure MySQL-Serverprozess 60 Prozent der Gesamtspeichergröße (GB), die in Ihrer Instanz von Azure Database for MySQL – Flexible Server verfügbar ist.

MySQL-Server (mysqld)

Der Azure MySQL-Serverprozess (mysqld) ist die zentrale Engine für Datenbankvorgänge. Beim Start initialisiert sie Gesamtkomponenten wie den InnoDB-Pufferpool und den Threadcache. Dabei verwendet sie Arbeitsspeicher auf der Grundlage von Konfigurations- und Workloadanforderungen. Der InnoDB-Pufferpool speichert beispielsweise häufig verwendete Daten und Indizes zwischen, um die Abfrageausführung zu beschleunigen, und der Threadcache verwaltet Clientverbindungsthreads. Weitere Informationen

InnoDB-Speicher-Engine

Als standardmäßige Speicher-Engine von MySQL verwendet InnoDB Arbeitsspeicher zum Zwischenspeichern häufig verwendeter Daten und zum Verwalten interner Strukturen wie dem InnoDB-Pufferpool und dem Protokollpuffer. Der InnoDB-Pufferpool speichert Tabellendaten und Indizes im Arbeitsspeicher, um Datenträger-E/A zu minimieren, was die Leistung verbessert. Der Größenparameter des InnoDB-Pufferpools wird basierend auf der Größe des physischen Speichers (GB) berechnet, der auf dem Server verfügbar ist. Weitere Informationen zu den verfügbaren Größen des InnoDB-Pufferpools in Azure Database for MySQL – Flexible Server finden Sie hier.

Threads

Clientverbindungen werden über dedizierte Threads verwaltet, die vom Verbindungs-Manager verarbeitet werden. Diese Threads behandeln Authentifizierung, Abfrageausführung und Ergebnisabruf für Clientinteraktionen. Weitere Informationen

Weitere Informationen zu den verfügbaren Computeserien finden Sie in der Azure VM-Dokumentation zu „burstfähigen“ VM-Größen (B-Serie), „Universell“ (Dadsv5-Serie bzw. Ddsv4-Serie) und „Unternehmenskritisch“ (Edsv4-Serie/Edsv5-Serie/Eadsv5-Serie).

Leistungsbeschränkungen von burstfähigen Reiheninstanzen

Die burstfähige Computeebene wurde als kostengünstige Lösung für Workloads entwickelt, die nicht ständig die volle CPU-Leistung benötigen. Diese Ebene ist ideal für nicht produktionsbezogene Workloads, wie z. B. Entwicklungs-, Staging- oder Testumgebungen. Die einzigartige Funktion der burstfähigen Computeebene ist seine Fähigkeit, „Burst“ zu nutzen, d. h. zur Nutzung von mehr als der Basis-CPU-Leistung mit bis zu 100 % der virtuellen CPU, wenn die Workload dies erfordert. Dies wird durch ein CPU-Kreditmodell ermöglicht, mit dem B-Reiheninstanzen „CPU-Guthaben“ in Zeiten mit geringer CPU-Auslastung sammeln können. Diese Guthaben können dann in Zeiten mit hoher CPU-Auslastung aufgewendet werden, sodass die Instanz über die CPU-Basisleistung hinausgehen kann.

Es ist jedoch wichtig zu wissen, dass eine burstfähige Instanz, sobald ihr CPU-Guthaben aufgebraucht ist, mit ihrer CPU-Basisleistung arbeitet. Die CPU-Basisleistung eines Standard_B1ms beträgt beispielsweise 20 %, d. h. 0,2 Vcore. Angenommen, der Server der burstfähigen Ebene führt eine Workload aus, die mehr CPU-Leistung erfordert als die Basisebene und hat das CPU-Guthaben aufgebraucht. In diesem Fall kann der Server Leistungsbeschränkungen erfahren und letztlich Auswirkungen auf verschiedene Systemvorgänge auf dem Server wie Beenden/Starten/Neu starten haben.

Aufgrund dieser Einschränkung kann es zu Verbindungsproblemen kommen und Systemvorgänge können betroffen sein. In solchen Situationen empfiehlt es sich, die Arbeitsauslastung auf dem Server anzuhalten, Gutschriften gemäß dem B-Serie-Kreditbankingmodell zu sammeln oder den Server auf höhere Ebenen wie Allgemein oder Geschäftskritisch zu skalieren.

Die burstfähige Compute-Ebene bietet daher erhebliche Kosten- und Flexibilitätsvorteile für bestimmte Workloadtypen, es wird daher nicht für Produktionsworkloads empfohlen, die eine konsistente CPU-Leistung erfordern. Die burstfähige Ebene unterstützt nicht die Funktionalität der Erstellung der Lesereplikate in Azure Database for MySQL – Flexibler Server und Hochverfügbarkeitskonzepte in Azure Database for MySQL – Flexibler Server. Für solche Workloads und Funktionen sind andere Compute-Ebenen, z. B. „Universell“ oder „Unternehmenskritisch“ besser geeignet.

Weitere Informationen zum CPU-Guthabenmodell der B-Serie von Azure finden Sie in den B-Serien burstfähiger VM-Größen und dem CPU-Guthabenmodell der B-Serie.

Überwachung von CPU-Guthaben auf burstfähiger Ebene

Die Überwachung Ihres CPU-Guthabensaldos ist entscheidend für die Aufrechterhaltung der optimalen Leistung auf der burstfähigen Compute-Ebene. Azure Database for MySQL Flexible Server bietet zwei wichtige Metriken im Zusammenhang mit CPU-Guthaben. Der ideale Schwellenwert zum Auslösen einer Warnung hängt von Ihren Workload- und Leistungsanforderungen ab.

Überwachen von Azure Database for MySQL – Flexibler Server: Diese Metrik gibt die Anzahl der von Ihrer Instanz verbrauchten CPU-Guthaben an. Die Überwachung dieser Metrik kann Ihnen helfen, die CPU-Auslastungsmuster Ihrer Instanz zu verstehen und die Leistung effektiv zu verwalten.

Überwachen von Azure Database for MySQL – Flexibler Server: Diese Metrik gibt die Anzahl des für Ihre Instanz verbleibenden CPU-Guthaben an. Wenn Sie diese Metrik überwachen, können Sie verhindern, dass Ihre Instanz aufgrund ihrer CPU-Guthaben die Leistung beeinträchtigt. Wenn die Metrik für das verbleibende CPU-Guthaben unter ein bestimmtes Niveau fällt (z. B. weniger als 30 % des gesamten verfügbaren Guthabens), deutet dies darauf hin, dass die Instanz Gefahr läuft, ihr CPU-Guthaben zu erschöpfen, wenn die aktuelle CPU-Auslastung anhält.

Weitere Informationen zum Einrichten von Warnungen zu Metriken finden Sie in dieser Führungslinie.

Speicher

Der von Ihnen bereitgestellte Speicher definiert die Speicherkapazität, die für Ihren flexiblen Server zur Verfügung steht. Der Speicher wird für die Datenbankdateien, temporären Dateien, Transaktionsprotokolle und MySQL-Serverprotokolle verwendet. Für die Dienstebenen „Burstfähig“ und „Universell“ reicht der Speicherbereich von mindestens 20 GiB bis maximal 16 TiB. Umgekehrt erstreckt sich der Speichersupport auf bis zu 32 TiB für die Dienstebene „Unternehmenskritisch“. Der Speicher wird auf allen Dienstebenen in Schritten von 1 GiB skaliert und kann nach der Erstellung des Servers hochskaliert werden.

Sie können Ihren Speicherverbrauch im Azure-Portal (mit Azure Monitor) mithilfe der Metriken für „Speicherbegrenzung“, „Speicher in Prozent“ und „Verwendeter Speicher“ überwachen. Weitere Informationen zu Metriken finden Sie im Artikel Überwachung.

Erreichen der Speicherbegrenzung

Wenn der auf dem Server verbrauchte Speicherplatz fast die bereitgestellte Begrenzung erreicht hat, wird der Server in den schreibgeschützten Modus versetzt, um verloren gegangene Schreibzugriffe auf den Server zu schützen. Server mit 100 GiB oder weniger bereitgestelltem Speicher werden als schreibgeschützt gekennzeichnet, wenn der freie Speicher weniger als fünf Prozent der bereitgestellten Speichergröße beträgt. Server mit mehr als 100 GiB bereitgestelltem Speicher werden als schreibgeschützt gekennzeichnet, wenn der freie Speicher weniger als 5 GiB beträgt.

Wenn Sie also beispielsweise 110 GiB Speicher bereitgestellt haben und die tatsächliche Auslastung 105 GiB überschreitet, wird der Server als schreibgeschützt gekennzeichnet. Wenn Sie andererseits 5 GiB Speicher bereitgestellt haben, wird der Server als schreibgeschützt gekennzeichnet, wenn der freie Speicher unter 256 MB sinkt.

Während der Dienst versucht, den Server als schreibgeschützt zu kennzeichnen, werden alle neuen Schreibtransaktionsanforderungen blockiert, und bereits vorhandene aktive Transaktionen werden weiterhin ausgeführt. Wenn der Server als schreibgeschützt festgelegt ist, führen alle nachfolgenden Schreibvorgänge und die Transaktionscommits zu einem Fehler, die Leseabfragen funktionieren allerdings weiter unterbrechungsfrei.

Sie sollten den bereitgestellten Speicherplatz auf dem Server erhöhen, um den Server aus dem schreibgeschützten Modus zu bewegen. Hierfür können Sie das Azure-Portal oder die Azure CLI verwenden. Sobald er vergrößert wurde, ist der Server wieder bereit, Schreibtransaktionen zu akzeptieren.

Wir empfehlen Ihnen, eine Warnung einzurichten, die Sie benachrichtigt, wenn sich Ihr Serverspeicher dem Schwellenwert nähert, damit Sie vermeiden können, in den schreibgeschützten Zustand zu gelangen. Weitere Informationen finden Sie in der Dokumentation zu Warnungen zum Einrichten einer Warnung.

Automatische Speichervergrößerung

Die automatische Speichervergrößerung verhindert, dass Ihr Server nicht mehr über genügend Speicherplatz verfügt und schreibgeschützt wird. Wenn die automatische Speichervergrößerung aktiviert ist, wird der Speicher automatisch ohne Beeinträchtigung der Workload vergrößert. Die automatische Speichervergrößerung ist standardmäßig für alle neuen Servererstellungen aktiviert. Bei Servern mit weniger als 100 GB bereitgestelltem Speicher wird die bereitgestellte Speichergröße um 5 GB erhöht, sobald der freie Speicher unter zehn Prozent des bereitgestellten Speichers sinkt. Bei Servern mit mehr als 100 GB bereitgestelltem Speicher wird die bereitgestellte Speichergröße um fünf Prozent erhöht, sobald der freie Speicherplatz unter 10 GB der bereitgestellten Speichergröße sinkt. Dabei gelten die maximalen, oben beschriebenen Speichergrenzwerte. Aktualisieren Sie die Serverinstanz, um den aktualisierten Speicher anzuzeigen, der unter Einstellungen auf der Seite Compute und Speicher bereitgestellt wird.

Wenn Sie also beispielsweise 1.000 GB Speicher bereitgestellt haben und die tatsächliche Auslastung 990 GB überschreitet, wird die Speichergröße des Servers auf 1.050 GB erhöht. Bei 20 GB bereitgestelltem Speicher wird die Speichergröße alternativ auf 25 GB erhöht, wenn weniger als 2 GB Speicher frei ist.

Denken Sie daran, dass der Speicher nach dem automatischen Hochskalieren nicht mehr herunterskaliert werden kann.

IOPS

Azure Database for MySQL Flexible Server unterstützt vorab bereitgestellte IOPS und automatisch skalierbare IOPS. Speicher-IOPS in Azure Database for MySQL – Flexibler Server Der minimale IOPS-Wert beträgt für alle Computegrößen 360, und der maximale IOPS-Wert wird durch die ausgewählte Computegröße bestimmt. Weitere Informationen zum maximalen IOPS-Wert pro Computegröße finden Sie in der Tabelle.

Sie können Ihren E/A-Verbrauch im Azure-Portal (mit Azure Monitor) mit der Metrik Überwachen von Azure Database for MySQL – Flexible Server überwachen. Wenn Sie mehr IOPS als den maximalen IOPS-Wert auf Grundlage der Compute-Größe benötigen, müssen Sie die Compute-Größe Ihres Servers skalieren.

Vorab bereitgestellte IOPS

Azure Database for MySQL Flexibler Server bietet vorab bereitgestellte IOPS, sodass Sie Ihrer Instanz von Azure Database for MySQL Flexibler Server eine bestimmte Anzahl von IOPS zuordnen können. Diese Einstellung stellt konsistente und vorhersagbare Leistung für Ihre Workloads sicher. Mit vorab bereitgestellten IOPS können Sie einen bestimmten IOPS-Grenzwert für Ihr Speichervolume definieren, um sicherzustellen, dass einige Anforderungen pro Sekunde verarbeitet werden können. Dies ergibt ein zuverlässiges und sicheres Leistungsniveau. Mit vorab bereitgestellten IOPS können Sie zusätzliche IOPS über den IOPS-Grenzwert hinaus bereitstellen. Mit dieser Funktion können Sie die Anzahl der IOPS basierend auf Ihren Workloadanforderungen jederzeit erhöhen oder verringern.

IOPS für Autoskalierung

Der Eckpfeiler von Azure Database for MySQL – Flexibler Server ist seine Fähigkeit, die beste Leistung für Workloads der Ebene 1 zu erzielen. Dies kann verbessert werden, indem der Server die Leistung seiner Datenbankserver (E/A) je nach Workloadanforderungen automatisch skalieren kann. Mit dieser aktivierbaren Funktion kann der Benutzer den IOPS-Wert bei Bedarf skalieren, ohne vorab eine bestimmte EA-Anzahl pro Sekunde bereitstellen zu müssen. Wenn Sie das Feature für Autoskalierungs-IOPS aktivieren, können Sie die E/A-Verwaltung in Azure Database for MySQL – Flexibler Server jetzt sorgenfrei genießen, da der Server die IOPS je nach Workloadbedarf automatisch hoch- oder herunterskaliert. AutoScale IOPS skaliert automatisch auf die „max. unterstützten IOPS“ für jede Dienstebene und Computegröße, wie in der Dokumentation zu Dienstebenen angegeben. Dadurch wird eine optimale Leistung gewährleistet, ohne dass eine manuelle Skalierung erforderlich ist.

Mit der IOPS-Autoskalierungsfunktion zahlen Sie nur für die Nutzung des Servers von Ihnen genutzte E/A-Leistung und müssen keine Ressourcen mehr bereitstellen und bezahlen, die nicht vollständig genutzt werden, was Zeit und Geld spart. Darüber hinaus können unternehmenskritische Tier-1-Anwendungen eine konsistente Leistung erzielen, indem zusätzliche E/A jederzeit für die Workload verfügbar gemacht wird. Mit Autoscale IOPS entfällt der Verwaltungsaufwand, der erforderlich ist, um den Kunden von Azure Database for MySQL flexibler Server die beste Leistung zu den geringsten Kosten zu bieten.

Dynamische Skalierung:: Mit automatisch skalierbaren IOPS werden die IOPS-Grenzwerte Ihres Datenbankservers basierend auf dem tatsächlichen Bedarf Ihrer Workload dynamisch angepasst. Das gewährleistet eine optimale Leistung ohne manuelle Eingriffe oder Konfiguration.

Verarbeitung von Workloadspitzen: Mit automatisch skalierbaren IOPS kann Ihre Datenbank Workloadspitzen oder -schwankungen reibungslos verarbeiten, ohne dass die Leistung Ihrer Anwendungen beeinträchtigt wird. Mit diesem Feature wird eine konsistente Reaktionsfähigkeit auch während Auslastungsspitzen sichergestellt.

Kosteneinsparungen: Im Gegensatz zu vorab bereitgestellten IOPS, bei denen ein fester IOPS-Grenzwert angegeben und unabhängig vom Verbrauch abgerechnet wird, bezahlen Sie bei automatisch skalierbaren IOPS nur für die tatsächlich verbrauchten E/A-Vorgänge.

Backup

Der Dienst sichert Ihren Server automatisch. Sie können einen Aufbewahrungszeitraum von 1 bis 35 Tagen auswählen. Weitere Informationen zu Sicherungen finden Sie im Konzeptartikel zur Sicherung und Wiederherstellung.

Skalieren von Ressourcen

Nachdem Sie Ihren Server erstellt haben, können Sie die Computeebene, die Computegröße (virtuelle Kerne und Arbeitsspeicher) und die Speichermenge sowie den Aufbewahrungszeitraum für Sicherungen einzeln ändern. Die Computegröße kann ebenso wie die Aufbewahrungsdauer für Sicherungen von 1 bis zu 35 Tagen zentral hoch- oder herunterskaliert werden. Die Speichergröße kann nur erhöht werden. Die Skalierung der Ressourcen kann über das Portal oder per Azure CLI durchgeführt werden.

Wenn Sie die Computeebene oder die Computegröße ändern, muss der Server neu gestartet werden, damit der neue Servertyp wirksam wird. Wenn das System den Wechsel zum neuen Server durchführt, können keine neuen Verbindungen hergestellt werden, und für alle Transaktionen ohne Commit erfolgt ein Rollback. Dieses Fenster variiert, liegt aber in den meisten Fällen zwischen 60 und 120 Sekunden.

Die Skalierung des Speichers und die Änderung des Aufbewahrungszeitraums von Sicherungen sind Onlinevorgänge und erfordern keinen Neustart des Servers.

Preis

Aktuelle Preisinformationen finden Sie auf der Seite Azure-Datenbank für MySQL – Preise. Informationen zu den Kosten der gewünschten Konfiguration können Sie im Azure-Portal auf der Registerkarte Compute und Speicher anzeigen. Dort werden die monatlichen Kosten basierend auf den von Ihnen ausgewählten Optionen angegeben. Wenn Sie nicht über ein Azure-Abonnement verfügen, können Sie den Azure-Preisrechner verwenden, um einen geschätzten Preis zu erhalten. Wählen Sie auf der Website des Azure-Preisrechners die Option Elemente hinzufügen aus, erweitern Sie die Kategorie Datenbanken, wählen Sie Azure Database for MySQL und Flexible Server als Bereitstellungstyp aus, um die Optionen anzupassen.

Wenn Sie die Serverkosten optimieren möchten, können Sie folgende Tipps in Betracht ziehen:

• Skalieren Sie Ihre Computeebene oder Computegröße (virtuelle Kerne) herunter, wenn Compute nicht ausgelastet ist.
• Erwägen Sie den Wechsel auf die Computeebene „Burstfähig“, wenn Ihre Workload die volle Computekapazität der Ebenen „Universell“ und „Unternehmenskritisch“ nicht kontinuierlich benötigt.
• Beenden Sie den Server, wenn er nicht verwendet wird.
• Verringern Sie den Aufbewahrungszeitraum der Sicherung, wenn eine längere Aufbewahrung der Sicherung nicht erforderlich ist.

Zugehöriger Inhalt

• Schnellstart: Erstellen einer Instanz von Azure Database for MySQL mit dem Azure-Portal
• Einschränkungen in Azure Database for MySQL – Flexible Server