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 Verwenden der Amazon RDS-Empfehlungen.

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:

  • Sie können die Nutzung von Arbeitsspeicher, CPU und Speicher ü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 Ihre Datenbankarbeitslast 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 DB-Instance-Metriken.

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 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 eine typische Arbeitslast 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.

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 (Überwachung). 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 DB-Instance-Metriken.

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 Megabytes 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 Überwachung 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 DB-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.

Optimieren von MySQL-Abfragen

Weitere Informationen dazu, wie Sie Abfragen im Hinblick auf eine bessere Leistung schreiben, finden Sie unter Optimizing SELECT statements in der MySQL-Dokumentation. Zusätzliche Ressourcen für die Optimierung von Abfragen finden Sie unter Optimierung der MySQL-Leistung und Optimierungsressourcen.

Optimieren von Oracle-Abfragen

Weitere Informationen dazu, wie Sie Abfragen im Hinblick auf eine bessere Leistung schreiben und analysieren, finden Sie im Handbuch für die Optimierung von Datenbank-SQL in der Oracle-Dokumentation.

Optimieren von SQL Server-Abfragen

Informationen zur Verbesserung von Abfragen für SQL Server-DB-Instances finden Sie unter Analysieren einer Abfrage in der SQL Server-Dokumentation. Sie können auch die Ausführungs-, Index- und E/A-Datenverwaltungsansichten (DMVs) verwenden, die in der Dokumentation Dynamische Verwaltungssichten und Funktionen beschrieben werden, um Probleme mit SQL Server-Abfragen zu beheben.

Ein häufiger Aspekt beim Optimieren von Abfragen stellt die Erstellung effektiver Indizes dar. Sie können den Datenbankoptimierungsratgeber verwenden, um potenzielle Indexverbesserungen für Ihre DB-Instance zu ermitteln. Weitere Informationen finden Sie unter Analyse Ihres Datenbank-Workloads in einer Amazon RDS-DB-Instance mit dem SQL Server-Optimierungshelfer.

Optimieren von PostgreSQL-Abfragen

Informationen dazu, wie Sie einen Abfrageplan analysieren, finden Sie unter Using EXPLAIN in der PostgreSQL-Dokumentation. Sie können diese Informationen verwenden, um eine Abfrage oder zugrundeliegende Tabellen zu ändern, um die Abfrageleistung zu verbessern. In Kontrolle des Planers mit expliziten JOIN-Klauseln finden Sie Tipps dazu, wie Sie Joins im Hinblick auf eine optimale Leistung in Ihrer Abfrage angeben.

Optimieren von MariaDB-Abfragen

Unter Query Optimizations in der MariaDB-Dokumentation finden Sie weitere Informationen zum Schreiben von Abfragen im Hinblick auf eine bessere Leistung.

Bewährte Methoden für das Arbeiten mit MySQL-Speichermodulen

In einer MySQL-DB-Instance sollten Sie die folgenden Grenzen für die Tabellenerstellung beachten:

  • Sie sind auf 10.000 Tabellen beschränkt, wenn Sie Speicher mit bereitgestellten IOPS oder Speicher für allgemeine Zwecke verwenden und die Größe der DB-Instance mindestens 200 GiB beträgt.

  • Sie sind auf 1000 Tabellen beschränkt, wenn Sie magnetischen Speicher oder Speicher für allgemeine Zwecke verwenden und die Größe der DB-Instance weniger als 200 GiB beträgt.

Diese Grenzen werden empfohlen, da eine große Zahl von Tabellen die Wiederherstellungszeit für eine Datenbank nach einem Failover oder einem Datenbankabsturz deutlich verlängert. Wenn Sie mehr Tabellen als empfohlen erstellen müssen, legen Sie den Parameter innodb_file_per_table auf 0 fest. Weitere Informationen finden Sie unter Arbeiten mit InnoDB-Tablespaces zur Verbesserung der Wiederherstellungszeiten nach Abstürzen und Arbeiten mit DB-Parametergruppen.

Im Fall von MySQL-DB-Instances, die Version 5.7 oder höher verwenden, können Sie diese Grenzen für die Tabellenerstellung aufgrund von Verbesserungen für die InnoDB-Absturzwiederherstellung überschreiten. Es wird jedoch dennoch empfohlen, aufgrund der möglichen Auswirkungen auf die Leistung, die die Erstellung einer sehr großen Zahl von Tabellen haben kann, vorsichtig vorzugehen.

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.

Die Funktionen „Point-In-Time Restore“ und „Snapshot Restore“ von Amazon RDS for MySQL benötigen ein Speichermodul, das nach einem Absturz wiederhergestellt werden kann, und werden nur für das InnoDB-Speichermodul 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.

Bewährte Methoden für das Arbeiten mit MariaDB-Speichermodulen

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. Für MariaDB-DB-Instances in Amazon RDS werden InnoDB (für Version 10.2 und höher) und XtraDB (für Version 10.0 und 10.1) als Speicher-Engines empfohlen und unterstützt. Wenn Sie dennoch Aria mit Amazon RDS verwenden möchten, kann die Befolgung der unter Automatisierte Sicherungen mit nicht unterstützten MariaDB-Speicher-Engines beschriebenen Schritte in bestimmten Szenarien helfen, eine Snapshot-Wiederherstellungsfunktion zu erhalten.

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.

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 checkpoint_segments und checkpoint_timeout, um die Zahl der Schreibvorgänge zum WAL-Protokoll zu reduzieren.

  • Deaktivieren Sie den Parameter synchronous_commit (deaktivieren Sie nicht FSYNC.)

  • 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 zur Selbstbereinigungsfunktion finden Sie unter Routinemäßige Reinigung.

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 Parameter autovacuum_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 zur Selbstbereinigung, wann sie ausgeführt wird und welche Parameter erforderlich sind, finden Sie in der PostgreSQL-Dokumentation.

Die folgende Abfrage zeigt die Anzahl der „toten“ Tupeln in einer Tabelle namens 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)

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 Verwenden von 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 Ihrer Arbeitslast 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 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.

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: