Best Practices für eine optimale Leistung von Azure Database for MySQL – Flexibler Server
Hier erfahren Sie, wie Sie bei der Verwendung von Azure Database for MySQL – Flexibler Server eine optimale Leistung erzielen. Die Empfehlungen in diesem Abschnitt werden von uns aktualisiert, wenn der Plattform neue Funktionen hinzugefügt werden.
Geografische Nähe
Achten Sie darauf, eine Anwendung und die Datenbank in derselben Region bereitzustellen. Als schnelle Überprüfung vor dem Starten von Benchmarktests zur Leistung ermitteln Sie die Netzwerklatenz zwischen Client und Datenbank mithilfe einer einfachen SELECT 1-Abfrage.
Wenn Ressourcen wie eine Webanwendung und die zugehörige Datenbank in verschiedenen Regionen ausgeführt werden, kann es eine erhöhte Latenz in der Kommunikation zwischen diesen Ressourcen geben. Ein weiterer möglicher Nebeneffekt, wenn sich die Anwendung und die Datenbank in verschiedenen Regionen befinden, betrifft die Übertragungskosten für ausgehende Daten.
Zur Verbesserung der Leistung und Zuverlässigkeit einer Anwendung in einer kostenoptimierten Bereitstellung sollten sich der Webanwendungsdienst und die Azure Database for MySQL – Flexibler Server-Ressource unbedingt in derselben Region und Verfügbarkeitszone befinden. Diese Colocation eignet sich am besten für Anwendungen, bei denen die Latenz beachten werden muss. Sie bietet außerdem den besten Durchsatz, da die Ressourcen eng gekoppelt sind.
Beschleunigte Netzwerke
Nutzen Sie den beschleunigten Netzwerkbetrieb für den Anwendungsserver, wenn Sie virtuelle Azure-Computer, Azure Kubernetes oder App Services verwenden. Der beschleunigte Netzwerkbetrieb ermöglicht die E/A-Virtualisierung mit Einzelstamm (Single Root I/O Virtualization, SR-IOV) auf einem virtuellen Computer und somit eine erhebliche Steigerung der Netzwerkleistung. Über diesen für Hochleistung konzipierten Pfad wird der Host des Datenpfads umgangen, um Latenzen, Jitter und CPU-Auslastung zu verringern. So können mit unterstützten VM-Typen die anspruchsvollsten Netzwerkworkloads genutzt werden.
Verbindungseffizienz
Das Einrichten einer neuen Verbindung ist immer eine arbeits- und zeitaufwendige Aufgabe. Wenn eine Anwendung eine Datenbankverbindung anfordert, priorisiert sie die Zuordnung vorhandener Datenbankverbindungen im Leerlauf, statt eine neue Verbindung zu erstellen. Im Folgenden finden Sie einige Optionen für bewährte Verbindungsmethoden:
ProxySQL: Verwenden Sie ProxySQL. Das Tool bietet integriertes Verbindungspooling und einen Lastenausgleich für Ihre Workload mit mehreren Lesereplikaten nach Bedarf mit Änderungen am Anwendungscode.
Heimdall-Datenproxy: Alternativ dazu können Sie auch den Heimdall-Datenproxy verwenden. Hierbei handelt es sich um eine herstellerneutrale, proprietäre Proxylösung. Er unterstützt das Zwischenspeichern von Abfragen und das Aufteilen von Lese-/Schreibvorgängen mit Erkennung von Replikationsverzögerungen. Weitere Informationen finden Sie unter Accelerate MySQL Performance with the Heimdall Proxy (Verbessern der MySQL-Leistung mit dem Heimdall-Proxy).
Persistente oder langlebige Verbindung: Wenn Ihre Anwendung nur kurze Transaktionen oder Abfragen mit einer Ausführungszeit unter 5–10 ms aufweist, ersetzen Sie kurze Verbindungen durch persistente Verbindungen. Zum Ersetzen kurzer Verbindungen durch dauerhafte Verbindungen sind nur geringfügige Änderungen am Code erforderlich, doch dies wirkt sich auf die Leistung in vielen typischen Anwendungsszenarien deutlich positiv aus. Stellen Sie sicher, dass Sie ein Timeout festlegen oder die Verbindung trennen, wenn die Transaktion abgeschlossen ist.
Replikat: Wenn Sie ein Replikat verwenden, können Sie mit ProxySQL die Last zwischen dem primären und dem lesbaren sekundären Replikatserver ausgleichen. Erfahren Sie, wie Sie ProxySQL einrichten.
Verbindungspooling
Beim Verbindungspooling handelt es sich um einen Mechanismus, mit dem Datenbankverbindungen erstellt und zugeordnet und Datenbanken vor Überspannungen in Verbindungen geschützt werden. Ziehen Sie das Verbindungspooling in Erwägung, wenn Ihre Anwendung in relativ kurzer Zeit viele Verbindungen öffnet und die Verbindungen kurzlebig sind. Diese Art von Verbindungen kann zum Beispiel in einer Größenordnung von Hunderten oder Tausenden pro Sekunde auftreten, und die Zeit, die zum Herstellen und Trennen dieser Verbindungen benötigt wird, ist im Vergleich zur Gesamtlebensdauer der Verbindungen erheblich.
Wenn das Verbindungspooling vom Entwicklungsframework Ihrer Anwendung nicht unterstützt wird, verwenden Sie stattdessen zwischen der Anwendung und dem Datenbankserver einen Verbindungsproxy (z. B. ProxySQL oder Heimdall).
Handhabung der Verbindungsskalierung
Ein gängiger Ansatz zum Skalieren von Webanwendungen bei schwankendem Bedarf besteht im Hinzufügen und Entfernen von Anwendungsservern. Jeder Anwendungsserver kann einen Verbindungspool mit der Datenbank verwenden. Dieser Ansatz führt dazu, dass die Gesamtzahl der Verbindungen auf einem Datenbankserver im Verhältnis zur Anzahl der Anwendungsserver zunimmt. Wenn ein Datenbankserver beispielsweise über 10 Anwendungsserver verfügt und jeder für 100 Datenbankverbindungen konfiguriert ist, ergibt dies 1.000 Datenbankverbindungen. Wenn die Anwendungsworkload aufgrund einer höheren Benutzeraktivität oder zu Spitzenzeiten zunimmt und weitere 50 Anwendungsserver hinzugefügt werden, ergeben sich insgesamt 6.000 Datenbankverbindungen. In der Regel befinden sich die meisten dieser Verbindungen im Leerlauf, nachdem sie von den Anwendungsservern hergestellt wurden. Da Leerlaufverbindungen Ressourcen (Arbeitsspeicher und CPU) verbrauchen, um offen zu bleiben, kann die Skalierbarkeit der Datenbank beeinträchtigt werden.
Eine weitere potenzielle Herausforderung ist der Umgang mit der Gesamtzahl der Verbindungen mit dem Datenbankserver. Diese hängt von der Anzahl der mit dem Datenbankserver verbundenen Anwendungsserver ab, von denen jeder eigene Verbindungen herstellt. In diesen Szenarios sollten Sie die Verbindungspools auf den Anwendungsservern optimieren. Versuchen Sie, die Anzahl der Verbindungen in jedem Pool auf ein akzeptables Minimum zu reduzieren, um sicherzustellen, dass keine Anhäufung von Verbindungen auf der Datenbankserverseite besteht. Betrachten Sie dies als kurzfristige Lösung, um den Auswirkungen der Skalierung des Anwendungsservers entgegenzuwirken, und nicht als dauerhafte Lösung, um das Wachstum der Anwendung zu bewältigen.
Als langfristige Lösung nutzen Sie zwischen Datenbankserver und Anwendungsserver einen Verbindungsproxy (z. B. ProxySQL oder Heimdall). Dies ist hilfreich, weil der Proxy Folgendes leistet:
- Er stellt eine Verbindung mit dem Datenbankserver mit einer festen Anzahl von Verbindungen her.
- Er akzeptiert Anwendungsverbindungen und dient bei potenziellen Verbindungsfluten als Puffer.
Proxys können weitere Features wie Zwischenspeichern von Abfragen, Verbindungspuffer, Umschreiben/Weiterleiten von Abfragen und Lastenausgleich bereitstellen. Eine noch bessere Skalierbarkeit können Sie mit mehreren Proxyinstanzen erzielen.
Umgang mit Verbindungen für mehr Fehlertoleranz und eine schnellere Wiederherstellung
Berücksichtigen Sie beim Entwerfen Ihrer Anwendungen und Umgebung für Fehlertoleranz und schnellere Wiederherstellung, dass in einer Datenbankumgebung wahrscheinlich Verbindungsunterbrechungen oder Hardwarefehler auftreten. Denken Sie auch daran, dass betriebliche Maßnahmen wie die Skalierung von Instanzgrößen, Patching und die Durchführung eines manuellen Failovers erforderlich sind.
Stellen Sie sich beispielsweise ein Szenario vor, in dem Ihr Datenbankserver das Failover innerhalb einer Minute abgeschlossen hat, Ihre Anwendung jedoch mehrere Minuten länger ausfällt, weil zum Beispiel die DNS-TTL auf der Anwendungsseite zu lang ist. In diesen Fällen kann einfach durch Verringern des TTL-Werts eine schnellere Wiederherstellung erreicht werden, oder die Integration eines Verbindungsproxys zwischen Anwendungs- und Datenbankserver kann bei der Behandlung solcher Fehler helfen.
Partition
Wenn in Ihrer Produktionsworkload extrem große Tabellen verwendet werden, ist die Partitionierung eine geeignete Methode, um die Datenbankleistung zu verbessern und die Wartung zu erleichtern. Durch die Partitionierung wird die Verwaltung großer Tabellen erleichtert. Mit diesem Ansatz können Sie Partitionen hinzufügen und löschen und so große Tabellen effektiv verwalten. Mithilfe der Partitionierung lässt sich auch die Engine skalieren, da interne Strukturkonflikte wie interne Sperren pro Tabelle oder pro Index (z. B. btr_search_latch in InnoDB) abgeschwächt werden.
Durch Hinzufügen von fünf Partitionen wird beispielsweise eine große Tabelle mit viel Aktivitäten in fünf kleinere, effizientere Tabellen aufgeteilt. Dies würde in erster Linie für Fälle hilfreich sein, in denen der Hauptvorgang das Suchen von Primärschlüsseln in der Tabelle ist, damit die Abfragen die Vorteile der "Partitionsbereinigung" nutzen können. Eine Partitionierung kann aber auch bei einem Tabellenscan hilfreich sein.
Während die Partitionierung ihre Vorteile hat, hat sie auch einige Einschränkungen, z. B. das Fehlen der Unterstützung für Fremdschlüssel in partitionierten Tabellen, das Fehlen von Abfragecaches usw. Eine vollständige Liste dieser Einschränkungen finden Sie im MySQL-Referenzhandbuch im Kapitel Einschränkungen und Begrenzungen der Partitionierung.
Trennen von Lese- und Schreibvorgängen
Bei den meisten Anwendungen wird hauptsächlich aus der Datenbank gelesen.Nur nur ein kleiner Prozentsatz der Interaktionen umfasst Schreibvorgänge. Die Anzahl der aktiven Verbindungen in der primären Datenbank, die für die Verbindungspools berechnet wurden, umfasst wahrscheinlich auch Lesezugriffe. Wenn möglichst viele Abfragen auf Lesereplikate verlagert werden und der Zugriff auf die primäre beschreibbare Instanz beibehalten bleibt, erhöht sich die Gesamtzahl der von den Anwendungsservern durchgeführten Datenbankaktivitäten, ohne dass sich die Belastung der primären Datenbank erhöht. Wenn Sie nicht bereits auf Lesereplikate zugreifen, zumindest für längere ausgeführte Abfragen wie Berichte, sollten Sie erwägen, die Berichterstellung oder Analyse sofort in das Lesen von Replikaten zu verschieben.
Der Einsatz von Lesereplikaten in größerem Umfang erfordert möglicherweise eine sorgfältigere Überlegung, da die Replikate aufgrund der asynchronen Natur der Replikation etwas im Nachtreffen gegenüber des Primärsystems. Suchen Sie so viele Bereiche der Anwendung wie möglich, in denen Lesevorgänge aus den Replikaten mit nur geringfügigen Codeänderungen durchgeführt werden können. Sie sollten diese Methode hinsichtlich einer Zwischenspeicherung auch auf höheren Ebenen anwenden: Unterstützen Sie mehr vom schreibgeschützten oder sich nur langsam ändernden Inhalt aus einer dedizierten Zwischenspeicherungsebene wie Azure Cache for Redis.
Schreibskalierung und Sharding (horizontales Partitionieren)
Im Laufe der Zeit werden Anwendungen weiterentwickelt und neue Funktionen hinzugefügt. Die Tabellen werden aus Bequemlichkeit, oder weil es allgemein üblich ist, zur primären Datenbank hinzugefügt. Zur Bewältigung des zunehmenden Datenverkehrs in einer Datenbank sollten Bereiche der Anwendung ermittelt werden, die problemlos in separate Datenbanken verschoben werden können. Zudem sollte eine horizontale Partitionierung oder vertikale Teilung der Datenbank in Erwägung gezogen werden.
Bei der horizontalen Partitionierung einer Datenbank werden mehrere Kopien des Anwendungsschemas in separaten Datenbanken erstellt und die Kunden sowie alle zugehörigen Daten basierend auf Kunden-ID, geografischem Standort oder einem anderen Attribut nach Kunde oder Mandant getrennt. Das funktioniert bei SaaS- oder B2C-Anwendungen sehr gut, bei denen die einzelnen Kunden klein sind und die Auslastung der Anwendung auf die aggregierte Nutzung von Millionen von Kunden zurückzuführen ist. Schwieriger ist es jedoch bei B2B-Anwendungen, bei denen die Kunden unterschiedlich groß sind und möglicherweise einzelne Großkunden die Datenverkehrslast für einen bestimmten Shard dominieren.
Vertikale Teilung der Last durch funktionales Sharding der Datenbank – Verschieben von separaten Anwendungsdomänen (oder von Microservices) in eigene Datenbanken. Dadurch wird die Last von der primären Datenbank auf separate, Diensten zugeordneten Datenbanken verteilt. Einfache Beispiele sind eine Protokollierungstabelle oder Standortkonfigurationsinformationen, die sich nicht in derselben Datenbank wie die stark belastete Auftragstabelle befinden müssen. Zu den komplexeren Beispielen gehört die Trennung von Kunden- und Kontodomänen von den Auftrags- oder Auftragserfüllungsdomänen. In einigen Fällen kann dies Anwendungsänderungen erfordern, z. B. zum Ändern von E-Mail- oder Hintergrundauftragswarteschlangen, um eigenständig zu sein und sich nicht auf Verknüpfungen zurück zu einer Kunden- oder Auftragstabelle zu verlassen. Vorhandene Tabellen und Daten können mit Azure Database for MySQL – Flexibler Server-Lesereplikaten und durch Höherstufen des Replikats sowie durch Verweisen von Teilen der Anwendung auf die neu erstellte beschreibbare Datenbank in eine neue primäre Datenbank verschoben werden. In der neu erstellten Datenbank müssen wie in der ursprünglichen primären Datenbank der Zugriff mit Verbindungspools begrenzt, Abfragen optimiert und die Last mit eigenen Replikaten verteilt werden.
Konfigurationen für den Datenimport
- Sie können Ihre Instanz temporär auf eine höhere SKU-Größe skalieren, bevor Sie einen Datenimportvorgang starten, und sie nach dem erfolgreichen Import wieder herunterskalieren.
- Sie können Ihre Daten mit minimalen Ausfallzeiten importieren, indem Sie MySQL lokal zu Azure Database for MySQL für Online- oder Offlinemigrationen migrieren.
Azure Database for MySQL – Flexibler Server: Arbeitsspeicherempfehlungen
Eine bewährte Methode zur Verbesserung der Leistung von Azure Database for MySQL – Flexibler Server besteht darin, genügend Arbeitsspeicher (RAM) zuzuweisen, damit sich der Arbeitssatz nahezu vollständig im Arbeitsspeicher befindet.
- Anhand der Metriken für Azure Database for MySQL – Flexibler Server können Sie überprüfen, ob der Prozentsatz an Arbeitsspeicher die Grenzwerte erreicht.
- Richten Sie Warnungen zu solchen Messwerten ein, damit Sie bei Erreichen der Servergrenzwerte Maßnahmen zur Behebung ergreifen können. Überprüfen Sie basierend auf den definierten Grenzwerten, ob das Hochskalieren der Datenbank-SKU (auf eine höhere Computegröße oder einen besseren Tarif) zu einer deutlichen Leistungssteigerung führt.
- Setzen Sie das Hochskalieren so lange fort, bis Ihre Leistungsdaten nach einem Skalierungsvorgang nicht mehr deutlich sinken. Weitere Informationen zum Überwachen der Metriken einer Datenbankinstanz finden Sie in den Datenbankmetriken für Azure Database for MySQL – Flexibler Server.
„Aufwärmen“ des InnoDB-Pufferpools
Nach dem Neustart der Instanz von Azure Database for MySQL – Flexibler Server werden die Datenseiten im Speicher geladen, wenn die Tabellen abgefragt werden. Dies hat eine längere Wartezeit und eine geringere Leistung bei der ersten Abfrageausführung zur Folge. Dies ist möglicherweise für latenzempfindliche Workloads nicht akzeptabel.
Durch das „Aufwärmen“ des InnoDB-Pufferpools wird die Startzeit verkürzt, indem Datenträgerseiten, die sich bereits vor dem Neustart im Pufferpool befanden, erneut geladen werden, ohne darauf zu warten, dass DML- oder SELECT-Vorgänge auf die entsprechenden Zeilen zugreifen.
Sie können die Aufwärmzeit nach dem Neustart der Instanz von Azure Database for MySQL – Flexibler Server verkürzen und damit einen Leistungsvorteil erzielen, indem Sie Serverparameter für den InnoDB-Pufferpool konfigurieren. InnoDB speichert einen Prozentsatz der zuletzt verwendeten Seiten für jeden Pufferpool beim Herunterfahren des Servers und stellt diese Seiten beim Serverstart wieder her.
Beachten Sie dabei allerdings, dass die verbesserte Leistung auch eine längere Startzeit für den Server zur Folge hat. Wenn dieser Parameter aktiviert ist, müssen Sie davon ausgehen, dass sich die Start- und Neustartzeiten des Servers abhängig von den auf dem Server bereitgestellten IOPS erhöhen.
Es wird empfohlen, die Neustartzeit zu testen und zu überwachen, um sicherzustellen, dass die Leistung bei Starts bzw. Neustarts akzeptabel ist, da der Server während dieser Zeit nicht verfügbar ist. Wenn weniger als 1000 IOPS bereitgestellt werden (oder anders ausgedrückt: wenn der bereitgestellte Speicher kleiner als 335 GB ist), sollte von der Verwendung dieses Parameters abgesehen werden.
Wenn Sie den Zustand des Pufferpools beim Herunterfahren des Servers speichern möchten, legen Sie den Serverparameter innodb_buffer_pool_dump_at_shutdown auf ON fest. Legen Sie analog dazu den Serverparameter innodb_buffer_pool_load_at_startup auf ON fest, um den Pufferpoolzustand beim Serverstart wiederherzustellen. Sie können die Auswirkung auf die Start-/Neustartdauer steuern, indem Sie den Wert des Serverparameters innodb_buffer_pool_dump_pct verringern und optimieren. Dieser Parameter ist standardmäßig auf 25 festgelegt.
Hinweis
Die Aufwärmparameter des InnoDB-Pufferpools werden nur auf universellen Speicherservern mit maximal 16 TB Speicher unterstützt. Weitere Informationen finden Sie in den Speicheroptionen für Azure Database for MySQL – Flexibler Server.