Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Methoden für Amazon RDS

Erfahren Sie mehr über bewährte Methoden für die Zusammenarbeit mit AmazonRDS. Dieser Abschnitt wird mit neuen bewährten Methoden aktualisiert, sobald diese bekannt sind.

RDSGrundlegende Betriebsrichtlinien von Amazon

Im Folgenden finden Sie grundlegende betriebliche Richtlinien, die jeder bei der Zusammenarbeit mit Amazon befolgen sollteRDS. Beachten Sie, dass das Amazon RDS Service Level Agreement vorschreibt, dass Sie die folgenden Richtlinien befolgen:

Empfehlungen für DB-Instances RAM

Eine bewährte Methode von Amazon für die RDS Leistung besteht darin, RAM so viel zuzuweisen, dass sich Ihr Arbeitssatz fast 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 IOPS Read-Metrik (mit Amazon CloudWatch), während die DB-Instance geladen ist. Der Wert von Read IOPS sollte klein und stabil sein. In einigen Fällen RAM führt die Skalierung der DB-Instance-Klasse auf eine Klasse mit mehr Werten zu einem dramatischen Rückgang von ReadIOPS. In diesen Fällen war Ihr Arbeitssatz nicht fast vollständig im Speicher. Fahren Sie mit der Skalierung fort, bis der Lesevorgang nach einem Skalierungsvorgang nicht IOPS mehr dramatisch abnimmt oder der IOPS Lesevorgang auf einen sehr geringen Wert reduziert wird. Informationen zur Überwachung der Metriken einer DB-Instance finden Sie unter Metriken in der RDS Amazon-Konsole anzeigen.

AWS Datenbanktreiber

Wir empfehlen die AWS Treibersuite für Anwendungskonnektivität. Die Treiber wurden so konzipiert, dass sie schnellere Switchover- und Failover-Zeiten sowie Authentifizierung mit unterstützen AWS Secrets Manager, AWS Identity and Access Management (IAM) und Federated Identity. Das Tool AWS Treiber verlassen sich auf die Überwachung des DB-Instance-Status und die Kenntnis der Instance-Topologie, um den neuen Writer zu ermitteln. Dieser Ansatz reduziert die Switchover- und Failover-Zeiten auf einstellige Sekunden, im Vergleich zu mehreren zehn Sekunden bei Open-Source-Treibern.

Mit der Einführung neuer Servicefunktionen ist das Ziel der AWS Die Treibersuite soll über eine integrierte Unterstützung für diese Servicefunktionen verfügen.

Weitere Informationen finden Sie unter Mit den AWS Treibern eine Verbindung zu DB-Instances herstellen.

Verwendung von „Enhanced Monitoring“ (Erweiterte Überwachung) zur Identifizierung von Betriebssystemproblemen

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

Verwendung von Metriken zur Identifizierung von Problemen mit der Leistung

Um Leistungsprobleme zu identifizieren, die durch unzureichende Ressourcen und andere häufige Engpässe verursacht werden, können Sie die für Ihre Amazon RDS DB-Instance verfügbaren Metriken überwachen.

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 CloudWatch Amazon-Alarme auch für bestimmte Metrik-Schwellenwerte einrichten, sodass Sie benachrichtigt werden, wenn diese erreicht werden.

Um Probleme mit der Leistung zu beheben, müssen Sie die Basisleistung des Systems kennen. Wenn Sie eine DB-Instance einrichten und mit einer typischen Workload ausführen, erfassen Sie die Durchschnitts-, Maximal- und Minimalwerte aller Leistungsmetriken. Führen Sie diesen Vorgang in verschiedenen Intervallen aus (z. B. eine Stunde, 24 Stunden, eine Woche, zwei Wochen). Auf diese Weise erhalten Sie eine Vorstellung davon, 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.

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

Sie können die kombinierten Performance Insights und CloudWatch Metriken im Performance Insights Insights-Dashboard einsehen und Ihre DB-Instance überwachen. Performance Insights muss für Ihre DB-Instance aktiviert sein, damit diese Ansicht verwendet werden kann. Weitere Informationen zu dieser Überwachungsansicht finden Sie unter Kombinierte Metriken mit dem Performance Insights Insights-Dashboard anzeigen.

Sie können einen Leistungsanalysebericht für einen bestimmten Zeitraum erstellen und sich die ermittelten Erkenntnisse und Empfehlungen zur Lösung der Probleme ansehen. Weitere Informationen finden Sie unter Erstellen eines Leistungsanalyseberichts in Performance Insights.

Sie können Leistungskennzahlen auch mit dem CLI oder anzeigenAPI. Weitere Informationen finden Sie unter Metriken in der RDS Amazon-Konsole anzeigen.

Der Alarm wird im Bereich CloudWatch Alarme angezeigt.

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.

Detailliertere einzelne Beschreibungen der verfügbaren Leistungsmetriken finden Sie unter Überwachung von Amazon RDS Amazon 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:

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

Wenn Ihre Abfragen optimiert sind und ein Problem weiterhin besteht, sollten Sie ein Upgrade Ihres RDS Amazon-Kontos in Betracht ziehen. Sie könnten ein Upgrade auf eine Version durchführen, die mehr Ressourcen (CPU,, FestplattenspeicherRAM, Netzwerkbandbreite, I/O-Kapazität) enthält, die mit dem Problem zusammenhängen.

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 zu optimieren. Hier optimieren Sie sie, damit sie kostengünstiger ausgeführt werden können. Verwenden Sie die folgenden Ressourcen, um Informationen zur Verbesserung von Abfragen zu erhalten:

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

Sowohl die Tabellengröße als auch die Anzahl der Tabellen in einer Meine SQL Datenbank können sich auf die Leistung auswirken.

Tabellengröße

In der Regel bestimmen Betriebssystembeschränkungen in Bezug auf Dateigrößen die effektive maximale Tabellengröße für Meine SQL Datenbanken. Daher werden die Grenzwerte normalerweise nicht durch interne SQL Einschränkungen von My bestimmt.

Vermeiden Sie auf einer My SQL DB-Instance, dass die Tabellen in Ihrer Datenbank zu groß werden. Obwohl das allgemeine Speicherlimit 64 TiB beträgt, beschränken bereitgestellte Speicherlimits die maximale Größe einer Meine SQL 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 Meine SQL Dateigrößenbeschränkungen bei Amazon RDS.

Sehr große Tabellen (größer als 100 GB) können sich negativ auf die Leistung sowohl beim Lesen als auch beim Schreiben auswirken (einschließlich DML Anweisungen und insbesondere DDL Anweisungen). Indizes für große Tabellen können die Leistung bestimmter Tabellen erheblich verbessern, sie können jedoch auch die Leistung von Anweisungen beeinträchtigen. DML DDLAnweisungen, wie z. B.ALTER TABLE, können bei großen Tabellen erheblich langsamer sein, da diese Operationen in einigen Fällen eine Tabelle vollständig neu erstellen können. Diese DDL Anweisungen können die Tabellen für die Dauer des Vorgangs sperren.

Wie viel Speicher My SQL für Lese- und Schreibvorgänge benötigt, hängt von den Tabellen ab, die an den Vorgängen beteiligt sind. Es hat sich bewährt, mindestens so viel zur Verfügung RAM zu haben, dass die Indizes der aktiv verwendeten Tabellen gespeichert werden können. Verwenden Sie die folgende Abfrage, um die zehn größten Tabellen und Indizes in einer Datenbank zu finden:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Anzahl der Tabellen

Das zugrunde liegende Dateisystem hat möglicherweise eine Begrenzung für die Anzahl der Dateien, die Tabellen darstellen. My SQL hat jedoch keine Begrenzung der Anzahl der Tabellen. Trotzdem kann die Gesamtzahl der Tabellen in der My SQL InnoDB-Speicher-Engine zur Leistungsverschlechterung beitragen, unabhängig von der Größe dieser Tabellen. Um die Auswirkungen auf das Betriebssystem zu begrenzen, können Sie die Tabellen auf mehrere Datenbanken in derselben My SQL 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, liegt dies daran, dass ich mit Speicherdateien SQL arbeite, einschließlich deren Öffnen und Schließen. Um dieses Problem zu lösen, können Sie die Größe der Parameter table_open_cache und table_definition_cache erhöhen. Wenn Sie jedoch die Werte dieser Parameter erhöhen, kann sich die Menge des von My SQL verwendeten Speichers erheblich erhöhen, und möglicherweise wird sogar der gesamte verfügbare Speicher beansprucht. Weitere Informationen finden Sie unter So SQL öffnet und schließt My Tables in der SQL Dokumentation Meine.

Darüber hinaus können zu viele Tabellen die SQL Startzeit von My Startup erheblich beeinflussen. Sowohl ein fehlerfreies Herunterfahren und Neustarten als auch eine Wiederherstellung nach einem Absturz können beeinträchtigt werden, insbesondere in Versionen vor My SQL 8.0.

Wir empfehlen, insgesamt weniger als 10 000 Tabellen in allen Datenbanken einer DB-Instance zu speichern. Einen Anwendungsfall mit einer großen Anzahl von Tabellen in einer Datenbank vom Typ Meine SQL Datenbank finden Sie unter One Million Tables in My SQL 8.0.

Speicher-Engine

Die point-in-time Wiederherstellungs- und Snapshot-Wiederherstellungsfunktionen von Amazon RDS for My SQL erfordern eine Speicher-Engine, die nach einem Absturz wiederhergestellt werden kann. Diese Funktionen werden nur für die InnoDB-Speicher-Engine unterstützt. My SQL unterstützt zwar mehrere Speicher-Engines mit unterschiedlichen Funktionen, aber nicht alle sind für die Wiederherstellung nach einem Absturz und die Haltbarkeit von Daten optimiert. Die ISAM Speicher-Engine My unterstützt beispielsweise keine zuverlässige Wiederherstellung nach einem Absturz und kann verhindern, dass eine point-in-time Wiederherstellung oder Snapshot-Wiederherstellung wie vorgesehen funktioniert. Dies kann dazu führen, dass Daten verloren gehen oder beschädigt werden, wenn My nach einem Absturz neu gestartet SQL wird.

InnoDB ist die empfohlene und unterstützte Speicher-Engine für My SQL DB-Instances bei AmazonRDS. InnoDB-Instances können auch zu Aurora migriert werden, während Meine ISAM Instances nicht migriert werden können. My ISAM schneidet jedoch besser ab als InnoDB, wenn Sie eine intensive Volltextsuche benötigen. Wenn Sie My immer noch ISAM mit Amazon verwendenRDS, Automatisierte Backups mit nicht unterstützten My SQL Storage Engines kann es in bestimmten Szenarien für die Snapshot-Wiederherstellung hilfreich sein, die unter beschriebenen Schritte zu befolgen.

Wenn Sie bestehende ISAM My-Tabellen in InnoDB-Tabellen konvertieren möchten, können Sie den in der Dokumentation Meine Tabellen von My ISAM nach InnoDB konvertieren beschriebenen Prozess verwenden. SQL My ISAM und InnoDB haben unterschiedliche Stärken und Schwächen, daher sollten Sie die Auswirkungen dieser Umstellung auf Ihre Anwendungen vollständig abwägen, bevor Sie dies tun.

Darüber hinaus wird Federated Storage Engine derzeit nicht von Amazon RDS for My SQL 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 (größer als 100 GB) können sich negativ auf die Leistung sowohl beim Lesen als auch beim Schreiben auswirken (einschließlich DML Anweisungen und insbesondere DDL Anweisungen). Indizes für große Tabellen können die Leistung bestimmter Tabellen erheblich verbessern, sie können jedoch auch die Leistung von Anweisungen beeinträchtigen. DML DDLAnweisungen, wie z. B.ALTER TABLE, können bei großen Tabellen erheblich langsamer sein, da diese Operationen in einigen Fällen eine Tabelle vollständig neu erstellen können. Diese DDL Anweisungen können die Tabellen für die Dauer des Vorgangs 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 hat sich bewährt, mindestens genug zu habenRAM, um die Indizes der aktiv verwendeten Tabellen zu speichern. Verwenden Sie die folgende Abfrage, um die zehn größten Tabellen und Indizes in einer Datenbank zu finden:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Anzahl der Tabellen

Das zugrunde liegende Dateisystem hat möglicherweise eine Begrenzung für die Anzahl der Dateien, die Tabellen darstellen. MariaDB hat jedoch keine Begrenzung für die Anzahl der Tabellen. Trotzdem kann die Gesamtzahl der Tabellen in der InnoDB-Speicher-Engine von MariaDB unabhängig von der Größe dieser Tabellen zu 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. Diese Arbeit umfasst das Öffnen und Schließen von Speicherdateien durch MariaDB. 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. Es könnte sogar der gesamte verfügbare Speicher belegt werden. 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

Die point-in-time Wiederherstellungs- und Snapshot-Wiederherstellungsfunktionen von Amazon RDS für MariaDB erfordern eine Speicher-Engine, die nach einem Absturz wiederhergestellt werden kann. 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. Aria ist zwar ein absturzsicherer Ersatz für My, kann aber dennoch verhindernISAM, dass eine Wiederherstellung oder Snapshot-Wiederherstellung wie vorgesehen funktioniert. point-in-time Dies kann dazu führen, dass Daten verloren gehen oder beschädigt werden, wenn MariaDB nach einem Absturz erneut gestartet wird. InnoDB ist die empfohlene und unterstützte Speicher-Engine für MariaDB-DB-Instances auf Amazon. RDS Wenn Sie sich dennoch dafür entscheiden, Aria mit Amazon zu verwendenRDS, Automatisierte Backups mit nicht unterstützten MariaDB-Speicher-Engines kann das Befolgen der unter beschriebenen Schritte in bestimmten Szenarien für die Snapshot-Wiederherstellung hilfreich sein.

Wenn Sie bestehende ISAM My-Tabellen in InnoDB-Tabellen konvertieren möchten, können Sie den in Converting Tables from My ISAM to InnoDB beschriebenen Prozess in der MariaDB-Dokumentation verwenden. My ISAM und InnoDB haben unterschiedliche Stärken und Schwächen, daher sollten Sie die Auswirkungen dieser Umstellung auf Ihre Anwendungen vollständig abwägen, bevor Sie dies tun.

Bewährte Methoden für die Arbeit mit Oracle

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

EIN JAHR 2020 AWS Der virtuelle Workshop beinhaltete eine Präsentation über den Betrieb von Oracle-Produktionsdatenbanken auf AmazonRDS. Das Video der Präsentation ist hier verfügbar:

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

Einer von zwei wichtigen Bereichen, in denen Sie die Leistung von Postgre verbessern könnenSQL, ist das Laden von Daten in eine DB-Instance. RDS Ein weiterer Grund ist die Verwendung der SQL Postgre-Autovakuumfunktion. In den folgenden Abschnitten werden einige der empfohlenen Verfahren für diese Bereiche beschrieben.

Informationen darüber, wie Amazon andere gängige SQL DBA Postgre-Aufgaben RDS implementiert, finden Sie unterHäufige DBA-Aufgaben für Amazon RDS for PostgreSQL.

Daten in eine Postgre-DB-Instance laden SQL

Wenn Sie Daten in eine Amazon RDS for SQL Postgre-DB-Instance laden, ändern Sie Ihre DB-Instance-Einstellungen und Ihre DB-Parametergruppenwerte. Legen Sie diese fest, um den effizientesten Import von Daten in Ihre DB-Instance zu ermöglichen.

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

Modifizieren Sie die DB-Parametergruppe so, dass sie die folgenden Einstellungen enthält. Testen Sie außerdem die Parametereinstellungen, um die effizientesten Einstellungen für Ihre DB-Instance zu ermitteln.

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 SQL Postgre-Autovakuumfunktion

Wir empfehlen Ihnen dringend, die Autovacuum-Funktion für SQL Postgre-Datenbanken zu verwenden, um die Integrität Ihrer Postgre-DB-Instance aufrechtzuerhalten. SQL Autovacuum automatisiert die Ausführung des ANALYZE Befehls VACUUM und Die Verwendung von Autovacuum ist von Postgre vorgeschriebenSQL, nicht von Amazon vorgeschriebenRDS, und ihre Verwendung ist entscheidend für eine gute Leistung. Die Funktion ist standardmäßig für alle neuen Amazon RDS for SQL Postgre-DB-Instances aktiviert, und die zugehörigen Konfigurationsparameter sind standardmäßig entsprechend festgelegt.

Ihr Datenbankadministrator muss diese Wartungsoperation kennen und verstehen. Die SQL Postgre-Dokumentation zu Autovacuum finden Sie unter The 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.

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 Autovacuum, wann es ausgeführt wird und welche Parameter erforderlich sind, finden Sie in der Postgre-Dokumentation unter Routine-Vacuuming. SQL

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

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) 

Video mit SQL bewährten Methoden von Amazon RDS für Postgre

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

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

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

Denken Sie bei der Arbeit mit einer Multi-AZ-Bereitstellung von SQL Server daran, dass Amazon Replikate für alle SQL Server-Datenbanken auf Ihrer Instance RDS 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 mit bewährten Methoden RDS für Amazon for SQL Server

Das Jahr 2019 AWS Die re:Invent-Konferenz beinhaltete eine Präsentation über neue Funktionen und bewährte 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 Daten sichern, wiederherstellen und exportieren.

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

Es ist eine RDS bewährte Methode von Amazon, eine DB-Instance mit der bevorzugten Nebenversion der Datenbank-Engine zu erstellen. Sie können das AWS CLI RDSAPI, Amazon oder AWS CloudFormation um die Erstellung von DB-Instances zu automatisieren. Wenn Sie diese Methoden verwenden, können Sie nur die Hauptversion angeben und Amazon erstellt RDS automatisch die Instance mit der bevorzugten Nebenversion. Wenn beispielsweise Postgre SQL 12.5 die bevorzugte Nebenversion ist und Sie Version 12 mit angebencreate-db-instance, wird die DB-Instance 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:

Video zu den RDS neuen Funktionen von Amazon

Das Jahr 2023 AWS Die re:Invent-Konferenz beinhaltete eine Präsentation über neue RDS Amazon-Funktionen. Das Video der Präsentation ist hier verfügbar: