Bewährte Methoden für Amazon RDS - Amazon Relational Database Service

Bewährte Methoden für Amazon RDS

Informieren Sie sich über die bewährten Methoden für die Arbeit mit Amazon RDS. Dieser Abschnitt wird mit neuen bewährten Methoden aktualisiert, sobald diese bekannt sind.

Anmerkung

Allgemeine Empfehlungen für Amazon RDS finden Sie unter Amazon RDS Betrachtungsempfeh.

Grundlegende Anleitungen für den Amazon RDS-Betrieb

Im Folgenden finden Sie einige grundlegende Anleitungen für die Ausführung, die bei der Arbeit mit Amazon RDS befolgt werden sollten. Beachten Sie, dass das Amazon RDS Service Level Agreement voraussetzt, dass Sie die folgenden Anleitungen befolgen:

  • Verwenden Sie Metriken, um Speicher, CPU, Replikatverzögerung und Speichernutzung zu überwachen. Amazon CloudWatch kann so eingerichtet werden, dass Sie benachrichtigt werden, wenn sich die Nutzungsmuster ändern oder die Kapazitäten Ihrer Bereitstellung beinahe erschöpft sind. Auf diese Weise können Sie die Leistung und Verfügbarkeit des Systems wahren.

  • Skalieren Sie Ihre DB-Instance, wenn Sie die Grenzen der Speicherkapazität beinahe erreicht haben. Sie sollten etwas Puffer in Speicher und Arbeitsspeicher haben, um unvorhergesehene Nachfragesteigerungen seitens Ihrer Anwendungen bewältigen zu können.

  • Aktivieren Sie automatische Sicherungen und richten Sie das Sicherungsfenster so ein, dass Sicherungen während Zeiten mit nur wenigen Schreibvorgangs-IOPS ausgeführt werden. Dann ist eine Sicherung am wenigsten störend für Ihre Datenbanknutzung.

  • Wenn Ihr Datenbank-Workload mehr E/A benötigt, als Sie bereitgestellt haben, ist die Wiederherstellung nach einem Failover oder einem Datenbankfehler langsam. Führen Sie einen der folgenden Schritte aus, um die E/A-Kapazität einer DB-Instance zu steigern:

    • Migrieren Sie zu einer anderen DB-Instance-Klasse mit einer höheren E/A-Kapazität.

    • Konvertieren Sie von einem magnetischen Speicher zu einem Speicher für allgemeine Zwecke oder zu einem Speicher mit bereitgestellten IOPS, abhängig davon, wie groß die benötigte Steigerung ist. Weitere Informationen zu den verfügbaren Speichertypen finden Sie unter Amazon RDS-Speichertypen.

      Wenn Sie zu einem Speicher mit bereitgestellten IOPS konvertieren, müssen Sie sicherstellen, dass Sie eine DB-Instance-Klasse verwenden, die für bereitgestellte IOPS optimiert ist. Weitere Informationen zu bereitgestellten IOPS finden Sie unter Bereitgestellter IOPS SSD-Speicher.

    • Wenn Sie bereits einen Speicher mit bereitgestellten IOPS verwenden, sollten Sie zusätzliche Durchsatzkapazitäten bereitstellen.

  • Wenn Ihre Client-Anwendung die Domain Name Service (DNS)-Daten Ihrer DB-Instances zwischenspeichert, sollten Sie einen Time-to-Live (TTL)-Wert von weniger als 30 Sekunden festlegen. Da sich die IP-Adresse einer DB-Instance nach einem Failover ändern kann, kann das Zwischenspeichern 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.

  • Testen Sie den Failover für Ihre DB-Instance, um zu verstehen, wie lange der Vorgang für Ihren speziellen Anwendungsfall dauert, und um sicherzustellen, dass die Anwendung, die auf Ihre DB-Instance zugreift, nach dem Failover automatisch eine Verbindung zur neuen DB-Instance herstellen kann.

RAM-Empfehlungen für DB-Instances

Eine bewährte Methode im Zusammenhang mit der Verbesserung der Leistung von Amazon RDS besteht in der Zuteilung von ausreichend RAM, damit sich Ihr Arbeitssatz beinahe vollständig im Arbeitsspeicher befindet. Der Arbeitssatz umfasst die Daten und Indizes, die häufig auf Ihrer Instance verwendet werden. Je häufiger Sie die DB-Instance verwenden, desto größer wird der Arbeitssatz.

Um festzustellen, ob sich Ihr Arbeitssatz fast vollständig im Arbeitsspeicher befindet, überprüfen Sie die ReadIOPS-Metrik (unter Verwendung von Amazon CloudWatch), während die DB-Instance unter Last ist. Der Wert von ReadIOPS sollte klein und stabil sein. Wenn die Skalierung der DB-Instance-Klasse zu einer Klasse mit mehr RAM zu einer deutlichen Abnahme des ReadIOPS-Werts führt, befand sich Ihr Arbeitssatz nicht beinahe vollständig im Arbeitsspeicher. Skalieren Sie weiter, bis der ReadIOPS-Wert nach einer Skalierungsoperation nicht mehr deutlich abnimmt oder zu einem sehr kleinen Wert reduziert wird. Informationen zur Überwachung der Metriken einer DB-Instance finden Sie unter Anzeigen von Metriken in der Amazon RDS-Konsole.

Verwendung von Enhanced Monitoring zur Identifizierung von Betriebssystemproblemen

Wenn Enhanced Monitoring aktiviert ist, stellt Amazon RDS Metriken in Echtzeit für das Betriebssystem (OS) bereit, auf dem Ihre DB-Instance ausgeführt wird. Sie können die Metriken für Ihre DB-Instance über die Konsole anzeigen oder die Enhanced Monitoring-JSON-Ausgabe aus Amazon CloudWatch Logs in einem Überwachungssystem Ihrer Wahl nutzen. Weitere Informationen zu Enhanced Monitoring finden Sie unter Überwachen von Betriebssystem-Metriken mithilfe von „Enhanced Monitoring“·(Erweiterte·Überwachung).

Verwendung von Metriken zur Identifizierung von Problemen mit der Leistung

Sie können die Metriken überwachen, die für Ihre Amazon RDS-DB-Instance verfügbar sind, um Leistungsprobleme aufgrund unzureichender Ressourcen und anderer häufiger Engpässe zu identifizieren.

Anzeigen von Leistungsmetriken

Sie sollten die Leistungsmetriken regelmäßig überwachen, um die Durchschnitts-, Höchst- und Mindestwerte für eine Vielzahl von Zeitbereichen anzuzeigen. Wenn Sie dies tun, können Sie feststellen, wenn die Leistung nachlässt. Sie können auch Amazon CloudWatch-Alarme für bestimmte Metrikgrenzwerte einrichten, um benachrichtigt zu werden, wenn sie erreicht werden.

Um Probleme mit der Leistung zu beheben, müssen Sie die Basisleistung des Systems kennen. Wenn Sie eine neue DB-Instance einrichten und in dieser einen typischen Workload ausführen, sollten Sie die Durchschnitts-, Höchst- und Mindestwerte aller Leistungsmetriken in unterschiedlichen Intervallen erfassen (beispielsweise eine Stunde, 24 Stunden, eine Woche, zwei Wochen), um eine Vorstellung davon zu erhalten, was normal ist. Dies hilft, um Vergleichswerte für Betriebsstunden während und außerhalb von Spitzenbelastungen zu erhalten. Sie können diese Informationen anschließend verwenden, um festzustellen, wann die Leistung unter Standardwerte absinkt.

Fall Sie Multi-AZ-DB-Clustern verwenden, können Sie die Zeitdifferenz zwischen der letzten Transaktion auf der Writer-DB-Instance und der zuletzt angewendeten Transaktion auf einer Reader-DB-Instance überwachen. Dieser Unterschied heißt replica lag (Replikatverzögerung). Weitere Informationen finden Sie unter Replikatverzögerung und Multi-AZ-DB-Cluster.

So können Sie sich die Leistungsmessungen anzeigen

  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich die Option Databases (Datenbanken) und anschließend eine DB-Instance.

  3. Wählen Sie Monitoring. Die ersten acht Leistungsmetriken werden angezeigt. Die Metriken zeigen standardmäßig Informationen für den aktuellen Tag an.

  4. Verwenden Sie die nummerierten Schaltflächen oben rechts, um durch die zusätzlichen Metriken zu blättern, oder wählen Sie "Einstellungen anpassen", um weitere Metriken anzuzeigen.

  5. Wählen Sie eine Leistungsmetrik zur Anpassung des Zeitbereichs, um Daten für andere Tage als den aktuellen Tag anzuzeigen. Sie können die Werte für Statistik, Zeitraum und Intervall ändern, um die angezeigten Informationen anzupassen. Um beispielsweise die Spitzenwerte für eine Metrik für jeden Tag der letzten beiden Wochen anzuzeigen, legen Sie Statistik auf Maximum, Zeitraum auf Letzte 2 Wochen und Intervall auf Tag fest.

    Anmerkung

    Wenn Sie die Werte für Statistik, Zeitraum und Intervall ändern, werden sie für alle Metriken geändert. Die aktualisierten Werte gelten für die restliche Sitzung oder bis Sie diese erneut ändern.

Sie können die Leistungsmetriken auch über die CLI oder API anzeigen. Weitere Informationen finden Sie unter Anzeigen von Metriken in der Amazon RDS-Konsole.

Einen CloudWatch-Alarm legen Sie wie folgt fest

  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich die Option Databases (Datenbanken) und anschließend eine DB-Instance.

  3. Wählen Sie Logs & Events (Protokolle und Ereignisse).

  4. Wählen Sie im Abschnitt CloudWatch alarms (CloudWatch-Alarme= die Option Create alarm (Alarm erstellen).

    
                            Dialogfeld „Create Alarm (Alarm erstellen)“
  5. Wählen Sie für Send notifications (Benachrichtigungen senden) Yes (Ja) und für Send notifications to (Benachrichtigungen senden an= New email or SMS topic (Neue E-Mail oder SMS Thema).

  6. Geben Sie unter Topic name (Themaname) einen Namen für die Benachrichtigung und unter With these recipients (Mit diesen Empfängern) eine kommagetrennte Liste von E-Mail-Adressen und Telefonnummern ein.

  7. Wählen Sie für Metric (Metrik) die einzustellende Alarmstatistik und Metrik.

  8. Geben Sie für Threshold (Schwellenwert) an, ob die Metrik größer, kleiner oder gleich dem Schwellenwert sein muss, und geben Sie den Schwellenwert an.

  9. Wählen Sie für Evaluation period (Evaluierungszeitraum) den Evaluierungszeitraum für den Alarm und für consecutive period(s) of (aufeinanderfolgende Periode(n) von) den Zeitraum, in dem der Schwellenwert erreicht worden sein muss, um den Alarm auszulösen.

  10. Geben Sie unter Alarmname einen aussagekräftigen Namen für Ihren Alarm ein.

  11. Wählen Sie Create Alarm aus.

Der Alarm erscheint im Abschnitt CloudWatch alarms (CloudWatch-Alarme).

Auswerten von Leistungsmetriken

Eine DB-Instance besitzt eine Reihe unterschiedlicher Kategorien von Metriken. Die Entscheidung, welche Werte akzeptabel sind, ist von der Metrik abhängig.

CPU

  • CPU-Nutzung – Prozentsatz der verwendeten Verarbeitungskapazität des Computers.

Arbeitsspeicher

  • Freisetzbarer Arbeitsspeicher – Größe des RAM, die in der DB-Instance verfügbar ist (in Megabytes). Die rote Linie in der Metrik der Registerkarte Monitoring (Überwachung) kennzeichnet 75 % für CPU-, Arbeitsspeicher- und Speichermetriken. Wenn der Speicherverbrauch der Instance diese Linie häufig überschreitet, bedeutet dies, dass Sie die Workload prüfen sollten oder die Instance aktualisieren müssen.

  • Swap-Nutzung – Größe des Auslagerungsbereichs, der in der DB-Instance verwendet wird (in Megabytes).

Festplattenkapazität

  • Freier Speicherplatz – Größe des Datenträgerbereichs, der zurzeit in der DB-Instance nicht verwendet wird (in Megabytes).

Eingabe-/Ausgabe-Operationen

  • Lese-IOPS, Schreib-IOPS – die durchschnittliche Anzahl der Lese- oder Schreib-Datenträgeroperationen pro Sekunde.

  • Leselatenz, Schreiblatenz – die durchschnittliche Zeit, die eine Lese- oder Schreiboperation benötigt (in Millisekunden).

  • Lesedurchsatz, Schreibdurchsatz – die durchschnittliche Anzahl der Megabytes, die pro Sekunde aus dem Datenträger gelesen oder zum Datenträger geschrieben werden.

  • Warteschlangentiefe – die Anzahl der E/A-Operationen, die darauf warten, zum Datenträger geschrieben oder aus dem Datenträger gelesen zu werden.

Netzwerkdatenverkehr

  • Netzwerkeingangsdurchsatz, Netzwerkübertragungsdurchsatz – die Rate des Netzwerkdatenverkehrs zur und von der DB-Instance (in Bytes pro Sekunde).

Datenbankverbindungen

  • Datenbankverbindungen – die Anzahl der Client-Sitzungen, die mit der DB-Instance verbunden sind.

Detailliertere einzelne Beschreibungen der verfügbaren Leistungsmetriken finden Sie unter Überwachen von Amazon RDS-Metriken mit Amazon CloudWatch.

Allgemein ausgedrückt, sind die zulässigen Werte für Leistungsmetriken davon abhängig, wie die Basisleistung aussieht und welche Aufgaben von Ihrer Anwendung ausgeführt werden. Prüfen Sie, ob dauerhafte oder tendenzielle Abweichungen von Ihrer Ausgangsbasis vorliegen. Im Folgenden finden Sie ein paar Hinweise zu bestimmten Metriken:

  • Hohe CPU- oder RAM-Nutzung – Hohe Werte für die CPU- oder RAM-Nutzung können angemessen sein, wenn sie der Zielsetzung Ihrer Anwendung entsprechen (z. B. in Bezug auf Durchsatz oder Gleichzeitigkeit) und erwartet werden.

  • Nutzung des Datenträgerplatzes – Überprüfen Sie die Nutzung des Datenträgerplatzes, wenn konsistent 85 Prozent oder mehr des gesamten Datenträgerplatzes belegt werden. Prüfen Sie, ob Daten in der Instance gelöscht oder auf einem anderen System archiviert werden können, um Speicherplatz freizugeben.

  • Netzwerkdatenverkehr – Wenden Sie sich an Ihren Systemadministrator, um zu erfahren, welcher Durchsatz für Ihr Domänennetzwerk und Ihre Internetverbindung erwartet wird. Überprüfen Sie den Netzwerkdatenverkehr, wenn der Durchsatz dauerhaft unter dem erwarteten Wert liegt.

  • Datenbankverbindungen – Ziehen Sie eine Einschränkung der Datenbankverbindungen in Betracht, wenn bei einer großen Anzahl von Benutzerverbindungen eine Abnahme der Instance-Leistung und der Reaktionszeit zu erkennen ist. Die optimale Anzahl der Benutzerverbindungen für Ihre DB-Instance ist von der Instance-Klasse und der Komplexität der Operationen abhängig, die ausgeführt werden. Sie können die Anzahl der Datenbankverbindungen festlegen, indem Sie ihre DB-Instance einer Parametergruppe zuordnen, für die der Parameter User Connections (Benutzerverbindungen) auf einen anderen Wert als 0 (unbegrenzt) festgelegt ist. Sie können eine entweder eine vorhandene Parametergruppe verwenden oder eine neue erstellen. Weitere Informationen finden Sie unter Arbeiten mit Parametergruppen.

  • IOPS-Metriken – Die erwarteten Werte für IOPS-Metriken sind von der Datenträgerspezifikation und der Serverkonfiguration abhängig. Verwenden Sie die Basiswerte als typische Werte. Prüfen Sie, ob dauerhafte Abweichungen von den Werten Ihrer Ausgangsbasis vorliegen. Sie erzielen eine optimale IOPS-Leistung, wenn Sie sicherstellen, dass die typischen zu verarbeitenden Datensätze komplett in den Arbeitsspeicher geladen werden können, sodass die Lese- und Schreibvorgänge auf ein Minimum beschränkt werden.

Bei Problemen mit Leistungsmetriken sollten Sie zunächst die am häufigsten verwendeten und kostspieligsten Abfragen anpassen, um festzustellen, ob dies den Druck auf die Systemressourcen verringert und die Leistung verbessert. Weitere Informationen finden Sie unter Optimieren von Abfragen.

Wenn Ihre Abfragen optimiert sind und dennoch ein Problem besteht, sollten Sie Ihre Amazon RDS-DB-Instance-Klassen auf eine Klasse aktualisieren, die in Bezug auf die Ressource, die mit dem Problem im Zusammenhang steht (CPU, RAM, Datenträgerplatz, Netzwerkbandbreite, E/A-Kapazität), mehr Kapazitäten bereitstellt.

Optimieren von Abfragen

Eine der besten Möglichkeiten zur Verbesserung der Leistung von DB-Instances besteht darin, die am häufigsten verwendeten und ressourcenintensivsten Abfragen so anzupassen, dass ihre Ausführung weniger aufwändig wird. Verwenden Sie die folgenden Ressourcen, um Informationen zur Verbesserung von Abfragen zu erhalten:

Best Practices für die Arbeit mit MySQL

Sowohl die Tabellengröße als auch die Anzahl der Tabellen in einer MySQL-Datenbank können die Leistung beeinträchtigen.

Tabellengröße

In der Regel bestimmen Betriebssystemeinschränkungen für Dateigrößen die effektive maximale Tabellengröße für MySQL-Datenbanken. Daher werden die Grenzwerte normalerweise nicht durch interne MySQL-Einschränkungen bestimmt.

Vermeiden Sie es in MySQL-DB-Instances, dass Tabellen in Ihrer Datenbank zu groß werden. Obwohl die allgemeine Speichergrenze 64 TiB beträgt, beschränken die Begrenzungen für den bereitgestellten Speicher die maximale Größe einer MySQL-Tabellendatei auf 16 TiB. Partitionieren Sie Ihre großen Tabellen so, dass die Dateigrößen deutlich unter der 16-TiB-Grenze liegen. Dieser Ansatz kann auch Leistung und Wiederherstellungszeit verbessern. Weitere Informationen finden Sie unter MySQL-Dateigrößenlimits in Amazon RDS.

Sehr große Tabellen (mehr als 100 GB) können sich negativ auf die Leistung sowohl bei Lese- als auch bei Schreibvorgängen auswirken (einschließlich DML-Anweisungen und insbesondere DDL-Anweisungen). Indizes für große Tabellen können die Select-Performance erheblich verbessern, sie können jedoch auch die Leistung von DML-Anweisungen beeinträchtigen. DDL-Anweisungen wie ALTER TABLE können für die großen Tabellen erheblich langsamer sein, da diese Vorgänge in einigen Fällen eine Tabelle vollständig neu aufbauen können. Diese DDL-Anweisungen könnten die Tabellen für die Dauer der Operation sperren.

Die Menge an Speicher, die MySQL für Lese- und Schreibvorgänge benötigt, hängt von den Tabellen ab, die an den Vorgängen beteiligt sind. Es ist eine bewährte Methode, mindestens genug RAM zu haben, um die Indizes aktiv genutzter Tabellen zu halten. Verwenden Sie die folgende Abfrage, um die zehn größten Tabellen und Indizes in einer Datenbank zu finden:

SELECT CONCAT(table_schema, '.', table_name), CONCAT(ROUND(table_rows / 1000000, 2), 'M') rows, CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G') DATA, CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G') idx, CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size, ROUND(index_length / data_length, 2) idxfrac FROM information_schema.TABLES ORDER BY data_length + index_length DESC LIMIT 10;

Anzahl der Tabellen

Während das zugrunde liegende Dateisystem möglicherweise eine Begrenzung für die Anzahl der Dateien hat, die Tabellen darstellen, hat MySQL keine Begrenzung für die Anzahl der Tabellen. Die Gesamtzahl der Tabellen in der MySQL InnoDB-Speicher-Engine kann jedoch unabhängig von der Größe dieser Tabellen zur Leistungseinbußen beitragen. Um die Auswirkungen auf das Betriebssystem zu begrenzen, können Sie die Tabellen auf mehrere Datenbanken in derselben MySQL-DB-Instance aufteilen. Dies könnte die Anzahl der Dateien in einem Verzeichnis begrenzen, löst jedoch nicht das Gesamtproblem.

Wenn es aufgrund einer großen Anzahl von Tabellen (mehr als 10 000) zu Leistungseinbußen kommt, wird dies dadurch verursacht, dass MySQL mit Speicherdateien arbeitet, sie öffnet und schließt. Um dieses Problem zu lösen, können Sie die Größe der Parameter table_open_cache und table_definition_cache erhöhen. Eine Erhöhung der Parameterwerte kann jedoch die Menge des von MySQL verwendeten Speichers erheblich erhöhen und kann sogar den gesamten verfügbaren Speicher verwenden. Weitere Informationen finden Sie unter How MySQL Opens and Closes Tables (Wie MySQL Tabellen öffnet und schließt) in der MySQL-Dokumentation.

Darüber hinaus können sich zu viele Tabellen erheblich auf die Startzeit von MySQL auswirken. Sowohl ein sauberes Herunterfahren als auch ein Neustart sowie eine Absturzwiederherstellung können insbesondere in Versionen vor MySQL 8.0 beeinträchtigt werden.

Wir empfehlen, insgesamt weniger als zehntausend Tabellen in allen Datenbanken einer DB-Instance zu haben. Informationen zu einem Anwendungsfall mit einer großen Anzahl von Tabellen in einer MySQL-Datenbank finden Sie unter One Million Tables in MySQL 8.0 (1 Million Tabellen in MySQL 8.0).

Speicher-Engine

Die Funktionen „Point-In-Time Restore“ und „Snapshot Restore“ von Amazon RDS für MySQL benötigen eine Speicher-Engine, das nach einem Absturz wiederhergestellt werden kann, und werden nur für die InnoDB-Speicher-Engine unterstützt. MySQL unterstützt zwar verschiedene Speichermodule mit unterschiedlichen Kapazitäten. Von diesen sind jedoch nicht alle für die Wiederherstellung nach einem Absturz und Datenbeständigkeit optimiert. Beispielsweise unterstützt das MyISAM-Speichermodul keine zuverlässige Wiederherstellung nach Abstürzen und verhindert möglicherweise, dass eine Point-In-Time- oder Snapshot-Wiederherstellung wie beabsichtigt funktioniert. Dies kann dazu führen, dass Daten verloren gehen oder beschädigt werden, wenn MySQL nach einem Absturz erneut gestartet wird.

InnoDB ist das empfohlene und unterstützte Speichermodul für MySQL-DB-Instances in Amazon RDS. InnoDB-Instances können auch zu Aurora migriert werden, während MyISAM-Instances nicht migriert werden können. MyISAM bietet jedoch eine bessere Leistung als InnoDB, wenn Sie intensive Volltextsuchfunktionen benötigen. Wenn Sie dennoch MyISAM mit Amazon RDS verwenden möchten, kann die Befolgung der unter Automatisierte Backups mit nicht unterstützten MySQL-Speicher-Engines beschriebenen Schritte in bestimmten Szenarien helfen, eine Snapshot-Wiederherstellungsfunktion zu erhalten.

Wenn Sie vorhandene MyISAM-Tabellen in InnoDB-Tabellen konvertieren möchten, können Sie den in der MySQL-Dokumentation beschriebenen Vorgang verwenden. MyISAM und InnoDB haben verschiedene Vor- und Nachteile. Daher sollten Sie die Auswirkungen vollständig auswerten, bevor Sie den Wechsel für Ihre Anwendungen ausführen.

Darüber hinaus wird die Federated Storage Engine aktuell von Amazon RDS für MySQL nicht unterstützt.

Best Practices für die Arbeit mit MariaDB

Sowohl Tabellengrößen als auch die Anzahl der Tabellen in einer MariaDB-Datenbank können sich auf die Performance auswirken.

Tabellengröße

In der Regel bestimmen Betriebssystemeinschränkungen für Dateigrößen die effektive maximale Tabellengröße für MariaDB-Datenbanken. Daher werden die Grenzwerte normalerweise nicht durch interne MariaDB-Einschränkungen festgelegt.

Vermeiden Sie es in MariaDB-Instances, dass Tabellen in Ihrer Datenbank zu groß werden. Obwohl die allgemeine Speichergrenze 64 TiB beträgt, beschränken die Begrenzungen für den bereitgestellten Speicher die maximale Größe einer MariaDB-Tabellendatei auf 16 TiB. Partitionieren Sie Ihre großen Tabellen so, dass die Dateigrößen deutlich unter der 16-TiB-Grenze liegen. Dieser Ansatz kann auch Leistung und Wiederherstellungszeit verbessern.

Sehr große Tabellen (mehr als 100 GB) können sich negativ auf die Leistung sowohl bei Lese- als auch bei Schreibvorgängen auswirken (einschließlich DML-Anweisungen und insbesondere DDL-Anweisungen). Indizes für große Tabellen können die Select-Performance erheblich verbessern, sie können jedoch auch die Leistung von DML-Anweisungen beeinträchtigen. DDL-Anweisungen wie ALTER TABLE können für die großen Tabellen erheblich langsamer sein, da diese Vorgänge in einigen Fällen eine Tabelle vollständig neu aufbauen können. Diese DDL-Anweisungen könnten die Tabellen für die Dauer der Operation sperren.

Die Menge an Speicher, die MariaDB für Lese- und Schreibvorgänge benötigt, hängt von den an den Operationen beteiligten Tabellen ab. Es ist eine bewährte Methode, mindestens genug RAM zu haben, um die Indizes aktiv genutzter Tabellen zu halten. Verwenden Sie die folgende Abfrage, um die zehn größten Tabellen und Indizes in einer Datenbank zu finden:

SELECT CONCAT(table_schema, '.', table_name), CONCAT(ROUND(table_rows / 1000000, 2), 'M') rows, CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G') DATA, CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G') idx, CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size, ROUND(index_length / data_length, 2) idxfrac FROM information_schema.TABLES ORDER BY data_length + index_length DESC LIMIT 10;

Anzahl der Tabellen

Während das zugrunde liegende Dateisystem möglicherweise eine Begrenzung für die Anzahl der Dateien hat, die Tabellen repräsentieren, hat MariaDB keine Begrenzung für die Anzahl der Tabellen. Die Gesamtzahl der Tabellen in der MariaDB InnoDB-Speicher-Engine kann jedoch unabhängig von der Größe dieser Tabellen zur Leistungseinbußen beitragen. Um die Auswirkungen auf das Betriebssystem zu begrenzen, können Sie die Tabellen auf mehrere Datenbanken in derselben MariaDB-Instance aufteilen. Dies könnte die Anzahl der Dateien in einem Verzeichnis begrenzen, löst jedoch nicht das Gesamtproblem.

Wenn es aufgrund einer großen Anzahl von Tabellen (mehr als 10 000) zu Leistungseinbußen kommt, wird dies dadurch verursacht, dass MariaDB mit Speicherdateien arbeitet, sie öffnet und schließt. Um dieses Problem zu lösen, können Sie die Größe der Parameter table_open_cache und table_definition_cache erhöhen. Eine Erhöhung der Werte dieser Parameter könnte jedoch die Menge des von MariaDB verwendeten Speichers erheblich erhöhen und kann sogar den gesamten verfügbaren Speicher verwenden. Weitere Informationen finden Sie unter Optimizing table_open_cache (table_open_cache optimieren) in der MariaDB-Dokumentation.

Darüber hinaus können zu viele Tabellen die Startzeit von MariaDB erheblich beeinflussen. Sowohl ein sauberes Herunterfahren und Neustart als auch eine Absturzwiederherstellung können beeinträchtigt werden. Wir empfehlen, insgesamt weniger als zehntausend Tabellen in allen Datenbanken einer DB-Instance zu haben.

Speicher-Engine

Für die zeitpunktbezogene und die Snapshot-Wiederherstellungsfunktion in Amazon RDS für MariaDB ist eine nach einem Absturz wiederherstellungsfähige Speicher-Engine notwendig. MariaDB unterstützt zwar mehrere Speicher-Engines mit unterschiedlichen Fähigkeiten und Kapazitäten, jedoch sind nicht alle von ihnen für die Wiederherstellung nach Ausfall und für Datenbeständigkeit optimiert. Zwar ist Aria ein absturzsicherer Ersatz für MyISAM, verhindert aber möglicherweise, dass eine zeitpunktbezogene oder eine Snapshot-Wiederherstellung wie beabsichtigt funktioniert. Dies kann dazu führen, dass Daten verloren gehen oder beschädigt werden, wenn MariaDB nach einem Absturz erneut gestartet wird. InnoDB ist das empfohlene und unterstützte Speichermodul für MariaDB-DB-Instances in Amazon RDS. Wenn Sie dennoch Aria mit Amazon RDS verwenden möchten, kann die Befolgung der unter Automatisierte Backups mit nicht unterstützten MariaDB-Speicher-Engines beschriebenen Schritte in bestimmten Szenarien helfen, eine Snapshot-Wiederherstellungsfunktion zu erhalten.

Wenn Sie vorhandene MyISAM-Tabellen in InnoDB-Tabellen konvertieren möchten, können Sie den in der MariaDB-Dokumentation beschriebenen Vorgang verwenden. MyISAM und InnoDB haben verschiedene Vor- und Nachteile. Daher sollten Sie die Auswirkungen vollständig auswerten, bevor Sie den Wechsel für Ihre Anwendungen ausführen.

Bewährte Methoden für die Arbeit mit Oracle

Informationen zu bewährten Methoden für die Arbeit mit Amazon RDS für Oracle finden Sie unter Bewährte Methoden für die Ausführung von Oracle-Datenbanken in Amazon Web Services.

Ein virtueller AWS-Workshop 2020 umfasste eine Präsentation über ausgeführte Oracle-Datenbanken in Amazon RDS. Das Video der Präsentation ist hier verfügbar:

Bewährte Methoden für die Arbeit mit PostgreSQL

Zwei wichtige Bereiche, in denen Sie die Leistung für PostgreSQL in Amazon RDS verbessern können, sind das Laden von Daten in eine DB-Instance und die Verwendung der PostgreSQL-Selbstbereinigungsfunktion. In den folgenden Abschnitten werden einige der empfohlenen Verfahren für diese Bereiche beschrieben.

Informationen darüber, wie andere häufige PostgreSQL-DBA-Aufgaben Amazon RDS implementiert werden, finden Sie unter Häufige DBA-Aufgaben für Amazon RDS for PostgreSQL.

Laden von Daten in eine PostgreSQL-DB-Instance

Beim Laden von Daten in eine Amazon RDS-PostgreSQL-DB-Instance sollten Sie Ihre DB-Instance-Einstellungen und Ihre DB-Parametergruppenwerte ändern, um die effizienteste Art zu unterstützen, Daten in Ihre DB-Instance zu laden.

Ändern Sie die Einstellungen für Ihre DB-Instance wie folgt:

  • Deaktivieren Sie die DB-Instance-Sicherungen (Sicherungsaufbewahrung auf 0 setzen).

  • Deaktivieren Sie Multi-AZ.

Modifizieren Sie die DB-Parametergruppe so, dass sie die folgenden Einstellungen enthält. Sie sollten die Parametereinstellungen testen, um die effizientesten Einstellungen für Ihre DB-Instance zu ermitteln:

  • Erhöhen Sie den Wert des Parameters maintenance_work_mem. Weitere Informationen zu PostgreSQL-Ressourcennutzungsparametern finden Sie in der PostgreSQL-Dokumentation.

  • Erhöhen Sie den Wert der Parameter max_wal_size und checkpoint_timeout, um die Zahl der Schreibvorgänge zum WAL-Protokoll zu reduzieren.

  • Parameter synchronous_commit deaktivieren.

  • Deaktivieren Sie den PostgreSQL-Selbstbereinigungsparameter.

  • Stellen Sie sicher, dass sämtliche Tabellen, die Sie importieren, protokolliert sind. In nicht protokollierten Tabellen gespeicherte Daten können bei einem Failover verloren gehen. Weitere Informationen finden Sie unter CREATE TABLE UNLOGGED.

Verwenden Sie den Befehl pg_dump -Fc (komprimiert) oder den Befehl pg_restore -j (parallel) mit diesen Einstellungen.

Nachdem der Ladevorgang abgeschlossen ist, setzen Sie Ihre DB-Instance und DB-Parameter auf ihre normalen Einstellungen zurück.

Arbeiten mit der PostgreSQL-Selbstbereinigungsfunktion

Die Selbstbereinigungsfunktion für PostgreSQL-Datenbanken ist eine Funktion, deren Verwendung nachdrücklich empfohlen wird, um die Integrität Ihrer PostgreSQL-DB-Instance zu wahren. Die Selbstbereinigung automatisiert die Ausführung der Befehle VACUUM und ANALYZE. Die Verwendung der Selbstbereinigung wird von PostgreSQL erfordert, nicht von Amazon RDS auferlegt, und ist von kritischer Bedeutung für eine gute Leistung. Die Funktion ist für alle neuen Amazon RDS-PostgreSQL-DB-Instances standardmäßig aktiviert. Die zugehörigen Konfigurationsparameter werden standardmäßig entsprechend festgelegt.

Ihr Datenbankadministrator muss diese Wartungsoperation kennen und verstehen. Die PostgreSQL-Dokumentation zu Autocauger finden Sie unter Der Autovacuum Daemon.

Die Selbstbereinigung ist keine „ressourcenlose“ Operation, sondern wird im Hintergrund ausgeführt und gibt Benutzeroperationen soweit möglich Vorrang. Bei Aktivierung prüft die Selbstbereinigung auf Tabellen mit einer großen Zahl von aktualisierten oder gelöschten Tupeln. Sie schützt darüber hinaus vor dem Verlust sehr alter Daten aufgrund von Transaktions-ID-Wraparounds. Weitere Informationen finden Sie unter Verhindern von Transaktions-ID-Wraparound-Fehlern.

Die Selbstbereinigung sollte nicht als Operation mit hohem Overhead betrachtet werden, die reduziert werden kann, um eine bessere Leistung zu erzielen. Im Gegenteil; die Leistung von Tabellen mit sehr häufigen Aktualisierungs- und Löschvorgängen wird mit der Zeit schnell abnehmen, wenn keine Selbstbereinigung ausgeführt wird.

Wichtig

Die fehlende Ausführung von Selbstbereinigungen kann dazu führen, dass letzten Endes eine Ausfallzeit erforderlich ist, um eine VACUUM-Operation auszuführen, die sehr viel größere Auswirkungen hat. Wenn eine Amazon RDS-PostgreSQL-DB-Instance aufgrund einer übermäßig konservativen Verwendung der Selbstbereinigung nicht verfügbar ist, fährt die PostgreSQL-Datenbank herunter, um sich zu schützen. An diesem Punkt muss Amazon RDS direkt in der DB-Instance eine vollständige Bereinigung im Einzelbenutzermodus ausführen, was zu einem Ausfall von mehreren Stunden führen kann. Daher wird nachdrücklich empfohlen, die Selbstbereinigung, die standardmäßig aktiviert ist, nicht zu deaktivieren.

Die Selbstbereinigungsparameter legen fest, wann und wie die harte Selbstbereinigung ausgeführt wird. Die Parameterautovacuum_vacuum_threshold und autovacuum_vacuum_scale_factor legen fest, wann die Selbstbereinigung ausgeführt wird. Die Parameter autovacuum_max_workers, autovacuum_nap_time, autovacuum_cost_limit und autovacuum_cost_delay legen fest, wie die harte Selbstbereinigung ausgeführt wird. Weitere Informationen zu Autovakuum, wann es ausgeführt wird und welche Parameter erforderlich sind, finden Sie unter Routine Vacuuming in der PostgreSQL-Dokumentation.

Die folgende Abfrage zeigt die Anzahl der „toten“ Tupel in einer Tabelle mit dem Namen table1:

PROMPT> select relname, n_dead_tup, last_vacuum, last_autovacuum from pg_catalog.pg_stat_all_tables where n_dead_tup > 0 and relname = 'table1';

Die Ergebnisse der Abfrage sehen ähnlich wie folgt aus:

relname | n_dead_tup | last_vacuum | last_autovacuum ---------+------------+-------------+----------------- tasks | 81430522 | | (1 row)

Amazon RDS für PostgreSQL Video zu bewährten Praktiken

Die AWS re:Invent-Konferenz 2020 beinhaltete eine Präsentation über neue Funktionen und bewährte Methoden für die Arbeit mit PostgreSQL bei Amazon RDS. Das Video der Präsentation ist hier verfügbar:

Bewährte Methoden für die Arbeit mit SQL Server

