Bewährte Methoden für die Entwicklung von Anwendungen mit Azure Database for MySQL

  • Artikel

GILT FÜR: Azure Database for MySQL – Single Server Azure Database for MySQL – Flexible Server

Wichtig

Azure Database for MySQL single server is on the retirement path. Es wird dringend empfohlen, ein Upgrade auf azure Database for MySQL flexiblen Server durchzuführen. Weitere Informationen zum Migrieren zu Azure Database for MySQL flexible Server finden Sie unter Was geschieht mit Azure Database for MySQL Single Server?

Im Folgenden finden Sie einige bewährte Methoden, die Ihnen beim Erstellen einer cloudfähigen Anwendung mithilfe von Azure Database for MySQL helfen sollen. Diese bewährten Methoden können die Entwicklungszeit für Ihre App verkürzen.

Konfiguration von Anwendungs- und Datenbankressourcen

Anwendung und Datenbank in derselben Region

Stellen Sie sicher, dass sich sämtliche Abhängigkeiten in derselben Region befinden, wenn Sie Ihre Anwendung in Azure bereitstellen. Wenn Sie die Instanzen auf verschiedene Regionen oder Verfügbarkeitszonen verteilen, führt dies zu Netzwerklatenzen, die sich auf die Gesamtleistung Ihrer Anwendung auswirken können.

Sichern des MySQL-Servers

Ihr MySQL-Server sollte sicher konfiguriert und nicht öffentlich zugänglich sein. Verwenden Sie eine der folgenden Optionen, um Ihren Server zu schützen:

Aus Gründen der Sicherheit müssen Sie Verbindungen mit Ihrem MySQL-Server immer über SSL herstellen und den Server und Ihre Anwendung für die Verwendung von TLS 1.2 konfigurieren. Weitere Informationen finden Sie unter Konfigurieren von SSL/TLS.

Verwenden von erweiterten Netzwerken mit AKS

Wenn der beschleunigte Netzwerkbetrieb auf einem virtuellen Computer aktiviert ist, ist die Wartezeit geringer, Jitter reduziert und die CPU-Auslastung des virtuellen Computers niedriger. Weitere Informationen finden Sie unter Bewährte Methoden für Azure Kubernetes Service und Azure Database for MySQL.

Optimieren der Serverparameter

Bei Workloads mit sehr vielen Lesevorgängen kann das Optimieren der Serverparameter tmp_table_size und max_heap_table_size zu einer besseren Leistung beitragen. Um die für diese Variablen erforderlichen Werte zu berechnen, sehen Sie sich die Gesamtwerte für den Arbeitsspeicher pro Verbindung und den Basisarbeitsspeicher an. Die Summe der Parameter für den Arbeitsspeicher pro Verbindung ohne tmp_table_size plus Basisarbeitsspeicher ergibt den Gesamtarbeitsspeicher des Servers.

Verwenden Sie die folgende Formel, um die maximale Größe von tmp_table_size und max_heap_table_size zu berechnen:

(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections

Hinweis

Der Gesamtarbeitsspeicher gibt die Gesamtmenge an Arbeitsspeicher an, die dem Server für alle bereitgestellten virtuellen Kerne zur Verfügung steht. Bei einem universellen Azure Database for MySQL-Server mit zwei virtuellen Kernen beispielsweise beträgt der Gesamtarbeitsspeicher 5 GB × 2. Weitere Informationen zum Arbeitsspeicher für jede Dienstebene finden Sie in der Dokumentation zu den Tarifen.

„Basisarbeitsspeicher“ gibt die Arbeitsspeichervariablen wie query_cache_size und innodb_buffer_pool_size an, die MySQL beim Start des Servers initialisiert und zuweist. „Arbeitsspeicher pro Verbindung“ (z. B. sort_buffer_size und join_buffer_size) ist Arbeitsspeicher, der nur zugewiesen wird, wenn er von einer Abfrage benötigt wird.

Erstellen von Benutzern ohne Administratorrechte

Erstellen Sie Benutzer ohne Administratorrechte für jede Datenbank. In der Regel entsprechen die Benutzernamen den Namen der Datenbanken.

Zurücksetzen Ihres Kennworts

Mit dem Azure-Portal können Sie das Kennwort für Ihren MySQL-Server zurücksetzen.

Das Zurücksetzen des Serverkennworts für eine Produktionsdatenbank kann dazu führen, dass Ihre Anwendung nicht mehr verfügbar ist. Sie sollten das Kennwort für Produktionsworkloads daher außerhalb der Spitzennutzungszeiten zurücksetzen, um die Auswirkungen auf die Benutzer Ihrer Anwendung zu minimieren.

Leistung und Resilienz

Im Folgenden finden Sie einige Tools und Verfahren, mit denen Sie Leistungsprobleme Ihrer Anwendung debuggen können.

Aktivieren von Protokollen zu langsamen Abfragen zum Ermitteln von Leistungsproblemen

Sie können Protokolle zu langsamen Abfragen und Überwachungsprotokolle auf Ihrem Server aktivieren. Durch eine Analyse des Protokolls für langsame Abfragen können Sie Leistungsengpässe erkennen.

Überwachungsprotokolle sind auch über Azure-Diagnoseprotokolle in Azure Monitor-Protokollen, Azure Event Hubs und in Speicherkonten verfügbar. Weitere Informationen finden Sie unter Beheben von Problemen bei der Abfrageleistung.

Verbindungspooling verwenden

Das Verwalten von Datenbankverbindungen kann sich auf die Leistung der gesamten Anwendung erheblich auswirken. Um die Leistung zu optimieren, müssen Sie die Häufigkeit reduzieren, mit der Verbindungen hergestellt werden, und die Zeit für das Herstellen von Verbindungen in wichtigen Codepfaden verkürzen. Verwenden Sie das Verbindungspooling für die Verbindung mit Azure Database for MySQL, um die Resilienz und Leistung zu verbessern.

Sie können die Verbindungspoolfunktion ProxySQL verwenden, um Verbindungen effizient zu verwalten. Mithilfe einer Verbindungspoolfunktion können Verbindungen im Leerlauf reduziert und vorhandene Verbindungen wiederverwendet werden, um Probleme zu vermeiden. Weitere Informationen finden Sie unter Einrichten von ProxySQL.

Wiederholungslogik zum Behandeln vorübergehender Fehler

Bei Ihrer Anwendung können vorübergehende Fehler auftreten, die dazu führen, dass Verbindungen mit der Datenbank vorübergehend gelöscht oder getrennt werden. In solchen Situationen ist der Server nach ein oder zwei Wiederholungen innerhalb von 5–10 Sekunden wieder betriebsbereit.

Es wird empfohlen, vor dem ersten Wiederholungsversuch fünf Sekunden zu warten. Erhöhen Sie dann nach jeder Wiederholung die Wartezeit nach und nach auf bis zu 60 Sekunden. Begrenzen Sie die maximale Anzahl von Wiederholungen, nach denen Ihre Anwendung den Vorgang als fehlerhaft ansieht, damit Sie weitere Untersuchungen anstellen können. Weitere Informationen finden Sie unter Beheben von Verbindungsproblemen.

Aktivieren von Lesereplikaten zum Minimieren von Failovervorgängen

Für Failoverszenarien können Sie die Datenreplikation verwenden. Wenn Sie Lesereplikate verwenden, erfolgt zwischen Quell- und Replikatservern kein automatisiertes Failover.

Sie stellen eine Verzögerung zwischen Quelle und Replikat fest, da die Replikation asynchron verläuft. Die Netzwerkverzögerung kann durch viele Faktoren beeinflusst werden, z. B. durch die Größe der Workload auf dem Quellserver und die Wartezeit zwischen Rechenzentren. In den meisten Fällen beträgt die Replikatverzögerung einige Sekunden bis zu wenigen Minuten.

Datenbankbereitstellung

Konfigurieren einer Azure Database for MySQL-Aufgabe in der CI/CD-Bereitstellungspipeline

Gelegentlich werden Sie Änderungen in der Datenbank bereitstellen müssen. In solchen Fällen können Sie Continuous Integration (CI) und Continuous Delivery (CD) über Azure-Pipelines verwenden und eine Aufgabe für Ihren MySQL-Server verwenden, um die Datenbank durch Ausführung eines benutzerdefinierten Skripts zu aktualisieren.

Effektive Prozesse bei einer manuellen Datenbankbereitstellung

Im Folgenden finden Sie Schritte für die manuelle Datenbankbereitstellung, mit denen Sie Ausfallzeiten sowie das Risiko von Bereitstellungsfehlern minimieren können:

  1. Erstellen Sie mit mysqldump oder MySQL Workbench eine Kopie der Produktionsdatenbank in einer neuen Datenbank.
  2. Aktualisieren Sie die neue Datenbank mit den erforderlichen Schemaänderungen oder Aktualisierungen.
  3. Versetzen Sie die Produktionsdatenbank in den schreibgeschützten Zustand. Bis die Bereitstellung abgeschlossen ist, sollten in der Produktionsdatenbank keine Schreibvorgänge erfolgen.
  4. Testen Sie die Anwendung mit der frisch aktualisierten Datenbank aus Schritt 1.
  5. Stellen Sie die Anwendungsänderungen bereit, und stellen Sie sicher, dass die Anwendung jetzt die neue Datenbank mit den neuesten Updates verwendet.
  6. Behalten Sie die alte Produktionsdatenbank, um ein Rollback der Änderungen ausführen zu können. Danach können Sie die alte Produktionsdatenbank löschen oder bei Bedarf in Azure Storage exportieren.

Hinweis

Wenn die Anwendung beispielsweise eine E-Commerce-App ist, die nicht in einen schreibgeschützten Zustand versetzt werden kann, stellen Sie die Änderungen direkt in der Produktionsdatenbank bereit, nachdem Sie eine Sicherung erstellt haben. Diese Änderungen sollten zu einer Zeit mit wenig Datenverkehr für die App erfolgen, um mögliche Auswirkungen zu minimieren, da es bei einigen Benutzer*innen zu Anforderungsfehlern kommen könnte.

Stellen Sie sicher, dass Ihr Anwendungscode auch Anforderungsfehler behandelt.

Verwenden von nativen MySQL-Metriken, um zu ermitteln, ob die Workload die Größen arbeitsspeicherinterner temporärer Tabellen überschreitet

Bei Workloads mit vielen Lesevorgängen können Abfragen an den MySQL-Server die Größen temporärer Tabellen im Arbeitsspeicher überschreiten. Eine Workload mit vielen Lesevorgängen kann dazu führen, dass der Server temporäre Tabellen auf einen Datenträger schreibt. Dies wiederum beeinträchtigt die Leistung Ihrer Anwendung. Um zu ermitteln, ob Ihr Server aufgrund einer Größenüberschreitung der temporären Tabelle auf einen Datenträger schreibt, sehen Sie sich die folgenden Metriken an:

show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';

Die Metrik created_tmp_disk_tables gibt an, wie viele Tabellen auf dem Datenträger erstellt wurden. Die Metrik created_tmp_table gibt Aufschluss darüber, wie viele temporäre Tabellen für Ihre Workload im Arbeitsspeicher erstellt werden müssen. Um zu ermitteln, ob für eine bestimmte Abfrage temporäre Tabellen verwendet werden, führen Sie eine EXPLAIN-Anweisung für die Abfrage aus. Die Details in der Spalte extra enthalten Using temporary, wenn die Abfrage mithilfe von temporären Tabellen ausgeführt wird.

Um zu berechnen, für welchen Prozentsatz Ihrer Workload die Abfragen auf Datenträgern geschrieben werden, verwenden Sie die folgende Formel mit Ihren Metrikwerten:

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

Im Idealfall sollte dieser Prozentsatz unter 25 % liegen. Wenn der Prozentsatz 25 % oder höher ist, empfiehlt es sich, Änderungen an zwei Serverparametern vorzunehmen: „tmp_table_size“ und „max_heap_table_size“.

Datenbankschema und -abfragen

Denken Sie beim Erstellen von Datenbankschemas und -abfragen an die folgenden Tipps.

Verwenden des richtigen Datentyps für Tabellenspalten

Verwenden Sie immer die richtigen Datentypen, je nachdem, welche Arten von Daten Sie speichern möchten. So können Sie den Speicher optimieren und Fehler aufgrund von falschen Datentypen reduzieren.

Verwenden von Indizes

Sie können Indizes verwenden, um langsame Abfragen zu vermeiden. Mithilfe von Indizes lassen sich Zeilen mit bestimmten Spalten schnell finden. Weitere Informationen finden Sie unter How MySQL Uses Indexes (Verwenden von Indizes in MySQL).

Verwenden der EXPLAIN-Anweisung in SELECT-Abfragen

Verwenden Sie eine EXPLAIN-Anweisung, um zu erfahren, auf welche Weise MySQL Ihre Abfrage ausführt. So können Sie mögliche Engpässe oder Probleme bei Ihrer Abfrage erkennen. Weitere Informationen finden Sie unter Verwenden von EXPLAIN zum Analysieren der Abfrageleistung in Azure Database for MySQL.