Freigeben über

Best Practices für Servervorgänge in Azure Database for MySQL – Flexibler Server

  • Artikel

Lernen Sie die Best Practices für die Arbeit mit Azure Database for MySQL Flexibler Server kennen. Die in diesem Abschnitt beschriebenen Best Practices werden aktualisiert, wenn der Plattform neue Funktionen hinzugefügt werden.

Betriebliche Richtlinien für Azure Database for MySQL Flexibler Server

Es empfiehlt sich, bei der Arbeit mit Azure Database for MySQL Flexibler Server die folgenden betrieblichen Richtlinien zu befolgen, um die Leistung Ihrer Datenbank zu verbessern:

  • Gemeinsame Nutzung: Zum Reduzieren der Netzwerklatenz sollten sich Client und Datenbankserver in derselben Azure-Region befinden.

  • Überwachen Ihrer Arbeitsspeicher-, CPU- und Speichernutzung: Sie können Warnung einrichten, um eine Benachrichtigung zu erhalten, wenn sich Nutzungsmuster ändern oder das Kapazitätslimit der Bereitstellung erreicht wird. So können Sie Maßnahmen ergreifen, um Systemleistung und -verfügbarkeit sicherzustellen.

  • Beschleunigte Protokolle für verbesserte Leistung: Durch Aktivieren der Funktion Beschleunigte Protokolle werden transaktionsbezogene Protokollvorgänge optimiert, wodurch der Serverdurchsatz und die Leistung gesteigert werden. Dieses Feature, das ohne zusätzliche Kosten verfügbar ist, ist eine wichtige Ergänzung zu den betrieblichen bewährten Methoden für Benutzerinnen und Benutzer der unternehmenskritischen Dienstebene.

  • Skalieren Sie Ihre DB-Instanz: Sie können hochskalieren, wenn Sie sich den Speicherkapazitätsgrenzwerten nähern. Sie sollten sowohl beim Arbeitsspeicher als auch beim Massenspeicher einen Puffer einrechnen, um ein unvorhergesehenes Anwachsen der Anforderungen Ihrer Anwendungen abdecken zu können. Sie können auch das Feature der automatischen Speichervergrößerung aktivieren, um sicherzustellen, dass der Dienst den Speicher automatisch skaliert, wenn dieser sich den Grenzwerten nähert.

  • Konfigurieren von Sicherungen: Aktivieren Sie lokale oder georedundante Sicherungen, je nach Anforderungen des Unternehmens. Über den Aufbewahrungszeitraum können Sie festlegen, wie lange die Sicherungen aus Gründen der Geschäftskontinuität verfügbar sein sollen.

  • Optimieren der E/A-Kapazität mit IOPS-Autoskalierung: Wenn Ihre Datenbankworkload mehr E/A-Vorgänge erfordert als bereitgestellt werden, werden Wiederherstellungs- oder andere Transaktionsvorgänge für Ihre Datenbank nur langsam ausgeführt. Um die E/A-Kapazität einer Serverinstanz zu erhöhen, führen Sie eine der folgenden Aktionen aus:

    • Verwenden der IOPS-Autoskalierung: Die IOPS-Autoskalierung eliminiert die Notwendigkeit, eine bestimmte Anzahl von E/A-Vorgängen pro Sekunde vorab bereitzustellen. Stattdessen kann Ihr Server IOPS basierend auf Workloadanforderungen1 automatisch anpassen. Das bedeutet, dass Ihr Server IOPS automatisch nach oben oder unten skalieren kann, je nach Bedarf der Workload.

    • Azure Database for MySQL Flexibler Server bietet eine IOPS-Skalierung mit einer Geschwindigkeit von drei IOPS pro bereitgestelltem GB Speicherplatz. Vergrößern Sie den bereitgestellten Speicher, um den IOPS-Wert zu skalieren und eine bessere Leistung zu erzielen.

    • Wenn Sie bereits Speicher mit bereitgestellten IOPS verwenden, stellen Sie zusätzliche Durchsatzkapazität bereit.

  • Skalieren von Computeressourcen: Die Datenbankworkload kann auch durch CPU oder Arbeitsspeicher eingeschränkt sein. Dies kann schwerwiegende Auswirkungen auf die Transaktionsverarbeitung haben. Die Computerleistung (Tarif) kann nur zwischen den Tarifen „Universell“ und „Arbeitsspeicheroptimiert“ hoch- oder herunterskaliert werden.

  • Testen des Failovers: Testen Sie das Failover für Ihre Serverinstanz manuell, um zu ermitteln, wie lang der Prozess für Ihren Anwendungsfall dauert, und um sicherzustellen, dass die Anwendung, die auf die Serverinstanz zugreift, nach dem Failover automatisch eine Verbindung mit der neuen Serverinstanz herstellen kann.

  • Verwenden eines Primärschlüssels: Stellen Sie sicher, dass Ihre Tabellen über einen primären oder eindeutigen Schlüssel verfügen, wenn Sie mit der Azure Database for MySQL Flexibler Server-Instanz arbeiten. Ein solcher Schlüssel ist beim Erstellen von Sicherungen, Replikaten und Ähnlichem sehr nützlich und verbessert die Leistung.

  • Konfigurieren des TTL-Werts: Wenn Ihre Clientanwendung die DNS-Daten (Domain Name Service) Ihrer Serverinstanz zwischenspeichert, legen Sie einen TTL-Wert (Time-To-Live) von weniger als 30 Sekunden fest. Die zugrunde liegende IP-Adresse einer Serverinstanz kann sich nach einem Failover ändern. Daher kann eine Zwischenspeicherung der DNS-Daten über einen längeren Zeitraum zu Verbindungsfehlern führen, wenn Ihre Anwendung versucht, eine Verbindung mit einer IP-Adresse herzustellen, die nicht mehr verwendet wird.

  • Verwenden Sie Verbindungspools, um ein Erreichen der maximalen Anzahl von Verbindungen zu vermeiden. Verwenden Sie außerdem eine Wiederholungslogik, um vorübergehende Verbindungsprobleme zu vermeiden.

  • Wenn Sie ein Replikat verwenden, können Sie mit ProxySQL die Last zwischen dem primären und dem lesbaren sekundären Replikatserver ausgleichen. Im erwähnten Artikel finden Sie die Schritte zur Einrichtung.

  • Wenn Sie die Ressource bereitstellen, vergewissern Sie sich, dass die automatische Speichervergrößerung in der Azure Database for MySQL Flexibler Server-Instanz aktiviert ist. Dies zieht keine weiteren Kosten nach sich und schützt die Datenbank vor möglicherweise auftretenden Speicherengpässen.

Verwenden von InnoDB mit Azure Database for MySQL – Flexibler Server

  • Wenn Sie die Funktion ibdata1 verwenden, bei der es sich um einen System-Tablespace handelt, kann die Datendatei nicht verkleinert oder bereinigt werden, indem Sie die Daten aus der Tabelle löschen oder die Tabelle in die Datei pro Tabelle tablespaces verschieben.

  • Bei einer Datenbankgröße von mehr als 1 TB sollten Sie die Tabelle im tablespace innodb_file_per_table erstellen. Bei einer einzelnen Tabelle mit mehr als 1 TB sollten Sie die Partitionstabelle verwenden.

  • Bei einem Server mit einer großen tablespace-Anzahl startet die Engine aufgrund der sequenziellen Tabellenbereichsüberprüfung während des Starts oder Failovers von Azure Database for MySQL Flexibler Server nur sehr langsam.

  • Wenn die Gesamtanzahl von Tabellen weniger als 500 beträgt, legen Sie „innodb_file_per_table = ON“ fest, bevor Sie eine Tabelle erstellen.

  • Wenn Sie über mehr als 500 Tabellen in einer Datenbank verfügen, überprüfen Sie die Tabellengröße jeder einzelnen Tabelle. Bei großen Tabellen sollten Sie weiterhin den Tabellenbereich „file-per-table“ in Erwägung ziehen, um zu verhindern, dass der Systemtabellenbereich das maximale Speicherlimit erreicht.

Hinweis

Ziehen Sie bei Tabellen mit einer Größe von unter 5 GB den Systemtabellenbereich in Erwägung:

CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;

  • Partitionieren Sie Ihre Tabelle während der Erstellung, wenn die Tabelle groß ist und möglicherweise auf mehr als 1 TB anwächst.

  • Verwenden Sie mehrere Azure Database for MySQL Flexibler Server-Instanzen und verteilen Sie die Tabellen auf diesen Servern. Wenn Sie 10.000 Tabellen oder mehr haben, stellen Sie sicher, dass Sie nicht zu viele Tabellen auf einem einzelnen Server platzieren.

Zugehöriger Inhalt