Zu den bewährten Methoden für eine Multi-AZ-Bereitstellung mit einer SQL Server-DB-Instance gehören:

  • Verwenden Sie Amazon RDS-DB-Ereignisse, um Failover zu überwachen. Beispielsweise können Sie per Textnachricht oder E-Mail benachrichtigt werden, wenn ein Failover für eine DB-Instance ausgeführt wird. Weitere Informationen über Amazon RDS-Ereignisse finden Sie unter Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen.

  • Wenn Ihre Anwendung DNS-Werte zwischenspeichert, legen Sie den Time-to-Live (TTL)-Wert auf weniger als 30 Sekunden fest. Diese TTL-Festlegung stellt eine bewährte Methode für den Fall dar, dass es einen Failover gibt, bei dem die IP-Adresse möglicherweise geändert wird. In diesem Fall wird der zwischengespeicherte Wert vielleicht nicht mehr verwendet.

  • Es wird empfohlen, die folgenden Modi nicht zu aktivieren, da sie die Transaktionsprotokollierung deaktivieren, die für Multi-AZ erforderlich ist:

    • Einfacher Wiederherstellungsmodus

    • Offlinemodus

    • Schreibgeschützter Modus

  • Führen Sie Tests durch, um zu ermitteln, wie lange Ihre DB-Instance für einen Failover-Vorgang benötigt. Die Failover-Zeit kann unterschiedlich sein, abhängig von der Datenbank, der Instance-Klasse und des Speichertyps, die oder den Sie verwenden. Sie sollten auch die Fähigkeit Ihrer Anwendung testen, bei einem Failover weiter ausgeführt zu werden.

  • Um die Failover-Zeit zu verkürzen, sollten Sie folgende Schritte ausführen:

    • Stellen Sie sicher, dass Sie Ihrem Workload ausreichend bereitgestellte IOPS zugeteilt haben. Ein unzureichender E/A kann zu längeren Failover-Zeiten führen. Die Datenbankwiederherstellung erfordert E/A.

    • Verwenden Sie kleinere Transaktionen. Die Datenbankwiederherstellung ist von Transaktionen abhängig. Wenn Sie daher große Transaktionen in mehrere kleinere Transaktionen aufteilen können, sollte die Failover-Zeit verkürzt werden.

  • Berücksichtigen Sie, dass es während eines Failovers zu erhöhten Latenzen kommt. Als Teil des Failover-Vorgangs repliziert Amazon RDS Ihre Daten automatisch zu einer neuen Standby-Instance. Diese Replikation bedeutet, dass neue Daten an zwei verschiedene DB-Instances übergeben werden. Daher kann es eine gewisse Latenz geben, bis die Standby-DB-Instance zur neuen primären DB-Instance aufgeschlossen hat.

  • Stellen Sie Ihre Anwendungen in allen Availability Zones bereit. Wenn eine Availability Zone ausfällt, sind die Anwendungen in den anderen Availability Zones weiterhin verfügbar.

Denken Sie bei der Arbeit mit einer Multi-AZ-Bereitstellung von SQL Server daran, dass Amazon RDS Replicas für alle SQL Server-Datenbanken auf Ihrer Instance erstellt. Wenn Sie nicht möchten, dass bestimmte Datenbanken sekundäre Replicas aufweisen, richten Sie eine separate DB-Instance ein, die für diese Datenbanken keine Multi-AZ verwendet.

Video zu bewährten Methoden für Amazon RDS für SQL Server

Die AWS re:Invent-Konferenz 2019 umfasste eine Präsentation zu neuen Funktionen und bewährten Methoden für die Arbeit mit SQL Server auf Amazon RDS. Das Video der Präsentation ist hier verfügbar:

Arbeiten mit DB-Parametergruppen

Es wird empfohlen, DB-Parametergruppenänderungen stets zuerst in einer Test-DB-Instance durchzuführen, bevor Sie diese Parametergruppenänderungen auf Ihre Produktions-DB-Instances anwenden. Wenn die DB-Modulparameter in einer DB-Parametergruppe falsch festgelegt werden, kann dies unbeabsichtigte nachteilige Auswirkungen haben, einschließlich verminderter Leistung und Systeminstabilität. Gehen Sie stets vorsichtig vor, wenn Sie DB-Modulparameter ändern, und sichern Sie Ihre DB-Instance, bevor Sie eine DB-Parametergruppe ändern.

Informationen zum Sichern Ihrer DB-Instance finden Sie unter Sichern und Wiederherstellen einer Amazon-RDS-DB-Instance.

Bewährte Methoden zur Automatisierung der DB-Instance-Erstellung

Es ist eine bewährte Methode für Amazon RDS, eine DB-Instance mit der bevorzugten Nebenversion des Datenbankmoduls zu erstellen. Sie können die AWS CLI-, Amazon-RDS-API verwenden oder AWS CloudFormation, um die Erstellung einer DB-Instance zu automatisieren. Wenn Sie diese Methoden verwenden, können Sie nur die Hauptversion angeben und Amazon RDS erstellt die Instance mit der bevorzugten Nebenversion automatisch. ..Wenn zum Beispiel PostgreSQL 12.5 die bevorzugte Nebenversion ist und Sie Version 12 mit create-db-instance angeben, wird die DB-Instanz Version 12.5 sein.

Um die bevorzugte Nebenversion zu ermitteln, können Sie den Befehl describe-db-engine-versions mit der Option --default-only ausführen; siehe folgendes Beispiel.

aws rds describe-db-engine-versions --default-only --engine postgres { "DBEngineVersions": [ { "Engine": "postgres", "EngineVersion": "12.5", "DBParameterGroupFamily": "postgres12", "DBEngineDescription": "PostgreSQL", "DBEngineVersionDescription": "PostgreSQL 12.5-R1", ...some output truncated... } ] }

Informationen zum programmgesteuerten Erstellen von DB-Instanzen finden Sie in den folgenden Ressourcen:

Präsentationsvideo zu den neuen Funktionen und bewährten Methoden in Amazon RDS

Die AWS re:Invent-Konferenz 2019 umfasste eine Präsentation zu neuen Amazon RDS-Funktionen und bewährten Methoden für die Überwachung, Analyse und Optimierung der Datenbankleistung unter Verwendung von RDS. Das Video der Präsentation ist hier verfügbar: