Dienstebenen für Azure Database for MySQL – Flexibler Server
GILT FÜR:
Azure Database for MySQL – Flexible Server
Sie können eine flexible Serverinstanz von Azure Database for MySQL in einer von drei verschiedenen Dienstgattungen erstellen: Burstable, General Purpose und Business Critical. Die Dienstebenen werden durch die zugrunde liegende VM-SKU unterschieden, die die B-Serie, die D-Serie und die E-Serie verwendet. 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 dieselbe Speichertechnologie verwendet. Alle Ressourcen werden auf der Azure Database for MySQL, flexible Serverinstanzebene, bereitgestellt. Ein Server kann über eine oder mehrere Datenbanken verfügen.
| Ressource/Ebene | Burstfähig | Allgemeiner Zweck | Unternehmenskritisch |
|---|---|---|---|
| VM-Serie | B-Serie | Dadsv5-SerieDdsv4-Serie | Edsv4/Edsv5-Serie*/Eadsv5-Serie |
| V-Kerne | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Arbeitsspeicher pro V-Kern | Variable | 4 GiB | 8 GiB ** |
| Speichergröße | 20 GiB bis 16 TiB | 20 GiB bis 16 TiB | 20 GiB bis 16 TiB |
| Aufbewahrungszeitraum von Datenbanksicherungen | 1 bis 35 Tage | 1 bis 35 Tage | 1 bis 35 Tage |
** Mit Ausnahme von 64, 80 und 96 vCores, die jeweils 504 GiB, 504 GiB und 672 GiB Speicher haben.
* Ev5 Compute bietet die beste Leistung unter anderen VM-Serien in Bezug auf QPS und Latenz. Weitere Informationen zur Leistung und regionalen Verfügbarkeit von Ev5 Compute finden Sie hier.
Um eine Computeebene auszuwählen, verwenden Sie die folgende Tabelle als Ausgangspunkt.
| Computeebene | Zielworkloads |
|---|---|
| Burstfähig | Am besten geeignet für Workloads, die nicht kontinuierlich die vollständige CPU benötigen. |
| Universell | Geeignet für die meisten Unternehmensworkloads mit gängigen Compute- und Arbeitsspeicheranforderungen und skalierbarem E/A-Durchsatz. Hierzu zählen beispielsweise zum Hosten von Web- und mobilen Apps verwendete Server und andere Unternehmensanwendungen. |
| Unternehmenskritisch | Geeignet für Hochleistungs-Datenbankworkloads, für die In-Memory-Leistung erforderlich ist, um eine schnellere Transaktionsverarbeitung und höhere Parallelität zu erzielen. Hierzu zählen beispielsweise Server für die Verarbeitung von Echtzeitdaten und leistungsstarke Transaktions- oder Analyse-Apps. |
Nachdem Sie einen Server erstellt haben, können die Computeebene, die Computegröße und die Speichergröße geändert werden. Die Computeskalierung erfordert einen Neustart und dauert zwischen 60-120 Sekunden, während die Speicherskalierung keinen Neustart erfordert. 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.
Detaillierte Spezifikationen der verfügbaren Servertypen für Burstfähig:
| Computegröße | V-Kerne | Größe des physischen Speichers (GiB) | Gesamtspeichergröße (GiB) | Maximal unterstützte IOPS | Max. Anzahl von Verbindungen | Temporärer Speicher (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1s | 1 | 1 | 1.1 | 320 | 171 | 0 |
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8,8 | 1.700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17.6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35,2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52,8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5.000 | 13653 | 0 |
Detaillierte Spezifikationen der verfügbaren Servertypen für Universell:
| Computegröße | V-Kerne | Größe des physischen Speichers (GiB) | Gesamtspeichergröße (GiB) | Maximal unterstützte IOPS | Max. Anzahl von Verbindungen | Temporärer Speicher (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 17.28 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 17.28 |
Detaillierte Spezifikationen der verfügbaren Servertypen für Unternehmenskritisch:
| Computegröße | V-Kerne | Größe des physischen Speichers (GiB) | Gesamtspeichergröße (GiB) | Maximal unterstützte IOPS | Max. Anzahl von Verbindungen | Temporärer Speicher (SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5.000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5.000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38.000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38.000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E80ids_v4 | 80 | 504 | 693 | 72000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5.000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38.000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80.000 | 100.000 | 2004 |
Speicherverwaltung in Azure Database for MySQL – Flexible Server
In MySQL spielt der Speicher eine wichtige 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 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) fungiert als 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ähig“ (B-Serie), „Universell“ (Dadsv5-Serie bzw. Ddsv4-Serie) und „Unternehmenskritisch“ (Edsv4-Serie/Edsv5-Serie/Eadsv5-Serie).
Leistungsbeschränkungen von burstfähigen Reiheninstanzen
Hinweis
Bei der burstfähigen Computeebene (B-Serie) geht das Guthaben möglicherweise verloren, wenn der virtuelle Computer gestartet/beendet oder neu gestartet wird. Weitere Informationen finden Sie in den häufig gestellten Fragen zur burstfähigen Serie (B-Serie).
Burstable Compute Tier (burstfähige Compute-Ebene) 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-produktive Workloads, wie z. B. Entwicklungs-, Staging- oder Testumgebungen. Die einzigartige Funktion der burstfähigen Compute-Ebene 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 Arbeitslast (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. Wenn auf dem burstfähigen Ebenenserver eine Arbeitslast ausgeführt wird, die mehr CPU-Leistung als die Basisstufe erfordert, und das CPU-Guthaben aufgebraucht ist, kann es zu Leistungseinschränkungen auf dem Server kommen, die sich auf verschiedene Systemoperationen, wie Beenden/Start/Neustart, Ihres Servers auswirken können.
Hinweis
Bei Servern in der Burstable (B-Serie) Computeebene, z. B. Standard_B1s/Standard_B1ms/Standard_B2s, kann ihre relativ kleinere Hostspeichergröße unter kontinuierlicher Arbeitsauslastung zu Abstürzen (nicht genügend Arbeitsspeicher) führen, auch wenn die Metrik memory_percent nicht 100% erreicht hat.
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 keine Funktionalität zum Erstellen von Lesereplikaten und Hochverfügbarkeitsfunktion. 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-Reihen burstfähiger Instanzen 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 spezifischen Workload- und Leistungsanforderungen ab.
CPU-Guthaben verbraucht: 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.
CPU-Guthaben verbleibend: Diese Metrik zeigt die Anzahl der verbleibenden CPU-Guthaben für Ihre Instanz an. Wenn Sie diese Metrik im Auge behalten, 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.
Storage
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. Auf allen Dienstebenen werden mindestens 20 GiB und maximal 16 TiB Speicherplatz unterstützt. Der Speicher wird in Schritten von 1 GiB skaliert und kann nach der Erstellung des Servers hochskaliert werden.
Hinweis
Der Speicher kann nur zentral hochskaliert und nicht herunterskaliert 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. Leseabfragen werden weiterhin ohne Unterbrechung fortgesetzt.
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 Arbeitsauslastung vergrößert. Die automatische Speichervergrößerung ist standardmäßig für alle neuen Servererstellungen aktiviert. Bei Servern mit 100 GB oder weniger 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. Wenn Sie 20 GB Speicherplatz zur Verfügung gestellt haben, wird die Speichergröße auf 25 GB erhöht, wenn weniger als 2 GB Speicherplatz frei sind.
Denken Sie daran, dass der Speicher nach dem automatischen Hochskalieren nicht mehr herunterskaliert werden kann.
Hinweis
Die automatische Speichervergrößerung ist standardmäßig für einen Server mit konfigurierter Hochverfügbarkeit aktiviert und kann nicht deaktiviert werden.
IOPS
Azure Database for MySQL Flexible Server unterstützt vorab bereitgestellte IOPS und automatisch skalierbare IOPS. Weitere Informationen 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.
Wichtig
**Der minimale IOPS-Wert beträgt für alle Computegrößen 360.
**Der maximale IOPS-Wert wird durch die ausgewählte Computegröße bestimmt.
Sie können Ihren E/A-Verbrauch im Azure-Portal (mit Azure Monitor) mit der Metrik E/A in Prozent ü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 der Azure Database for MySQL Flexible Server ist seine Fähigkeit, die beste Leistung für Arbeitsauslastungen der Ebene 1 zu erzielen. Diese kann verbessert werden, indem der Server die Leistung (IO) seiner Datenbankserver automatisch und nahtlos skaliert, je nach den Anforderungen der Workload. Dies ist eine Funktion, die aktiviert werden muss und mit der Benutzer den IOPS-Wert bei Bedarf skalieren können, ohne vorab eine bestimmte EA-Anzahl pro Sekunde bereitstellen zu müssen. Wenn Sie die Autoscale IOPS-Funktion aktivieren, können Sie die IO-Verwaltung in Azure Database for MySQL flexibler Server jetzt sorgenfrei genießen, da der Server die IOPs je nach Arbeitslastbedarf automatisch nach oben oder unten skaliert.
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 sowohl Zeit als auch 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 der Autoskalierung von IOPS entfällt der Verwaltungsaufwand, der erforderlich ist, um Kunden von Azure Database for MySQL – Flexible Server die beste Leistung zu geringstmöglichen 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 erstellt automatisch Sicherungen Ihres Servers. Sie können als Aufbewahrungszeitraum einen Bereich 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 hoch- oder herunterskaliert werden. Die Aufbewahrungsdauer für Sicherungen kann 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.
Hinweis
Die Speichergröße kann nur erhöht werden. Nach der Erhöhung können Sie nicht mehr zu einer kleineren Speichergröße zurückkehren.
Wenn Sie die Computeebene oder die Computegröße ändern, wird der Server neu gestartet, damit der neue Servertyp wirksam wird. Während des Moments, in dem 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-120 Sekunden.
Die Skalierung des Speichers und die Änderung des Aufbewahrungszeitraums von Sicherungen sind Onlinevorgänge und erfordern keinen Neustart des Servers.
Preise
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
- Erfahren Sie, wie Sie eine Instanz von Azure Database for MySQL Flexible Server im Portal erstellen.
- Informieren Sie sich über die Diensteinschränkungen.