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. # Verwenden von Amazon Aurora PostgreSQL Limitless Database Amazon Aurora PostgreSQL Limitless Database bietet automatisierte horizontale Skalierung zur Verarbeitung von Millionen von Schreibtransaktionen pro Sekunde, und verwaltet Petabyte an Daten. Gleichzeitig bleibt die Einfachheit des Betriebs in einer einzigen Datenbank erhalten. Mit Aurora PostgreSQL Limitless Database können Sie sich auf die Entwicklung umfangreicher Anwendungen konzentrieren, ohne zur Unterstützung Ihrer Workloads komplexe Lösungen für die Skalierung Ihrer Daten über mehrere DB-Instances hinweg erstellen und instandhalten zu müssen. **Topics** + [ # Die Architektur von Aurora PostgreSQL Limitless Database ](limitless-architecture.md) + [ # Erste Schritte mit Aurora PostgreSQL Limitless Database ](limitless-getting-started.md) + [ # Voraussetzungen und Überlegungen zu Aurora PostgreSQL Limitless Database ](limitless-reqs-limits.md) + [ # Voraussetzungen für die Verwendung von Aurora PostgreSQL Limitless Database ](limitless-prereqs.md) + [ # Erstellen eines DB-Clusters, der Aurora PostgreSQL Limitless Database verwendet ](limitless-cluster.md) + [ # Arbeiten mit DB-Shard-Gruppen ](limitless-shard.md) + [ # Erstellen von Tabellen in Aurora PostgreSQL Limitless Database ](limitless-creating.md) + [ # Laden von Daten in Aurora PostgreSQL Limitless Database ](limitless-load.md) + [ # Abfragen einer Aurora PostgreSQL Limitless Database ](limitless-query.md) + [ # Verwalten einer Aurora PostgreSQL Limitless Database ](limitless-managing.md) + [ # Überwachen einer Aurora PostgreSQL Limitless Database ](limitless-monitoring.md) + [ # Instanzspezifische Leistungs- und Ressourcenüberwachung ](limitless-instance-monitoring.md) + [ # Sichern und Wiederherstellen von Aurora PostgreSQL Limitless Database ](limitless-bak.md) + [ # Aktualisieren von Amazon Aurora PostgreSQL Limitless Database ](limitless-upg.md) + [ # Referenz zu Aurora PostgreSQL Limitless Database ](limitless-reference.md) # Die Architektur von Aurora PostgreSQL Limitless Database Limitless Database verdankt ihre Skalierbarkeit einer zweischichtigen Architektur, die aus mehreren Datenbankknoten besteht. Knoten sind entweder Router oder Shards. + Shards sind DB-Instances von Aurora PostgreSQL, die jeweils eine Teilmenge der Daten für Ihre Datenbank speichern und so eine gleichzeitige Verarbeitung ermöglichen, um einen höheren Schreibdurchsatz zu erzielen. + Router verwalten die verteilte Struktur der Datenbank und liefern Datenbank-Clients das Bild einer zentralen Datenbank. Router verwalten Metadaten darüber, wo Daten gespeichert sind, analysieren eingehende SQL-Befehle und senden diese Befehle an Shards. Anschließend aggregieren sie Daten aus Shards, um ein einziges Ergebnis an den Client zurückzugeben, und verwalten verteilte Transaktionen, um für Einheitlichkeit in der gesamten verteilten Datenbank zu sorgen. Aurora PostgreSQL Limitless Database unterscheidet sich von [Aurora-DB-Cluster](Aurora.Overview.md) (Standard) dadurch, dass sie anstelle einer Writer-DB-Instance und von Reader-DB-Instances über eine DB-Shard-Gruppe verfügt. Alle Knoten, aus denen Ihre Limitless-Database-Architektur besteht, sind in der DB-Shard-Gruppe enthalten. Die einzelnen Shards und Router in der DB-Shard-Gruppe sind in Ihrem AWS-Konto nicht sichtbar. Sie verwenden den DB-Cluster-Endpunkt, um auf Limitless Database zuzugreifen. Die folgende Abbildung zeigt die High-Level-Architektur von Aurora PostgreSQL Limitless Database. ![\[High-Level-Architektur von Aurora PostgreSQL Limitless Database mit primärem Cluster, Shard-Gruppen und Datenverteilung.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/limitless_high_level_arch_GA.png) Weitere Informationen zur Architektur von Aurora PostgreSQL Limitless Database und zu deren Verwendung finden Sie in diesem Video des AWS-Event-Kanals auf YouTube: [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/pUqVCK7Ggh0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/pUqVCK7Ggh0) Weitere Informationen zur Architektur eines standardmäßigen Aurora-DB-Clusters finden Sie unter [Amazon-Aurora-DB-Cluster](Aurora.Overview.md). ## Wichtige Begriffe zu Aurora PostgreSQL Limitless Database **DB-Shard-Gruppe** Ein Container für Limitless-Database-Knoten (Shards und Router). **Router** Ein Knoten, der SQL-Verbindungen von Clients akzeptiert, SQL-Befehle an Shards sendet, für systemweite Einheitlichkeit sorgt und Ergebnisse an Clients zurückgibt. **Shard** Ein Knoten, der eine Teilmenge von Sharded-Tabellen, vollständige Kopien von Referenztabellen und Standardtabellen speichert. Akzeptiert Abfragen von Routern, kann aber von den Clients nicht direkt kontaktiert werden. **Sharded-Tabelle** Eine Tabelle, deren Daten auf Shards partitioniert sind. **Shard-Schlüssel** Eine Spalte oder eine Gruppe von Spalten in einer Shard-Tabelle, die verwendet werden, um die Partitionierung zwischen Shards zu bestimmen. **Zusammengefasste Tabellen** Zwei Sharded-Tabellen, die denselben Shard-Schlüssel verwenden und explizit als zusammengefasst deklariert sind. Alle Daten für denselben Shard-Schlüsselwert werden an denselben Shard gesendet. **Referenztabelle** Eine Tabelle, deren Daten für jeden Shard vollständig kopiert wurden. **Standardtabelle** Der Standard-Tabellentyp in Limitless Database. Sie können Standardtabellen in Sharded- und Referenztabellen konvertieren. Alle Standardtabellen werden auf demselben vom System ausgewählten Shard gespeichert, sodass zwischen Standardtabellen innerhalb eines einzigen Shard Verknüpfungen stattfinden können. Standardtabellen sind jedoch durch die maximale Kapazität des Shards (128 TiB) begrenzt. Dieser Shard speichert auch Daten aus Sharded- und Referenztabellen, sodass der effektive Grenzwert für Standardtabellen unter 128 TiB liegt. ## Tabellentypen für Aurora PostgreSQL Limitless Database Aurora PostgreSQL Limitless Database unterstützt drei Tabellentypen: *Sharded*, *Referenz* und *Standard*. Bei Sharded-Tabellen sind die Daten auf alle Shards in der DB-Shard-Gruppe verteilt. Limitless Database veranlasst dies automatisch mithilfe eines *Shard-Schlüssels*, bei dem es sich um eine Spalte oder eine Gruppe von Spalten handelt, die Sie bei der Partitionierung der Tabelle festlegen. Alle Daten mit demselben Wert für den Shard-Schlüssel werden an denselben Shard gesendet. Sharding basiert auf Hash, nicht auf Bereichen oder Listen. Geeignete Anwendungsfälle für Sharded-Tabellen: + Die Anwendung arbeitet mit einer bestimmten Teilmenge von Daten. + Die Tabelle ist sehr groß. + Die Tabelle wächst möglicherweise schneller als andere Tabellen. Sharded-Tabellen können *zusammengefasst* werden, was bedeutet, dass sie denselben Shard-Schlüssel verwenden und alle Daten aus beiden Tabellen mit demselben Shard-Schlüsselwert an denselben Shard gesendet werden. Wenn Sie Tabellen zusammenfassen und sie mithilfe des Shard-Schlüssels verknüpfen, kann die Verknüpfung auf einem einzigen Shard ausgeführt werden, da alle erforderlichen Daten auf diesem Shard vorhanden sind. Für Referenztabellen gibt es eine vollständige Kopie all ihrer Daten auf jedem Shard in der DB-Shard-Gruppe. Referenztabellen werden in der Regel für kleinere Tabellen mit einem geringeren Schreibvolumen verwendet, die aber dennoch häufig verknüpft werden müssen und sich nicht für Sharding eignen. Beispiele für Referenztabellen sind Datumstabellen und Tabellen mit geographischen Daten wie Bundesland, Stadt und Postleitzahl. Standardtabellen sind der Standardtabellentyp in Aurora PostgreSQL Limitless Database. Es handelt sich bei diesen Tabellen nicht um verteilte Tabellen. Aurora PostgreSQL Limitless Database unterstützt Verknüpfungen zwischen Standardtabellen und Standard-, Sharded- und Referenztabellen. ## Fakturierung für Aurora PostgreSQL Limitless Database Informationen zu den Gebühren für Aurora PostgreSQL Limitless Database finden Sie unter [ Abrechnung von DB-Instances für Aurora](User_DBInstanceBilling.md). Informationen zur Preisgestaltung von Aurora finden Sie in der [Aurora-Preisliste](https://aws.amazon.com/rds/aurora/pricing). # Erste Schritte mit Aurora PostgreSQL Limitless Database Sie führen die folgenden Aktionen aus, um mit Aurora PostgreSQL Limitless Database zu beginnen: 1. Erstellen eines Aurora PostgreSQL-DB-Clusters und einer DB-Shard-Gruppe für Limitless Databases Weitere Informationen finden Sie unter [Erstellen eines DB-Clusters, der Aurora PostgreSQL Limitless Database verwendet](limitless-cluster.md). 1. Erstellen Sie Sharded- und Referenztabellen in der DB-Shard-Gruppe. Weitere Informationen finden Sie unter [Erstellen von Tabellen in Aurora PostgreSQL Limitless Database](limitless-creating.md). 1. Ändern Sie die Kapazität für Ihre DB-Shard-Gruppe, unterteilen Sie Shards und fügen Sie Router hinzu. Weitere Informationen finden Sie unter [Arbeiten mit DB-Shard-Gruppen](limitless-shard.md). 1. Laden Sie Daten in die DB-Shard-Gruppe. Weitere Informationen finden Sie unter [Laden von Daten in Aurora PostgreSQL Limitless Database](limitless-load.md). 1. Führen Sie Abfragen und andere SQL-Anweisungen an der DB-Shard-Gruppe aus. Weitere Informationen finden Sie unter [Abfragen einer Aurora PostgreSQL Limitless Database](limitless-query.md). 1. Überwachen Sie die Leistung von Limitless Database. Weitere Informationen finden Sie unter [Überwachen einer Aurora PostgreSQL Limitless Database](limitless-monitoring.md). # Voraussetzungen und Überlegungen zu Aurora PostgreSQL Limitless Database Für Aurora PostgreSQL Limitless Database gelten die folgenden Voraussetzungen und Überlegungen. **Topics** + [ ## Voraussetzungen für Aurora PostgreSQL Limitless Database ](#limitless-requirements) + [ ## Überlegungen zu Aurora PostgreSQL Limitless Database ](#limitless-limitations) + [ ## Features, die in Aurora PostgreSQL Limitless Database nicht unterstützt werden ](#limitless-not-supported) ## Voraussetzungen für Aurora PostgreSQL Limitless Database Erfüllen Sie unbedingt diese Voraussetzungen für Aurora PostgreSQL Limitless Database. + Aurora PostgreSQL Limitless Database ist in allen Ländern AWS-Regionen außer im asiatisch-pazifischen Raum (Taipeh) verfügbar. **Anmerkung** Wenn Sie Ihren DB-Cluster von Aurora PostgreSQL Limitless Database in USA Ost (Nord-Virginia) erstellen, nehmen Sie die Availability Zone (AZ) `us-east-1e` nicht in Ihre DB-Subnetzgruppe auf. Aufgrund von Ressourcenbeschränkungen wird Aurora Serverless v2 (und daher Aurora PostgreSQL Limitless Database) in der AZ `us-east-1e` nicht unterstützt. + Aurora PostgreSQL Limitless Database unterstützt nur die DB-Cluster-Speicherkonfiguration Aurora I/O-Optimized. Weitere Informationen finden Sie unter [Speicherkonfigurationen für DB-Cluster von Amazon Aurora](Aurora.Overview.StorageReliability.md#aurora-storage-type). + Aurora PostgreSQL Limitless Database verwendet spezielle Versionen der Aurora PostgreSQL DB-Engine für Aurora PostgreSQL Limitless Database:. `16.X-limitless` Siehe auch [Verfügbare Aurora PostgreSQL Limitless-Datenbankversionen](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/limitless-updates.html) + Ihr DB-Cluster darf keine Writer- oder Reader-DB-Instances haben. + Sie müssen Erweiterte Überwachung und Performance-Insights verwenden. Die Aufbewahrungszeit von Performance-Insights muss mindestens 1 Monat (31 Tage) betragen. + Sie müssen das PostgreSQL-Protokoll nach Amazon CloudWatch Logs exportieren. **Anmerkung** Für einige erforderliche Funktionen wie Enhanced Monitoring, Performance Insights und CloudWatch Logs fallen zusätzliche Gebühren an. Informationen zur Preisgestaltung von Aurora finden Sie in der [Aurora-Preisliste](https://aws.amazon.com/rds/aurora/pricing). ## Überlegungen zu Aurora PostgreSQL Limitless Database Die folgenden Überlegungen gelten für DB-Shard-Gruppen in Aurora PostgreSQL Limitless Database: + Sie können nur eine DB-Shard-Gruppe pro DB-Cluster haben. + Sie können bis zu fünf DB-Shard-Gruppen pro Gruppe einrichten. AWS-Region Daher können Sie bis zu fünf Aurora PostgreSQL Limitless Database DB-Cluster pro haben. AWS-Region Weitere Informationen finden Sie unter [Kontingente in Amazon Aurora](CHAP_Limits.md#RDS_Limits.Limits). + Sie können die maximale Kapazität einer DB-Shard-Gruppe auf 16—6144 festlegen. ACUs Für Kapazitätsgrenzen über 6144 wenden Sie sich an. ACUs AWS Die anfängliche Anzahl von Routern und Shards wird durch die maximale Kapazität bestimmt, die Sie bei der Erstellung einer DB-Shard-Gruppe festgelegt haben. Weitere Informationen finden Sie unter [Korrelieren der maximalen Kapazität der DB-Shard-Gruppe mit der Anzahl der erstellten Router und Shards](limitless-cluster.md#limitless-capacity-mapping). + Die Anzahl der Router und Shards ändert sich nicht, wenn Sie die maximale Kapazität einer DB-Shard-Gruppe ändern. + Stellen Sie sicher, dass das DB-Subnetz, in dem Sie die DB-Shard-Gruppe erstellen, über genügend freie IP-Adressen verfügt, um Verbindungen mit der DB-Shard-Gruppe herzustellen. Sie benötigen eine IP-Adresse für jeden Router und bis zu drei IP-Adressen für jeden Shard in der DB-Shard-Gruppe. Weitere Informationen zur Anzahl der Router, die beim Generieren einer DB-Shard-Gruppe erstellt werden, finden Sie unter [Korrelieren der maximalen Kapazität der DB-Shard-Gruppe mit der Anzahl der erstellten Router und Shards](limitless-cluster.md#limitless-capacity-mapping). + Wenn Sie Ihre DB-Shard-Gruppe öffentlich zugänglich machen, richten Sie in Ihrer VPC unbedingt ein Internet-Gateway ein. + Sie verwenden SQL-Funktionen, um [Shards zu unterteilen](limitless-shard-split.md) und [Router hinzuzufügen](limitless-add-router.md). + Das Zusammenführen von Shards wird nicht unterstützt. + Sie können keine einzelnen Shards und Router löschen. + Sie können Shard-Schlüssel in keiner Weise ändern (`UPDATE`-Operationen an ihnen ausführen), auch nicht ihre Werte in Tabellenzeilen. Um einen Shard-Schlüssel zu ändern, löschen Sie ihn und erstellen Sie ihn anschließend neu. + Die Isolationsstufen REPEATABLE READ, READ COMMITTED und READ UNCOMMITTED werden unterstützt. Sie können die Isolationsstufe nicht auf „serialisierbar“ festlegen. + Manche SQL-Befehle werden nicht unterstützt. Weitere Informationen finden Sie unter [Referenz zu Aurora PostgreSQL Limitless DatabaseReferenz zu Limitless Database](limitless-reference.md). + Nicht alle PostgreSQL-Erweiterungen werden unterstützt. Weitere Informationen finden Sie unter [Erweiterungen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Extensions). + Beim Erstellen einer Shard-Gruppe oder beim Hinzufügen neuer Shard-Gruppenknoten (Shards oder Router) werden diese Knoten in einer der Availability Zones (AZs) erstellt, die dem DB-Cluster zur Verfügung stehen. Sie können keine bestimmte AZ für einzelne Knoten auswählen. + Wenn Sie eine Rechenredundanz von 2 verwenden (zwei Compute-Standbys für die DB-Shard-Gruppe), stellen Sie sicher, dass Ihre DB-Subnetzgruppe mindestens drei hat. AZs + Aurora PostgreSQL Limitless Database unterstützt bis zu 54 Zeichen für Namen von Sharded-Tabellen. Die folgenden Überlegungen gelten für DB-Cluster in Aurora PostgreSQL Limitless Database: + Wir empfehlen Ihnen, AWS verwaltete Richtlinien zu verwenden, um die Berechtigungen für Ihre Datenbank und Anwendungen auf diejenigen zu beschränken, die Kunden für ihre Anwendungsfälle benötigen. Weitere Informationen finden Sie unter [Best Practices für Richtlinien](security_iam_id-based-policy-examples.md#security_iam_service-with-iam-policy-best-practices). + Wenn Sie Ihren DB-Cluster von Aurora PostgreSQL Limitless Database erstellen, legen Sie nur Skalierungsparameter für die DB-Shard-Gruppe fest. + Wenn Sie Ihren DB-Cluster löschen müssen, müssen Sie zuerst die DB-Shard-Gruppe löschen. + Aurora PostgreSQL Limitless Database kann nicht als Replikationsquelle dienen. ## Features, die in Aurora PostgreSQL Limitless Database nicht unterstützt werden Die folgenden Features von Aurora PostgreSQL werden in Aurora PostgreSQL Limitless Database nicht unterstützt: + Active Directory (Kerberos)-Authentifizierung + DevOpsAmazon-Guru + Amazon ElastiCache + Amazon Blue/Green RDS-Bereitstellungen + Amazon-RDS-Proxy + Aurora Auto Scaling (automatisches Hinzufügen von Reader-Instances zum DB-Cluster) + Globale Aurora-Datenbank + Aurora Machine Learning + Aurora-Empfehlungen + Aurora Serverless v1 + Null-ETL-Integrationen von Aurora + AWS Backup + AWS Lambda Integration + AWS Secrets Manager + Babelfish für Aurora PostgreSQL + Klonen von DB-Clustern + Benutzerdefinierte Endpunkte + Datenbankaktivitätsstreams + Read Replicas + RDS-Daten-API # Voraussetzungen für die Verwendung von Aurora PostgreSQL Limitless Database Um Aurora PostgreSQL Limitless Database verwenden zu können, müssen Sie zunächst die folgenden Aufgaben ausführen. **Topics** + [ ## Aktivieren von DB-Shard-Gruppenoperationen ](#limitless-enable-iam) ## Aktivieren von DB-Shard-Gruppenoperationen Bevor Sie eine DB-Shard-Gruppe erstellen können, müssen Sie DB-Shard-Gruppenoperationen aktivieren. + Fügen Sie der IAM-Richtlinie der IAM-Rolle des Benutzers, der auf Aurora PostgreSQL Limitless Database zugreift, den folgenden Abschnitt hinzu: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowDBShardGroup", "Effect": "Allow", "Action": [ "rds:CreateDBShardGroup", "rds:DescribeDBShardGroups", "rds:DeleteDBShardGroup", "rds:ModifyDBShardGroup", "rds:RebootDBShardGroup" ], "Resource": [ "arn:aws:rds:*:*:shard-group:*", "arn:aws:rds:*:*:cluster:*" ] } ] } ``` ------ # Erstellen eines DB-Clusters, der Aurora PostgreSQL Limitless Database verwendet Sie erstellen einen neuen Aurora-DB-Cluster mit der Limitless-Database-Version von Aurora PostgreSQL und fügen dem Cluster eine DB-Shard-Gruppe hinzu. Wenn Sie eine DB-Shard-Gruppe hinzufügen, geben Sie die maximale Rechenkapazität für die gesamte DB-Shard-Gruppe (Summe der Kapazitäten für alle Router und Shards) in Aurora-Kapazitätseinheiten (ACUs) an. Jede ACU ist eine Kombination aus etwa 2 Gibibyte (GiB) Arbeitsspeicher, entsprechender CPU und Netzwerkleistung. Skalierung erhöht oder verringert die Kapazität für Ihre DB-Shard-Gruppe, abhängig von der Workload Ihrer Anwendung, ähnlich wie bei [Aurora Serverless v2](aurora-serverless-v2.how-it-works.md). **Topics** + [ ## Korrelieren der maximalen Kapazität der DB-Shard-Gruppe mit der Anzahl der erstellten Router und Shards ](#limitless-capacity-mapping) + [ # Erstellen Ihres DB Clusters ](limitless-create-cluster.md) ## Korrelieren der maximalen Kapazität der DB-Shard-Gruppe mit der Anzahl der erstellten Router und Shards Die anfängliche Anzahl von Routern und Shards in einer DB-Shard-Gruppe wird durch die maximale Kapazität bestimmt, die Sie bei der Erstellung der DB-Shard-Gruppe festgelegt haben. Je höher die maximale Kapazität, desto mehr Router und Shards werden in der DB-Shard-Gruppe erstellt. Jeder Knoten (Shard oder Router) hat seinen eigenen aktuellen Kapazitätswert, der ebenfalls in ACUs gemessen wird. + Limitless Database skaliert einen Knoten auf eine höhere Kapazität, wenn ihre aktuelle Kapazität zu gering ist, um die Last zu bewältigen. Knoten werden jedoch nicht hochskaliert, wenn die Gesamtkapazität den maximalen Wert erreicht hat. + Limitless Database skaliert den Knoten auf eine geringere Kapazität herunter, wenn dessen aktuelle Kapazität höher als erforderlich ist. Knoten werden jedoch nicht herunterskaliert, wenn die Gesamtkapazität dem Minimum entspricht. Die folgende Tabelle zeigt die Korrelation zwischen der maximalen Kapazität der DB-Shard-Gruppe in Aurora-Kapazitätseinheiten (ACUs) und der Anzahl der erstellten Knoten (Router und Shards). **Anmerkung** Diese Werte können sich ändern. Wenn Sie die Rechenredundanz auf einen Wert ungleich Null setzen, wird die Gesamtzahl der Shards verdoppelt oder verdreifacht. Dies führt zu zusätzlichen Kosten. Die Knoten in Rechen-Standbys werden auf die gleiche Kapazität wie der Writer hoch- und herunterskaliert. Sie legen den Kapazitätsbereich für die Standbys nicht separat fest. | Knoten insgesamt | Router | Shards | Standard-Mindestkapazität (ACUs) | Maximaler Kapazitätsbereich (ACUs) | | --- | --- | --- | --- | --- | | 4 | 2 | 2 | 16 | 16–400 | | 5 | 2 | 3 | 20 | 401–500 | | 6 | 2 | 4 | 24 | 501–600 | | 7 | 3 | 4 | 28 | 601–700 | | 8 | 3 | 5 | 32 | 701–800 | | 9 | 3 | 6 | 36 | 801–900 | | 10 | 4 | 6 | 40 | 901–1 000 | | 11 | 4 | 7 | 44 | 1 001–1 100 | | 12 | 4 | 8 | 48 | 1 101–1 200 | | 13 | 5 | 8 | 52 | 1 201–1 300 | | 14 | 5 | 9 | 56 | 1 301–1 400 | | 15 | 5 | 10 | 60 | 1 401–1 500 | | 16 | 6 | 10 | 64 | 1 501–1 600 | | 17 | 6 | 11 | 68 | 1 601–1 700 | | 18 | 6 | 12 | 72 | 1 701–1 800 | | 19 | 7 | 12 | 76 | 1 801–1 900 | | 20 | 7 | 13 | 80 | 1 901–2 000 | | 21 | 7 | 14 | 84 | 2 001–2 100 | | 22 | 8 | 14 | 88 | 2 101–2 200 | | 23 | 8 | 15 | 92 | 2 201–2 300 | | 24 | 8 | 16 | 96 | 2 301–6 144 | Die auf maximaler Kapazität basierende dynamische Konfiguration für die DB-Shard-Gruppe ist nur während der Erstellung verfügbar. Die Anzahl der Router und Shards bleibt gleich, wenn die maximale Kapazität geändert wird. Weitere Informationen finden Sie unter [Ändern der Kapazität einer DB-Shard-Gruppe](limitless-capacity.md). Sie können SQL-Befehle verwenden, um Shards und Router zu einer DB-Shard-Gruppe hinzuzufügen. Weitere Informationen finden Sie hier: + [Unterteilen eines Shards in einer DB-Shard-Gruppe](limitless-shard-split.md) + [Hinzufügen eines Routers zu einer DB-Shard-Gruppe](limitless-add-router.md) **Anmerkung** Shards oder Router können nicht gelöscht werden. # Erstellen Ihres DB Clusters Nutzen Sie die folgenden Verfahren, um einen DB-Cluster von Aurora PostgreSQL zu erstellen, der Aurora PostgreSQL Limitless Database verwendet. Sie können entweder die AWS-Managementkonsole oder die AWS CLI nutzen, um Ihren DB-Cluster zu erstellen, der Aurora PostgreSQL Limitless Database verwendet. Sie erstellen den primären DB-Cluster und die DB-Shard-Gruppe. ## Konsole Wenn Sie die AWS-Managementkonsole zum Erstellen des primären DB-Clusters verwenden, wird die DB-Shard-Gruppe im gleichen Verfahren ebenfalls erstellt. **So erstellen Sie den DB-Cluster mithilfe der Konsole** 1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie **Create database (Datenbank erstellen)** aus. Die Seite **Datenbank erstellen** wird angezeigt. 1. Wählen Sie als **Engine-Typ** **Aurora (PostgreSQL-kompatibel)**. 1. Wählen Sie für **Version** eine der folgenden Optionen aus: + **Aurora PostgreSQL mit Limitless Database (kompatibel mit PostgreSQL 16.4)** + **Aurora PostgreSQL mit Limitless Database (kompatibel mit PostgreSQL 16.6)** 1. Für **Aurora PostgreSQL Limitless Database**: ![\[Konsoleneinstellungen für Aurora PostgreSQL Limitless Database mit Konfigurationsoptionen für Sharding und Verteilungsparametern.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/limitless_create_database.png) 1. Geben Sie die **Kennung der DB-Shard-Gruppe** ein. **Wichtig** Nachdem Sie die DB-Shard-Gruppe erstellt haben, können Sie die ID des DB-Clusters oder der DB-Shard-Gruppe nicht mehr ändern. 1. Für den **Kapazitätsbereich der DB-Shard-Gruppe**: 1. Geben Sie die **Minimale Kapazität (ACUs)** ein. Verwenden Sie einen Wert von mindestens 16 ACUs. Für eine Entwicklungsumgebung ist der Standardwert 16 ACUs. Für eine Produktionsumgebung ist der Standardwert 24 ACUs. 1. Geben Sie die **Maximale Kapazität (ACUs)** ein. Verwenden Sie einen Wert von mindestens 16 und höchstens 6 144 ACUs. Für eine Entwicklungsumgebung ist der Standardwert 64 ACUs. Für eine Produktionsumgebung ist der Standardwert 384 ACUs. Weitere Informationen finden Sie unter [Korrelieren der maximalen Kapazität der DB-Shard-Gruppe mit der Anzahl der erstellten Router und Shards](limitless-cluster.md#limitless-capacity-mapping). 1. Wählen Sie für **Bereitstellung von DB-Shard-Gruppen** aus, ob Standbys für die DB-Shard-Gruppe erstellt werden sollen: + **Keine Compute-Redundanz**: Erstellt eine DB-Shard-Gruppe ohne Standbys für jeden Shard. Dies ist der Standardwert. + **Compute-Redundanz mit einem einzigen Failover-Ziel**: Erstellt eine DB-Shard-Gruppe mit einem Compute-Standby in einer anderen Availability Zone (AZ). + **Compute-Redundanz mit zwei Failover-Zielen**: Erstellt eine DB-Shard-Gruppe mit zwei Compute-Standbys in zwei verschiedenen AZs. **Anmerkung** Wenn Sie die Compute-Redundanz auf einen Wert ungleich Null setzen, wird die Gesamtzahl der Shard-DB-Instances verdoppelt oder verdreifacht. Bei diesen zusätzlichen DB-Instances handelt es sich um Compute-Standbys, die auf dieselbe Kapazität wie die Writer-Instance hoch- und herunterskaliert werden. Sie legen den Kapazitätsbereich für die Standbys nicht separat fest. Daher verdoppeln und verdreifachen sich die ACU-Auslastung und die Kosten entsprechend. Den genauen ACU-Verbrauch, der sich aus der Compute-Redundanz ergibt, finden Sie in der Metrik `DBShardGroupComputeRedundancyCapacity` unter [DBShardGroup-Metriken](limitless-monitoring.cw.md#limitless-monitoring.cw.DBShardGroup). 1. Wählen Sie aus, ob die DB-Shard-Gruppe öffentlich zugänglich gemacht werden soll. **Anmerkung** Sie können diese Einstellung nicht mehr ändern, nachdem Sie die DB-Shard-Gruppe erstellt haben. 1. Für **Konnektivität**: 1. (Optional) Wählen Sie **Verbindung zu einer EC2-Compute-Ressource herstellen** und dann eine vorhandene EC2-Instance aus, oder erstellen Sie eine neue. **Anmerkung** Wenn Sie eine Verbindung zu einer EC2-Instance herstellen, können Sie die DB-Shard-Gruppe nicht öffentlich zugänglich machen. 1. Wählen Sie als **Netzwerktyp** entweder **IPv4** oder den **Dual-Stack-Modus** aus. 1. Wählen Sie die **Virtual Private Cloud (VPC)** und die **DB-Subnetzgruppe** aus, oder verwenden Sie die Standardeinstellungen. **Anmerkung** Wenn Sie Ihren DB-Cluster von Limitless Database in USA Ost (Nord-Virginia) erstellen, nehmen Sie die Availability Zone (AZ) `us-east-1e` nicht in Ihre DB-Subnetzgruppe auf. Aufgrund von Ressourcenbeschränkungen wird Aurora Serverless v2 – und somit auch Limitless Database – in der AZ `us-east-1e` nicht unterstützt. 1. Wählen Sie die **VPC-Sicherheitsgruppe (Firewall)** aus, oder verwenden Sie die Standardeinstellung. 1. Wählen Sie für die **Datenbankauthentifizierung** entweder **Passwort-Authentifizierung** oder **Passwort- und IAM-Datenbank-Authentifizierung** aus. 1. Stellen Sie für die **Überwachung** sicher, dass die Kontrollkästchen **Performance Insights aktivieren** und **Erweiterte Überwachung aktivieren** aktiviert sind. Wählen Sie für Performance Insights eine Aufbewahrungszeit von mindestens einem Monat. 1. Erweitern Sie die letzte **Zusätzliche Konfiguration** auf der Seite. 1. Achten Sie darauf, dass für **Protokollexporte** das Kontrollkästchen **PostgreSQL-Protokoll** aktiviert ist. 1. Geben Sie nach Bedarf weitere Einstellungen an. Weitere Informationen finden Sie unter [Einstellungen für Aurora-DB-Cluster](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). 1. Wählen Sie **Create database (Datenbank erstellen)** aus. Nachdem der primäre DB-Cluster und die DB-Shard-Gruppe erstellt wurden, werden sie auf der Seite **Datenbanken** angezeigt. ![\[Primärer DB-Cluster und DB-Shard-Gruppe in Aurora PostgreSQL Limitless Database.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/limitless_cluster_164.png) ## CLI Wenn Sie die AWS CLI verwenden, um einen DB-Cluster zu erstellen, der Aurora PostgreSQL Limitless Database verwendet, führen Sie die folgenden Aufgaben aus: 1. [Erstellen Sie den primären DB-Cluster](#limitless-create-CLI.cluster). 1. [Erstellen Sie die DB-Shard-Gruppe](#limitless-create-CLI.shard-group). ### Erstellen Sie den primären DB-Cluster Die folgenden Parameter sind erforderlich, um den DB-Cluster zu erstellen: + `--db-cluster-identifier`: Der Name Ihres DB-Clusters. + `--engine`: Der DB-Cluster muss die `aurora-postgresql`-DB-Engine verwenden. + `--engine-version`: Der DB-Cluster muss eine der DB-Engine-Versionen verwenden: + `16.4-limitless` + `16.6-limitless` + `--storage-type`: Der DB-Cluster muss die Speicherkonfiguration des `aurora-iopt1`-DB-Clusters verwenden. + `--cluster-scalability-type`: Gibt den Skalierbarkeitsmodus des Aurora-DB-Clusters an. Wenn dieser Parameter auf `limitless` gesetzt ist, arbeitet der Cluster als Aurora PostgreSQL Limitless Database. Wenn er auf `standard` (Standard) gesetzt ist, verwendet der Cluster die normale DB-Instance-Erstellung. **Anmerkung** Sie können diese Einstellung nicht mehr ändern, nachdem Sie den DB-Cluster erstellt haben. + `--master-username`: Der Name des Masterbenutzers für diesen DB-Cluster. + `--master-user-password`: Das Passwort für den Masterbenutzer. + `--enable-performance-insights`: Sie müssen Performance Insights aktivieren. + `--performance-insights-retention-period`: Die Aufbewahrungsfrist für Performance Insights muss mindestens 31 Tage betragen. + `--monitoring-interval`: Das Intervall in Sekunden zwischen den Punkten, an denen erweiterte Überwachungsmetriken für den DB-Cluster erfasst werden. Dieser Wert darf nicht `0` sein. + `--monitoring-role-arn`: Der Amazon-Ressourcenname (ARN) für die IAM-Rolle, die es RDS erlaubt, erweiterte Überwachungsmetriken an Amazon CloudWatch Logs zu senden. + `--enable-cloudwatch-logs-exports`: Sie müssen `postgresql`-Protokolle zu CloudWatch-Protokollen exportieren. Die folgenden Parameter sind optional: + `--db-subnet-group-name`: Die DB-Subnetzgruppe, die mit dem DB-Cluster verknüpft werden soll. Dies bestimmt auch die VPC, die mit dem DB-Cluster verknüpft wird **Anmerkung** Wenn Sie Ihren DB-Cluster von Limitless Database in USA Ost (Nord-Virginia) erstellen, nehmen Sie die Availability Zone (AZ) `us-east-1e` nicht in Ihre DB-Subnetzgruppe auf. Aufgrund von Ressourcenbeschränkungen wird Aurora Serverless v2 – und somit auch Limitless Database – in der AZ `us-east-1e` nicht unterstützt. + `--vpc-security-group-ids`: Eine Liste der VPC-Sicherheitsgruppen, die mit dem DB-Cluster verknüpft werden sollen. + `--performance-insights-kms-key-id`: Die Kennung AWS KMS key für die Verschlüsselung von Performance-Insights-Daten. Wenn Sie keinen KMS-Schlüssel angeben, wird der Standardschlüssel für Ihr AWS-Konto verwendet. + `--region`: Die AWS-Region, in der Sie den DB-Cluster erstellen. Es muss eine Region sein, die Aurora PostgreSQL Limitless Database unterstützt. Um die Standard-VPC- und VPC-Sicherheitsgruppe zu verwenden, lassen Sie die Optionen `--db-subnet-group-name` und `--vpc-security-group-ids` weg. **So erstellen Sie den primären DB-Cluster** + ``` aws rds create-db-cluster \ --db-cluster-identifier my-limitless-cluster \ --engine aurora-postgresql \ --engine-version 16.6-limitless \ --storage-type aurora-iopt1 \ --cluster-scalability-type limitless \ --master-username myuser \ --master-user-password mypassword \ --db-subnet-group-name mysubnetgroup \ --vpc-security-group-ids sg-c7e5b0d2 \ --enable-performance-insights \ --performance-insights-retention-period 31 \ --monitoring-interval 5 \ --monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \ --enable-cloudwatch-logs-exports postgresql ``` Weitere Informationen finden Sie unter [create-db-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/create-db-cluster.html). ### Erstellen Sie die DB-Shard-Gruppe Als Nächstes erstellen Sie die DB-Shard-Gruppe in dem DB-Cluster, den Sie soeben erstellt haben. Die folgenden Parameter sind erforderlich: + `--db-shard-group-identifier`: Der Name Ihrer DB-Shard-Gruppe. Die Kennung der DB-Shard-Gruppe hat die folgenden Einschränkungen: + Muss in dem AWS-Konto und in der AWS-Region, in der Sie sie erstellen, eindeutig sein. + Muss zwischen 1 und 63 Buchstaben, Zahlen oder Bindestriche enthalten. + Das erste Zeichen muss ein Buchstabe sein. + Darf nicht mit einem Bindestrich enden oder zwei aufeinanderfolgende Bindestriche enthalten. + **Wichtig** Nachdem Sie die DB-Shard-Gruppe erstellt haben, können Sie die ID des DB-Clusters oder der DB-Shard-Gruppe nicht mehr ändern. + `--db-cluster-identifier`: Der Name des DB-Clusters, in dem Sie die DB-Shard-Gruppe erstellen. + `--max-acu`: Die maximale Kapazität Ihrer DB-Shard-Gruppe. Sie muss zwischen 16 und 6 144 ACUs liegen. Für Kapazitätsgrenzen von mehr als 6 144 ACUs wenden Sie sich bitte an AWS. Die anfängliche Anzahl von Routern und Shards wird durch die maximale Kapazität bestimmt, die Sie bei der Erstellung der DB-Shard-Gruppe festgelegt haben. Je höher die maximale Kapazität, desto mehr Router und Shards werden in der DB-Shard-Gruppe erstellt. Weitere Informationen finden Sie unter [Korrelieren der maximalen Kapazität der DB-Shard-Gruppe mit der Anzahl der erstellten Router und Shards](limitless-cluster.md#limitless-capacity-mapping). Die folgenden Parameter sind optional: + `--compute-redundancy`: Ob Standbys für die DB-Shard-Gruppe erstellt werden sollen. Folgende Parameterwerte sind möglich: + `0`: Erstellt eine DB-Shard-Gruppe ohne Standbys für jeden Shard. Dies ist der Standardwert. + `1`: Erstellt eine DB-Shard-Gruppe mit einem Compute-Standby in einer anderen Availability Zone (AZ). + `2`: Erstellt eine DB-Shard-Gruppe mit zwei Compute-Standbys in zwei verschiedenen AZs. **Anmerkung** Wenn Sie die Rechenredundanz auf einen Wert ungleich Null setzen, wird die Gesamtzahl der Shards verdoppelt oder verdreifacht. Dies führt zu zusätzlichen Kosten. Die Knoten in Rechen-Standbys werden auf die gleiche Kapazität wie der Writer hoch- und herunterskaliert. Sie legen den Kapazitätsbereich für die Standbys nicht separat fest. + `--min-acu`: Die minimale Kapazität Ihrer DB-Shard-Gruppe. Sie muss mindestens 16 ACUs umfassen, was dem Standardwert entspricht. + `--publicly-accessible|--no-publicly-accessible`: Ob der DB-Shard-Gruppe öffentlich zugängliche IP-Adressen zugewiesen werden sollen. Der Zugriff auf die DB-Shard-Gruppe wird von den von dem Cluster verwendeten Sicherheitsgruppen kontrolliert. Der Standardwert ist `--no-publicly-accessible`. **Anmerkung** Sie können diese Einstellung nicht mehr ändern, nachdem Sie die DB-Shard-Gruppe erstellt haben. **So erstellen Sie die DB-Shard-Gruppe** + ``` aws rds create-db-shard-group \ --db-shard-group-identifier my-db-shard-group \ --db-cluster-identifier my-limitless-cluster \ --max-acu 1000 ``` # Arbeiten mit DB-Shard-Gruppen Sie führen die folgenden Aufgaben aus, um eine DB-Shard-Gruppe für Aurora PostgreSQL Limitless Database hinzuzufügen und zu verwalten. **Topics** + [ ## Herstellen einer Verbindung zu Ihrem Aurora PostgreSQL Limitless Database-DB-Cluster ](#limitless-endpoint) + [ ## Ermitteln der Anzahl von Routern und Shards in einer DB-Shard-Gruppe ](#limitless-shard.number) + [ ## Beschreibung von DB-Shard-Gruppen ](#limitless-describe) + [ ## Neustarten einer DB-Shard-Gruppe ](#limitless-reboot) + [ # Ändern der Kapazität einer DB-Shard-Gruppe ](limitless-capacity.md) + [ # Unterteilen eines Shards in einer DB-Shard-Gruppe ](limitless-shard-split.md) + [ # Hinzufügen eines Routers zu einer DB-Shard-Gruppe ](limitless-add-router.md) + [ # Löschen einer DB-Shard-Gruppe ](limitless-shard-delete.md) + [ # Hinzufügen einer DB-Shard-Gruppe zu einem vorhandenen DB-Cluster von Aurora PostgreSQL Limitless Database ](limitless-shard-add.md) ## Herstellen einer Verbindung zu Ihrem Aurora PostgreSQL Limitless Database-DB-Cluster Um mit Aurora PostgreSQL Limitless Database zu arbeiten, stellen Sie eine Verbindung zum Writer oder Reader des Cluster-Endpunkts her. Sie können `psql` oder jedes andere Verbindungsdienstprogramm verwenden, das mit PostgreSQL funktioniert: ``` $ psql -h DB_cluster_endpoint -p port_number -U database_username -d postgres_limitless ``` Im folgenden Beispiel wird der Endpunkt für den DB-Cluster verwendet, den Sie in [CLI](limitless-create-cluster.md#limitless-create-CLI) erstellt haben. ``` $ psql -h my-limitless-cluster.cluster-ckifpdyyyxxx.us-east-1.rds.amazonaws.com -p 5432 -U postgres -d postgres_limitless ``` **Anmerkung** Die Standarddatenbank für die DB-Shard-Gruppe in Aurora PostgreSQL Limitless Database ist `postgres_limitless`. ### Verwenden des Limitless Connection-Plug-ins Beim Herstellen einer Verbindung mit Aurora PostgreSQL Limitless Database stellen Clients eine Verbindung über den Cluster-Endpunkt her und werden über Amazon Route 53 an einen Transaktionsrouter weitergeleitet. Route 53 ist jedoch in seiner Fähigkeit zum Lastenausgleich eingeschränkt und kann ungleichmäßige Arbeitslasten auf Transaktionsroutern ermöglichen. Das [Limitless Connection-Plug-in](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/using-the-jdbc-driver/using-plugins/UsingTheLimitlessConnectionPlugin.md) für den [AWSJDBC-Treiber](https://github.com/awslabs/aws-advanced-jdbc-wrapper) behebt dieses Problem, indem es einen clientseitigen Lastenausgleich mit Lasterkennung durchführt. Weitere Informationen zum [AWS JDBC-Treiber](https://github.com/awslabs/aws-advanced-jdbc-wrapper) finden Sie unter [Herstellen einer Verbindung mit Aurora PostgreSQL mithilfe des AWS-JDBC-Treibers](Aurora.Connecting.md#Aurora.Connecting.JDBCDriverPostgreSQL). ## Ermitteln der Anzahl von Routern und Shards in einer DB-Shard-Gruppe Sie können die folgende Abfrage verwenden, um die Anzahl der Router und Shards zu ermitteln: ``` SELECT * FROM rds_aurora.limitless_subclusters; subcluster_id | subcluster_type ---------------+----------------- 1 | router 2 | router 3 | shard 4 | shard 5 | shard 6 | shard ``` ## Beschreibung von DB-Shard-Gruppen Verwenden Sie den AWS CLI-Befehl `describe-db-shard-groups`, um Ihre DB-Shard-Gruppen zu beschreiben. Der folgende Parameter ist optional: + `--db-shard-group-identifier` – Der Name einer DB-Shard-Gruppe. Im folgenden Beispiel wird eine bestimmte DB-Shard-Gruppe beschrieben. ``` aws rds describe-db-shard-groups --db-shard-group-identifier my-db-shard-group ``` Die Ausgabe sieht in etwa folgendermaßen aus: ``` { "DBShardGroups": [ { "DBShardGroupResourceId": "shardgroup-8986d309a93c4da1b1455add17abcdef", "DBShardGroupIdentifier": "my-shard-group", "DBClusterIdentifier": "my-limitless-cluster", "MaxACU": 1000.0, "ComputeRedundancy": 0, "Status": "available", "PubliclyAccessible": false, "Endpoint": "my-limitless-cluster.limitless-ccetp2abcdef.us-east-1.rds.amazonaws.com" } ] } ``` ## Neustarten einer DB-Shard-Gruppe Manchmal müssen Sie Ihre DB-Shard-Gruppe neu starten, beispielsweise wenn sich der Parameter `max_connections`aufgrund einer Änderung der maximalen Kapazität ändert. Sie können AWS-Managementkonsole oder AWS CLI verwenden, um die Kapazität einer DB-Shard-Gruppe zu ändern. ### Konsole Gehen Sie wie folgt vor: Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Navigieren Sie zur Seite **Datenbanken**. 1. Wählen Sie die DB-Shard-Gruppe aus, die Sie neu starten möchten. 1. Wählen Sie unter **Aktionen** die Option **Neustart** aus. 1. Wählen Sie **Bestätigen** aus. ### CLI Verwenden Sie den AWS CLI-Befehl `reboot-db-shard-group` mit den folgenden erforderlichen Parameter, um eine DB-Parametergruppe zu kopieren: + `--db-shard-group-identifier` – Der Name einer DB-Shard-Gruppe. Im folgenden Beispiel wird eine DB-Shard-Gruppe neu gestartet. ``` aws rds reboot-db-shard-group --db-shard-group-identifier my-db-shard-group ``` # Ändern der Kapazität einer DB-Shard-Gruppe Sie können die AWS-Managementkonsole oder die AWS CLI verwenden, um die Kapazität einer DB-Shard-Gruppe zu ändern. ## Konsole Gehen Sie wie folgt vor: Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Navigieren Sie zur Seite **Databases (Datenbanken)**. 1. Wählen Sie die DB-Shard-Gruppe aus, die Sie ändern möchten. 1. Wählen Sie für **Actions (Aktionen)** die Option **Modify (Ändern)** aus. Die Seite **DB-Shard-Gruppe ändern** wird angezeigt. ![\[Seite „DB-Shard-Gruppe ändern“.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/limitless_modify_shard_group.png) 1. Geben Sie einen neuen Wert für **Minimale Kapazität (ACUs)** ein, z. B. **100**. 1. Geben Sie einen neuen Wert für **Maximale Kapazität (ACUs)** ein, z. B. **1000**. 1. Klicken Sie auf **Weiter**. Es wird eine Bestätigungsseite mit der Zusammenfassung Ihrer Änderungen angezeigt. 1. Überprüfen Sie Ihre Änderungen und wählen Sie dann **DB-Shard-Gruppe ändern** aus. ## CLI Verwenden Sie den AWS CLI-Befehl `modify-db-shard-group` mit den folgenden Parametern: + `--db-shard-group-identifier`: Der Name der DB-Shard-Gruppe. + `--max-acu`: Die neue maximale Kapazität der DB-Shard-Gruppe. Sie können die maximale Kapazität der DB-Shard-Gruppe auf 16 bis 6 144 ACUs festlegen. Für Kapazitätsgrenzen von mehr als 6 144 ACUs wenden Sie sich bitte an AWS. Die Anzahl der Router und Shards ändert sich nicht. + `--min-acu`: Die neue minimale Kapazität Ihrer DB-Shard-Gruppe. Sie muss mindestens 16 ACUs umfassen, was dem Standardwert entspricht. Das folgende CLI-Beispiel ändert den Kapazitätsbereich einer DB-Shard-Gruppe auf 100 bis 1 000 ACUs. ``` aws rds modify-db-shard-group \ --db-shard-group-identifier my-db-shard-group \ --min-acu 100 \ --max-acu 1000 ``` # Unterteilen eines Shards in einer DB-Shard-Gruppe Sie können einen Shard in einer DB-Shard-Gruppe manuell in zwei kleinere Shards unterteilen. Dies wird als ein *vom Benutzer initiierter* Shard-Split bezeichnet. Aurora PostgreSQL Limitless Database kann Shards auch unterteilen, wenn sie über sehr große Datenmengen verfügen oder sehr stark genutzt werden. Dies wird als ein *vom System initiierter* Shard-Split bezeichnet. **Topics** + [ ## Voraussetzungen ](#limitless-shard-split.prereqs) + [ ## Unterteilen eines Shards ](#limitless-shard-split.proc) + [ ## Nachverfolgen von Shard-Splits ](#limitless-shard-split.track) + [ ## Finalisieren von Shard-Splits ](#limitless-shard-split.finalize) + [ ## Abbrechen eines Shard-Splits ](#limitless-shard-split.cancel) ## Voraussetzungen Für vom Benutzer initiierte Shard-Splits gelten die folgenden Voraussetzungen: + Sie müssen über eine DB-Shard-Gruppe verfügen. + Die DB-Shard-Gruppe darf nicht leer sein: Sie muss mindestens eine Sharded-Tabelle enthalten. + Ein Benutzer muss die Berechtigung `rds_aurora_limitless_cluster_admin` haben. Der `rds_superuser` hat dieses Recht; daher hat es auch der Masterbenutzer. Der `rds_superuser` kann anderen Benutzern das Privileg gewähren: ``` /* Logged in as the master user or a user with rds_superuser privileges */ CREATE USER username; GRANT rds_aurora_limitless_cluster_admin to username; ``` + Sie müssen die Subcluster-ID (Knoten-ID) des Shards kennen, den Sie unterteilen möchten. Sie können die ID mithilfe der folgenden Abfrage identifizieren: ``` SELECT * FROM rds_aurora.limitless_subclusters; subcluster_id | subcluster_type ---------------+----------------- 1 | router 2 | router 3 | shard 4 | shard 5 | shard 6 | shard ``` Wenn Sie möchten, dass das System Shard-Splits initiiert, legen Sie die folgenden DB-Cluster-Parameter in einer benutzerdefinierten DB-Cluster-Parametergruppe fest, die Ihrem DB-Cluster zugeordnet ist: | Parameter | Wert | | --- | --- | | `rds_aurora.limitless_enable_auto_scale` | `on` | | `rds_aurora.limitless_auto_scale_options` | Entweder `split_shard` oder `add_router,split_shard` | | `rds_aurora.limitless_finalize_split_shard_mode` | Dieser Parameter bestimmt, wie *vom System initiierte* Shard-Splits finalisiert werden. Der Wert kann eine der folgenden Formen annehmen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/limitless-shard-split.html) Weitere Informationen finden Sie unter [Finalisieren von Shard-Splits](#limitless-shard-split.finalize). Dieser Parameter gilt nur für vom System initiierte Shard-Splits. | Weitere Informationen finden Sie unter [DB-Cluster-Parametergruppen für Amazon-Aurora-DB-Cluster](USER_WorkingWithDBClusterParamGroups.md). ## Unterteilen eines Shards Verwenden Sie die Funktion `rds_aurora.limitless_split_shard`, um einen Shard in einer DB-Shard-Gruppe zu unterteilen. Diese Funktion startet einen Auftrag zum Unterteilen des Shards, der asynchron ausgeführt wird. ``` SELECT rds_aurora.limitless_split_shard('subcluster_id'); ``` Warten Sie nach erfolgreicher Übermittlung des Auftrags auf die Rückgabe einer Auftrags-ID, zum Beispiel: ``` SELECT rds_aurora.limitless_split_shard('3'); job_id --------------- 1691300000000 (1 row) ``` **Anmerkung** Gleichzeitige Shard-Splits werden nicht unterstützt. Führen Sie die Aufträge nacheinander aus und schließen Sie jeden Auftrag ab, bevor Sie einen weiteren Split veranlassen. ## Nachverfolgen von Shard-Splits Sie können die Auftrags-ID verwenden, um einen Shard-Split-Auftrag nachzuverfolgen. Führen Sie die folgende Abfrage aus, um einen bestimmten Auftrag zu beschreiben und weitere Informationen dazu zu erhalten: ``` SELECT * FROM rds_aurora.limitless_list_shard_scale_jobs(job_id); ``` Zum Beispiel: ``` SELECT * FROM rds_aurora.limitless_list_shard_scale_jobs(1691300000000); job_id | action | job_details | status | submission_time | message ---------------+-------------+-----------------------+---------+------------------------+------------------------------------------- 1691300000000 | SPLIT_SHARD | Split Shard 3 by User | SUCCESS | 2023-08-06 05:33:20+00 | Scaling job succeeded. + | | | | | New shard instance with ID 7 was created. (1 row) ``` Die Abfrage gibt einen Fehler zurück, wenn Sie einen nicht vorhandenen Auftrag als Eingabe übermitteln. ``` SELECT * from rds_aurora.limitless_list_shard_scale_jobs(1691300000001); ERROR: no job found with the job ID provided ``` Sie können den Status aller Shard-Split-Aufträge verfolgen, indem Sie dieselbe Abfrage ohne Auftrags-ID ausführen, zum Beispiel: ``` SELECT * FROM rds_aurora.limitless_list_shard_scale_jobs(); job_id | action | job_details | status | submission_time | message ---------------+-------------+-----------------------+-------------+------------------------+-------------------------------------------------------------- 1691200000000 | SPLIT_SHARD | Split Shard 3 by User | IN_PROGRESS | 2023-08-05 01:46:40+00 | 1691300000000 | SPLIT_SHARD | Split Shard 4 by User | SUCCESS | 2023-08-06 05:33:20+00 | Scaling job succeeded. + | | | | | New shard instance with ID 7 was created. 1691400000000 | SPLIT_SHARD | Split Shard 5 by User | FAILED | 2023-08-07 09:20:00+00 | Error occurred for the add shard job 1691400000000. | | | | | Retry the command. If the issue persists, contact AWS Support. 1691500000000 | SPLIT_SHARD | Split Shard 5 by User | CANCELED | 2023-08-07 09:20:00+00 | Scaling job was cancelled. (4 rows) ``` Der Auftragsstatus kann einer der folgenden Werte sein: + `IN_PROGRESS`: Der Shard-Split-Auftrag wurde eingereicht und ist in Bearbeitung. Sie können nur einen Auftrag nach dem anderen ausführen. + `PENDING`: Der Shard-Split-Auftrag wartet darauf, dass Sie ihn finalisieren. Weitere Informationen finden Sie unter [Finalisieren von Shard-Splits](#limitless-shard-split.finalize). + `CANCELLATION_IN_PROGRESS`: Der Shard-Split-Auftrag wird vom Benutzer abgebrochen. + `CANCELED`: Der Shard-Split-Auftrag wurde vom Benutzer oder vom System erfolgreich abgebrochen. + `SUCCESS`: Der Shard-Split-Auftrag wurde erfolgreich abgeschlossen. Das Feld `message` enthält die Instance-ID des neuen Shards. + `FAILED`: Der Shard-Split-Auftrag ist fehlgeschlagen. Das Feld `message` enthält die Einzelheiten zu dem Fehler und alle Maßnahmen, die zu dem fehlgeschlagenen Auftrag ergriffen werden können. ## Finalisieren von Shard-Splits Das Finalisieren ist der letzte Schritt des Shard-Split-Prozesses. Er verursacht etwas Ausfallzeit. Wenn Sie einen Shard-Split-Auftrag starten, erfolgt die Finalisierung sofort, nachdem der Auftrag erfolgreich abgeschlossen wurde. Manchmal unterteilt das System Shards auf Grundlage ihrer Workload, wenn Sie vom System initiierte Shard-Splits mithilfe des Parameters `rds_aurora.limitless_enable_auto_scale` aktiviert haben. In diesem Fall können Sie wählen, ob die Finalisierung sofort oder zu einem von Ihnen gewünschten Zeitpunkt erfolgt. Sie verwenden den DB-Cluster-Parameter `rds_aurora.limitless_finalize_split_shard_mode`, um zu bestimmen, wann dies geschieht: + Wenn Sie den Wert auf `immediate` setzen, geschieht dies sofort. + Wenn Sie den Wert auf `user_initiated` setzen, müssen Sie den Shard-Split-Auftrag manuell abschließen. Ein RDS-Ereignis wird an Sie gesendet, und der Status des Shard-Split-Auftrags wechselt in `PENDING`. Bei der Einstellung `user_initiated` verwenden Sie die Funktion `rds_aurora.limitless_finalize_split_shard`, um den Shard-Split-Auftrag zu finalisieren: ``` SELECT * FROM rds_aurora.limitless_finalize_split_shard(job_id); ``` **Anmerkung** Diese Funktion gilt nur für Shard-Splits, die vom System initiiert werden, nicht von Ihnen. ## Abbrechen eines Shard-Splits Sie können einen vom Benutzer oder vom System initiierten Shard-Split mit dem Status `IN_PROGRESS` oder `PENDING` abbrechen. Sie benötigen die Auftrags-ID, um den Auftrag abzubrechen. ``` SELECT * from rds_aurora.limitless_cancel_shard_scale_jobs(job_id); ``` Es wird keine Ausgabe zurückgegeben, es sei denn, es liegt ein Fehler vor. Sie können den Abbruch mithilfe einer Abfrage zur Auftragsverfolgung überwachen. # Hinzufügen eines Routers zu einer DB-Shard-Gruppe Sie können einen Router zu einer DB-Shard-Gruppe hinzufügen. **Topics** + [ ## Voraussetzungen ](#limitless-add-router.prereqs) + [ ## Hinzufügen eines Routers ](#limitless-add-router.proc) + [ ## Nachverfolgen von Router-Hinzufügungen ](#limitless-add-router.track) + [ ## Abbrechen einer Router-Hinzufügung ](#limitless-add-router.cancel) ## Voraussetzungen Folgende Voraussetzungen gelten für das Hinzufügen eines Routers: + Sie müssen über eine DB-Shard-Gruppe verfügen. + Ein Benutzer muss die Berechtigung `rds_aurora_limitless_cluster_admin` haben. Der `rds_superuser` hat dieses Recht; daher hat es auch der Masterbenutzer. Der `rds_superuser` kann anderen Benutzern das Privileg gewähren: ``` /* Logged in as the master user or a user with rds_superuser privileges */ CREATE USER username; GRANT rds_aurora_limitless_cluster_admin to username; ``` **Anmerkung** Wenn Sie das Standard-CA-Zertifikat Ihres AWS-Kontos ändern, nachdem die DB-Shard-Gruppe erstellt wurde, verwendet der neue Router das neue CA-Zertifikat, das sich vom CA-Zertifikat des vorhandenen Routers unterscheidet. Abhängig von Ihrem Trust Store können einige Verbindungen fehlschlagen. + Wenn Sie möchten, dass das System das Hinzufügen von Routern initiiert, legen Sie die folgenden DB-Cluster-Parameter in einer benutzerdefinierten DB-Cluster-Parametergruppe fest, die Ihrem DB-Cluster zugeordnet ist: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/limitless-add-router.html) Weitere Informationen finden Sie unter [DB-Cluster-Parametergruppen für Amazon-Aurora-DB-Cluster](USER_WorkingWithDBClusterParamGroups.md). ## Hinzufügen eines Routers Verwenden Sie die Funktion `rds_aurora.limitless_add_router`, um einen Router hinzuzufügen. Diese Funktion startet einen Auftrag zum Hinzufügen eines Routers, der asynchron ausgeführt wird. ``` SELECT rds_aurora.limitless_add_router(); ``` Warten Sie nach erfolgreicher Übermittlung des Auftrags auf die Rückgabe einer Auftrags-ID, zum Beispiel: ``` job_id --------------- 1691300000000 (1 row) ``` **Anmerkung** Gleichzeitige Aufträge zum Hinzufügen von Routern werden nicht unterstützt. Führen Sie die Aufträge nacheinander aus und schließen Sie jeden Auftrag ab, bevor Sie eine weitere Hinzufügung einleiten. ## Nachverfolgen von Router-Hinzufügungen Sie können die Auftrags-ID verwenden, um einen Auftrag zum Hinzufügen eines Routers nachzuverfolgen. Führen Sie die folgende Abfrage aus, um einen bestimmten Auftrag zu beschreiben und weitere Informationen dazu zu erhalten: ``` SELECT * FROM rds_aurora.limitless_list_router_scale_jobs(job_id); ``` Zum Beispiel: ``` SELECT * FROM rds_aurora.limitless_list_router_scale_jobs(1691300000000); job_id | action | job_details | status | submission_time | message ---------------+------------+--------------------------+---------+------------------------+------------------------------------------- 1691300000000 | ADD_ROUTER | Add 1 new Router by User | SUCCESS | 2023-08-06 05:33:20+00 | Scaling job succeeded. + | | | | | New router instance with ID 7 was created. (1 row) ``` Die Abfrage gibt einen Fehler zurück, wenn Sie einen nicht vorhandenen Auftrag als Eingabe übermitteln. ``` SELECT * from rds_aurora.limitless_list_router_scale_jobs(1691300000001); ERROR: no job found with the job ID provided ``` Sie können den Status aller Router-Hinzufügungen verfolgen, indem Sie dieselbe Abfrage ohne Auftrags-ID ausführen, zum Beispiel: ``` SELECT * FROM rds_aurora.limitless_list_router_scale_jobs(); job_id | action | job_details | status | submission_time | message ---------------+------------+--------------------------+-------------+------------------------+------------------------------------------- 1691200000000 | ADD_ROUTER | Add 1 new Router by User | IN_PROGRESS | 2023-08-05 01:46:40+00 | 1691300000000 | ADD_ROUTER | Add 1 new Router by User | SUCCESS | 2023-08-06 05:33:20+00 | Scaling job succeeded. + | | | | | New router instance with ID 7 was created. 1691400000000 | ADD_ROUTER | Add 1 new Router by User | FAILED | 2023-08-07 09:20:00+00 | Error occurred for the add router job 1691400000000. | | | | | Retry the command. If the issue persists, contact AWS Support. 1691500000000 | ADD_ROUTER | Add 1 new Router by User | CANCELED | 2023-08-07 09:20:00+00 | Scaling job was cancelled. (4 rows) ``` Der Auftragsstatus kann einer der folgenden Werte sein: + `IN_PROGRESS`: Der Auftrag zum Hinzufügen eines Routers wurde übermittelt und ist in Bearbeitung. Sie können nur einen Auftrag nach dem anderen ausführen. + `CANCELLATION_IN_PROGRESS`: Der Auftrag zum Hinzufügen eines Routers wird vom Benutzer abgebrochen. + `CANCELED`: Der Auftrag zum Hinzufügen eines Routers wurde vom Benutzer oder vom System erfolgreich abgebrochen. + `SUCCESS`: Der Auftrag zum Hinzufügen eines Routers wurde erfolgreich abgeschlossen. Das Feld `message` enthält die Instance-ID des neuen Routers. + `FAILED`: Der Auftrag zum Hinzufügen eines Routers ist fehlgeschlagen. Das Feld `message` enthält die Einzelheiten zu dem Fehler und alle Maßnahmen, die zu dem fehlgeschlagenen Auftrag ergriffen werden können. **Anmerkung** Es gibt keinen Status `PENDING`, da Router-Hinzufügungen nicht finalisiert werden müssen. Sie verursachen keine Ausfallzeiten. ## Abbrechen einer Router-Hinzufügung Sie können einen Router-Hinzufügung mit dem Status `IN_PROGRESS` abbrechen. Sie benötigen die Auftrags-ID, um den Auftrag abzubrechen. ``` SELECT * from rds_aurora.limitless_cancel_router_scale_jobs(job_id); ``` Es wird keine Ausgabe zurückgegeben, es sei denn, es liegt ein Fehler vor. Sie können den Abbruch mithilfe einer Abfrage zur Auftragsverfolgung überwachen. # Löschen einer DB-Shard-Gruppe Sie können eine DB-Shard-Gruppe bei Bedarf löschen. Beim Löschen einer DB-Shard-Gruppe werden die Rechenknoten (Shards und Router) gelöscht, nicht jedoch der Speicher. ## Konsole Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Navigieren Sie zur Seite **Databases (Datenbanken)**. 1. Wählen Sie die DB-Shard-Gruppe aus, die Sie löschen möchten. 1. Klicken Sie bei ** Actions** auf **Delete**. 1. Geben Sie **delete me** in das Feld ein und wählen Sie dann **Löschen**. Die DB-Shard-Gruppe wird gelöscht. ## AWS CLI Zum Löschen einer DB-Shard-Gruppe verwenden Sie den AWS CLI-Befehl `delete-db-shard-group` mit folgendem Parameter: + `--db-shard-group-identifier`: Der Name der DB-Shard-Gruppe. Im folgenden Beispiel wird eine DB-Shard-Gruppe in dem DB-Cluster von Aurora PostgreSQL gelöscht, die Sie zuvor erstellt haben. ``` aws rds delete-db-shard-group --db-shard-group-identifier my-db-shard-group ``` # Hinzufügen einer DB-Shard-Gruppe zu einem vorhandenen DB-Cluster von Aurora PostgreSQL Limitless Database Sie können eine DB-Shard-Gruppe in einem vorhandenen DB-Cluster erstellen, wenn Sie beispielsweise einen DB-Cluster wiederherstellen oder die DB-Shard-Gruppe gelöscht hatten. Weitere Informationen zu den Anforderungen an den primären DB-Cluster und die DB-Shard-Gruppe finden Sie unter [Voraussetzungen und Überlegungen zu Aurora PostgreSQL Limitless DatabaseVoraussetzungen und Überlegungen zu Aurora PostgreSQL Limitless Database](limitless-reqs-limits.md). **Anmerkung** Sie können nur eine DB-Shard-Gruppe pro Cluster haben. Der DB-Cluster von Limitless Database muss sich im Status `available` befinden, bevor Sie eine DB-Shard-Gruppe erstellen können. ## Konsole Sie können die AWS-Managementkonsole verwenden, um einem vorhandenen DB-Cluster eine DB-Shard-Gruppe hinzuzufügen. **So fügen Sie eine DB-Shard-Gruppe hinzu** 1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Navigieren Sie zur Seite **Databases (Datenbanken)**. 1. Wählen Sie den DB-Cluster von Limitless Database aus, dem Sie eine DB-Shard-Gruppe hinzufügen möchten. 1. Wählen Sie für **Aktionen** die Option **DB-Shard-Gruppe hinzufügen** aus. ![\[Fügen Sie eine DB-Shard-Gruppe hinzu.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/limitless_add_shard_group.png) 1. Geben Sie die **Kennung der DB-Shard-Gruppe** ein. **Wichtig** Nachdem Sie die DB-Shard-Gruppe erstellt haben, können Sie die ID des DB-Clusters oder der DB-Shard-Gruppe nicht mehr ändern. 1. Geben Sie die **Minimale Kapazität (ACUs)** ein. Verwenden Sie einen Wert von mindestens 16 ACUs. 1. Geben Sie die **Maximale Kapazität (ACUs)** ein. Verwenden Sie einen Wert zwischen 16 und 6 144 ACUs. Weitere Informationen finden Sie unter [Korrelieren der maximalen Kapazität der DB-Shard-Gruppe mit der Anzahl der erstellten Router und Shards](limitless-cluster.md#limitless-capacity-mapping). 1. Wählen Sie für **Bereitstellung von DB-Shard-Gruppen** aus, ob Standbys für die DB-Shard-Gruppe erstellt werden sollen: + **Keine Compute-Redundanz**: Erstellt eine DB-Shard-Gruppe ohne Standbys für jeden Shard. Dies ist der Standardwert. + **Compute-Redundanz mit einem einzigen Failover-Ziel**: Erstellt eine DB-Shard-Gruppe mit einem Compute-Standby in einer anderen Availability Zone (AZ). + **Compute-Redundanz mit zwei Failover-Zielen**: Erstellt eine DB-Shard-Gruppe mit zwei Compute-Standbys in zwei verschiedenen AZs. 1. Wählen Sie aus, ob die DB-Shard-Gruppe öffentlich zugänglich gemacht werden soll. **Anmerkung** Sie können diese Einstellung nicht mehr ändern, nachdem Sie die DB-Shard-Gruppe erstellt haben. 1. Wählen Sie **DB-Shard-Gruppe hinzufügen** aus. ## AWS CLI Verwenden Sie den AWS CLI-Befehl `create-db-shard-group`, um eine neue DB-Shard-Gruppe zu erstellen. Die folgenden Parameter sind erforderlich: + `--db-cluster-identifier`: Der DB-Cluster, zu dem die DB-Shard-Gruppe gehört. + `--db-shard-group-identifier`: Der Name der DB-Shard-Gruppe. Die Kennung der DB-Shard-Gruppe hat die folgenden Einschränkungen: + Muss in dem AWS-Konto und in der AWS-Region, in der Sie sie erstellen, eindeutig sein. + Muss zwischen 1 und 63 Buchstaben, Zahlen oder Bindestriche enthalten. + Das erste Zeichen muss ein Buchstabe sein. + Darf nicht mit einem Bindestrich enden oder zwei aufeinanderfolgende Bindestriche enthalten. **Wichtig** Nachdem Sie die DB-Shard-Gruppe erstellt haben, können Sie die ID des DB-Clusters oder der DB-Shard-Gruppe nicht mehr ändern. + `--max-acu`: Die maximale Kapazität der DB-Shard-Gruppe. Verwenden Sie einen Wert zwischen 16 und 6 144 ACUs. Die folgenden Parameter sind optional: + `--compute-redundancy`: Ob Standbys für die DB-Shard-Gruppe erstellt werden sollen. Folgende Parameterwerte sind möglich: + `0`: Erstellt eine DB-Shard-Gruppe ohne Standbys für jeden Shard. Dies ist der Standardwert. + `1`: Erstellt eine DB-Shard-Gruppe mit einem Compute-Standby in einer anderen Availability Zone (AZ). + `2`: Erstellt eine DB-Shard-Gruppe mit zwei Compute-Standbys in zwei verschiedenen AZs. **Anmerkung** Wenn Sie die Rechenredundanz auf einen Wert ungleich Null setzen, wird die Gesamtzahl der Knoten verdoppelt oder verdreifacht. Dies führt zu zusätzlichen Kosten. + `--min-acu`: Die minimale Kapazität Ihrer DB-Shard-Gruppe. Sie muss mindestens 16 ACUs umfassen, was dem Standardwert entspricht. + `--publicly-accessible|--no-publicly-accessible`: Ob der DB-Shard-Gruppe öffentlich zugängliche IP-Adressen zugewiesen werden sollen. Der Zugriff auf die DB-Shard-Gruppe wird von den von dem Cluster verwendeten Sicherheitsgruppen kontrolliert. Der Standardwert ist `--no-publicly-accessible`. **Anmerkung** Sie können diese Einstellung nicht mehr ändern, nachdem Sie die DB-Shard-Gruppe erstellt haben. Im folgenden Beispiel wird eine DB-Shard-Gruppe in einem DB-Cluster von Aurora-PostgreSQL erstellt. ``` aws rds create-db-shard-group \ --db-cluster-identifier my-db-cluster \ --db-shard-group-identifier my-new-shard-group \ --max-acu 1000 ``` Die Ausgabe sieht in etwa folgendermaßen aus: ``` { "Status": "CREATING", "Endpoint": "my-db-cluster.limitless-ckifpdyyyxxx.us-east-1.rds.amazonaws.com", "PubliclyAccessible": false, "DBClusterIdentifier": "my-db-cluster", "MaxACU": 1000.0, "DBShardGroupIdentifier": "my-new-shard-group", "DBShardGroupResourceId": "shardgroup-8986d309a93c4da1b1455add17abcdef", "ComputeRedundancy": 0 } ``` # Erstellen von Tabellen in Aurora PostgreSQL Limitless Database Es gibt in Aurora PostgreSQL Limitless Database drei Arten von Tabellen, die Ihre Daten enthalten: + Standard: Sie sind der Standardtabellentyp in Aurora PostgreSQL Limitless Database. Sie erstellen Standardtabellen mit dem Befehl [CREATE TABLE](https://www.postgresql.org/docs/current/sql-createtable.html) und können DDL-Operationen (Data Description Language) und DML-Operationen (Data Manipulation Language) an ihnen ausführen. Standardtabellen sind keine verteilten Tabellen. Sie werden auf einem der vom System intern ausgewählten Shards gespeichert. + Sharded: Diese Tabellen sind auf mehrere Shards verteilt. Die Daten werden auf Grundlage der Werte der angegebenen Spalten in der Tabelle auf die Shards aufgeteilt. Dieser Satz von Spalten wird als Shard-Schlüssel bezeichnet. + Referenz: Diese Tabellen werden auf allen Shards repliziert. Sie werden für selten geänderte Referenzdaten wie Produktkataloge und Postleitzahlen verwendet. Auf Shards können Join-Abfragen zwischen Referenz- und Shard-Tabellen ausgeführt werden, wodurch unnötige Datenbewegungen zwischen Shards und Routern vermieden werden. Es gibt zwei Möglichkeiten, Limitless-Tabellen zu erstellen: + [Erstellen von Limitless-Tabellen mithilfe von Variablen](limitless-creating-config.md): Verwenden Sie diese Methode, wenn Sie neue Sharded- und Referenz-Tabellen erstellen möchten. + [Konvertieren von Standardtabellen in Limitless-Tabellen](limitless-converting-standard.md): Verwenden Sie diese Methode, wenn Sie bestehende Standardtabellen in Sharded-und Referenztabellen konvertieren möchten. Wir bieten auch [Beispielschemata](limitless-sample-schemas.md) für Aurora PostgreSQL Limitless Database. # Erstellen von Limitless-Tabellen mithilfe von Variablen Sie können mit Variablen Sharded- und Referenztabellen erstellen, indem Sie den Modus zur Tabellenerstellung festlegen. Die von Ihnen erstellten Tabellen verwenden dann diesen Modus, bis Sie einen anderen festlegen. Verwenden Sie die folgenden Variablen, um Sharded- und Referenztabellen zu erstellen: + `rds_aurora.limitless_create_table_mode`: Legen Sie diese Sitzungsvariable auf `sharded` oder `reference` fest. Der Standardwert dieser Variable lautet `standard`. + `rds_aurora.limitless_create_table_shard_key`: Legen Sie für diese Sitzungsvariable ein Array von Spaltennamen fest, die als Shard-Schlüssel verwendet werden sollen. Diese Variable wird ignoriert, wenn `rds_aurora.limitless_create_table_mode` nicht `sharded` ist. Formatieren Sie den Wert als `untyped array literal`, ähnlich wie beim Einfügen von Literalen in eine Array-Spalte. Weitere Informationen finden Sie unter [Arrays](https://www.postgresql.org/docs/current/arrays.html) in der PostgreSQL-Dokumentation. + `rds_aurora.limitless_create_table_collocate_with`: Legen Sie für diese Sitzungsvariable einen bestimmten Tabellennamen fest, um neu erstellte Tabellen dieser Tabelle zuzuordnen. Wenn zwei oder mehr Tabellen mit demselben Shard-Schlüssel „gesharded“ werden, können Sie diese Tabellen explizit einander zuordnen (zusammenfassen). Wenn zwei oder mehr Tabellen zusammengefasst werden, werden Zeilen aus diesen Tabellen mit denselben Shard-Schlüsselwerten auf demselben Shard platziert. Die Zusammenfassung hilft dabei, einige Operationen auf einen einzigen Shard zu beschränken, was zu einer besseren Leistung führt. **Anmerkung** Alle primären und eindeutigen Schlüssel müssen den Shard-Schlüssel enthalten. Das bedeutet, dass der Shard-Schlüssel eine Teilmenge des primären oder eindeutigen Schlüssels ist. Limitless-Tabellen haben einige Einschränkungen. Weitere Informationen finden Sie unter [DDL-Einschränkungen und andere Informationen für Aurora PostgreSQL Limitless Database](limitless-reference.DDL-limitations.md). **Topics** + [ ## Beispiele für die Verwendung von Variablen zur Erstellung von Limitless-Tabellen ](#limitless-tables-examples) + [ ## Tabellenansichten für Aurora PostgreSQL Limitless Database ](#limitless-table-views) ## Beispiele für die Verwendung von Variablen zur Erstellung von Limitless-Tabellen In den folgenden Beispielen wird gezeigt, wie Sie diese Variablen verwenden, um Sharded- und Referenztabellen zu erstellen. Erstellen Sie eine Sharded-Tabelle mit dem Namen `items` und dem Shard-Schlüssel `id`. ``` BEGIN; SET LOCAL rds_aurora.limitless_create_table_mode='sharded'; SET LOCAL rds_aurora.limitless_create_table_shard_key='{"id"}'; CREATE TABLE items(id int, val int, item text); COMMIT; ``` Erstellen Sie eine Sharded-Tabelle mit dem Namen `items` und einem Shard-Schlüssel, der sich aus den Spalten `item_id` und `item_cat` zusammensetzt. ``` BEGIN; SET LOCAL rds_aurora.limitless_create_table_mode='sharded'; SET LOCAL rds_aurora.limitless_create_table_shard_key='{"item_id", "item_cat"}'; CREATE TABLE items(item_id int, item_cat varchar, val int, item text); COMMIT; ``` Erstellen Sie eine Sharded-Tabelle mit dem Namen `item_description` und einem Shard-Schlüssel, der sich aus den `item_id` und `item_cat` zusammensetzt, und ordnen Sie sie der Tabelle `items` aus dem vorherigen Beispiel zu. ``` BEGIN; SET LOCAL rds_aurora.limitless_create_table_mode='sharded'; SET LOCAL rds_aurora.limitless_create_table_shard_key='{"item_id", "item_cat"}'; SET LOCAL rds_aurora.limitless_create_table_collocate_with='items'; CREATE TABLE item_description(item_id int, item_cat varchar, color_id int); COMMIT; ``` Erstellen Sie eine Referenztabelle mit dem Namen `colors`. ``` BEGIN; SET LOCAL rds_aurora.limitless_create_table_mode='reference'; CREATE TABLE colors(color_id int primary key, color varchar); COMMIT; ``` Verwenden Sie die folgende Anweisung, um die Sitzungsvariable `rds_aurora.limitless_create_table_mode` auf `standard` zurückzusetzen: ``` RESET rds_aurora.limitless_create_table_mode; ``` Nachdem Sie diese Variable zurückgesetzt haben, werden Tabellen als Standardtabellen erstellt, was der Standardeinstellung entspricht. Weitere Informationen zu Standardtabellen finden Sie unter [Konvertieren von Standardtabellen in Limitless-Tabellen](limitless-converting-standard.md). ## Tabellenansichten für Aurora PostgreSQL Limitless Database Informationen zu Limitless-Database-Tabellen finden Sie anhand der folgenden Ansichten. **rds\$1aurora.limitless\$1tables** Die Ansicht `rds_aurora.limitless_tables` enthält Informationen über Limitless-Tabellen und deren Typen. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_tables; table_gid | local_oid | schema_name | table_name | table_status | table_type | distribution_key -----------+-----------+-------------+-------------+--------------+-------------+------------------ 5 | 18635 | public | standard | active | standard | 6 | 18641 | public | ref | active | reference | 7 | 18797 | public | orders | active | sharded | HASH (order_id) 2 | 18579 | public | customer | active | sharded | HASH (cust_id) (4 rows) ``` **rds\$1aurora.limitless\$1table\$1collocations** Die Ansicht `rds_aurora.limitless_table_collocations` enthält Informationen über zusammengefasste Sharded-Tabellen. Zum Beispiel sind die Tabellen `orders` und `customers` zusammengefasst und haben die gleiche `collocation_id`. Die Tabellen `users` und `followers` sind zusammengefasst und haben die gleiche `collocation_id`. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocations ORDER BY collocation_id; collocation_id | schema_name | table_name ----------------+-------------+------------ 16002 | public | orders 16002 | public | customers 16005 | public | users 16005 | public | followers (4 rows) ``` **rds\$1aurora.limitless\$1table\$1collocation\$1distributions** Das Ansicht `rds_aurora.limitless_table_collocation_distributions` zeigt die Schlüsselverteilung für jede Kollokation. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocation_distributions ORDER BY collocation_id, lower_bound; collocation_id | subcluster_id | lower_bound | upper_bound ----------------+---------------+----------------------+---------------------- 16002 | 6 | -9223372036854775808 | -4611686018427387904 16002 | 5 | -4611686018427387904 | 0 16002 | 4 | 0 | 4611686018427387904 16002 | 3 | 4611686018427387904 | 9223372036854775807 16005 | 6 | -9223372036854775808 | -4611686018427387904 16005 | 5 | -4611686018427387904 | 0 16005 | 4 | 0 | 4611686018427387904 16005 | 3 | 4611686018427387904 | 9223372036854775807 (8 rows) ``` # Konvertieren von Standardtabellen in Limitless-Tabellen Sie können Standardtabellen in Sharded- oder Referenztabellen konvertieren. Während der Konvertierung werden Daten aus der Standardtabelle in die verteilte Tabelle verschoben. Anschließend wird die Quell-Standardtabelle gelöscht. Daten werden mit dem Befehl `INSERT INTO SELECT FROM` verschoben. **Contents** + [ ## Erstellen von Sharded-Tabellen ](#limitless-creating-sharded) + [ ## Erstellen von zusammengefassten Tabellen ](#limitless-creating-sharded.colocated) + [ ## Erstellen von Referenztabellen ](#limitless-creating-reference) ## Erstellen von Sharded-Tabellen Sie erstellen Sharded-Tabellen, indem Sie das Verfahren `rds_aurora.limitless_alter_table_type_sharded` für Standardtabellen ausführen. Dieses Verfahren verwendet eine Standardtabelle und eine Liste von Spalten und verteilt dann die angegebene Tabelle, wobei die Spaltenliste als Shard-Schlüssel verwendet wird. Das Verfahren wird synchron ausgeführt und erwirbt eine `ACCESS EXCLUSIVE`-Sperre für die Tabelle. Nachdem das Verfahren erfolgreich abgeschlossen wurde, wird die Quell-Standardtabelle gelöscht, und eine Shard-Tabelle mit demselben Namen wird verfügbar. Das Verfahren `rds_aurora.limitless_alter_table_type_sharded` verwendet die folgende Syntax: ``` postgres=> CALL rds_aurora.limitless_alter_table_type_sharded('schema.table', ARRAY['shard_key1', 'shard_key2', ... 'shard_keyn']); ``` Das Verfahren erfordert die folgenden Parameter: + `schema`: Das Datenbankschema, das die Tabelle enthält, die „gesharded“ werden soll. Wenn das Schema nicht angegeben ist, verwendet das Verfahren den `search_path`. + `table`: Die Tabelle, die „gesharded“ werden soll. + `shard_keyn`: Eine Reihe von Tabellenspalten, die als Shard-Schlüssel verwendet werden sollen. Shard-Schlüsselwerte sind Zeichenkettenliterale und unterscheiden daher zwischen Groß- und Kleinschreibung. Wenn ein Shard-Schlüssel ein einfaches Anführungszeichen (') enthält, verwenden Sie ein anderes einfaches Anführungszeichen, um es aufzuheben. Wenn beispielsweise eine Tabellenspalte `customer's id` genannt wird, verwenden Sie `customer''s id` als Shard-Schlüssel. Backslashes (\$1) und doppelte Anführungszeichen (") müssen nicht aufgehoben werden. **Anmerkung** Alle primären und eindeutigen Schlüssel müssen den Shard-Schlüssel enthalten. Das bedeutet, dass der Shard-Schlüssel eine Teilmenge des primären oder eindeutigen Schlüssels ist. In Shard-Tabellen unterstützt die Einschränkung `CHECK` keine Ausdrücke. Weitere Informationen finden Sie unter [Beschränkungen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Constraints). **So erstellen Sie eine Sharded-Tabelle** Das folgende Beispiel zeigt, wie Sie die Sharded-Tabelle `customer` mit dem Shard-Schlüssel `customer_id` erstellen. 1. Erstellen Sie die Standardtabelle. ``` CREATE TABLE customer (customer_id INT PRIMARY KEY NOT NULL, zipcode INT, email VARCHAR); ``` 1. Konvertieren Sie die Standardtabelle in eine Sharded-Tabelle. ``` postgres=> CALL rds_aurora.limitless_alter_table_type_sharded('public.customer', ARRAY['customer_id']); postgres=> \d List of relations Schema | Name | Type | Owner --------+--------------+-------------------+-------------------- public | customer | partitioned table | postgres_limitless public | customer_fs1 | foreign table | postgres_limitless public | customer_fs2 | foreign table | postgres_limitless public | customer_fs3 | foreign table | postgres_limitless public | customer_fs4 | foreign table | postgres_limitless public | customer_fs5 | foreign table | postgres_limitless (6 rows) ``` ## Erstellen von zusammengefassten Tabellen Wenn zwei oder mehr Tabellen mit demselben Shard-Schlüssel „gesharded“ werden, können Sie diese Tabellen explizit einander zuordnen (zusammenfassen). Wenn zwei oder mehr Tabellen zusammengefasst werden, werden Zeilen aus diesen Tabellen mit denselben Shard-Schlüsselwerten auf demselben Shard platziert. Die Zusammenfassung hilft dabei, einige Operationen auf einen einzigen Shard zu beschränken, was zu einer besseren Leistung führt. Sie verwenden das Verfahren `rds_aurora.limitless_alter_table_type_sharded` mit der folgenden Syntax: ``` postgres=> CALL rds_aurora.limitless_alter_table_type_sharded('schema.collocated_table', ARRAY['shard_key1', 'shard_key2', ... 'shard_keyn'], 'schema.sharded_table'); ``` Das Verfahren erfordert die folgenden Parameter: + `schema`: Das Datenbankschema, das die zusammenzufassenden Tabellen enthält. Wenn das Schema nicht angegeben ist, verwendet das Verfahren den `search_path`. + `collocated_table`: Die Tabelle, die mit der anderen zusammengefasst werden soll. + `shard_keyn`: Eine Reihe von Tabellenspalten, die als Shard-Schlüssel verwendet werden sollen. Sie müssen denselben Shard-Schlüssel wie für die ursprüngliche Sharded-Tabelle verwenden, einschließlich derselben Spaltennamen und Spaltentypen. + `sharded_table`: Die Sharded-Tabelle, mit der Sie die `collocated_table` zusammenfassen. **So erstellen Sie eine zusammengefasste Tabelle** 1. Erstellen Sie die erste Sharding-Tabelle, indem Sie das Verfahren in [Erstellen von Sharded-Tabellen](#limitless-creating-sharded) befolgen. 1. Erstellen Sie die Standardtabelle für die zusammengefasste Tabelle. ``` CREATE TABLE mytable2 (customer_id INT PRIMARY KEY NOT NULL, column1 INT, column2 VARCHAR); ``` 1. Konvertieren Sie die Standardtabelle in eine zusammengefasste Tabelle. ``` postgres=> CALL rds_aurora.limitless_alter_table_type_sharded('public.mytable2', ARRAY['customer_id'], 'public.customer'); postgres=> \d List of relations Schema | Name | Type | Owner --------+--------------+-------------------+-------------------- public | customer | partitioned table | postgres_limitless public | customer_fs1 | foreign table | postgres_limitless public | customer_fs2 | foreign table | postgres_limitless public | customer_fs3 | foreign table | postgres_limitless public | customer_fs4 | foreign table | postgres_limitless public | customer_fs5 | foreign table | postgres_limitless public | mytable2 | partitioned table | postgres_limitless public | mytable2_fs1 | foreign table | postgres_limitless public | mytable2_fs2 | foreign table | postgres_limitless public | mytable2_fs3 | foreign table | postgres_limitless public | mytable2_fs4 | foreign table | postgres_limitless public | mytable2_fs5 | foreign table | postgres_limitless (12 rows) ``` ## Erstellen von Referenztabellen Sie erstellen Referenztabellen, indem Sie das Verfahren `rds_aurora.limitless_alter_table_type_reference` für Standardtabellen ausführen. Dieses Verfahren repliziert eine bestimmte Tabelle auf alle Shards in der DB-Shard-Gruppe und ändert den Tabellentyp in „Referenz“. Das Verfahren wird synchron ausgeführt und erwirbt eine `ACCESS EXCLUSIVE`-Sperre für die Tabelle. Nachdem das Verfahren erfolgreich abgeschlossen wurde, wird die Quell-Standardtabelle gelöscht, und eine Referenztabelle mit demselben Namen wird verfügbar. Das Verfahren `rds_aurora.limitless_alter_table_type_reference` verwendet die folgende Syntax: ``` postgres=> CALL rds_aurora.limitless_alter_table_type_reference('schema.table'); ``` Das gespeicherte Verfahren erfordert die folgenden Parameter: + `schema`: Das Datenbankschema, das die Tabelle enthält, die repliziert werden soll. Wenn das Schema nicht angegeben ist, verwendet das Verfahren den `search_path`. + `table`: Die Tabelle, die repliziert werden soll. **Anmerkung** Die Standardtabelle, aus der Sie die Referenztabelle erstellen, muss über einen Primärschlüssel verfügen. In Referenztabellen unterstützt die Einschränkung `CHECK` keine Ausdrücke. Die vorherige Funktion, `limitless_table_alter_type_reference`, ist veraltet. **So erstellen Sie eine Referenztabelle** Das folgende Beispiel zeigt, wie Sie die Referenztabelle `zipcodes` erstellen. 1. Erstellen Sie die Standardtabelle. ``` CREATE TABLE zipcodes (zipcode INT PRIMARY KEY, details VARCHAR); ``` 1. Konvertieren Sie die Standardtabelle in eine Referenztabelle. ``` CALL rds_aurora.limitless_alter_table_type_reference('public.zipcodes'); postgres=> \d List of relations Schema | Name | Type | Owner --------+--------------+-------------------+-------------------- public | customer | partitioned table | postgres_limitless public | customer_fs1 | foreign table | postgres_limitless public | customer_fs2 | foreign table | postgres_limitless public | customer_fs3 | foreign table | postgres_limitless public | customer_fs4 | foreign table | postgres_limitless public | customer_fs5 | foreign table | postgres_limitless public | zipcodes | foreign table | postgres_limitless (7 rows) ``` Die Ausgabe zeigt die Sharded-Tabelle `customer` und die Referenztabelle `zipcodes`. # Beispielschemata für Aurora PostgreSQL Limitless Database Wir stellen Ihnen die folgenden Beispielschemata für Aurora PostgreSQL Limitless Database zur Verfügung: + [Beispielschema für Limitless E-Commerce](https://github.com/aws-samples/sample-schemas-for-amazon-aurora-postgresql-limitless-database/tree/main/limitless_ec_sample_schema) + [Limitless pgbench](https://github.com/aws-samples/sample-schemas-for-amazon-aurora-postgresql-limitless-database/tree/main/limitless_pgbench) Sie können diese Schemata verwenden, um schnell eine Beispieldatenbank zu erstellen und Daten in Tabellen von Aurora PostgreSQL Limitless Database zu laden. Weitere Informationen finden Sie im [GitHub-Repository](https://github.com/aws-samples/sample-schemas-for-amazon-aurora-postgresql-limitless-database). # Laden von Daten in Aurora PostgreSQL Limitless Database Sie können Daten mithilfe des `COPY`-Befehls oder des Dienstprogramms zum Laden von Daten in Tabellen von Aurora PostgreSQL Limitless Database laden. **Anmerkung** Sie können Daten in Standard-, Sharded- und Referenztabellen laden. **Contents** + [ # Verwenden des COPY-Befehls in Aurora PostgreSQL Limitless Database ](limitless-load.copy.md) + [ ## Verwenden des COPY-Befehls, um Daten in Aurora PostgreSQL Limitless Database zu laden ](limitless-load.copy.md#limitless-load.copy-to) + [ ### Unterteilen von Daten in mehrere Dateien ](limitless-load.copy.md#limitless-load.copy-split) + [ ## Kopieren von Limitless-Database-Daten in eine Datei mit dem COPY-Befehl ](limitless-load.copy.md#limitless-load.copy-from) + [ # Verwenden des Dienstprogramms zum Laden von Daten für Aurora PostgreSQL Limitless Database ](limitless-load.utility.md) + [ ## Einschränkungen ](limitless-load.utility.md#limitless-load.limitations) + [ ## Voraussetzungen ](limitless-load.utility.md#limitless-load.prereqs) + [ ## Vorbereiten der Quelldatenbank ](limitless-load.utility.md#limitless-load.source) + [ ## Vorbereiten der Zieldatenbank ](limitless-load.utility.md#limitless-load.destination) + [ ## Erstellen von Datenbank-Anmeldeinformationen ](limitless-load.utility.md#limitless-load.users) + [ ### Erstellen Sie die Quelldatenbank-Anmeldeinformationen ](limitless-load.utility.md#limitless-load.users.source) + [ ### Erstellen Sie die Anmeldeinformationen für die Zieldatenbank ](limitless-load.utility.md#limitless-load.users.destination) + [ # Einrichten der Datenbankauthentifizierung und des Ressourcenzugriffs mithilfe eines Skripts ](limitless-load.script.md) + [ ## Setup-Skript für das Datenladeprogramm ](limitless-load.script.md#limitless-load.script.file) + [ ## Ausgabe aus dem Setup-Skript des Dienstprogramms zum Laden von Daten ](limitless-load.script.md#limitless-load.script.output) + [ ## Bereinigen von fehlerhaften Ressourcen ](limitless-load.script.md#limitless-load.script.cleanup) + [ # Manuelles Einrichten der Datenbankauthentifizierung und des Ressourcenzugriffs ](limitless-load.manual.md) + [ ## Erstellung des vom Kunden verwalteten AWS KMS key ](limitless-load.manual.md#limitless-load.auth.create-kms) + [ ## Erstellen der Datenbank-Secrets ](limitless-load.manual.md#limitless-load.auth.secrets) + [ ## Erstellen der IAM-Rolle ](limitless-load.manual.md#limitless-load.auth.iam-role) + [ ## Aktualisierung der vom Kunden verwalteten AWS KMS key ](limitless-load.manual.md#limitless-load.auth.update-kms) + [ ## Hinzufügen der Berechtigungsrichtlinien für die IAM-Rolle ](limitless-load.manual.md#limitless-load.auth.iam-policy) + [ # Laden von Daten aus einem DB-Cluster von Aurora PostgreSQL oder einer DB-Instance von RDS für Postgre ](limitless-load.data.md) + [ # Überwachen des Ladens von Daten ](limitless-load.monitor.md) + [ ## Auflisten von Aufträgen zum Laden von Daten ](limitless-load.monitor.md#limitless-load.monitor-list) + [ ## Anzeigen der Details von Aufträgen zum Laden von Daten mithilfe der Auftrags-ID ](limitless-load.monitor.md#limitless-load.monitor-describe) + [ ## Überwachen der Amazon-CloudWatch-Protokollgruppe ](limitless-load.monitor.md#limitless-load.monitor-cwl) + [ ## Überwachen von RDS-Ereignissen ](limitless-load.monitor.md#limitless-load.monitor-events) + [ # Abbrechen eines Auftrags zum Laden von Daten ](limitless-load.cancel.md) # Verwenden des COPY-Befehls in Aurora PostgreSQL Limitless Database Sie können die Funktion[\$1copy](https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-META-COMMANDS-COPY) im Dienstprogramm `psql` verwenden, um Daten in und aus Aurora PostgreSQL Limitless Database zu importieren und zu exportieren. ## Verwenden des COPY-Befehls, um Daten in Aurora PostgreSQL Limitless Database zu laden Aurora PostgreSQL Limitless Database ist mit der [\$1copy](https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-META-COMMANDS-COPY)-Funktionalität im Dienstprogramm `psql` zum Importieren von Daten kompatibel. In Limitless Database wird wie in Aurora PostgreSQL Folgendes nicht unterstützt: + Direkter SSH-Zugriff auf DB-Instances: Sie können eine Datendatei (z. B. im CSV-Format) nicht auf den DB-Instance-Host kopieren und `COPY` von der Datei aus ausführen. + Lokale Dateien auf der DB-Instance verwenden: Verwenden Sie `COPY ... FROM STDIN` und `COPY ... TO STDOUT`. Der `COPY`-Befehl in PostgreSQL bietet Optionen für die Arbeit mit lokalen Dateien (`FROM/TO`) und die Übertragung von Daten über eine Verbindung zwischen dem Client und dem Server (`STDIN/STDOUT`). Weitere Informationen finden Sie unter [COPY](https://www.postgresql.org/docs/current/sql-copy.html) in der PostgreSQL-Dokumentation. Der `\copy`-Befehl im PostgreSQL-Dienstprogramm `psql` funktioniert mit lokalen Dateien auf dem Computer, auf dem Sie den `psql`-Client ausführen. Er ruft den entsprechenden `COPY ... FROM STDIN`- oder `COPY ... FROM STDOUT`-Befehl auf dem Remote-Server (z. B. Limitless Database) auf, zu dem Sie eine Verbindung herstellen. Er liest Daten aus der lokalen Datei in `STDIN` ein oder schreibt an sie aus `STDOUT`. ### Unterteilen von Daten in mehrere Dateien Daten werden auf mehreren Shards in Aurora PostgreSQL Limitless Database gespeichert. Um das Laden von Daten mit `\copy` zu beschleunigen, können Sie Ihre Daten in mehrere Dateien unterteilen. Importieren Sie Daten dann unabhängig für jede Datendatei, indem Sie separate `\copy`-Befehle parallel ausführen. Sie haben beispielsweise eine Eingabedatendatei im CSV-Format mit 3 Millionen zu importierenden Zeilen. Sie können die Datei in Blöcke aufteilen, die jeweils 200 000 Zeilen (15 Blöcke) enthalten: ``` split -l200000 data.csv data_ --additional-suffix=.csv -d ``` Dies führt zu Dateien von `data_00.csv` bis `data_14.csv`. Anschließend können Sie Daten mit 15 parallelen `\copy`-Befehlen importieren, zum Beispiel: ``` psql -h dbcluster.limitless-111122223333.aws-region.rds.amazonaws.com -U username -c "\copy test_table from '/tmp/data_00.csv';" postgres_limitless & psql -h dbcluster.limitless-111122223333.aws-region.rds.amazonaws.com -U username -c "\copy test_table FROM '/tmp/data_01.csv';" postgres_limitless & ... psql -h dbcluster.limitless-111122223333.aws-region.rds.amazonaws.com -U username -c "\copy test_table FROM '/tmp/data_13.csv';" postgres_limitless & psql -h dbcluster.limitless-111122223333.aws-region.rds.amazonaws.com -U username -c "\copy test_table FROM '/tmp/data_14.csv';" postgres_limitless ``` Mit dieser Technik wird dieselbe Datenmenge etwa zehnmal schneller importiert als mit einem einzigen `\copy`-Befehl. ## Kopieren von Limitless-Database-Daten in eine Datei mit dem COPY-Befehl Sie können den Befehl [\$1copy](https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-META-COMMANDS-COPY) verwenden, um Daten aus einer Limitless-Tabelle in eine Datei zu kopieren, wie im folgenden Beispiel gezeigt: ``` postgres_limitless=> \copy test_table TO '/tmp/test_table.csv' DELIMITER ',' CSV HEADER; ``` # Verwenden des Dienstprogramms zum Laden von Daten für Aurora PostgreSQL Limitless Database Aurora bietet ein Dienstprogramm, um Daten aus einem DB-Cluster von Aurora-PostgreSQL oder einer DB-Instance von RDS für PostgreSQL direkt in Limitless Database zu laden. Sie führen die folgenden Schritte aus, um das Dienstprogramm zum Laden von Daten zu verwenden: 1. [Voraussetzungen](#limitless-load.prereqs) 1. [Vorbereiten der Quelldatenbank](#limitless-load.source) 1. [Vorbereiten der Zieldatenbank](#limitless-load.destination) 1. [Erstellen von Datenbank-Anmeldeinformationen](#limitless-load.users) 1. Eine der beiden folgenden Komponenten: + [Einrichten der Datenbankauthentifizierung und des Ressourcenzugriffs mithilfe eines Skripts](limitless-load.script.md) (empfohlen) + [Manuelles Einrichten der Datenbankauthentifizierung und des Ressourcenzugriffs](limitless-load.manual.md) 1. [Laden von Daten aus einem DB-Cluster von Aurora PostgreSQL oder einer DB-Instance von RDS für Postgre](limitless-load.data.md) ## Einschränkungen Das Dienstprogramm zum Laden von Daten hat die folgenden Einschränkungen: + Die folgenden Datentypen werden nicht unterstützt: `enum`, `ARRAY`, `BOX`, `CIRCLE`, `LINE`, `LSEG`, `PATH`, `PG_LSN`, `PG_SNAPSHOT`, `POLYGON`, `TSQUERY`, `TSVECTOR` und `TXID_SNAPSHOT`. + An erster Stelle stehende Nullen (`0`) werden beim Laden aus dem `VARBIT`-Datentyp entfernt. + Die Datenmigration schlägt fehl, wenn die Zieltabellen Fremdschlüssel enthalten. + Limitless Data Utility unterstützt die folgenden Quellkonfigurationen für Amazon RDS for PostgreSQL Multi-AZ-DB-Cluster: + Primäre Instance + Unterstützte Modi: snapshot, snapshot\$1then\$1cdc + Replikat-Instance + Unterstützter Modus: Nur Snapshot + Anforderung: hot\$1standby\$1feedback muss aktiviert sein + Nicht unterstützt: snapshot\$1then\$1cdc ## Voraussetzungen Für das Dienstprogramm zum Laden von Daten gelten die folgenden Voraussetzungen: + Die Quelldatenbank verwendet Aurora PostgreSQL oder RDS für PostgreSQL Version 11.x und höher. + Die Quelldatenbank befindet sich in derselben AWS-Konto und AWS-Region wie die Ziel-DB-Shard-Gruppe. + Der Quell-DB-Cluster oder die Quell-DB-Instance befindet sich im Status `available`. + Tabellen in der Quelldatenbank und in der Limitless-Datenbank haben dieselben Tabellennamen, Spaltennamen und Spaltendatentypen. + Die Quell- und Zieltabellen haben Primärschlüssel, die dieselben Spalten und Spaltenreihenfolgen verwenden. + Sie benötigen eine Umgebung, in der Sie eine Verbindung zu einer Limitless-Datenbank herstellen können, um Befehle zum Laden von Daten ausführen zu können. Folgende Befehle sind verfügbar: + `rds_aurora.limitless_data_load_start` + `rds_aurora.limitless_data_load_cancel` + Für CDC: + Die Quelldatenbank und die Shard-Gruppe der Ziel-DB müssen dieselbe DB-Subnetzgruppe, VPC-Sicherheitsgruppe und denselben Datenbankport verwenden. Diese Setups sind für Netzwerkverbindungen zur Quelldatenbank und zu den Routern in der DB-Shard-Gruppe vorgesehen. + Sie müssen in der Quelldatenbank logische Replikation aktivieren. Der Benutzer der Quelldatenbank muss über Leserechte für die logische Replikation verfügen. ## Vorbereiten der Quelldatenbank Um auf die Quelldatenbank für das Laden von Daten zugreifen zu können, müssen Sie eingehenden Netzwerkverkehr zulassen. Führen Sie die folgenden Schritte aus. **So lassen Sie Netzwerkverkehr zur Quelldatenbank zu** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Navigieren Sie zur Seite **Sicherheitsgruppen**. 1. Wählen Sie die **Sicherheitsgruppen-ID** für die Sicherheitsgruppe, die vom Quell-DB-Cluster oder der Quell-DB-Instance verwendet wird. Die Sicherheitsgruppen-ID lautet beispielsweise `sg-056a84f1712b77926`. 1. Gehen Sie auf der Registerkarte **Regeln für eingehenden Datenverkehr** wie folgt vor: 1. Wählen Sie **Edit inbound rules** (Regeln für eingehenden Datenverkehr bearbeiten) aus. 1. Fügen Sie eine neue Regel für eingehenden Datenverkehr für den Quell-DB-Cluster oder die Quell-DB-Instance hinzu: + Portbereich: Datenbankport für die Quelldatenbank, in der Regel `5432` + Sicherheitsgruppen-ID: `sg-056a84f1712b77926` in diesem Beispiel ![\[Fügen Sie eine Regel für eingehenden Datenverkehr für die Quelldatenbank hinzu.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/limitless_self_access_inbound_rule.png) 1. Gehen Sie auf der Registerkarte **Regeln für ausgehenden Datenverkehr** wie folgt vor: 1. Wählen Sie **Edit outbound rules** (Regeln für ausgehenden Datenverkehr bearbeiten). 1. Fügen Sie eine neue Regel für ausgehenden Datenverkehr für den Quell-DB-Cluster oder die Quell-DB-Instance hinzu: + Datenbank-Port: `All traffic` (beinhaltet Ports `0-65535`) + Sicherheitsgruppen-ID: `sg-056a84f1712b77926` in diesem Beispiel ![\[Fügen Sie eine Regel für ausgehenden Datenverkehr für die Quelldatenbank hinzu.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/limitless_self_access_outbound_rule.png) 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon VPC-Konsole unter [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Navigieren Sie zur ** ACLsNetzwerkseite**. 1. Fügen Sie die standardmäßige Netzwerk-ACL-Konfiguration hinzu, wie unter [Standard-Netzwerk-ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#default-network-acl) beschrieben. ## Vorbereiten der Zieldatenbank Folgen Sie den Verfahren unter [Erstellen von Tabellen in Aurora PostgreSQL Limitless Database](limitless-creating.md), um die Zieltabellen in der DB-Shard-Gruppe zu erstellen. Ihre Zieltabellen müssen dieselben Schemata, Tabellennamen und Primärschlüssel wie die Quelltabellen haben. ## Erstellen von Datenbank-Anmeldeinformationen Sie müssen Datenbankbenutzer in den Quell- und Zieldatenbanken erstellen und den Benutzern die erforderlichen Rechte gewähren. Weitere Informationen dazu finden Sie im Abschnitt [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) und [GRANT](https://www.postgresql.org/docs/current/sql-grant.html) der PostgreSQL-Dokumentation. ### Erstellen Sie die Quelldatenbank-Anmeldeinformationen Der Quelldatenbankbenutzer wird in dem Befehl übergeben, mit dem Laden zu beginnen. Dieser Benutzer muss über die Berechtigung verfügen, die Replikation von der Quelldatenbank aus durchzuführen. 1. Verwenden Sie den Datenbank-Masterbenutzer (oder einen anderen Benutzer mit dieser `rds_superuser`-Rolle), um einen Quelldatenbankbenutzer mit `LOGIN`-Berechtigungen zu erstellen. ``` CREATE USER source_db_username WITH PASSWORD 'source_db_user_password'; ``` 1. Weisen Sie Ihrem Quelldatenbankbenutzer die `rds_superuser`-Rolle zu. ``` GRANT rds_superuser to source_db_username; ``` 1. Wenn Sie den Modus `full_load_and_cdc` verwenden, weisen Sie die `rds_replication`-Rolle Ihrem Quelldatenbankbenutzer zu. Die Rolle `rds_replication` erteilt Berechtigungen zur Verwaltung von logischen Slots und zum Streamen von Daten mithilfe von logischen Slots. ``` GRANT rds_replication to source_db_username; ``` ### Erstellen Sie die Anmeldeinformationen für die Zieldatenbank Der Zieldatenbankbenutzer benötigt die Berechtigung, in die Zieltabellen in der DB-Shard-Gruppe zu schreiben. 1. Verwenden Sie den Datenbank-Masterbenutzer (oder einen anderen Benutzer mit dieser `rds_superuser`-Rolle), um einen Zieldatenbankbenutzer mit `LOGIN`-Berechtigungen zu erstellen. ``` CREATE USER destination_db_username WITH PASSWORD 'destination_db_user_password'; ``` 1. Weisen Sie Ihrem Zieldatenbankbenutzer die `rds_superuser`-Rolle zu. ``` GRANT rds_superuser to destination_db_username; ``` # Einrichten der Datenbankauthentifizierung und des Ressourcenzugriffs mithilfe eines Skripts Das Setup-Skript erstellt eine vom Kunden verwaltete Rolle AWS KMS key, eine AWS Identity and Access Management (IAM) Rolle und zwei AWS Secrets Manager Geheimnisse. Führen Sie die folgenden Schritte aus, um das Setup-Skript zu verwenden: 1. Stellen Sie sicher, dass Sie das AWS CLI installiert und mit Ihren AWS-Konto Anmeldeinformationen konfiguriert haben. 1. Installieren Sie den JSON-Prozessor der `jq`-Befehlszeile. Weitere Informationen finden Sie unter [qlang/jq](https://github.com/jqlang/jq). 1. Kopieren Sie die Datei [data\$1loading\$1script.zip](samples/data_loading_script.zip) auf Ihren Computer und extrahieren Sie die Datei `data_load_aws_setup_script.sh` daraus. 1. Bearbeiten Sie das Skript und ersetzen Sie die folgenden Platzhaltervariablen durch die entsprechenden Werte: + Ihr AWS-Konto + Das AWS-Region + Anmeldeinformationen für die Quelldatenbank + Anmeldeinformationen für die Zieldatenbank 1. Öffnen Sie ein neues Terminal auf Ihrem Computer und führen Sie den folgenden Befehl aus: ``` bash ./data_load_aws_setup_script.sh ``` ## Setup-Skript für das Datenladeprogramm Wir stellen den Text der Datei `data_load_aws_setup_script.sh` hier als Referenz zur Verfügung. ``` #!/bin/bash # Aurora Limitless data loading - AWS resources setup script # # Set up the account credentials in advance. # # Update the following script variables. # ################################### #### Start of variable section #### ACCOUNT_ID="12-digit_AWS_account_ID" REGION="AWS_Region" DATE=$(date +'%m%d%H%M%S') RANDOM_SUFFIX="${DATE}" SOURCE_SECRET_NAME="secret-source-${DATE}" SOURCE_USERNAME="source_db_username" SOURCE_PASSWORD="source_db_password" DESTINATION_SECRET_NAME="secret-destination-${DATE}" DESTINATION_USERNAME="destination_db_username" DESTINATION_PASSWORD="destination_db_password" DATA_LOAD_IAM_ROLE_NAME="aurora-data-loader-${RANDOM_SUFFIX}" TMP_WORK_DIR="./tmp_data_load_aws_resource_setup/" #### End of variable section #### ################################# # Main logic start echo "DATE - [${DATE}]" echo "RANDOM_SUFFIX - [${RANDOM_SUFFIX}]" echo 'START!' mkdir -p $TMP_WORK_DIR # Create the symmetric KMS key for encryption and decryption. TMP_FILE_PATH="${TMP_WORK_DIR}tmp_create_key_response.txt" aws kms create-key --region $REGION | tee $TMP_FILE_PATH KMS_KEY_ARN=$(cat $TMP_FILE_PATH | jq -r '.KeyMetadata.Arn') aws kms create-alias \ --alias-name alias/"${DATA_LOAD_IAM_ROLE_NAME}-key" \ --target-key-id $KMS_KEY_ARN \ --region $REGION # Create the source secret. TMP_FILE_PATH="${TMP_WORK_DIR}tmp_create_source_secret_response.txt" aws secretsmanager create-secret \ --name $SOURCE_SECRET_NAME \ --kms-key-id $KMS_KEY_ARN \ --secret-string "{\"username\":\"$SOURCE_USERNAME\",\"password\":\"$SOURCE_PASSWORD\"}" \ --region $REGION \ | tee $TMP_FILE_PATH SOURCE_SECRET_ARN=$(cat $TMP_FILE_PATH | jq -r '.ARN') # Create the destination secret. TMP_FILE_PATH="${TMP_WORK_DIR}tmp_create_destination_secret_response.txt" aws secretsmanager create-secret \ --name $DESTINATION_SECRET_NAME \ --kms-key-id $KMS_KEY_ARN \ --secret-string "{\"username\":\"$DESTINATION_USERNAME\",\"password\":\"$DESTINATION_PASSWORD\"}" \ --region $REGION \ | tee $TMP_FILE_PATH DESTINATION_SECRET_ARN=$(cat $TMP_FILE_PATH | jq -r '.ARN') # Create the RDS trust policy JSON file. # Use only rds.amazonaws.com for RDS PROD use cases. TRUST_POLICY_PATH="${TMP_WORK_DIR}rds_trust_policy.json" echo '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "rds.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }' > $TRUST_POLICY_PATH # Create the IAM role. TMP_FILE_PATH="${TMP_WORK_DIR}tmp_create_iam_role_response.txt" aws iam create-role \ --role-name $DATA_LOAD_IAM_ROLE_NAME \ --assume-role-policy-document "file://${TRUST_POLICY_PATH}" \ --tags Key=assumer,Value=aurora_limitless_table_data_load \ --region $REGION \ | tee $TMP_FILE_PATH IAM_ROLE_ARN=$(cat $TMP_FILE_PATH | jq -r '.Role.Arn') # Create the permission policy JSON file. PERMISSION_POLICY_PATH="${TMP_WORK_DIR}data_load_permission_policy.json" permission_json_policy=$(cat <<EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "Ec2Permission", "Effect": "Allow", "Action": [ "ec2:DescribeNetworkInterfaces", "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:CreateNetworkInterfacePermission", "ec2:DeleteNetworkInterfacePermission", "ec2:DescribeNetworkInterfacePermissions", "ec2:ModifyNetworkInterfaceAttribute", "ec2:DescribeNetworkInterfaceAttribute", "ec2:DescribeAvailabilityZones", "ec2:DescribeRegions", "ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups", "ec2:DescribeNetworkAcls" ], "Resource": "*" }, { "Sid": "SecretsManagerPermissions", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": [ "$SOURCE_SECRET_ARN", "$DESTINATION_SECRET_ARN" ] }, { "Sid": "KmsPermissions", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKey" ], "Resource": "$KMS_KEY_ARN" }, { "Sid": "RdsPermissions", "Effect": "Allow", "Action": [ "rds:DescribeDBClusters", "rds:DescribeDBInstances" ], "Resource": "*" } ] } EOF ) echo $permission_json_policy > $PERMISSION_POLICY_PATH # Add the inline policy. aws iam put-role-policy \ --role-name $DATA_LOAD_IAM_ROLE_NAME \ --policy-name aurora-limitless-data-load-policy \ --policy-document "file://${PERMISSION_POLICY_PATH}" \ --region $REGION # Create the key policy JSON file. KEY_POLICY_PATH="${TMP_WORK_DIR}data_load_key_policy.json" key_json_policy=$(cat <<EOF { "Id": "key-aurora-limitless-data-load-$RANDOM_SUFFIX", "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::$ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": "$IAM_ROLE_ARN" }, "Action": [ "kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKey" ], "Resource": "*" } ] } EOF ) echo $key_json_policy > $KEY_POLICY_PATH # Add the key policy. TMP_FILE_PATH="${TMP_WORK_DIR}tmp_put_key_policy_response.txt" sleep 10 # sleep 10 sec for IAM role ready aws kms put-key-policy \ --key-id $KMS_KEY_ARN \ --policy-name default \ --policy "file://${KEY_POLICY_PATH}" \ --region $REGION \ | tee $TMP_FILE_PATH echo 'DONE!' echo "ACCOUNT_ID : [${ACCOUNT_ID}]" echo "REGION : [${REGION}]" echo "RANDOM_SUFFIX : [${RANDOM_SUFFIX}]" echo "IAM_ROLE_ARN : [${IAM_ROLE_ARN}]" echo "SOURCE_SECRET_ARN : [${SOURCE_SECRET_ARN}]" echo "DESTINATION_SECRET_ARN : [${DESTINATION_SECRET_ARN}]" # Example of a successful run: # ACCOUNT_ID : [012345678912] # REGION : [ap-northeast-1] # RANDOM_SUFFIX : [0305000703] # IAM_ROLE_ARN : [arn:aws:iam::012345678912:role/aurora-data-loader-0305000703] # SOURCE_SECRET_ARN : [arn:aws:secretsmanager:ap-northeast-1:012345678912:secret:secret-source-0305000703-yQDtow] # DESTINATION_SECRET_ARN : [arn:aws:secretsmanager:ap-northeast-1:012345678912:secret:secret-destination-0305000703-5d5Jy8] # If you want to manually clean up failed resource, # please remove them in the following order: # 1. IAM role. # aws iam delete-role-policy --role-name Test-Role --policy-name ExamplePolicy --region us-east-1 # aws iam delete-role --role-name Test-Role --region us-east-1 # 2. Source and destination secrets. # aws secretsmanager delete-secret --secret-id MyTestSecret --force-delete-without-recovery --region us-east-1 # 3. KDM key. # aws kms schedule-key-deletion --key-id arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab --pending-window-in-days 7 --region us-east-1 ``` ## Ausgabe aus dem Setup-Skript des Dienstprogramms zum Laden von Daten Das folgende Beispiel zeigt die Ausgabe nach erfolgreicher Ausführung des Skripts. ``` % bash ./data_load_aws_setup_script.sh DATE - [0305000703] RANDOM_SUFFIX - [0305000703] START! { "KeyMetadata": { "AWSAccountId": "123456789012", "KeyId": "1234abcd-12ab-34cd-56ef-1234567890ab", "Arn": "arn:aws:kms:ap-northeast-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": "2024-03-05T00:07:49.852000+00:00", "Enabled": true, "Description": "", "KeyUsage": "ENCRYPT_DECRYPT", "KeyState": "Enabled", "Origin": "AWS_KMS", "KeyManager": "CUSTOMER", "CustomerMasterKeySpec": "SYMMETRIC_DEFAULT", "KeySpec": "SYMMETRIC_DEFAULT", "EncryptionAlgorithms": [ "SYMMETRIC_DEFAULT" ], "MultiRegion": false } } { "ARN": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:secret-source-0305000703-yQDtow", "Name": "secret-source-0305000703", "VersionId": "a017bebe-a71b-4220-b923-6850c2599c26" } { "ARN": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:secret-destination-0305000703-5d5Jy8", "Name": "secret-destination-0305000703", "VersionId": "32a1f989-6391-46b1-9182-f65d242f5eb6" } { "Role": { "Path": "/", "RoleName": "aurora-data-loader-0305000703", "RoleId": "AROAYPX63ITQOYORQSC6U", "Arn": "arn:aws:iam::123456789012:role/aurora-data-loader-0305000703", "CreateDate": "2024-03-05T00:07:54+00:00", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "rds.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }, "Tags": [ { "Key": "assumer", "Value": "aurora_limitless_table_data_load" } ] } } DONE! ACCOUNT_ID : [123456789012] REGION : [ap-northeast-1] RANDOM_SUFFIX : [0305000703] IAM_ROLE_ARN : [arn:aws:iam::123456789012:role/aurora-data-loader-0305000703] SOURCE_SECRET_ARN : [arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:secret-source-0305000703-yQDtow] DESTINATION_SECRET_ARN : [arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:secret-destination-0305000703-5d5Jy8] ``` ## Bereinigen von fehlerhaften Ressourcen Wenn Sie fehlerhafte Ressourcen manuell bereinigen möchten, entfernen Sie sie in der folgenden Reihenfolge: 1. IAM-Rolle, zum Beispiel: ``` aws iam delete-role-policy \ --role-name Test-Role \ --policy-name ExamplePolicy aws iam delete-role \ --role-name Test-Role ``` 1. Quell- und Ziel-Secrets, zum Beispiel: ``` aws secretsmanager delete-secret \ --secret-id MyTestSecret \ --force-delete-without-recovery ``` 1. KMS-Schlüssel, zum Beispiel: ``` aws kms schedule-key-deletion \ --key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \ --pending-window-in-days 7 ``` Danach können Sie das Skript erneut ausführen. # Manuelles Einrichten der Datenbankauthentifizierung und des Ressourcenzugriffs Das manuelle Verfahren zum Einrichten der Datenbankauthentifizierung und des Ressourcenzugriffs umfasst die folgenden Schritte: 1. [Erstellung des vom Kunden verwalteten AWS KMS key](#limitless-load.auth.create-kms) 1. [Hinzufügen der Berechtigungsrichtlinien für die IAM-Rolle](#limitless-load.auth.iam-policy) 1. [Erstellen der Datenbank-Secrets](#limitless-load.auth.secrets) 1. [Erstellen der IAM-Rolle](#limitless-load.auth.iam-role) 1. [Aktualisierung der vom Kunden verwalteten AWS KMS key](#limitless-load.auth.update-kms) Dieser Vorgang ist optional und umfasst dieselben Aufgaben wie in [Einrichten der Datenbankauthentifizierung und des Ressourcenzugriffs mithilfe eines Skripts](limitless-load.script.md). Wir empfehlen die Verwendung des Skripts. ## Erstellung des vom Kunden verwalteten AWS KMS key Folgen Sie den Verfahren unter [Erstellen symmetrischer Verschlüsselungsschlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk), um einen kundenverwalteten KMS-Schlüssel zu erstellen. Sie können auch einen vorhandenen Schlüssel verwenden, wenn er diese Anforderungen erfüllt. **So erstellen Sie einen kundenverwalteten KMS-Schlüssel** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS KMS Konsole unter [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms). 1. Navigieren Sie zur Seite **Kundenverwaltete Schlüssel**. 1. Klicken Sie auf **Create key**. 1. Gehen Sie auf der Seite **Schlüssel konfigurieren** wie folgt vor: 1. Wählen Sie als **Schlüsseltyp** die Option **Symmetrisch** aus. 1. Wählen Sie für **Schlüsselnutzung** die Option **Verschlüsseln und entschlüsseln** aus. 1. Wählen Sie **Weiter** aus. 1. Geben Sie auf der Seite **Bezeichnungen hinzufügen** einen **Alias** wie **limitless** ein und wählen Sie dann **Weiter** aus. 1. Vergewissern Sie sich, dass auf der Seite **Schlüsselverwaltungsberechtigungen definieren** das Kontrollkästchen **Schlüsseladministratoren das Löschen dieses Schlüssels erlauben** aktiviert ist, und wählen Sie dann **Weiter** aus. 1. Klicken Sie auf der Seite **Schlüsselnutzungsberechtigungen definieren** auf **Weiter**. 1. Klicken Sie auf der Seite **Prüfen** auf **Beenden**. Sie aktualisieren die Schlüsselrichtlinie später. Notieren Sie sich die Amazon-Ressourcennamen (ARN) des KMS-Schlüssels, der in [Hinzufügen der Berechtigungsrichtlinien für die IAM-Rolle](#limitless-load.auth.iam-policy) verwendet werden soll. [Informationen zur Verwendung des AWS CLI zur Erstellung des vom Kunden verwalteten KMS-Schlüssels finden Sie unter [create-key und create-alias](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kms/create-key.html).](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kms/create-alias.html) ## Erstellen der Datenbank-Secrets Damit das Datenladeprogramm auf die Quell- und Zieldatenbanktabellen zugreifen kann, erstellen Sie zwei geheime Daten inAWS Secrets Manager: einen für die Quelldatenbank und einen für die Zieldatenbank. In diesen Secrets werden die Benutzernamen und Passwörter für den Zugriff auf die Quell- und Zieldatenbanken gespeichert. Folgen Sie den Verfahren unter [AWS Secrets Manager-Secret erstellen](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html), um die Schlüssel- und Wertepaar-Secrets zu erstellen. **So erstellen Sie die Datenbank-Secrets** 1. Öffnen Sie die Secrets Manager Manager-Konsole unter [https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/). 1. Wählen Sie **Store a new secret** (Ein neues Secret speichern). 1. Gehen Sie auf der Seite **Secret-Typ auswählen** wie folgt vor: 1. Wählen Sie für **Secret-Typ** die Option **Anderer Secret-Typ** aus. 1. Wählen Sie für **Schlüssel/Wert-Paare** die Registerkarte **Klartext** aus. 1. Geben Sie den folgenden JSON-Code ein, wobei `sourcedbreader` und `sourcedbpassword` die Anmeldeinformationen des Benutzers der Quelldatenbank aus [Erstellen Sie die Quelldatenbank-Anmeldeinformationen](limitless-load.utility.md#limitless-load.users.source) sind. ``` { "username":"sourcedbreader", "password":"sourcedbpassword" } ``` 1. Wählen Sie für **Verschlüsselungsschlüssel** beispielsweise den KMS-Schlüssel aus, den Sie in [Erstellung des vom Kunden verwalteten AWS KMS key](#limitless-load.auth.create-kms) erstellt haben, z. B. `limitless`. 1. Wählen Sie **Weiter** aus. 1. Geben Sie auf der Seite **Secret konfigurieren** einen **Secret-Namen** ein, wie z. B. **source\$1DB\$1secret**, und wählen Sie dann **Weiter** aus. 1. Wählen Sie auf der Seite **Drehung konfigurieren – *optional*** die Option **Weiter** aus. 1. Wählen Sie auf der Seite **Review** (Überprüfung) **Store** (Speichern) aus. 1. Wiederholen Sie dieses Verfahren für das Secret der Zieldatenbank: 1. Geben Sie den folgenden JSON-Code ein, wobei `destinationdbwriter` und `destinationdbpassword` die Anmeldeinformationen des Benutzers der Zieldatenbank aus [Erstellen Sie die Anmeldeinformationen für die Zieldatenbank](limitless-load.utility.md#limitless-load.users.destination) sind. ``` { "username":"destinationdbwriter", "password":"destinationdbpassword" } ``` 1. Geben Sie einen **Secret-Namen** ein, z. B. **destination\$1DB\$1secret**. Notieren Sie sich ARNs die Geheimnisse, in denen Sie verwenden möchten[Hinzufügen der Berechtigungsrichtlinien für die IAM-Rolle](#limitless-load.auth.iam-policy). ## Erstellen der IAM-Rolle Für das Laden von Daten müssen Sie Zugriff auf AWS Ressourcen gewähren. Um Zugriff zu gewähren, erstellen Sie die IAM-Rolle `aurora-data-loader`, indem Sie die Schritte unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) ausführen. **So erstellen Sie die IAM-Rolle** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Navigieren Sie zur Seite **Rollen**. 1. Wählen Sie **Rolle erstellen** aus. 1. Gehen Sie auf der Seite **Vertrauenswürdige Entität auswählen** wie folgt vor: 1. Wählen Sie für **Vertrauenstyp der Entität** die Option **Benutzerdefinierte Vertrauensrichtlinie** aus. 1. Geben Sie für die benutzerdefinierte Vertrauensrichtlinie den folgenden JSON-Code ein: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "rds.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ 1. Wählen Sie **Weiter** aus. 1. Wählen Sie auf der Seite **Add permissions** (Berechtigungen hinzufügen) die Option **Next** (Weiter) aus. 1. Gehen Sie auf der Seite **Benennen, prüfen und erstellen** wie folgt vor: 1. Geben Sie für **Rollenname** **aurora-data-loader** oder einen von Ihnen bevorzugten Namen ein. 1. Wählen Sie **Tag hinzufügen** aus und geben Sie das folgende Tag ein: + **Schlüssel**: **assumer** + **Value (Wert)**: **aurora\$1limitless\$1table\$1data\$1load** **Wichtig** Aurora PostgreSQL Limitless Database kann nur eine IAM-Rolle annehmen, die über dieses Tag verfügt. 1. Wählen Sie **Rolle erstellen** aus. ## Aktualisierung der vom Kunden verwalteten AWS KMS key Folgen Sie den Verfahren unter [Ändern einer Schlüsselrichtlinie](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html), um die IAM-Rolle `aurora-data-loader` zur Standard-Schlüsselrichtlinie hinzuzufügen. **So fügen Sie die IAM-Rolle zur Schlüsselrichtlinie hinzu** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS KMS Konsole unter [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms). 1. Navigieren Sie zur Seite **Kundenverwaltete Schlüssel**. 1. Wählen Sie den KMS-Schlüssel aus, den Sie in [Erstellung des vom Kunden verwalteten AWS KMS key](#limitless-load.auth.create-kms) erstellt haben, z. B. `limitless`. 1. Wählen Sie auf der Registerkarte **Schlüsselrichtlinie** für **Schlüsselbenutzer** die Option **Hinzufügen** aus. 1. Wählen **Sie im Fenster „Schlüsselbenutzer hinzufügen**“ beispielsweise den Namen der IAM-Rolle aus[Erstellen der IAM-Rolle](#limitless-load.auth.iam-role), in der Sie sie erstellt haben. **aurora-data-loader** 1. Wählen Sie **Hinzufügen** aus. ## Hinzufügen der Berechtigungsrichtlinien für die IAM-Rolle Sie müssen der erstellten IAM-Rolle Berechtigungen hinzufügen. Auf diese Weise kann das Dienstprogramm zum Laden von Daten von Aurora PostgreSQL Limitless Database auf verwandte AWS-Ressourcen zugreifen, um Netzwerkverbindungen aufzubauen und die Secrets der Anmeldeinformationen der Quell- und Ziel-DB abzurufen. Weitere Informationen finden Sie unter [Ändern einer Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage_modify.html#roles-modify_gen-policy). **So fügen Sie Berechtigungsrichtlinien hinzu** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 1. Navigieren Sie zur Seite **Rollen**. 1. Wählen Sie beispielsweise die IAM-Rolle aus[Erstellen der IAM-Rolle](#limitless-load.auth.iam-role), in der Sie erstellt haben. **aurora-data-loader** 1. Wählen Sie auf der Registerkarte **Berechtigungen** für **Berechtigungsrichtlinien** die Option **Berechtigungen hinzufügen** und dann **Inline-Richtlinie erstellen** aus. 1. Wählen Sie auf der Seite **Berechtigungen angeben** den **JSON**-Editor aus. 1. Kopieren Sie die folgende Vorlage und fügen Sie sie in den JSON-Editor ein. Ersetzen Sie dabei die Platzhalter durch die ARNs für Ihre Datenbankgeheimnisse und den KMS-Schlüssel. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Ec2Permission", "Effect": "Allow", "Action": [ "ec2:DescribeNetworkInterfaces", "ec2:CreateNetworkInterface", "ec2:DeleteNetworkInterface", "ec2:CreateNetworkInterfacePermission", "ec2:DeleteNetworkInterfacePermission", "ec2:DescribeNetworkInterfacePermissions", "ec2:ModifyNetworkInterfaceAttribute", "ec2:DescribeNetworkInterfaceAttribute", "ec2:DescribeAvailabilityZones", "ec2:DescribeRegions", "ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups", "ec2:DescribeNetworkAcls" ], "Resource": "*" }, { "Sid": "SecretsManagerPermissions", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": [ "arn:aws:secretsmanager:us-east-1:123456789012:secret:source_DB_secret-ABC123", "arn:aws:secretsmanager:us-east-1:123456789012:secret:destination_DB_secret-456DEF" ] }, { "Sid": "KmsPermissions", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:us-east-1:123456789012:key/aa11bb22-####-####-####-fedcba123456" }, { "Sid": "RdsPermissions", "Effect": "Allow", "Action": [ "rds:DescribeDBClusters", "rds:DescribeDBInstances" ], "Resource": "*" } ] } ``` ------ 1. Prüfen Sie, ob Fehler vorliegen, und beheben Sie sie. 1. Wählen Sie **Weiter** aus. 1. Geben Sie auf der Seite **Überprüfen und erstellen** einen **Richtliniennamen** ein wie z. B. **data\$1loading\$1policy**, und wählen Sie anschließend **Richtlinie erstellen** aus. # Laden von Daten aus einem DB-Cluster von Aurora PostgreSQL oder einer DB-Instance von RDS für Postgre Nachdem Sie die Ressourcen- und Authentifizierungseinrichtung abgeschlossen haben, stellen Sie eine Verbindung zum Cluster-Endpunkt her und rufen Sie die gespeicherte Prozedur `rds_aurora.limitless_data_load_start` von einer Limitless-Datenbank wie `postgres_limitless` aus auf. Die Limitless-Datenbank ist eine Datenbank in der DB-Shard-Gruppe, in die Sie Daten migrieren möchten. Diese Funktion stellt im Hintergrund asynchron eine Verbindung zu der im Befehl angegebenen Quelldatenbank her, liest die Daten aus der Quelle und lädt die Daten auf die Shards. Für eine bessere Leistung werden die Daten mithilfe paralleler Threads geladen. Die Funktion ruft einen Point-in-Time-Tabellen-Snapshot ab, indem sie einen `SELECT`-Befehl zum Lesen der Daten der im Befehl angegebenen Tabelle(n) ausführt. Sie können Daten in Sharded-, Referenz- und Standardtabellen laden. Sie können Daten in `rds_aurora.limitless_data_load_start`-Aufrufen auf Datenbank-, Schema- oder Tabellenebene laden. + Datenbank: Sie können bei jedem Aufruf jeweils eine Datenbank laden. Die Anzahl der Schemata oder Tabellen innerhalb der Datenbank ist dabei nicht begrenzt. + Schema: Sie können bei jedem Aufruf maximal 15 Schemata laden. Die Anzahl der Tabellen innerhalb jedes Schemas ist dabei nicht begrenzt. + Tabelle: Sie können bei jedem Aufruf maximal 15 Tabellen laden. **Anmerkung** Diese Funktion verwendet keine Amazon-RDS-Snapshots oder Point-in-Time-Isolierung der Datenbank. Aus Gründen der tabellenübergreifenden Konsistenz empfehlen wir, die Quelldatenbank zu klonen und auf diese geklonte Datenbank als Quelle zu verweisen. Die gespeicherte Prozedur hat die folgende Syntax. ``` CALL rds_aurora.limitless_data_load_start('source_type', 'source_DB_cluster_or_instance_ID', 'source_database_name', 'streaming_mode', 'data_loading_IAM_role_arn', 'source_DB_secret_arn', 'destination_DB_secret_arn', 'ignore_primary_key_conflict_boolean_flag', 'is_dry_run', (optional parameter) schemas/tables => ARRAY['name1', 'name2', ...]); ``` Es werden folgende Eingabeparameter verwendet: + `source_type`: Der Quelltyp: `aurora_postgresql` oder `rds_postgresql` + `source_DB_cluster_or_instance_ID`: Die ID des DB-Clusters von Aurora-PostgreSQL oder die ID der DB-Instance von RDS für PostgreSQL + `source_database_name`: Der Name der Quelldatenbank, z. B. *Postgres* + `streaming_mode`: Ob die Erfassung von Datenänderungen (Change Data Capture, CDC) einbezogen werden soll: `full_load` oder `full_load_and_cdc` + `data_loading_IAM_role_arn`: Der Amazon-Ressourcenname (ARN) der IAM-Rolle für `aurora-data-loader` + `source_DB_secret_arn`: Der geheime ARN der Quell-DB + `destination_DB_secret_arn`: Der geheime ARN der Ziel-DB + `ignore_primary_key_conflict_boolean_flag`: Ob fortgefahren werden soll, wenn ein Primärschlüssel-Konflikt auftritt: + Wenn auf `true` gesetzt, werden beim Laden von Daten neue Änderungen für Zeilen mit einem Primärschlüssel-Konflikt ignoriert. + Wenn auf `false` gesetzt, werden beim Laden von Daten die vorhandenen Zeilen in Zieltabellen überschrieben, wenn ein Primärschlüssel-Konflikt auftritt. + `is_dry_run`: Ob getestet werden soll, ob der Auftrag zum Laden von Daten eine Verbindung zu den Quell- und Zieldatenbanken herstellen kann: + Wenn auf `true` gesetzt, werden die Verbindungen getestet, ohne dass Daten geladen werden + Wenn auf `false` gesetzt, werden Daten geladen + (optional) `schemas` oder `tables`: Ein Array von Schemata oder Tabellen, die geladen werden sollen. Sie können einen der folgenden Werte angeben: + Eine Liste von Tabellen im Format `tables => ARRAY['schema1.table1', 'schema1.table2', 'schema2.table1', ...]` + Eine Liste von Schemata im Format `schemas => ARRAY['schema1', 'schema2', ...]` Wenn Sie diesen Parameter nicht einschließen, wird die gesamte angegebene Quelldatenbank migriert. Der Ausgabeparameter ist die Auftrags-ID mit einer Nachricht. Im folgenden Beispiel wird veranschaulicht, wie die gespeicherte Prozedur `rds_aurora.limitless_data_load_start` zum Laden von Daten aus einem DB-Cluster von Aurora PostgreSQL verwendet wird. ``` CALL rds_aurora.limitless_data_load_start('aurora_postgresql', 'my-db-cluster', 'postgres', 'full_load_and_cdc', 'arn:aws:iam::123456789012:role/aurora-data-loader-8f2c66', 'arn:aws:secretsmanager:us-east-1:123456789012:secret:secret-source-8f2c66-EWrr0V', 'arn:aws:secretsmanager:us-east-1:123456789012:secret:secret-destination-8f2c66-d04fbD', 'true', 'false', tables => ARRAY['public.customer', 'public.order', 'public.orderdetails']); INFO: limitless data load job id 1688761223647 is starting. ``` # Überwachen des Ladens von Daten Aurora PostgreSQL Limitless Database bietet mehrere Möglichkeiten, Aufträge zum Laden von Daten überwachen: + [Auflisten von Aufträgen zum Laden von Daten](#limitless-load.monitor-list) + [Anzeigen der Details von Aufträgen zum Laden von Daten mithilfe der Auftrags-ID](#limitless-load.monitor-describe) + [Überwachen der Amazon-CloudWatch-Protokollgruppe](#limitless-load.monitor-cwl) + [Überwachen von RDS-Ereignissen](#limitless-load.monitor-events) ## Auflisten von Aufträgen zum Laden von Daten Sie können eine Verbindung zum Cluster-Endpunkt herstellen und die Ansicht `rds_aurora.limitless_data_load_jobs` verwenden, um Aufträge zum Laden von Daten aufzulisten. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_data_load_jobs LIMIT 6; job_id | status | message | source_db_identifier | source_db_name | full_load_complete_time | progress_details | start_time | last_updated_time | streaming_mode | source_engine_type | ignore_primary_key_conflict | is_dryrun ---------------+-----------+---------+-------------------------------+----------------+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+------------------------+------------------------+-------------------+--------------------+-----------------------------+----------- 1725697520693 | COMPLETED | | persistent-kdm-auto-source-01 | postgres | 2024-09-07 08:48:15+00 | {"FULL_LOAD": {"STATUS": "COMPLETED", "DETAILS": "9 of 9 tables loaded", "COMPLETED_AT": "2024/09/07 08:48:15+00", "RECORDS_MIGRATED": 600003}} | 2024-09-07 08:47:13+00 | 2024-09-07 08:48:15+00 | full_load | aurora_postgresql | t | f 1725696114225 | COMPLETED | | persistent-kdm-auto-source-01 | postgres | 2024-09-07 08:24:20+00 | {"FULL_LOAD": {"STATUS": "COMPLETED", "DETAILS": "3 of 3 tables loaded", "COMPLETED_AT": "2024/09/07 08:24:20+00", "RECORDS_MIGRATED": 200001}} | 2024-09-07 08:23:56+00 | 2024-09-07 08:24:20+00 | full_load | aurora_postgresql | t | f 1725696067630 | COMPLETED | | persistent-kdm-auto-source-01 | postgres | 2024-09-07 08:23:45+00 | {"FULL_LOAD": {"STATUS": "COMPLETED", "DETAILS": "6 of 6 tables loaded", "COMPLETED_AT": "2024/09/07 08:23:45+00", "RECORDS_MIGRATED": 400002}} | 2024-09-07 08:23:10+00 | 2024-09-07 08:23:45+00 | full_load | aurora_postgresql | t | f 1725694221753 | CANCELED | | persistent-kdm-auto-source-01 | postgres | | {} | 2024-09-07 07:31:18+00 | 2024-09-07 07:51:49+00 | full_load_and_cdc | aurora_postgresql | t | f 1725691698210 | COMPLETED | | persistent-kdm-auto-source-01 | postgres | 2024-09-07 07:10:51+00 | {"FULL_LOAD": {"STATUS": "COMPLETED", "DETAILS": "1 of 1 tables loaded", "COMPLETED_AT": "2024/09/07 07:10:51+00", "RECORDS_MIGRATED": 100000}} | 2024-09-07 07:10:42+00 | 2024-09-07 07:10:52+00 | full_load | aurora_postgresql | t | f 1725691695049 | COMPLETED | | persistent-kdm-auto-source-01 | postgres | 2024-09-07 07:10:48+00 | {"FULL_LOAD": {"STATUS": "COMPLETED", "DETAILS": "1 of 1 tables loaded", "COMPLETED_AT": "2024/09/07 07:10:48+00", "RECORDS_MIGRATED": 100000}} | 2024-09-07 07:10:41+00 | 2024-09-07 07:10:48+00 | full_load | aurora_postgresql | t | f (6 rows) ``` Datensätze von Aufträgen werden nach 90 Tagen gelöscht. ## Anzeigen der Details von Aufträgen zum Laden von Daten mithilfe der Auftrags-ID Wenn Sie die Auftrags-ID kennen, können Sie eine Verbindung zum Cluster-Endpunkt herstellen und die Ansicht `rds_aurora.limitless_data_load_job_details` verwenden, um die Details dieses Auftrags zum Laden von Daten anzuzeigen, einschließlich des Tabellennamens, des Auftragsstatus und der Anzahl der geladenen Zeilen. Sie können die Auftrags-ID in den Antworten auf die Startfunktionen für das Laden von Daten oder in der Ansicht `rds_aurora.limitless_data_load_jobs` abrufen. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_data_load_job_details WHERE job_id='1725696114225'; job_id | destination_table_name | destination_schema_name | start_time | status | full_load_rows | full_load_total_rows | full_load_complete_time | cdc_insert | cdc_update | cdc_delete --------------+------------------------+-------------------------+------------------------+-----------+----------------+----------------------+-------------------------+------------+------------+------------ 1725696114225 | standard_1 | public | 2024-09-07 08:23:57+00 | COMPLETED | 100000 | 100000 | 2024-09-07 08:24:08+00 | 0 | 0 | 0 1725696114225 | standard_2 | public | 2024-09-07 08:24:08+00 | COMPLETED | 100000 | 100000 | 2024-09-07 08:24:17+00 | 0 | 0 | 0 1725696114225 | standard_3 | public | 2024-09-07 08:24:18+00 | COMPLETED | 1 | 1 | 2024-09-07 08:24:20+00 | 0 | 0 | 0 1725696114225 | standard_4 | public | 2024-09-07 08:23:58+00 | PENDING | 0 | 0 | | 0 | 0 | 0 (4 rows) ``` Datensätze von Aufträgen werden nach 90 Tagen gelöscht. ## Überwachen der Amazon-CloudWatch-Protokollgruppe Nachdem sich der Status des Auftrags zum Laden von Daten in `RUNNING` geändert hat, können Sie den Fortschritt der Laufzeit mithilfe von Amazon CloudWatch Logs überprüfen. **So überwachen Sie CloudWatch-Protokollstreams** Melden Sie sich bei AWS-Managementkonsole an und öffnen Sie die CloudWatch-Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Navigieren Sie zu **Protokolle** und dann zu **Protokollgruppen**. 1. Wählen Sie die Protokollgruppe **/aws/rds/aurora-limitless-database** aus. 1. Suchen Sie per **job\$1id** nach dem Protokollstream Ihres Auftrags zum Laden von Daten. Der Protokollstream hat das Muster **Data-Load-Job-*job\$1id***. 1. Wählen Sie den Protokollstream aus, um die Protokollereignisse anzusehen. Jeder Protokollstream zeigt Ereignisse, die den Auftragsstatus und die Anzahl der Zeilen enthalten, die in die Zieltabellen von Aurora PostgreSQL Limitless Database geladen wurden. Wenn ein Auftrag zum Laden von Daten fehlschlägt, wird auch ein Fehlerprotokoll erstellt, das den Fehlerstatus und die Ursache anzeigt. Datensätze von Aufträgen werden nach 90 Tagen gelöscht. ## Überwachen von RDS-Ereignissen Der Auftrag zum Laden von Daten veröffentlicht auch RDS-Ereignisse, z. B. wenn ein Auftrag erfolgreich ist, fehlschlägt oder abgebrochen wird. Sie können die Ereignisse in der Zieldatenbank ansehen. Weitere Informationen finden Sie unter [DB-Shard-Gruppenereignisse](USER_Events.Messages.md#USER_Events.Messages.shard-group). # Abbrechen eines Auftrags zum Laden von Daten Um einen Auftrag zum Laden von Daten abzubrechen, rufen Sie die gespeicherte Prozedur `rds_aurora.limitless_data_load_cancel` mit der Auftrags-ID als Eingabeparameter auf. Sie rufen diese gespeicherte Prozedur aus derselben Datenbank in der DB-Shard-Gruppe auf, in der der spezifische Auftrag zum Laden von Daten gestartet wurde. Zum Beispiel: ``` CALL rds_aurora.limitless_data_load_cancel(12345); INFO: limitless data load job with id 12345 is canceling without rollback. ``` Sie können einen Auftrag zum Laden von Daten, der nicht existiert oder nicht in derselben DB-Shard-Gruppe ausgeführt wird, nicht abbrechen. Das Dienstprogramm zum Laden von Daten in Aurora PostgreSQL Limitless Database belässt geladene Daten ohne Rollback in den Zieltabellen, wie die Antwort zeigt. Wenn Sie die geladenen Daten nicht behalten möchten, empfehlen wir, die Zieltabellen zu kürzen. # Abfragen einer Aurora PostgreSQL Limitless Database Aurora PostgreSQL Limitless Database ist mit der PostgreSQL-Syntax für Abfragen kompatibel. Sie können Ihre Limitless Database mit `psql` oder einem anderen Verbindungsdienstprogramm abfragen, das mit PostgreSQL funktioniert. Um Abfragen auszuführen, stellen Sie eine Verbindung zum Limitless-Endpunkt her, wie unter [Herstellen einer Verbindung zu Ihrem Aurora PostgreSQL Limitless Database-DB-Cluster](limitless-shard.md#limitless-endpoint) gezeigt. Alle PostgreSQL-`SELECT`-Abfragen werden in Aurora PostgreSQL Limitless Database unterstützt. Abfragen werden jedoch auf zwei Ebenen ausgeführt: 1. Router, an den der Client die Anfrage sendet 1. Shards, auf denen sich die Daten befinden Die Leistung hängt davon ab, ob die Datenbank so abgefragt wird, dass ein hohes Maß an gleichzeitiger Verarbeitung verschiedener Abfragen auf verschiedenen Shards erreicht werden kann. Abfragen werden zunächst auf der Ebene der verteilten Transaktion (Router) analysiert. Vor der Planung der Abfrage findet eine Analysephase statt, in der der Ort aller an der Abfrage beteiligten Beziehungen ermittelt wird. Wenn es sich bei allen Beziehungen um Shard-Tabellen mit einem gefilterten Shard-Schlüssel auf demselben Shard oder um Referenztabellen handelt, wird die Abfrageplanung auf der Router-Ebene übersprungen und zur Planung und Ausführung vollständig auf den Shard übertragen. Dieser Prozess reduziert die Anzahl der Roundtrips zwischen verschiedenen Knoten (Router und Shard) und führt in den meisten Fällen zu einer besseren Leistung. Weitere Informationen finden Sie unter [Single-Shard-Abfragen in Aurora PostgreSQL Limitless Database](limitless-query.single-shard.md). **Anmerkung** In bestimmten Fällen, z. B. bei einem [kartesischen Produkt](https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-FROM) (Cross-Join), kann die Leistung der Abfrage optimiert werden, indem Daten separat vom Shard abgerufen werden. Weitere Informationen über Ausführungspläne zu Abfragen finden Sie in der [Referenz zu Aurora PostgreSQL Limitless DatabaseReferenz zu Limitless Database](limitless-reference.md) unter [EXPLAIN](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.EXPLAIN). Allgemeine Informationen zu Abfragen finden Sie im Abschnitt [Abfragen](https://www.postgresql.org/docs/current/queries-overview.html) der PostgreSQL-Dokumentation. **Topics** + [ # Single-Shard-Abfragen in Aurora PostgreSQL Limitless Database ](limitless-query.single-shard.md) + [ # Verteilte Abfragen in Aurora PostgreSQL Limitless Database ](limitless-query.distributed.md) + [ # Verteiltes Abfrage-Tracing in PostgreSQL-Protokollen in Aurora PostgreSQL Limitless Database ](limitless-query.tracing.md) + [ # Verteilte Deadlocks in Aurora PostgreSQL Limitless Database ](limitless-query.deadlocks.md) # Single-Shard-Abfragen in Aurora PostgreSQL Limitless Database Eine *Single-Shard-Abfrage* ist eine Abfrage, die direkt auf einem Shard ausgeführt werden kann, wobei die SQL-[ACID](https://en.wikipedia.org/wiki/ACID)-Semantik beibehalten wird. Wenn der Abfrageplaner auf dem Router auf eine solche Abfrage trifft, erkennt der Planer sie und leitet die gesamte SQL-Abfrage an den entsprechenden Shard weiter. Diese Optimierung reduziert die Anzahl der Netzwerk-Roundtrips vom Router zum Shard und verbessert die Leistung. Derzeit wird diese Optimierung für die Abfragen `INSERT`, `SELECT`, `UPDATE` und `DELETE` durchgeführt. **Topics** + [ ## Beispiele für Single-Shard-Abfragen ](#limitless-query.single-shard.examples) + [ ## Einschränkungen für Single-Shard-Abfragen ](#limitless-query.single-shard.restrictions) + [ ## Vollständig qualifizierte (explizite) Joins ](#limitless-query.single-shard.fq) + [ ## Festlegen eines aktiven Shard-Schlüssels ](#limitless-query.single-shard.active) ## Beispiele für Single-Shard-Abfragen Die folgenden Beispiele umfassen die Sharded-Tabelle `customers` mit dem Shard-Schlüssel `customer_id` und die Referenztabelle `zipcodes`. **SELECT** ``` postgres_limitless=> EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM customers WHERE customer_id = 100; QUERY PLAN --------------------------------------------------------- Foreign Scan Output: customer_id, other_id, customer_name, balance Remote SQL: SELECT customer_id, other_id, customer_name, balance FROM public.customers WHERE (customer_id = 100) Single Shard Optimized (9 rows) ``` ``` postgres_limitless=> EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM orders LEFT JOIN zipcodes ON orders.zipcode_id = zipcodes.zipcode_id WHERE customer_id = 11; QUERY PLAN --------------------------------------------------------------------------------------------------------- Foreign Scan Output: customer_id, order_id, zipcode_id, customer_name, balance, zipcodes.zipcode_id, zipcodes.city Remote SQL: SELECT orders.customer_id, orders.order_id, orders.zipcode_id, orders.customer_name, orders.balance, zipcodes.zipcode_id, zipcodes.city FROM (public.orders LEFT JOIN public.zipcodes ON ((orders.zipcode_id = zipcodes.zipcode_id))) WHERE (orders.customer_id = 11) Single Shard Optimized (13 rows) ``` **INSERT** ``` postgres_limitless=> EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO customers (customer_id, other_id, customer_name, balance) VALUES (1, 10, 'saikiran', 1000); QUERY PLAN ------------------------------------------------------- Insert on public.customers -> Result Output: 1, 10, 'saikiran'::text, '1000'::real Single Shard Optimized (4 rows) ``` **AKTUALISIERUNG** ``` postgres_limitless=> EXPLAIN (VERBOSE, COSTS OFF) UPDATE orders SET balance = balance + 100 WHERE customer_id = 100; QUERY PLAN --------------------------------------------------------------------------------------------- Update on public.orders Foreign Update on public.orders_fs00002 orders_1 -> Foreign Update Remote SQL: UPDATE public.orders SET balance = (balance + (100)::double precision) WHERE (customer_id = 100) Single Shard Optimized (6 rows) ``` **DELETE** ``` postgres_limitless=> EXPLAIN (VERBOSE, COSTS OFF) DELETE FROM orders WHERE customer_id = 100 and balance = 0; QUERY PLAN --------------------------------------------------------------------- Delete on public.orders Foreign Delete on public.orders_fs00002 orders_1 -> Foreign Delete Remote SQL: DELETE FROM public.orders WHERE ((customer_id = 100) AND (balance = (0)::double precision)) Single Shard Optimized (6 rows) ``` ## Einschränkungen für Single-Shard-Abfragen Für Single-Shard-Abfragen gelten die folgenden Einschränkungen: **Funktionen** Wenn eine Single-Shard-Abfrage eine Funktion enthält, kommt die Abfrage nur dann für die Single-Shard-Optimierung in Frage, wenn eine der folgenden Bedingungen zutrifft: + Die Funktion ist unveränderlich. Weitere Informationen finden Sie unter [Funktionsvolatilität](limitless-reference.DDL-limitations.md#limitless-function-volatility). + Die Funktion ist veränderbar, aber in der Ansicht `rds_aurora.limitless_distributed_functions` registriert. Weitere Informationen finden Sie unter [Verteilung der Funktionen](limitless-reference.DDL-limitations.md#limitless-function-distribution). **Ansichten** Wenn eine Abfrage eine oder mehrere Ansichten enthält, ist die Single-Shard-Optimierung für die Abfrage deaktiviert, wenn sie eine der folgenden Bedingungen erfüllt: + Jede Ansicht hat das Attribut `security_barrier`. + Für die in der Abfrage verwendeten Objekte sind mehrere Benutzerberechtigungen erforderlich. Eine Abfrage enthält beispielsweise zwei Ansichten, und die Ansichten werden unter zwei verschiedenen Benutzern ausgeführt. ``` CREATE VIEW v1 AS SELECT customer_name FROM customers c WHERE c.customer_id = 1; CREATE VIEW v2 WITH (security_barrier) AS SELECT customer_name FROM customers c WHERE c.customer_id = 1; postgres_limitless=> EXPLAIN VERBOSE SELECT * FROM v1; QUERY PLAN ------------------------------------------------------------------------------------ Foreign Scan (cost=100.00..101.00 rows=100 width=0) Output: customer_name Remote Plans from Shard postgres_s3: Seq Scan on public.customers_ts00001 c (cost=0.00..24.12 rows=6 width=32) Output: c.customer_name Filter: (c.customer_id = 1) Query Identifier: -6005737533846718506 Remote SQL: SELECT customer_name FROM ( SELECT c.customer_name FROM public.customers c WHERE (c.customer_id = 1)) v1 Query Identifier: -5754424854414896228 (12 rows) postgres_limitless=> EXPLAIN VERBOSE SELECT * FROM v2; QUERY PLAN -------------------------------------------------------------------------------------------- Foreign Scan on public.customers_fs00001 c (cost=100.00..128.41 rows=7 width=32) Output: c.customer_name Remote Plans from Shard postgres_s3: Seq Scan on public.customers_ts00001 customers (cost=0.00..24.12 rows=6 width=32) Output: customers.customer_name Filter: (customers.customer_id = 1) Query Identifier: 4136563775490008117 Remote SQL: SELECT customer_name FROM public.customers WHERE ((customer_id = 1)) Query Identifier: 5056054318010163757 (9 rows) ``` **Anweisungen PREPARE und EXECUTE** Aurora PostgreSQL Limitless Database unterstützt die Single-Shard-Optimierung für vorbereitete `SELECT`-, `UPDATE`- und `DELETE`-Anweisungen. Wenn Sie jedoch vorbereitete Anweisungen für `PREPARE` und `EXECUTE` verwenden und `plan_cache_mode` dabei auf `'force_generic_plan'` festgelegt haben, lehnt der Abfrageplaner die Single-Shard-Optimierung für diese Abfrage ab. **PL/pgSQL** Abfragen mit PL/pgSQL-Variablen werden als implizit vorbereitete Anweisungen ausgeführt. Wenn eine Abfrage PL/pgSQL-Variablen enthält, lehnt der Abfrageplaner die Single-Shard-Optimierung ab. Die Optimierung wird im PL/pgSQL-Block unterstützt, wenn die Anweisung keine PL/pgSQL-Variablen enthält. ## Vollständig qualifizierte (explizite) Joins Die Single-Shard-Optimierung basiert auf der Eliminierung von Partitionen. Der PostgreSQL-Optimierer eliminiert Partitionen auf der Grundlage konstanter Bedingungen. Wenn Aurora PostgreSQL Limitless Database feststellt, dass sich alle verbleibenden Partitionen und Tabellen auf demselben Shard befinden, markiert sie die Abfrage, die für die Single-Shard-Optimierung in Frage kommt. Alle Filterbedingungen müssen explizit sein, damit das Eliminieren von Partitionen funktioniert. Aurora PostgreSQL Limitless Database kann Partitionen ohne ein oder mehrere Join- oder Filterprädikate in den Shard-Schlüsseln jeder Sharded-Tabelle in der Anweisung nicht eliminieren. Gehen Sie davon aus, dass wir die Tabellen `customers`, `orders` und `order_details` auf Grundlage der Spalte `customer_id` partitioniert haben. In diesem Schema versucht die Anwendung, alle Daten für einen Kunden auf einem einzigen Shard zu speichern. Betrachten Sie folgende Abfrage: ``` SELECT * FROM customers c, orders o, order_details od WHERE c.customer_id = o.customer_id AND od.order_id = o.order_id AND c.customer_id = 1; ``` Diese Abfrage ruft alle Daten für einen Kunden (`c.customer_id = 1`) ab. Die Daten für diesen Kunden befinden sich auf einem einzigen Shard, aber Aurora PostgreSQL Limitless Database qualifiziert diese Abfrage nicht als Single-Shard-Abfrage. Der Optimierungsprozess für die Abfrage sieht wie folgt aus: 1. Der Optimierer kann Partitionen für `customers` und `orders` auf Grundlage der folgenden Bedingung entfernen: ``` c.customer_id = 1 c.customer_id = o.customer_id o.customer_id = 1 (transitive implicit condition) ``` 1. Der Optimierer kann keine Partitionen für `order_details` eliminieren, da es in der Tabelle keine konstante Bedingung gibt. 1. Der Optimierer kommt zu dem Schluss, dass er alle Partitionen aus `order_details` gelesen hat. Daher kann die Abfrage nicht für die Single-Shard-Optimierung qualifiziert werden. Um sie zu einer Single-Shard-Abfrage zu machen, fügen wir die folgende explizite Join-Bedingung hinzu: ``` o.customer_id = od.customer_id ``` Die geänderte Abfrage sieht wie folgt aus: ``` SELECT * FROM customers c, orders o, order_details od WHERE c.customer_id = o.customer_id AND o.customer_id = od.customer_id AND od. order_id = o. order_id AND c.customer_id = 1; ``` Jetzt kann der Optimierer Partitionen für `order_details` eliminieren. Die neue Abfrage wird zu einer Single-Shard-Abfrage und ist für die Optimierung geeignet. ## Festlegen eines aktiven Shard-Schlüssels Mit diesem Feature können Sie bei der Abfrage der Datenbank einen einzelnen Shard-Schlüssel festlegen, wodurch an alle `SELECT`- und DML-Abfragen der Shard-Schlüssel als konstantes Prädikat angehängt wird. Diese Funktion ist nützlich, wenn Sie eine Migration zu Aurora PostgreSQL Limitless Database durchgeführt und das Schema durch Hinzufügen von Shard-Schlüsseln zu Tabellen denormalisiert haben. Sie können ein Shard-Schlüsselprädikat automatisch an die bestehende SQL-Logik anhängen, ohne die Semantik der Abfragen zu ändern. Das Anhängen eines aktiven Shard-Schlüsselprädikats erfolgt nur für [kompatible Tabellen](#active-shard-key-compatible-tables). Das Feature Aktiver Shard-Schlüssel verwendet die Variable `rds_aurora.limitless_active_shard_key`, die die folgende Syntax hat: ``` SET [session | local] rds_aurora.limitless_active_shard_key = '{"col1_value", "col2_value", ...}'; ``` Einige Überlegungen zu aktiven Shard-Schlüsseln und Fremdschlüsseln: + Für eine Sharded-Tabelle kann eine Fremdschlüsselbeschränkung gelten, wenn die übergeordneten und untergeordneten Tabellen nebeneinander angeordnet sind und der Fremdschlüssel eine Obermenge des Shard-Schlüssels bildet. + Für eine Sharded-Tabelle kann eine Fremdschlüsselbeschränkung hinsichtlich einer Referenztabelle gelten. + Für eine Referenztabelle kann eine Fremdschlüsselbeschränkung hinsichtlich einer anderen Referenztabelle gelten. Nehmen wir an, wir haben eine `customers`-Tabelle mit angewendetem Sharding in der Spalte `customer_id`. ``` BEGIN; SET local rds_aurora.limitless_create_table_mode='sharded'; SET local rds_aurora.limitless_create_table_shard_key='{"customer_id"}'; CREATE TABLE customers(customer_id int PRIMARY KEY, name text , email text); COMMIT; ``` Bei einem aktiven Shard-Schlüsselsatz weisen Abfragen die folgenden Transformationen auf. **SELECT** ``` SET rds_aurora.limitless_active_shard_key = '{"123"}'; SELECT * FROM customers; -- This statement is changed to: SELECT * FROM customers WHERE customer_id = '123'::int; ``` **INSERT** ``` SET rds_aurora.limitless_active_shard_key = '{"123"}'; INSERT INTO customers(name, email) VALUES('Alex', 'alex@example.com'); -- This statement is changed to: INSERT INTO customers(customer_id, name, email) VALUES('123'::int, 'Alex', 'alex@example.com'); ``` **AKTUALISIERUNG** ``` SET rds_aurora.limitless_active_shard_key = '{"123"}'; UPDATE customers SET email = 'alex_new_email@example.com'; -- This statement is changed to: UPDATE customers SET email = 'alex_new_email@example.com' WHERE customer_id = '123'::int; ``` **DELETE** ``` SET rds_aurora.limitless_active_shard_key = '{"123"}'; DELETE FROM customers; -- This statement is changed to: DELETE FROM customers WHERE customer_id = '123'::int; ``` **Joins** Wenn an Tabellen mit einem aktiven Shard-Schlüssel Join-Operationen ausgeführt werden, wird das Shard-Schlüssel-Prädikat automatisch allen an der Verknüpfung beteiligten Tabellen hinzugefügt. Dieses automatische Hinzufügen des Shard-Schlüssel-Prädikats erfolgt nur, wenn alle Tabellen in der Abfrage derselben Kollokationsgruppe angehören. Wenn die Abfrage Tabellen aus verschiedenen Kollokationsgruppen umfasst, wird stattdessen ein Fehler ausgelöst. Gehen Sie davon aus, dass wir auch über `orders`- und `order_details`-Tabellen verfügen, die mit der `customers`-Tabelle zusammengefasst sind. ``` SET local rds_aurora.limitless_create_table_mode='sharded'; SET local rds_aurora.limitless_create_table_collocate_with='customers'; SET local rds_aurora.limitless_create_table_shard_key='{"customer_id"}'; CREATE TABLE orders (id int , customer_id int, total_amount int, date date); CREATE TABLE order_details (id int , order_id int, customer_id int, product_name VARCHAR(100), price int); COMMIT; ``` Hier rufen wir die letzten 10 Bestellrechnungen für einen Kunden ab, dessen Kundennummer 10 ist. ``` SET rds_aurora.limitless_active_shard_key = '{"10"}'; SELECT * FROM customers, orders, order_details WHERE orders.customer_id = customers.customer_id AND order_details.order_id = orders.order_id AND customers.customer_id = 10 order by order_date limit 10; ``` Diese Abfrage wird in Folgende transformiert: ``` SELECT * FROM customers, orders, order_details WHERE orders.customer_id = customers.customer_id AND orders.order_id = order_details.order_id AND customers.customer_id = 10 AND order_details.customer_id = 10 AND orders.customer_id = 10 AND ORDER BY "order_date" LIMIT 10; ``` **Tabellen, die mit aktiven Shard-Schlüsseln kompatibel sind** Das Shard-Schlüssel-Prädikat wird nur zu Tabellen hinzugefügt, die mit dem aktiven Shard-Schlüssel kompatibel sind. Eine Tabelle gilt als kompatibel, wenn ihr Shard-Schlüssel genau die Anzahl von Spalten enthält, die in der Variablen `rds_aurora.limitless_active_shard_key` angegeben ist. Wenn die Abfrage Tabellen umfasst, die nicht mit dem aktiven Shard-Schlüssel kompatibel sind, gibt das System einen Fehler aus, anstatt mit der Abfrage fortzufahren. Zum Beispiel: ``` -- Compatible table SET rds_aurora.limitless_active_shard_key = '{"10"}'; -- The following query works because the customers table is sharded on one column. SELECT * FROM customers; -- Incompatible table SET rds_aurora.limitless_active_shard_key = '{"10","20"}'; -- The following query raises a error because the customers table isn't sharded on two columns. SELECT * FROM customers; ``` # Verteilte Abfragen in Aurora PostgreSQL Limitless Database Verteilte Abfragen werden auf einem Router und mehr als einem Shard ausgeführt. Die Anfrage wird von einem der Router empfangen. Der Router erstellt und verwaltet die verteilte Transaktion, die dann an die teilnehmenden Shards gesendet wird. Die Shards erstellen eine lokale Transaktion mit dem vom Router bereitgestellten Kontext, und die Abfrage wird ausgeführt. Wenn die Transaktion übermittelt wird, verwendet der Router bei Bedarf ein optimiertes zweiphasiges Commit-Protokoll und einen zeitbasierten MVCC-Mechanismus (Multi Version Concurrency Control), um die [ACID](https://en.wikipedia.org/wiki/ACID)-Semantik in einem verteilten Datenbanksystem bereitzustellen. Zeitbasiertes MVCC zeichnet den Commit-Zeitpunkt für jede Transaktion auf und verwendet die Startzeit der Transaktion, um den Daten-Snapshot-Zeitpunkt zu generieren. Um anhand eines Reader-Snapshots festzustellen, ob eine Transaktion übermittelt (sichtbar) ist, vergleicht die Datenbank den Commit-Zeitpunkt der Transaktion mit dem Snapshot-Zeitpunkt. Wenn der Commit-Zeitpunkt vor dem Reader-Snapshot-Zeitpunkt liegt, ist die Transaktion sichtbar, andernfalls ist sie unsichtbar. Im Rahmen dieses Protokolls können Sie in der Aurora PostgreSQL Limitless Database immer hoch konsistente Daten erwarten. # Verteiltes Abfrage-Tracing in PostgreSQL-Protokollen in Aurora PostgreSQL Limitless Database Verteiltes Abfrage-Tracing ist ein Tool zum Verfolgen und Korrelieren von Abfragen in PostgreSQL-Protokollen in Aurora PostgreSQL Limitless Database. In Aurora PostgreSQL verwenden Sie die Transaktions-ID, um eine Transaktion zu identifizieren. In Aurora PostgreSQL Limitless Database kann sich eine Transaktions-ID jedoch auf verschiedenen Routern wiederholen. Daher empfehlen wir, dass Sie in Limitless Database stattdessen die Tracing-ID verwenden. Wichtige Anwendungsfälle: + Verwenden Sie die Funktion `rds_aurora.limitless_get_last_trace_id()`, um die eindeutige Tracing-ID der letzten Abfrage in der aktuellen Sitzung zu ermitteln. Durchsuchen Sie dann die DB-Cluster-Protokollgruppe in Amazon CloudWatch Logs mit dieser Tracing-ID, um alle zugehörigen Protokolle zu finden. Sie können die Parameter `log_min_messages` und `log_min_error_statement` zusammen verwenden, um die Menge der abgedruckten Protokolle zu steuern und eine Anweisung abzudrucken, die die Tracing-ID enthält. + Verwenden Sie den Parameter `log_min_duration_statement`, um die Laufzeit zu bestimmen, bei deren Überschreitung alle Abfragen ihre Ausführungsdauer und die Tracing-ID abdrucken. Diese Laufzeit kann dann in der Protokollgruppe des DB-Clusters in CloudWatch-Protokollen gesucht werden, um Knoten mit Engpässen zu ermitteln und Optimierungsmaßnahmen zu planen. Der Parameter `log_min_duration_statement` aktiviert die Tracing-ID für alle Knoten, unabhängig von den Werten der Parameter `log_min_messages` und `log_min_error_statement`. **Topics** + [ ## Tracing-ID ](#limitless-query.tracing.ID) + [ ## Verwenden des Abfrage-Tracings ](#limitless-query.tracing.using) + [ ## Beispiele für Protokolle ](#limitless-query.tracing.examples) ## Tracing-ID Im Mittelpunkt dieser Funktion steht eine eindeutige Kennung, die sogenannte *Tracing-ID*. Die Tracing-ID ist eine 31-stellige Zeichenfolge, die an die STATEMENT-Protokollzeilen von PostgreSQL-Protokollen angehängt wird und als genaue Kennung für korrelierende Protokolle dient, die sich auf eine bestimmte Abfrage beziehen. Beispiele sind `1126253375719408504000000000011` und `1126253375719408495000000000090`. Die Tracing-ID besteht aus den folgenden Elementen: + Transaktions-ID: Die ersten 20 Zeichen, die die Transaktion eindeutig identifizieren. + Befehls-ID: Die ersten 30 Zeichen, die auf eine einzelne Abfrage innerhalb einer Transaktion hinweisen. Wenn innerhalb eines expliziten Transaktionsblocks mehr als 4 294 967 294 Abfragen ausgeführt werden, wird die Befehls-Id zu `1`. In diesem Fall werden Sie durch die folgende `LOG`-Meldung im PostgreSQL-Protokoll benachrichtigt: ``` wrapping around the tracing ID back to 1 after running 4294967294 (4.2 billion or 2^32-2) queries inside of an explicit transaction block ``` + Knotentyp-ID: Die letzte Ziffer, die angibt, ob der Knoten als Koordinator-Router (`1`) oder als Teilnehmerknoten (`0`) fungiert. Die folgenden Beispiele veranschaulichen die Komponenten der Tracing-ID: + `1126253375719408504000000000011`: + Transaktions-ID: `1126253375719408504` + Befehls-ID: `112625337571940850400000000001` gibt den ersten Befehl im Transaktionsblock an. + Knotentyp-ID: `1` gibt einen Koordinator-Router an. + `1126253375719408495000000000090`: + Transaktions-ID: `1126253375719408495` + Befehls-ID: `112625337571940849500000000009` gibt den neunten Befehl im Transaktionsblock an. + Knotentyp-ID: `0` gibt einen Teilnehmerknoten an. ## Verwenden des Abfrage-Tracings Führen Sie die folgenden Aufgaben aus, um das Abfrage-Tracing zu verwenden: 1. Stellen Sie sicher, dass Tracing aktiviert ist. Sie können zur Überprüfung den folgenden Befehl verwenden: ``` SHOW rds_aurora.limitless_log_distributed_trace_id; ``` Die Funktion ist standardmäßig aktiviert (`on`). Wenn sie nicht aktiviert ist, aktivieren Sie sie mit dem folgenden Befehl: ``` SET rds_aurora.limitless_log_distributed_trace_id = on; ``` 1. Steuern Sie die Menge der abgedruckten Protokolle, indem Sie den Schweregrad des Protokolls konfigurieren. Die Menge der Protokolle wird durch den Parameter `log_min_messages` gesteuert. Der Parameter `log_min_error_statement` wird verwendet, um die `STATEMENT`-Zeile mit der Tracing-ID abzudrucken. Beide sind standardmäßig auf `ERROR` eingestellt. Sie können zur Überprüfung folgende Befehle verwenden: ``` SHOW log_min_messages; SHOW log_min_error_statement; ``` Um den Schweregrad zu aktualisieren und die Zeile `STATEMENT` für die aktuelle Sitzung abzudrucken, verwenden Sie die folgenden Befehle mit einem dieser Schweregrade: ``` SET log_min_messages = 'DEBUG5 | DEBUG4 | DEBUG3 | DEBUG2 | DEBUG1 | INFO | NOTICE | WARNING | ERROR | LOG | FATAL | PANIC'; SET log_min_error_statement = 'DEBUG5 | DEBUG4 | DEBUG3 | DEBUG2 | DEBUG1 | INFO | NOTICE | WARNING | ERROR | LOG | FATAL | PANIC'; ``` Zum Beispiel: ``` SET log_min_messages = 'WARNING'; SET log_min_error_statement = 'WARNING'; ``` 1. Aktivieren Sie das Abdrucken der Tracing-ID in den Protokollen ab einer bestimmten Laufzeit. Der Parameter `log_min_duration_statement` kann in die minimale Abfragelaufzeit geändert werden, bei deren Überschreitung die Abfrage für den gesamten DB-Cluster eine Protokollzeile mit der Ausführungsdauer zusammen mit den Tracing-IDs ausgibt. Dieser Parameter ist standardmäßig auf `-1` gesetzt, was bedeutet, dass er deaktiviert ist. Sie können zur Überprüfung den folgenden Befehl verwenden: ``` SHOW log_min_duration_statement; ``` Wenn Sie ihn in `0` ändern, werden die Dauer und die Tracing-ID in den Protokollen für jede Abfrage im DB-Cluster abgedruckt. Sie können ihn mit dem folgenden Befehl für die aktuelle Sitzung auf `0` festlegen: ``` SET log_min_duration_statement = 0; ``` 1. Rufen Sie die Tracing-ID ab. Rufen Sie nach dem Ausführen einer Abfrage (auch innerhalb eines expliziten Transaktionsblocks) die Funktion `rds_aurora.limitless_get_last_trace_id` auf, um die Tracing-ID des letzten Abfragelaufs abzurufen: ``` SELECT * FROM rds_aurora.limitless_get_last_trace_id(); ``` Diese Funktion gibt die Transaktions-ID und die Befehls-ID zurück. Sie gibt die Knotentyp-ID nicht zurück. ``` => SELECT * FROM customers; customer_id | fname | lname -------------+-------+------- (0 rows) => SELECT * FROM rds_aurora.limitless_get_last_trace_id(); transaction_identifier | command_identifier ------------------------+-------------------------------- 10104661421959001813 | 101046614219590018130000000001 (1 row) ``` Die Funktion gibt für nicht verteilte Abfragen eine Leerzeile zurück, da sie über keine Tracing-ID verfügen. ``` => SET search_path = public; SET => SELECT * FROM rds_aurora.limitless_get_last_trace_id(); transaction_identifier | command_identifier ------------------------+-------------------- | (1 row) ``` **Anmerkung** Bei VACUUM- und ANALYZE-Abfragen wird die Anweisung zur Dauer nicht mit der Tracing-ID protokolliert. Daher gibt `limitless_get_last_trace_id()` die Tracing-ID nicht zurück. Wenn es sich bei VACUUM oder ANALYZE um einen Vorgang mit langer Laufzeit handelt, können Sie die folgende Abfrage verwenden, um die Tracing-ID für diesen Vorgang abzurufen: ``` SELECT * FROM rds_aurora.limitless_stat_activity WHERE distributed_tracing_id IS NOT NULL; ``` Wenn der Server stoppt, bevor Sie die letzte Tracing-ID ausfindig machen können, müssen Sie die PostgreSQL-Protokolle manuell durchsuchen, um die Tracing-IDs in den Protokollen vom Zeitpunkt unmittelbar vor dem Ausfall zu finden. 1. Suchen Sie mit CloudWatch in den DB-Cluster-Protokollen nach der Tracing-ID. Verwenden Sie [CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html), um die Protokollgruppe des DB-Clusters abzufragen, wie in den folgenden Beispielen gezeigt. + Abfrage nach einer bestimmten Transaktions-ID und alle Befehle werden darin ausgeführt: ``` fields @timestamp, @message | filter @message like /10104661421959001813/ | sort @timestamp desc ``` + Abfrage nach einer bestimmten Befehls-ID: ``` fields @timestamp, @message | filter @message like /101046614219590018130000000001/ | sort @timestamp desc ``` 1. Untersuchen Sie alle Protokolle im DB-Cluster, die durch die verteilte Abfrage erstellt wurden. ## Beispiele für Protokolle Die folgenden Beispiele zeigen die Verwendung von Abfrage-Tracing. ### Korrelierung von Protokollen für fehleranfällige Abfragen In diesem Beispiel wird der Befehl `TRUNCATE` an der Tabelle `customers` ausgeführt, wenn diese Tabelle nicht existiert. **Ohne Abfrage-Tracing** PostgreSQL-Protokolldatei auf dem Koordinator-Router: ``` 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:DETAIL: relation "public.customers" does not exist 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:CONTEXT: remote SQL command: truncate public.customers; 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[27503]:STATEMENT: truncate customers; ``` PostgreSQL-Protokolldatei auf einem Teilnehmer-Shard: ``` 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[ 27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]: postgres@postgres_limitless:[ 27503]:STATEMENT: truncate customers; ``` Diese Protokolle sind typisch. Ihnen fehlen die exakten IDs, die für die einfache Korrelation von Abfragen im gesamten DB-Cluster erforderlich sind. **Mit Abfrage-Tracing** PostgreSQL-Protokolldatei auf dem Koordinator-Router: ``` 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:DETAIL: relation "public.customers" does not exist 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:CONTEXT: remote SQL command: truncate public.customers; 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:STATEMENT: /* tid = 1126253375719408502700000000011 */ truncate customers; ``` PostgreSQL-Protokolldatei auf einem Teilnehmer-Shard: ``` 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:ERROR: failed to execute remote query 2023-09-26 04:03:19 UTC:[local]:postgres@postgres_limitless:[27503]:STATEMENT: /* tid = 1126253375719408502700000000010 */ truncate customers; ``` Beim Abfrage-Tracing wird an jede Protokollzeile eine 31-stellige eindeutige Kennung angehängt. Hier stellen `1126253375719408502700000000011` und `1126253375719408502700000000010` jeweils die Tracing-IDs für den Koordinator- und die Teilnehmerknoten dar. + Transaktions-ID: `11262533757194085027` + Befehls-ID: `112625337571940850270000000001` + Knotentyp-ID: Die letzte Ziffer, `1` oder `0`, steht für einen Koordinator-Router bzw. einen Teilnehmerknoten. ### Korrelieren von Protokollen, um die Abfragelaufzeit auf verschiedenen Knoten zu ermitteln In diesem Beispiel wurde der Parameter `log_min_duration_statement` in `0` geändert, damit für alle Abfragen die Dauer abgedruckt wird. **Ohne Abfrage-Tracing** ``` 2024-01-15 07:28:46 UTC:[local]:postgres@postgres_limitless:[178322]:LOG: duration: 12.779 ms statement: select * from customers; ``` **Mit Abfrage-Tracing** PostgreSQL-Protokolldatei auf dem Koordinator-Router: ``` 2024-01-15 07:32:08 UTC:[local]:postgres@postgres_limitless:[183877]:LOG: duration: 12.618 ms statement: /* tid = 0457669566240497088400000000011 */ select * from customers; ``` PostgreSQL-Protokolldatei auf einem Teilnehmer-Shard: ``` 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.279 ms statement: /* tid = 0457669566240497088400000000010 */ START TRANSACTION ISOLATION LEVEL READ COMMITTED 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.249 ms parse : SELECT customer_id, fname, lname FROM public.customers 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.398 ms bind /c1: SELECT customer_id, fname, lname FROM public.customers 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.019 ms execute /c1: SELECT customer_id, fname, lname FROM public.customers 2024-01-15 07:32:08 UTC:localhost(46358):postgres@postgres_limitless:[183944]:LOG: duration: 0.073 ms statement: /* tid = 0457669566240497088400000000010 */ COMMIT TRANSACTION ``` # Verteilte Deadlocks in Aurora PostgreSQL Limitless Database In einer DB-Shard-Gruppe können Deadlocks zwischen Transaktionen auftreten, die auf verschiedene Router und Shards verteilt sind. Beispielsweise werden zwei gleichzeitige verteilte Transaktionen mit zwei Shards ausgeführt, wie in der folgenden Abbildung dargestellt. ![\[Verteilter Deadlock bei zwei verteilten Transaktionen.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/limitless_distributed_transaction_deadlock.png) Die Transaktionen sperren Tabellen und erzeugen Warteereignisse in den beiden Shards wie folgt: 1. Verteilte Transaktion 1: ``` UPDATE table SET value = 1 WHERE key = 'shard1_key'; ``` Shard 1 bleibt gesperrt. 1. Verteilte Transaktion 2: ``` UPDATE table SET value = 2 WHERE key = 'shard2_key'; ``` Shard 2 bleibt gesperrt. 1. Verteilte Transaktion 1: ``` UPDATE table SET value = 3 WHERE key = 'shard2_key'; ``` Die verteilte Transaktion 1 wartet auf Shard 2. 1. Verteilte Transaktion 2: ``` UPDATE table SET value = 4 WHERE key = 'shard1_key'; ``` Die verteilte Transaktion 2 wartet auf Shard 1. In diesem Szenario erkennen weder Shard 1 noch Shard 2 das Problem: Transaktion 1 wartet auf Shard 2 auf Transaktion 2 und Transaktion 2 wartet auf Shard 1 auf Transaktion 1. Aus globaler Sicht wartet Transaktion 1 auf Transaktion 2 und Transaktion 2 wartet auf Transaktion 1. Diese Situation, in der zwei Transaktionen auf zwei verschiedenen Shards aufeinander warten, wird als verteilter Deadlock bezeichnet. Aurora PostgreSQL Limitless Database kann verteilte Deadlocks automatisch erkennen und lösen. Ein Router in der DB-Shard-Gruppe wird benachrichtigt, wenn eine Transaktion zu lange auf den Erwerb einer Ressource wartet. Der Router, der die Benachrichtigung empfängt, beginnt, die erforderlichen Informationen von allen Routern und Shards innerhalb der DB-Shard-Gruppe zu sammeln. Der Router beendet daraufhin Transaktionen, die an einem verteilten Deadlock beteiligt sind, bis die restlichen Transaktionen in der DB-Shard-Gruppe weiter ausgeführt werden können, ohne sich gegenseitig zu blockieren. Sie erhalten die folgende Fehlermeldung, wenn Ihre Transaktion Teil eines verteilten Deadlocks war und dann vom Router beendet wurde: ``` ERROR: aborting transaction participating in a distributed deadlock ``` Der DB-Cluster-Parameter `rds_aurora.limitless_distributed_deadlock_timeout` legt fest, wie lange jede Transaktion auf einer Ressource wartet, bevor der Router aufgefordert wird, nach einem verteilten Deadlock zu suchen. Sie können den Parameterwert erhöhen, wenn Ihre Workload weniger anfällig für Deadlock-Situationen ist. Der Standardwert ist `1000` Millisekunden (1 Sekunde). Der Zyklus eines verteilten Deadlocks wird in den PostgreSQL-Protokollen veröffentlicht, wenn ein knotenübergreifender Deadlock gefunden und behoben wurde. Zu den Informationen über jeden Prozess, der Teil des Deadlocks ist, gehören die folgenden: + Koordinatorknoten, der die Transaktion gestartet hat + ID der virtuellen Transaktions (xid) auf dem Koordinatorknoten im Format `backend_id/backend_local_xid` + ID der verteilten Sitzung der Transaktion # Verwalten einer Aurora PostgreSQL Limitless Database In den folgenden Themen wird beschrieben, wie Sie die DB-Cluster Ihrer Aurora PostgreSQL Limitless Database verwalten. **Topics** + [ ## Überlegungen zur Datenbank- und Tabellengröße ](#limitless-db-size) + [ # Zurückgewinnen von Speicherplatz durch Bereinigung ](limitless-vacuum.md) ## Überlegungen zur Datenbank- und Tabellengröße Für Aurora PostgreSQL Limitless Database ist auf jedem Shard eine Sharded-Tabelle in eine Anzahl von Tabellensegmenten unterteilt. Diese Anzahl variiert, je nachdem, wie viele Shards in der DB-Shard-Gruppe verfügbar sind. Jeder Tabellenbereich kann bis zu 32 TiB groß werden, aber jeder Shard hat eine maximale Kapazität von 128 TiB. Referenztabellen haben eine Größenbeschränkung von 32 TiB für die gesamte DB-Shard-Gruppe. **Anmerkung** Die maximale Kapazität jedes Knotens (Router oder Shard) beträgt 128 TiB, da dies die maximale Kapazität für einen DB-Cluster von Aurora PostgreSQL ist. Die maximale Anzahl von Beziehungen pro Datenbank (einschließlich Tabellen, Ansichten und Indizes) in Aurora PostgreSQL und Aurora PostgreSQL Limitless Database beträgt 1 431 650 303. Weitere Informationen finden Sie in [Appendix K. – PostgreSQL-Limits](https://www.postgresql.org/docs/current/limits.html) in der PostgreSQL-Dokumentation und in [Amazon Aurora-Größenbeschränkungen](CHAP_Limits.md#RDS_Limits.FileSize.Aurora). # Zurückgewinnen von Speicherplatz durch Bereinigung PostgreSQL Multiversion Concurrency Control (MVCC) trägt zur Wahrung der Datenintegrität bei, indem es eine interne Kopie aktualisierter oder gelöschter Zeilen speichert, bis eine Transaktion entweder festgeschrieben oder zurückgesetzt wird. Diese Kopien, auch *Tupel* genannt, können zu einer Überlastung der Tabelle führen, wenn sie nicht regelmäßig bereinigt werden. PostgreSQL-Instances ordnen Transaktionen nach ihren Transaktions-IDs, und PostgreSQL verwendet MVCC, das auf Transaktions-IDs basiert, um die Sichtbarkeit von Tupeln zu kontrollieren und die Transaktionsisolierung zu gewährleisten. Jede Transaktion erstellt einen Daten-Snapshot, und jedes Tupel hat eine Version. Sowohl der Snapshot als auch die Version basieren auf der Transaktions-ID. Um Daten zu bereinigen, führt das Dienstprogramm `VACUUM` vier wichtige Funktionen in PostgreSQL aus: + `VACUUM` – Entfernt abgelaufene Zeilenversionen, wodurch Speicherplatz für die Wiederverwendung verfügbar wird. + `VACUUM FULL` – Ermöglicht eine vollständige Defragmentierung, indem veraltete Versionen entfernt und die Tabellen komprimiert werden, wodurch die Größe reduziert und die Effizienz gesteigert wird. + `VACUUM FREEZE` – Schützt vor Wraparound-Problemen bei Transaktions-IDs, indem ältere Zeilenversionen als gesperrt markiert werden. + `VACUUM ANALYZE` – Entfernt veraltete Zeilenversionen und aktualisiert die Abfrageplanungsstatistiken der Datenbank. Es ist eine Kombination aus `VACUUM`- und `ANALYZE`-Funktionen. Weitere Informationen zur Funktionsweise von `ANALYZE` in Aurora PostgreSQL Limitless Database finden Sie unter [ANALYZE](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.ANALYZE). Wie bei MVCC basiert die Bereinigung in Aurora PostgreSQL auf der Transaktions-ID. Wenn zu Beginn der Bereinigung eine Transaktion läuft, werden Zeilen, die für diese Transaktion noch sichtbar sind, nicht entfernt. Weitere Informationen zum Dienstprogramm `VACUUM` finden Sie unter [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) in der PostgreSQL-Dokumentation. Weitere Informationen zur Unterstützung von `VACUUM` in Aurora PostgreSQL Limitless Database finden Sie unter [VACUUM](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.VACUUM). **Topics** + [ ## AUTOVACUUM ](#limitless-autovacuum) + [ ## Zeitbasiertes Bereinigen in Aurora PostgreSQL Limitless Database ](#limitless-vacuum.time-based) + [ ## Verwenden von Datenbankstatistiken für die Bereinigung ](#limitless-vacuum.stats) + [ ## Unterschiede im Bereinigungsverhalten zwischen Aurora PostgreSQL und Aurora PostgreSQL Limitless Database ](#limitless-vacuum-limitations) ## AUTOVACUUM Aurora PostgreSQL verwendet die Dienstprogramme `VACUUM` und `AUTOVACUUM`, um nicht benötigte Tupel zu entfernen. Der zugrundeliegende Mechanismus für `AUTOVACUUM` und manuelles `VACUUM` ist derselbe, der einzige Unterschied besteht in der Automatisierung. `AUTOVACUUM` in Aurora PostgreSQL und Aurora PostgreSQL Limitless Database ist eine Kombination der Dienstprogramme `VACUUM` und `ANALYZE`. `AUTOVACUUM` legt gemäß einer vordefinierten Regel fest, welche Datenbanken und Tabellen bereinigt werden sollen, z. B. anhand des Prozentsatzes inaktiver Tupel und der Anzahl der Einfügungen. `AUTOVACUUM` wird beispielsweise regelmäßig aktiviert, um eine Bereinigung durchzuführen. Das Intervall wird durch den Parameter `autovacuum_naptime` gesteuert. Der Standardwert beträgt 1 Minute. Die Standardwerte für die Konfigurationsparameter `AUTOVACUUM` und `VACUUM` sind für Aurora PostgreSQL Limitless Database dieselben wie für Aurora PostgreSQL. Wenn der Daemon für `AUTOVACUUM` aktiviert ist, gibt er automatisch `ANALYZE`-Befehle aus, wenn sich der Inhalt einer Tabelle ausreichend geändert hat. In Aurora PostgreSQL Limitless Database gibt `AUTOVACUUM` `ANALYZE` auf Routern und auf Shards aus. Weitere Informationen zum Daemon für `AUTOVACUUM` und zu den mit `AUTOVACUUM` verbundenen Tabellenspeicherparametern finden Sie unter [Der Bereinigungsdaemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM ) und die [Speicherparameter](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) in der PostgreSQL-Dokumentation. ## Zeitbasiertes Bereinigen in Aurora PostgreSQL Limitless Database Aurora PostgreSQL Limitless Database ist ein verteiltes System, was bedeutet, dass mehrere Instances an einer Transaktion beteiligt sein können. Daher gilt die auf der Transaktions-ID basierende Transparenz nicht. Stattdessen verwendet Aurora PostgreSQL Limitless Database *zeitbasierte* Sichtbarkeit, da Transaktions-IDs nicht Instance-übergreifend „vereinheitlicht“ werden, die Zeit hingegen schon. Jeder Transaktions-Snapshot und jede Tupel-Version folgen der Zeit und nicht der Transaktions-ID. Genauer gesagt hat ein Transaktions-Snapshot eine Snapshot-Startzeit, und ein Tupel hat eine Erstellungszeit (bei einem `INSERT`- oder `UPDATE`-Vorgang) und eine Löschzeit (bei einem `DELETE`-Vorgang). Um die Datenkonsistenz zwischen den Instances in der DB-Shard-Gruppe aufrechtzuerhalten, muss Aurora PostgreSQL Limitless Database sicherstellen, dass beim Bereinigen keine Tupel entfernt werden, die für aktive Transaktionen in der DB-Shard-Gruppe noch sichtbar sind. Daher ist die Bereinigung in Aurora PostgreSQL Limitless Database auch zeitbasiert. Andere Aspekte von `VACUUM` bleiben gleich, einschließlich der Tatsache, dass ein Benutzer Zugriff auf diese Tabelle haben muss, um `VACUUM` auf einer bestimmten Tabelle auszuführen. **Anmerkung** Es wird dringend davon abgeraten, Transaktionen für längere Zeit offen zu lassen. Die zeitbasierte Bereinigung verbraucht mehr Speicher als die auf der Transaktions-ID basierte Bereinigung. Das folgende Beispiel veranschaulicht die Funktionsweise von zeitbasierter Bereinigung. 1. Eine Kundentabelle ist auf vier Shards verteilt. 1. Transaktion 1 beginnt mit einem wiederholbaren Lesevorgang und zielt nur auf einen Shard (Shard 1) ab. Diese Transaktion bleibt offen. Transaktion 1 ist älter als jede andere Transaktion, die danach gestartet wurde. 1. Transaktion 2 beginnt später, löscht alle Tupel aus einer Tabelle und wird anschließend festgeschrieben. 1. Wenn `AUTOVACUUM` oder manuelles `VACUUM` versucht, inaktive Tupel zu bereinigen (die aufgrund von Transaktion 2 inaktiv sind), wird nichts entfernt. Dies gilt nicht nur für Shard 1, sondern auch für die Shards 2 bis 4, da Transaktion 1 möglicherweise immer noch auf diese Tupel zugreifen muss. Sie sind aufgrund von MVCC immer noch für Transaktion 1 sichtbar. Der letzte Schritt wird durch Synchronisierung erreicht, sodass alle Shards über Transaktion 1 informiert sind, auch wenn Transaktion 1 nicht alle Shards betrifft. ## Verwenden von Datenbankstatistiken für die Bereinigung Um Informationen über Tupel zu erhalten, die Sie möglicherweise bereinigen müssen, verwenden Sie die Ansicht [limitless\$1stat\$1all\$1tables](limitless-monitoring-views.md#limitless_stat_all_tables), die ähnlich wie [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) funktioniert. Im folgenden Beispiel wird die Ansicht abgefragt. ``` SELECT * FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE '%customer%'; ``` Entsprechend verwenden Sie für Datenbankstatistiken [limitless\$1stat\$1database](limitless-monitoring-views.md#limitless_stat_database) anstelle von [pg\$1stat\$1database](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW) und [limitless\$1stat\$1activity](limitless-monitoring-views.md#limitless_stat_activity) anstelle von [pg\$1stat\$1activity](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW). Um die Festplattennutzung zu überprüfen, verwenden Sie die Funktion [limitless\$1stat\$1relation\$1sizes](limitless-monitoring-functions.md#limitless_stat_relation_sizes), die ähnlich wie [pg\$1relation\$1size](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-DBOBJECT) funktioniert. Im folgenden Beispiel wird die Funktion abgefragt. ``` SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customer'); ``` Um den Fortschritt eines `VACUUM`-Vorgangs in der Aurora PostgreSQL Limitless Database zu verfolgen, verwenden Sie die Ansicht [limitless\$1stat\$1progress\$1vacuum](limitless-monitoring-views.md#limitless_stat_progress_vacuum) anstelle von [pg\$1stat\$1progress\$1vacuum](https://www.postgresql.org/docs/15/progress-reporting.html#VACUUM-PROGRESS-REPORTING). Im folgenden Beispiel wird die Ansicht abgefragt. ``` SELECT * FROM rds_aurora.limitless_stat_progress_vacuum; ``` Weitere Informationen erhalten Sie unter [Ansichten für Aurora PostgreSQL Limitless Database](limitless-monitoring-views.md) und [Funktionen für Aurora PostgreSQL Limitless Database](limitless-monitoring-functions.md). ## Unterschiede im Bereinigungsverhalten zwischen Aurora PostgreSQL und Aurora PostgreSQL Limitless Database Einige weitere Unterschiede zwischen Aurora PostgreSQL und Aurora PostgreSQL Limitless Database in Bezug auf die Funktionsweise der Bereinigung sind die folgenden: + Aurora PostgreSQL führt `VACUUM`-Vorgänge mit Transaktions-IDs bis zur ältesten laufenden Transaktion durch. Wenn in der Datenbank keine laufende Transaktion vorhanden ist, führt `VACUUM` den Vorgang bis zur letzten Transaktion ausgeführt. + Aurora PostgreSQL Limitless Database synchronisiert den ältesten Zeit-Snapshot alle 10 Sekunden. Daher wird `VACUUM` den Vorgang möglicherweise nicht für Transaktionen durch, die innerhalb der letzten 10 Sekunden ausgeführt wurden. Weitere Informationen zur Unterstützung für `VACUUM` in Aurora PostgreSQL Limitless Database finden Sie unter [VACUUM](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.VACUUM) in der [Referenz zu Aurora PostgreSQL Limitless DatabaseReferenz zu Limitless Database](limitless-reference.md). # Überwachen einer Aurora PostgreSQL Limitless Database Sie können Amazon CloudWatch, Enhanced Monitoring und Performance Insights verwenden, um Aurora PostgreSQL Limitless Database zu überwachen. Es gibt auch neue Statistikfunktionen und -ansichten sowie Warteereignisse für Aurora PostgreSQL Limitless Database, die Sie für die Überwachung und Diagnose verwenden können. **Topics** + [ # Überwachen von Aurora PostgreSQL Limitless Database mit Amazon CloudWatch ](limitless-monitoring.cw.md) + [ # Überwachen von Aurora PostgreSQL Limitless Database mit CloudWatch Database Insights ](limitless-monitoring.cwdbi.md) + [ # Überwachen von Aurora PostgreSQL Limitless-Datenbank mit Amazon CloudWatch Logs ](limitless-monitoring.cwl.md) + [ # Überwachen einer Aurora PostgreSQL Limitless Database mithilfe der erweiterten Überwachung ](limitless-monitoring.em.md) + [ # Überwachen einer Aurora PostgreSQL Limitless Database mithilfe von Performance Insights ](limitless-monitoring.pi.md) + [ # Überwachen einer Aurora PostgreSQL Limitless Database mithilfe des RDS-Schutzes von Amazon GuardDuty ](limitless-monitoring.gd.md) + [ # Funktionen und Ansichten für Aurora PostgreSQL Limitless Database ](limitless-monitoring-fns-views.md) + [ # Warteereignisse für Aurora PostgreSQL Limitless Database ](limitless-monitoring-waits.md) + [ # Effizientes Bauen mit Funktionen ](limitless-performance-functions.md) # Überwachen von Aurora PostgreSQL Limitless Database mit Amazon CloudWatch CloudWatch-Metriken für Aurora PostgreSQL Limitless Database werden unter den folgenden Dimensionen gemeldet: + [DBShardGroup](#limitless-monitoring.cw.DBShardGroup) + [DBShardGroupRouterAggregation](#limitless-monitoring.cw.DBShardGroupRouterAggregate) + [DBShardGroupInstance](#limitless-monitoring.cw.DBShardGroupInstance) + [DBClusterIdentifier](#limitless-monitoring.cw.DBClusterIdentifier) Weitere Informationen zu CloudWatch-Metriken finden Sie unter [Überwachung von Amazon Aurora Aurora-Metriken mit Amazon CloudWatch](monitoring-cloudwatch.md). ## DBShardGroup-Metriken Wenn Sie `DBShardGroup`-Metriken für Aurora PostgreSQL Limitless Database in der CloudWatch-Konsole anzeigen möchten, wählen Sie **RDS** und dann **DBShardGroup** aus. Sie können die folgenden CloudWatch-Metriken verfolgen: + `DBShardGroupACUUtilization`: Auslastung der Aurora-Kapazitätseinheiten (ACU) in Prozent, berechnet aus `DBShardGroupCapacity` geteilt durch `DBShardGroupMaxACU`. + `DBShardGroupCapacity`: Anzahl der ACUs, die von den Writer-Instances der DB-Shard-Gruppe konsumiert werden. + `DBShardGroupComputeRedundancyCapacity`: Anzahl der ACUs, die von den Standby-Instances der DB-Shard-Gruppe konsumiert werden. + `DBShardGroupMaxACU`: Maximale Anzahl der ACUs, die für die DB-Shard-Gruppe konfiguriert sind. + `DBShardGroupMinACU`: Mindestanzahl der ACUs, die von der DB-Shard-Gruppe benötigt wird. Der Dimensionsschlüssel `DBShardGroupIdentifier` ist für die Aggregation der `DBShardGroup`-Metriken verfügbar. ## DBShardGroupRouterAggregation-Metriken Wenn Sie `DBShardGroupRouterAggregation`-Metriken für Aurora PostgreSQL Limitless Database in der CloudWatch-Konsole anzeigen möchten, wählen Sie **RDS** und dann **DBShardGroupRouterAggregation** aus. Sie können die folgenden CloudWatch-Metriken verfolgen: + `CommitThroughput`: Die durchschnittliche Anzahl von Commit-Vorgängen pro Sekunde auf allen Router-Knoten in der DB-Shard-Gruppe. + `DatabaseConnections`: Die Summe aller Verbindungen zwischen allen Router-Knoten in der DB-Shard-Gruppe. ## DBShardGroupInstance-Metriken Eine DBShardGroupInstance ist die einzelne DB-Instance innerhalb jedes Shard- oder Router-Subclusters. Wenn Sie `DBShardGroupInstance`-Metriken für Aurora PostgreSQL Limitless Database in der CloudWatch-Konsole anzeigen möchten, wählen Sie **RDS** und dann **DBShardGroupInstance** aus. Sie können die folgenden CloudWatch-Metriken verfolgen: + `ACUUtilization`: Der als `ServerlessDatabaseCapacity`-Metrik berechnete Prozentsatz geteilt durch den zugewiesenen maximalen ACU-Wert des Subclusters. + `AuroraReplicaLag`: In Limitless-Clustern mit aktivierter Compute-Redundanz ist dies die Dauer der Verzögerung, wenn Updates aus einer primären Instance im Subcluster repliziert werden. + `AuroraReplicaLagMaximum`: In Limitless-Clustern mit aktivierter Compute-Redundanz ist dies die maximale Verzögerung, wenn Updates aus einer primären Instance im Subcluster repliziert werden. Wenn Lesereplikate gelöscht oder umbenannt werden, könnte es zu einem vorübergehenden Anstieg der Replikationsverzögerung kommen, da die alte Ressource einem Recycling unterzogen wird. Verwenden Sie diese Metrik, um herauszufinden, ob auf einem der Lesegeräte ein Failover aufgrund einer hohen Replikationsverzögerung aufgetreten ist. + `AuroraReplicaLagMinimum`: In Limitless-Clustern mit aktivierter Compute-Redundanz ist dies die minimale Verzögerung, wenn Updates aus einer primären Instance im Subcluster repliziert werden. + `BufferCacheHitRatio`: Der Prozentsatz der Daten und Indizes, die aus dem Speichercache einer Instance bedient werden (im Gegensatz zum Speichervolume). + `CommitLatency`: Die durchschnittliche Dauer, die Engine und Speicher benötigen, um die Commit-Operationen für einen bestimmten Knoten (Router oder Shard) abzuschließen. + `CommitThroughput`: Die durchschnittliche Anzahl der Commit-Operationen pro Sekunde + `CPUUtilization`: Die CPU-Auslastung in Prozent des maximal zugewiesenen ACU-Werts des Subclusters. + `FreeableMemory`: Die Menge des nicht belegten Speichers, die verfügbar ist, wenn die Shard-Gruppe auf ihre maximale Kapazität skaliert wird. Dies wird durch die zugewiesenen ACUs der Shard-Gruppe bestimmt. Für jede ACU, bei der die aktuelle Kapazität unter der maximalen Kapazität liegt, erhöht sich dieser Wert ungefähr um 2 GiB. Daher nähert sich diese Metrik erst Null, wenn die DB-Shard-Gruppe bis zum Maximum hochskaliert ist. + `MaximumUsedTransactionIDs`: Das Alter der ältesten nicht bereinigten Transaktions-ID in Transaktionen. Erreicht dieser Wert 2.146.483.648 (2^31 - 1 000 000), wird die Datenbank in den Nur-Lese-Modus gezwungen, um den Wraparound der Transaktions-ID zu vermeiden. Weitere Informationen finden Sie unter [Transaktions-ID-Wraparound-Fehler vermeiden](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) in der PostgreSQL-Dokumentation. + `NetworkReceiveThroughput`: Die Menge des von Clients erhaltenen Netzwerkdurchsatzes für jede Instance in der DB-Shard-Gruppe. Dieser Durchsatz beinhaltet nicht den Netzwerkdatenverkehr zwischen den Instances in der DB-Shard-Gruppe und dem Cluster-Volume. + `NetworkThroughput`: Der aggregierte Netzwerkdurchsatz (sowohl übertragen als auch empfangen) zwischen Clients und Routern sowie Routern und Shards in der DB-Shard-Gruppe. Dieser Durchsatz beinhaltet nicht den Netzwerkdatenverkehr zwischen den Instances in der DB-Shard-Gruppe und dem Cluster-Volume. + `NetworkTransmitThroughput`: Die Menge des an Clients gesendeten Netzwerkdurchsatzes für jede Instance in der DB-Shard-Gruppe. Dieser Durchsatz beinhaltet nicht den Netzwerkdatenverkehr zwischen den Instances in der DB-Shard-Gruppe und dem Cluster-Volume. + `ReadIOPS`: Die durchschnittliche Anzahl der Datenträger-Eingabe-/Ausgabe-Lesevorgänge pro Sekunde (IOPS). + `ReadLatency`: Die durchschnittliche Dauer für einen Datenträger-Ein-/Ausgabe-(I/O)-Lesevorgang. + `ReadThroughput`: Die durchschnittliche Anzahl Byte, die pro Sekunde vom Datenträger gelesen werden. + `ServerlessDatabaseCapacity`: Die aktuelle Kapazität des DB-Shards oder Router-Subclusters innerhalb der DB-Shard-Gruppe. + `StorageNetworkReceiveThroughput`: Der Umfang des vom Aurora-Speicheruntersystem empfangenen Netzwerkdurchsatzes für jede Instance in der DB-Shard-Gruppe. + `StorageNetworkThroughput`: Der aggregierte Netzwerkdurchsatz, den jede Instance in der DB-Shard-Gruppe an das Aurora-Speichersubsystem sendet und vom Aurora-Speichersubsystem empfängt. + `StorageNetworkTransmitThroughput`: Der Umfang des von jeder Instance in der DB-Shard-Gruppe an das Aurora-Speicheruntersystem gesendeten Netzwerkdurchsatzes. + `SwapUsage`: Die Menge des von der DB-Shard-Gruppe verwendeten Auslagerungsbereichs. + `TempStorageIOPS`: Die durchschnittliche Anzahl von I/O-Operationen, die im lokalen Speicher durchgeführt werden, der der DB-Instance angefügt ist. Sie umfasst sowohl Lese- als auch Schreib-I/O-Vorgänge. `TempStorageIOPS` kann zusammen mit `TempStorageThroughput` verwendet werden, um die seltenen Fälle zu diagnostizieren, in denen die Netzwerkaktivität für Übertragungen zwischen Ihren DB-Instances und lokalen Speichergeräten für unerwartete Kapazitätssteigerungen verantwortlich ist. + `TempStorageThroughput`: Die Menge der mit einem Router oder einem Shard verknüpften Daten, die an den und aus dem lokalen Speicher übertragen wurden. + `WriteIOPS`: Die durchschnittliche Anzahl der Datenträger-Schreib-IOPS. + `WriteLatency`: Die durchschnittliche Dauer für einen Datenträger-Schreib-I/O-Vorgang. + `WriteThroughput`. Die durchschnittliche Anzahl Byte, die pro Sekunde auf den Datenträger geschrieben werden. Die folgenden Dimensionsschlüssel sind zum Aggregieren der `DBShardGroupInstance`-Metrik verfügbar. + `DBClusterIdentifier`: Der DB-Cluster von Aurora PostgreSQL. + `DBShardGroupIdentifier`: Die DB-Shard-Gruppe, zu der die Instance gehört. + `DBShardGroupSubClusterType`: Der Knotentyp, entweder `Distributed Transaction Router` (Router) oder `Data Access Shard` (Shard). + `DBShardGroupSubClusterIdentifier`: Der Name des Routers oder Shards, zu dem die Instance gehört. Im Folgenden finden Sie Beispiele für das Aggregieren von CloudWatch-Metriken: + Gesamt-`CPUUtilization` aller Instances, die zu einem bestimmten Shard oder Router in einer DB-Shard-Gruppe gehören. + Gesamt-`CPUUtilization` aller Instances in einer DB-Shard-Gruppe. ## DBClusterIdentifier-Metriken Wenn Sie `DBClusterIdentifier`-Metriken für Aurora PostgreSQL Limitless Database in der CloudWatch-Konsole anzeigen möchten, wählen Sie **RDS** und dann **DBClusterIdentifier** aus. Wenn Sie Aurora PostgreSQL Limitless Database verwenden, haben Sie möglicherweise mehr I/O-Vorgänge (Ein-/Ausgabe) als bei einem Aurora-DB-Cluster. Sie können die folgenden CloudWatch-Metriken für Ihren Limitless-Database-Cluster verfolgen: + `VolumeReadIops` Die Anzahl von in Rechnung gestellten I/O-Vorgängen aus einem Cluster-Volume, gemeldet in 5-Minuten-Intervallen. + `VolumeWriteIops`: Die Anzahl der Datenträger-I/O-Schreibvorgänge im Cluster-Volume, gemeldet in 5-Minuten-Intervallen. Aurora PostgreSQL Limitless Database verwendet die Cluster-Speicherkonfiguration Aurora I/O-Optimized. Mit Aurora I/O-Optimized zahlen Sie einen einzigen monatlichen Preis für alle I/O-Vorgänge, anstatt für jede Million I/O-Anfragen. Weitere Informationen finden Sie unter [Speicherkonfigurationen für DB-Cluster von Amazon Aurora](Aurora.Overview.StorageReliability.md#aurora-storage-type). Möglicherweise verwenden Sie auch mehr Speicher als für einen Aurora-DB-Cluster. Sie können die folgenden CloudWatch-Metriken hinsichtlich der Speichernutzung verfolgen: + `BackupRetentionPeriodStorageUsed`: Die gesamte kontinuierliche Backup-Speicherauslastung Ihres Clusters von Aurora PostgreSQL Limitless Database, die in Rechnung gestellt wurde. + `SnapshotStorageUsed`: Die gesamte Snapshot-Speicherauslastung Ihres Clusters von Aurora PostgreSQL Limitless Database, die in Rechnung gestellt wurde. + `TotalBackupStorageBilled`: Die Summe Ihrer Kosten für automatische Backup-Aufbewahrung und DB-Cluster-Snapshots. Weitere Information zu Backup-Speicherkosten finden Sie unter [Grundlegendes zur Backup-Speicher-Nutzung in Amazon Aurora](aurora-storage-backup.md). + `VolumeBytesUsed`: Die vom Cluster Ihrer Aurora PostgreSQL Limitless Database verwendeten Speichermenge, gemeldet in 5-Minuten-Intervallen. # Überwachen von Aurora PostgreSQL Limitless Database mit CloudWatch Database Insights Der Standardmodus von Database Insights ist für die Aktivierung von Aurora PostgreSQL Limitless Database erforderlich. Sie können damit die Datenbanklast (DB-Last) Ihrer DB-Instances von Limitless Database in Echtzeit überwachen. Die DB-Last misst den Sitzungsaktivitätsgrad in einer Datenbank. Sie können Database Insights verwenden, um die Leistung Ihrer DB-Instances von Aurora PostgreSQL Limitless Database in großem Umfang zu analysieren und Fehler zu beheben. Weitere Informationen zu CloudWatch-Database-Metriken finden Sie im folgenden Abschnitt. + [Überwachen von Amazon-Aurora-Datenbanken mit CloudWatch Database Insights](USER_DatabaseInsights.md) + [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html) im *Amazon-CloudWatch-Benutzerhandbuch* + [Erste Schritte mit CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Get-Started.html) im *Amazon-CloudWatch-Benutzerhandbuch* + [Konfigurieren Ihrer Datenbank zur Überwachung langsamer SQL-Abfragen mit Database Insights für Amazon Aurora](USER_DatabaseInsights.SlowSQL.md) Informationen zum Aktivieren des erweiterten Modus oder des Standardmodus von Database Insights finden Sie in den folgenden Themen. **Topics** + [ # Aktivieren des erweiterten Modus von Database Insights für Aurora PostgreSQL Limitless Database ](limitless-monitoring.cwdbi.advanced.md) + [ # Aktivieren des Standardmodus von Database Insights für Aurora PostgreSQL Limitless Database ](limitless-monitoring.cwdbi.standard.md) # Aktivieren des erweiterten Modus von Database Insights für Aurora PostgreSQL Limitless Database Gehen Sie wie folgt vor, um den erweiterten Modus von Database Insights für Ihre Aurora PostgreSQL Limitless Database zu aktivieren. ## Aktivieren des erweiterten Modus von Database Insights beim Erstellen eines DB-Clusters für Aurora PostgreSQL Limitless Database Aktivieren Sie den erweiterten Modus von Database Insights, wenn Sie eine Datenbank für Aurora PostgreSQL Limitless Database erstellen. ------ #### [ Console ] In der Konsole können Sie den erweiterten Modus von Database Insights aktivieren, wenn Sie einen DB-Cluster erstellen. Die Einstellungen für Database Insights gelten für alle DB-Instances in Ihrem DB-Cluster. **So aktivieren Sie den erweiterten Modus von Database Insights, wenn Sie einen DB-Cluster über die Konsole erstellen** 1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie **Databases (Datenbanken)** aus. 1. Wählen Sie **Create database (Datenbank erstellen)** aus. 1. Wählen Sie im Abschnitt **Database Insights** **Erweiterter Modus** aus. Wählen Sie dann eine der folgenden Optionen aus: + **Aufbewahrung** – Die Zeitspanne, für die die Performance-Insights-Daten aufbewahrt werden sollen. Der Aufbewahrungszeitraum für den erweiterten Modus von Database Insights muss 15-24 Monate betragen. + **AWS KMS key** – Geben Sie Ihren KMS-Schlüssel an. Performance Insights verschlüsselt alle potenziell sensiblen Daten mit Ihrem KMS-Schlüssel. Die Daten werden während der Übertragung und im Ruhezustand verschlüsselt. Weitere Informationen finden Sie unter [Verschlüsseln von Amazon Aurora-Ressourcen](Overview.Encryption.md). 1. Wählen Sie **Create database (Datenbank erstellen)** aus. ------ #### [ AWS CLI ] Um den erweiterten Modus von Database Insights beim Erstellen eines DB-Clusters zu aktivieren, rufen Sie den AWS CLI-Befehl [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) auf und geben Sie die folgenden Werte ein: + `--db-cluster-identifier`: Die Kennung für den DB-Cluster. + `--database-insights-mode advanced`: Um den erweiterten Modus von Database Insights zu aktivieren. + `--engine`: Der DB-Cluster muss die `aurora-postgresql`-DB-Engine verwenden. + `--engine-version`: Der DB-Cluster muss eine der DB-Engine-Versionen verwenden: + `16.4-limitless` + `16.6-limitless` + `--storage-type`: Der DB-Cluster muss die Speicherkonfiguration des `aurora-iopt1`-DB-Clusters verwenden. + `--cluster-scalability-type`: Gibt den Skalierbarkeitsmodus des Aurora-DB-Clusters an. Wenn dieser Parameter auf `limitless` gesetzt ist, arbeitet der Cluster als Aurora PostgreSQL Limitless Database. Wenn er auf `standard` (Standard) gesetzt ist, verwendet der Cluster die normale DB-Instance-Erstellung. **Anmerkung** Sie können diese Einstellung nicht mehr ändern, nachdem Sie den DB-Cluster erstellt haben. + `--master-username`: Der Name des Masterbenutzers für diesen DB-Cluster. + `--master-user-password`: Das Passwort für den Masterbenutzer. + `--enable-performance-insights`: Um Performance Insights für Database Insights zu aktivieren. + `--performance-insights-retention-period`: Der Aufbewahrungszeitraum für Daten für Ihren DB-Cluster. Um Database Insights zu aktivieren, muss der Aufbewahrungszeitraum mindestens 465 Tage betragen. + `--monitoring-interval`: Das Intervall in Sekunden zwischen den Punkten, an denen erweiterte Überwachungsmetriken für den DB-Cluster erfasst werden. Dieser Wert darf nicht `0` sein. + `--monitoring-role-arn`: Der Amazon-Ressourcenname (ARN) für die IAM-Rolle, die es RDS erlaubt, erweiterte Überwachungsmetriken an Amazon CloudWatch Logs zu senden. + `--enable-cloudwatch-logs-exports`: Sie müssen `postgresql`-Protokolle zu CloudWatch-Protokollen exportieren. Im folgenden Beispiel wird der erweiterte Modus von Database Insights aktiviert, wenn ein DB-Cluster erstellt wird. Für Linux, macOS oder Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier my-limitless-cluster \ --database-insights-mode advanced \ --engine aurora-postgresql \ --engine-version 16.6-limitless \ --storage-type aurora-iopt1 \ --cluster-scalability-type limitless \ --master-username myuser \ --master-user-password mypassword \ --enable-performance-insights \ --performance-insights-retention-period 465 \ --monitoring-interval 5 \ --monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \ --enable-cloudwatch-logs-exports postgresql ``` Für Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier my-limitless-cluster ^ --database-insights-mode advanced ^ --engine aurora-postgresql ^ --engine-version 16.6-limitless ^ --storage-type aurora-iopt1 ^ --cluster-scalability-type limitless ^ --master-username myuser ^ --master-user-password mypassword ^ --enable-performance-insights ^ --performance-insights-retention-period 465 ^ --monitoring-interval 5 ^ --monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^ --enable-cloudwatch-logs-exports postgresql ``` ------ #### [ RDS API ] Um den erweiterten Modus von Database Insights zu aktivieren, wenn Sie DB-Cluster erstellen, geben Sie die folgenden Parameter für Ihren Vorgang mit der Amazon-RDS-API [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) an. + `DatabaseInsightsMode` auf `advanced` + `Engine` auf `aurora-postgresql` + `EngineVersion` auf einer verfügbaren Engine-Version für Limitless Database + `StorageType` auf `aurora-iopt1` + `ClusterScalabilityType` auf `limitless` + `MasterUsername` + `MasterUserPassword` + `EnablePerformanceInsights` auf `True` + `PerformanceInsightsRetentionPeriod` auf mindestens `465` Tage + `MonitoringInterval` auf einen Wert, der nicht `0` ist + `MonitoringRoleArn` auf den Amazon-Ressourcennamen (ARN) für die IAM-Rolle, die es RDS erlaubt, erweiterte Überwachungsmetriken an Amazon CloudWatch Logs zu senden. ------ ## Aktivieren des erweiterten Modus von Database Insights beim Ändern eines DB-Clusters für Aurora PostgreSQL Limitless Database Aktivieren Sie Database Insights, wenn Sie eine Datenbank für Aurora PostgreSQL Limitless Database ändern. **Anmerkung** Um Database Insights zu aktivieren, muss jede DB-Instance in einem DB-Cluster dieselben Einstellungen für Performance Insights und Enhanced Monitoring aufweisen. ------ #### [ Console ] In der Konsole können Sie den erweiterten Modus von Database Insights aktivieren, wenn Sie einen DB-Cluster ändern. Die Einstellungen für Database Insights gelten für alle DB-Instances in Ihrem DB-Cluster. **So aktivieren Sie den erweiterten Modus von Database Insights, wenn Sie einen DB-Cluster über die Konsole ändern** 1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie **Databases (Datenbanken)** aus. 1. Wählen Sie einen DB-Cluster aus und klicken Sie dann auf **Ändern**. 1. Wählen Sie im Abschnitt **Database Insights** **Erweiterter Modus** aus. Wählen Sie dann eine der folgenden Optionen aus: + **Aufbewahrung** – Die Zeitspanne, für die die Performance-Insights-Daten aufbewahrt werden sollen. Der Aufbewahrungszeitraum für den erweiterten Modus von Database Insights muss 15-24 Monate betragen. + **AWS KMS key** – Geben Sie Ihren KMS-Schlüssel an. Performance Insights verschlüsselt alle potenziell sensiblen Daten mit Ihrem KMS-Schlüssel. Die Daten werden während der Übertragung und im Ruhezustand verschlüsselt. Weitere Informationen finden Sie unter [Verschlüsseln von Amazon Aurora-Ressourcen](Overview.Encryption.md). 1. Klicken Sie auf **Weiter**. 1. Wählen Sie für **Einplanung von Änderungen** die Option **Sofort anwenden** aus. Wenn Sie **Anwendung während des nächsten geplanten Wartungsfensters** auswählen, ignoriert Ihre Datenbank diese Einstellung und aktiviert den erweiterten Modus von Database Insights sofort. 1. Wählen Sie **Cluster bearbeiten** aus. ------ #### [ AWS CLI ] Um den erweiterten Modus von Database Insights beim Ändern eines DB-Clusters zu aktivieren, rufen Sie den AWS CLI-Befehl [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) auf und geben Sie die folgenden Werte ein: + `--database-insights-mode advanced`, um den erweiterten Modus von Database Insights zu aktivieren. + `--db-cluster-identifier`: Die Kennung für den DB-Cluster. + `--enable-performance-insights`, um Performance Insights für Database Insights zu aktivieren. + `--performance-insights-retention-period`: Der Aufbewahrungszeitraum für Daten für Ihren DB-Cluster. Um den erweiterten Modus von Database Insights zu aktivieren, muss der Aufbewahrungszeitraum mindestens 465 Tage betragen. Im folgenden Beispiel wird der erweiterte Modus von Database Insights aktiviert, wenn ein DB-Cluster geändert wird. Für Linux, macOS oder Unix: ``` aws rds modify-db-cluster \ --database-insights-mode advanced \ --db-cluster-identifier sample-db-identifier \ --enable-performance-insights \ --performance-insights-retention-period 465 ``` Für Windows: ``` aws rds modify-db-cluster ^ --database-insights-mode advanced ^ --db-cluster-identifier sample-db-identifier ^ --enable-performance-insights ^ --performance-insights-retention-period 465 ``` ------ #### [ RDS API ] Um den erweiterten Modus von Database Insights zu aktivieren, wenn Sie einen DB-Cluster ändern, geben Sie die folgenden Parameter für Ihren Vorgang der Amazon-RDS-API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) an. + `DatabaseInsightsMode` auf `advanced` + `EnablePerformanceInsights` auf `True` + `PerformanceInsightsRetentionPeriod` auf mindestens `465` Tage ------ # Aktivieren des Standardmodus von Database Insights für Aurora PostgreSQL Limitless Database Gehen Sie wie folgt vor, um den Standardmodus von Database Insights für Ihre Aurora PostgreSQL Limitless Database zu aktivieren. ## Aktivieren des Standardmodus von Database Insights beim Erstellen eines DB-Clusters für Aurora PostgreSQL Limitless Database Aktivieren Sie den Standardmodus von Database Insights, wenn Sie eine Datenbank für Aurora PostgreSQL Limitless Database erstellen. ------ #### [ Console ] In der Konsole können Sie den Standardmodus von Database Insights aktivieren, wenn Sie einen DB-Cluster erstellen. Die Einstellungen für Database Insights gelten für alle DB-Instances in Ihrem DB-Cluster. **So aktivieren Sie den Standardmodus von Database Insights, wenn Sie einen DB-Cluster über die Konsole erstellen** 1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie **Databases (Datenbanken)** aus. 1. Wählen Sie **Create database (Datenbank erstellen)** aus. 1. Wählen Sie im Abschnitt **Database Insights** **Standardmodus** aus. Wählen Sie dann eine der folgenden Optionen aus: + **Aufbewahrung** – Die Zeitspanne, für die die Performance-Insights-Daten aufbewahrt werden sollen. Um einen DB-Cluster für Aurora PostgreSQL Limitless Database zu erstellen, muss der Aufbewahrungszeitraum mindestens 31 Tage betragen. + **AWS KMS key** – Geben Sie Ihren KMS-Schlüssel an. Performance Insights verschlüsselt alle potenziell sensiblen Daten mit Ihrem KMS-Schlüssel. Die Daten werden während der Übertragung und im Ruhezustand verschlüsselt. Weitere Informationen finden Sie unter [Verschlüsseln von Amazon Aurora-Ressourcen](Overview.Encryption.md). 1. Wählen Sie **Create database (Datenbank erstellen)** aus. ------ #### [ AWS CLI ] Um den Standardmodus von Database Insights beim Erstellen eines DB-Clusters zu aktivieren, rufen Sie den AWS CLI-Befehl [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) auf und geben Sie die folgenden Werte ein: + `--db-cluster-identifier`: Die Kennung für den DB-Cluster. + `--database-insights-mode standard`: Um den Standardmodus von Database Insights zu aktivieren. + `--engine`: Der DB-Cluster muss die `aurora-postgresql`-DB-Engine verwenden. + `--engine-version`: Der DB-Cluster muss eine der DB-Engine-Versionen verwenden: + `16.4-limitless` + `16.6-limitless` + `--storage-type`: Der DB-Cluster muss die Speicherkonfiguration des `aurora-iopt1`-DB-Clusters verwenden. + `--cluster-scalability-type`: Gibt den Skalierbarkeitsmodus des Aurora-DB-Clusters an. Wenn dieser Parameter auf `limitless` gesetzt ist, arbeitet der Cluster als Aurora PostgreSQL Limitless Database. Wenn er auf `standard` (Standard) gesetzt ist, verwendet der Cluster die normale DB-Instance-Erstellung. **Anmerkung** Sie können diese Einstellung nicht mehr ändern, nachdem Sie den DB-Cluster erstellt haben. + `--master-username`: Der Name des Masterbenutzers für diesen DB-Cluster. + `--master-user-password`: Das Passwort für den Masterbenutzer. + `--enable-performance-insights`, um Performance Insights für Database Insights zu aktivieren. + `--performance-insights-retention-period`: Der Aufbewahrungszeitraum für Daten für Ihren DB-Cluster. Um einen DB-Cluster für Aurora PostgreSQL Limitless Database zu erstellen, muss der Aufbewahrungszeitraum mindestens 31 Tage betragen. + `--monitoring-interval`: Das Intervall in Sekunden zwischen den Punkten, an denen erweiterte Überwachungsmetriken für den DB-Cluster erfasst werden. Dieser Wert darf nicht `0` sein. + `--monitoring-role-arn`: Der Amazon-Ressourcenname (ARN) für die IAM-Rolle, die es RDS erlaubt, erweiterte Überwachungsmetriken an Amazon CloudWatch Logs zu senden. + `--enable-cloudwatch-logs-exports`: Sie müssen `postgresql`-Protokolle zu CloudWatch-Protokollen exportieren. Im folgenden Beispiel wird der Standardmodus von Database Insights aktiviert, wenn ein DB-Cluster erstellt wird. Für Linux, macOS oder Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier my-limitless-cluster \ --database-insights-mode standard \ --engine aurora-postgresql \ --engine-version 16.6-limitless \ --storage-type aurora-iopt1 \ --cluster-scalability-type limitless \ --master-username myuser \ --master-user-password mypassword \ --enable-performance-insights \ --performance-insights-retention-period 31 \ --monitoring-interval 5 \ --monitoring-role-arn arn:aws:iam::123456789012:role/EMrole \ --enable-cloudwatch-logs-exports postgresql ``` Für Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier my-limitless-cluster ^ --database-insights-mode standard ^ --engine aurora-postgresql ^ --engine-version 16.6-limitless ^ --storage-type aurora-iopt1 ^ --cluster-scalability-type limitless ^ --master-username myuser ^ --master-user-password mypassword ^ --enable-performance-insights ^ --performance-insights-retention-period 31 ^ --monitoring-interval 5 ^ --monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ^ --enable-cloudwatch-logs-exports postgresql ``` ------ #### [ RDS API ] Um den Standardmodus von Database Insights zu aktivieren, wenn Sie DB-Cluster erstellen, geben Sie die folgenden Parameter für Ihren Vorgang mit der Amazon-RDS-API [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) an. + `DatabaseInsightsMode` auf `standard` + `Engine` auf `aurora-postgresql` + `EngineVersion` auf einer verfügbaren Engine-Version für Limitless Database + `StorageType` auf `aurora-iopt1` + `ClusterScalabilityType` auf `limitless` + `MasterUsername` + `MasterUserPassword` + `EnablePerformanceInsights` auf `True` + `PerformanceInsightsRetentionPeriod` auf mindestens `31` Tage + `MonitoringInterval` auf einen Wert, der nicht `0` ist + `MonitoringRoleArn` auf den Amazon-Ressourcennamen (ARN) für die IAM-Rolle, die es RDS erlaubt, erweiterte Überwachungsmetriken an Amazon CloudWatch Logs zu senden. ------ ## Aktivieren des Standardmodus von Database Insights beim Ändern eines DB-Clusters für Aurora PostgreSQL Limitless Database Aktivieren Sie Database Insights, wenn Sie eine Datenbank für Aurora PostgreSQL Limitless Database ändern. **Anmerkung** Um Database Insights zu aktivieren, muss jede DB-Instance in einem DB-Cluster dieselben Einstellungen für Performance Insights und Enhanced Monitoring aufweisen. ------ #### [ Console ] In der Konsole können Sie den Standardmodus von Database Insights aktivieren, wenn Sie einen DB-Cluster erstellen. Die Einstellungen für Database Insights gelten für alle DB-Instances in Ihrem DB-Cluster. **So aktivieren Sie den Standardmodus von Database Insights, wenn Sie einen DB-Cluster über die Konsole ändern** 1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie **Databases (Datenbanken)** aus. 1. Wählen Sie einen DB-Cluster aus und klicken Sie dann auf **Ändern**. 1. Wählen Sie im Abschnitt **Database Insights** **Standardmodus** aus. Wählen Sie dann eine der folgenden Optionen aus: + **Aufbewahrung** – Die Zeitspanne, für die die Performance-Insights-Daten aufbewahrt werden sollen. Um einen DB-Cluster für Aurora PostgreSQL Limitless Database zu erstellen, muss der Aufbewahrungszeitraum mindestens 31 Tage betragen. + **AWS KMS key** – Geben Sie Ihren KMS-Schlüssel an. Performance Insights verschlüsselt alle potenziell sensiblen Daten mit Ihrem KMS-Schlüssel. Die Daten werden während der Übertragung und im Ruhezustand verschlüsselt. Weitere Informationen finden Sie unter [Verschlüsseln von Amazon Aurora-Ressourcen](Overview.Encryption.md). 1. Klicken Sie auf **Weiter**. 1. Wählen Sie für **Einplanung von Änderungen** die Option **Sofort anwenden** aus. Wenn Sie **Anwendung während des nächsten geplanten Wartungsfensters** auswählen, ignoriert Ihre Datenbank diese Einstellung und aktiviert den Standardmodus von Database Insights sofort. 1. Wählen Sie **Cluster bearbeiten** aus. ------ #### [ AWS CLI ] Um den Standardmodus von Database Insights beim Ändern eines DB-Clusters zu aktivieren, rufen Sie den AWS CLI-Befehl [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) auf und geben Sie die folgenden Werte ein: + `--db-cluster-identifier`: Die Kennung für den DB-Cluster. + `--database-insights-mode standard`, um den Standardmodus von Database Insights zu aktivieren. + `--enable-performance-insights`, um Performance Insights für Database Insights zu aktivieren. + `--performance-insights-retention-period`: Der Aufbewahrungszeitraum für Daten für Ihren DB-Cluster. Um den Standardmodus von Database Insights zu aktivieren, muss der Aufbewahrungszeitraum mindestens 31 Tage betragen. Im folgenden Beispiel wird der Standardmodus von Database Insights aktiviert, wenn ein DB-Cluster geändert wird. Für Linux, macOS oder Unix: ``` aws rds modify-db-cluster \ --database-insights-mode standard \ --db-cluster-identifier sample-db-identifier \ --enable-performance-insights \ --performance-insights-retention-period 31 ``` Für Windows: ``` aws rds modify-db-cluster ^ --database-insights-mode standard ^ --db-cluster-identifier sample-db-identifier ^ --enable-performance-insights ^ --performance-insights-retention-period 31 ``` ------ #### [ RDS API ] Um den Standardmodus von Database Insights zu aktivieren, wenn Sie einen DB-Cluster ändern, geben Sie die folgenden Parameter für Ihren Vorgang der Amazon-RDS-API [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) an. + `DatabaseInsightsMode` auf `standard` + `EnablePerformanceInsights` auf `True` + `PerformanceInsightsRetentionPeriod` auf mindestens `31` Tage ------ # Überwachen von Aurora PostgreSQL Limitless-Datenbank mit Amazon CloudWatch Logs Der Export von PostgreSQL-Protokollen nach CloudWatch Logs ist im Rahmen der Aktivierung von Aurora PostgreSQL Limitless Database erforderlich. Sie können in CloudWatch Logs Insights auf diese Protokolle zugreifen und sie analysieren, ähnlich wie beim Zugriff auf PostgreSQL-Protokolle für einen standardmäßigen DB-Cluster von Aurora PostgreSQL. Weitere Informationen finden Sie unter [Analysieren von Aurora-PostgreSQL-Protokollen mit CloudWatch Logs Insights](AuroraPostgreSQL.CloudWatch.Analyzing.md). Der Name der Protokollgruppe für den DB-Cluster ist derselbe wie in Aurora PostgreSQL: ``` /aws/rds/cluster/DB_cluster_ID/postgresql ``` Der Name der Protokollgruppe für die DB-Shard-Gruppe hat folgendes Format: ``` /aws/rds/cluster/DB_cluster_ID/DB_shard_group_ID/postgresql ``` Für jeden Knoten (Router oder Shard) gibt es Protokollstreams. Ihre Namen haben das folgende Format: ``` [DistributedTransactionRouter|DataAccessShard]/node_cluster_serial_ID-node_instance_serial_ID/n ``` Zum Beispiel: + Router – `DistributedTransactionRouter/6-6.2` + Shard – `DataAccessShard/22-22.0` **Anmerkung** Sie können PostgreSQL-Protokolldateien für die DB-Shard-Gruppe nicht direkt in der RDS-Konsole, in der AWS CLI oder in der RDS-API anzeigen, wie es für den DB-Cluster möglich ist. Um sie anzuzeigen, müssen Sie CloudWatch Logs Insights verwenden. # Überwachen einer Aurora PostgreSQL Limitless Database mithilfe der erweiterten Überwachung Im Rahmen der Aktivierung von Aurora PostgreSQL Limitless Database ist eine erweiterte Überwachung erforderlich. Sie können damit das Betriebssystem Ihrer DB-Instances von Limitless Database in Echtzeit überwachen. Aurora veröffentlicht die Metriken für erweiterte Überwachung in CloudWatch-Protokollen. Zu den wichtigsten verfügbaren Metriken gehören Datenbankverbindungen, Speichernutzung und Abfragelatenz. Diese können helfen, Leistungsengpässe zu identifizieren. Weitere Informationen zu Metriken für erweiterte Überwachung finden Sie unter [Betriebssystemmetriken für Aurora](USER_Monitoring-Available-OS-Metrics.md#USER_Monitoring-Available-OS-Metrics-RDS). # Überwachen einer Aurora PostgreSQL Limitless Database mithilfe von Performance Insights Verwenden Sie Performance Insights, um Ihren Cluster von Aurora PostgreSQL Limitless Database zu überwachen. Performance Insights funktioniert für Aurora PostgreSQL Limitless Database ähnlich wie für standardmäßige Aurora-DB-Cluster. Sie verfolgen jedoch Metriken für Aurora PostgreSQL Limitless Database auf Shard-Gruppenebene. Die beiden wichtigsten Performance-Insights-Metriken, die es zu verfolgen gilt, sind die folgenden: + Datenbanklast: Misst den Aktivitätsgrad in Ihrer Datenbank. Die wichtigste Metrik für Performance Insights ist `DBLoad`, die jede Sekunde erfasst wird. Die Einheit für die Metrik `DBLoad` in Performance Insights ist AAS (Durchschnittliche aktive Sitzungen) Um die Anzahl der durchschnittlich aktiven Sitzungen AAS zu erhalten, ruft Performance Insights die Anzahl der Sitzungen ab, die gleichzeitig eine Abfrage ausführen. Die AAS ist die Gesamtzahl der Sitzungen geteilt durch die Gesamtzahl der Beispiele. Weitere Informationen zu `DBLoad` und AAS finden Sie unter [Datenbanklast](USER_PerfInsights.Overview.ActiveSessions.md). + Maximale CPU: Die maximale Rechenleistung, die Ihrer Datenbank zur Verfügung steht. Um zu sehen, ob aktive Sitzungen die maximale CPU überschreiten, sehen Sie sich ihre Beziehung zur `Max vCPU`-Linie an. Der `Max vCPU`-Wert wird anhand der Anzahl der vCPU (virtuellen CPU)-Cores für Ihre DB-Instance bestimmt. Weitere Informationen zu `Max vCPU` finden Sie unter [Maximale CPU](USER_PerfInsights.Overview.MaxCPU.md). Darüber hinaus können Sie die Metrik `DBLoad` in *Dimensionen* aufteilen, also in „Unterkategorien“ der Metrik. Die am häufigsten verwendeten Dimensionen sind folgende: + Top-Instances: Zeigt die relative DB-Auslastung für Ihre Instances (Shards und Router) in absteigender Reihenfolge an. + Warteereignis: Bewirkt, dass SQL-Anweisungen warten, bis ein bestimmtes Ereignis eintritt, bevor sie mit der Ausführung fortfahren können. Warteereignisse geben an, wo Arbeit behindert wird. + Top-SQL: Zeigt, welche Abfragen am meisten zur Datenbanklast beitragen. Weitere Informationen zu Performance-Insights-Dimensionen finden Sie unter [Dimensionen](USER_PerfInsights.Overview.ActiveSessions.md#USER_PerfInsights.Overview.ActiveSessions.dimensions). Die folgende Abbildung zeigt die Dimension **Top-Instances** für eine DB-Shard-Gruppe. ![\[Die Dimension „Top-Instances“ für eine DB-Shard-Gruppe.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png) **Topics** + [ # Analysieren der DB-Last nach Wartevorgängen für Aurora PostgreSQL Limitless Database über das Dashboard von Performance Insights ](USER_PerfInsights.AnalyzeLimitlessTables.md) # Analysieren der DB-Last nach Wartevorgängen für Aurora PostgreSQL Limitless Database über das Dashboard von Performance Insights Mit Performance Insights können Sie Metriken auf Shard-Gruppenebene und Instance-Ebene für eine Aurora PostgreSQL Limitless-Datenbank verfolgen. Bei der Analyse der DB-Auslastung für eine Aurora PostgreSQL Limitless Database können Sie die DB-Last für jeden Shard und Router mit der maximalen vCPU vergleichen. **Anmerkung** Bei Aurora PostgreSQL Limitless Database sind Performance Insights und Enhanced Monitoring immer aktiviert. Die Mindestaufbewahrungsdauer für Performance-Insights-Daten für Limitless Database beträgt 31 Tage (1 Monat). In der Ansicht **Absolut** werden die Anzahl der durchschnittlichen aktiven Sitzungen (AAS) und die geschätzte vCPU angezeigt. Die Ansicht **Relativ** zeigt das Verhältnis von AAS zur geschätzten vCPU. **Topics** + [ ## Analysieren der relativen DB-Last für Aurora PostgreSQL Limitless Database über das Dashboard von Performance Insights ](#USER_PerfInsights.AnalyzeLimitlessTables.RelativeLoad) + [ # Analysieren der DB-Last nach Wartevorgängen für Aurora PostgreSQL Limitless Database über das Dashboard von Performance Insights ](USER_PerfInsights.AnalyzeLimitlessTables.Waits.md) + [ # Analysieren der Lastverteilung für Aurora PostgreSQL Limitless Database über das Dashboard von Performance Insights ](USER_PerfInsights.AnalyzeLimitlessTables.LoadDistribution.md) ## Analysieren der relativen DB-Last für Aurora PostgreSQL Limitless Database über das Dashboard von Performance Insights Sie können die Leistung Ihrer Aurora PostgreSQL Limitless Database verbessern, indem Sie die relative DB-Last verfolgen. Gehen Sie wie folgt vor, um die relative DB-Last nach Instance für Ihre Aurora PostgreSQL Limitless Database zu analysieren. **So analysieren Sie die relative DB-Last für Aurora PostgreSQL Limitless Database über die Konsole** 1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie im Navigationsbereich **Performance-Insights** aus. 1. Wählen Sie eine Aurora PostgreSQL Limitless Database aus. Das Dashbard von Performance Insights wird für diese Aurora PostgreSQL Limitless Database angezeigt. 1. Wählen Sie im Abschnitt **Datenbanklast (DB-Last)** die Option **Instances** für **Aufgeteilt nach** aus. **Um das Verhältnis von durchschnittlichen aktiven Sitzungen (AAS) zu vCPU-Kernen für alle Instances in Ihrer Aurora PostgreSQL Limitless Database anzuzeigen, wählen Sie **Relativ** für Angezeigt als** aus. Im Diagramm „Durchschnittliche aktive Sitzungen“ wird die DB-Last für Instances in Ihrer Aurora PostgreSQL Limitless Database angezeigt. ![\[Zeigen Sie das Dashboard von Performance Insights für Ihre Aurora PostgreSQL Limitless Database aufgeteilt nach Instances an.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pi-relative-instances.png) 1. Um die Top-Instances anzuzeigen, wählen Sie die Registerkarte **Top-Instances** aus. Im folgenden Beispiel ist `DTR-2-2` die Instance mit der höchsten DB-Last ![\[Verwenden Sie die Registerkarte „Top-Instances“ für eine Aurora PostgreSQL Limitless Database, aufgeteilt nach Instances.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pi-top-instances.png) 1. (Optional) Um die DB-Last für eine Instance in Ihrer Aurora PostgreSQL Limitless Database zu analysieren, wählen Sie den Instance-Namen in der Spalte **Instances** aus. Um die DB-Last für `DTR-2-2` anzuzeigen, wählen Sie `DTR-2-2` in der Spalte **Instances** aus. **Anmerkung** Sie können Performance-Insights-Metriken nur für Instances in einer Aurora PostgreSQL Limitless Database anzeigen. # Analysieren der DB-Last nach Wartevorgängen für Aurora PostgreSQL Limitless Database über das Dashboard von Performance Insights Sie können die Leistung Ihrer Aurora PostgreSQL Limitless Database verbessern, indem Sie Warteereignisse verfolgen. Gehen Sie wie folgt vor, um die DB-Last nach Warteereignissen für Ihre Aurora PostgreSQL Limitless Database zu analysieren. **So analysieren Sie die Datenbanklast nach Wartevorgängen für Aurora PostgreSQL Limitless Database über die Konsole** 1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie im Navigationsbereich **Performance-Insights** aus. 1. Wählen Sie eine Aurora PostgreSQL Limitless Database aus. Das Dashbard von Performance Insights wird für diese Aurora PostgreSQL Limitless Database angezeigt. 1. Wählen Sie im Abschnitt **Datenbanklast (DB-Last)** die Option **Wartevorgänge** für **Aufgeteilt nach** aus. Um die Anzahl der AAS und die geschätzte vCPU anzuzeigen, wählen Sie **Absolut** für **Angezeigt als** aus. Im Diagramm „Durchschnittliche aktive Sitzungen“ wird die DB-Last für Instances in Ihrer Aurora PostgreSQL Limitless Database angezeigt. ![\[Aufgeteilt nach Wartevorgängen.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-waits.png) 1. Scrollen Sie nach unten zur Registerkarte **Top SQL** (Top-SQL). Im folgenden Beispiel ist die SQL-Anweisung mit der höchsten Last nach Wartevorgängen die Anweisung `DELETE`. ![\[Die oberste SQL-Registerkarte, wenn sie nach Wartevorgängen aufgeteilt wird.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql.png) 1. Wählen Sie die SQL-Anweisung aus, um sie in auf ihre Komponentenanweisungen zu erweitern. Im folgenden Beispiel umfasst die `SELECT`-Anweisung drei Komponentenanweisungen. ![\[Wählen Sie eine SQL-Anweisung aus, um sie zu erweitern.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pi-waits-top-sql-selected.png) # Analysieren der Lastverteilung für Aurora PostgreSQL Limitless Database über das Dashboard von Performance Insights Möglicherweise möchten Sie die Lastverteilung für Instances auf Ihrer Aurora PostgreSQL Limitless Database ausgleichen. Gehen Sie wie folgt vor, um die Lastverteilung der Instances auf einer Aurora PostgreSQL Limitless Database zu analysieren. **So analysieren Sie die Lastverteilung der Instances auf einer Aurora PostgreSQL Limitless Database über die Konsole** 1. Öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie im Navigationsbereich **Performance-Insights** aus. 1. Wählen Sie eine Aurora PostgreSQL Limitless Database aus. Das Dashbard von Performance Insights wird für diese Aurora PostgreSQL Limitless Database angezeigt. 1. Wählen Sie im Abschnitt **Datenbanklast (DB-Last)** die Option **Instances** für **Aufgeteilt nach** aus. Um die Anzahl der AAS und die geschätzte vCPU für alle Instances in Ihrer Aurora PostgreSQL Limitless Database anzuzeigen, wählen Sie **Absolut** für **Angezeigt als** aus. Im Diagramm „Durchschnittliche aktive Sitzungen“ wird die DB-Last für Instances in Ihrer Aurora PostgreSQL Limitless Database angezeigt. ![\[Zeigen Sie das absolute Dashboard von Performance Insights für Ihre Aurora PostgreSQL Limitless Database aufgeteilt nach Instances an.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pi-absolute-instances.png) 1. Um ein Diagramm der Lastverteilung der Instances in Ihrer Aurora PostgreSQL Limitless Database anzuzeigen, wählen Sie die Registerkarte **Lastverteilung** aus. Im folgenden Beispiel ist `DTR-2-2` die Instance mit der höchsten DB-Last ![\[Die oberste SQL-Registerkarte, wenn Sie auf Instance-Ebene nach Wartevorgängen aufteilen.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pi-load-distribution.png) # Überwachen einer Aurora PostgreSQL Limitless Database mithilfe des RDS-Schutzes von Amazon GuardDuty Amazon GuardDuty ist ein Service zur Erkennung von Bedrohungen, der Sie beim Schutz Ihrer Konten, Container, Workloads und Daten in Ihrer AWS-Umgebung unterstützt. Mithilfe von Machine Learning (ML)-Modellen und Funktionen zur Erkennung von Anomalien und Bedrohungen überwacht GuardDuty kontinuierlich verschiedene Protokollquellen und Laufzeitaktivitäten, um potenzielle Sicherheitsrisiken und böswillige Aktivitäten in Ihrer Umgebung zu identifizieren und zu priorisieren. GuardDuty RDS Protection analysiert und profiliert Anmeldeereignisse auf potenzielle Zugriffsbedrohungen, die für Ihre Amazon-Aurora-Datenbanken bestehen könnten. Wenn Sie RDS Protection aktivieren, verarbeitet GuardDuty RDS-Anmeldeereignisse aus Ihren Aurora-Datenbanken. RDS Protection überwacht diese Ereignisse und erstellt ein Profil für potenzielle interne Bedrohungen oder externe Akteure. Weitere Informationen zum RDS-Schutz von GuardDuty in Aurora finden Sie unter [Überwachung von Bedrohungen mit Amazon GuardDuty RDS Protection für Amazon Aurora](guard-duty-rds-protection.md). Weitere Informationen zum Aktivieren des RDS-Schutzes von GuardDuty finden Sie unter [GuardDuty-RDS-Schutz](https://docs.aws.amazon.com/guardduty/latest/ug/rds-protection.html) im *Amazon-GuardDuty-Benutzerhandbuch*. # Funktionen und Ansichten für Aurora PostgreSQL Limitless Database Aurora PostgreSQL Limitless Database verfügt über hinzugefügte Funktionen und Ansichten. Sie basieren auf den entsprechenden Funktionen und Ansichten von Aurora PostgreSQL. **Anmerkung** Einige Statistiken können uneinheitliche Ergebnisse zurückgeben, wenn Transaktionen im Gange sind. **Topics** + [ # Funktionen für Aurora PostgreSQL Limitless Database ](limitless-monitoring-functions.md) + [ # Ansichten für Aurora PostgreSQL Limitless Database ](limitless-monitoring-views.md) # Funktionen für Aurora PostgreSQL Limitless Database In der folgenden Tabelle sehen Sie die neuen Funktionen für Aurora PostgreSQL Limitless Database. **Anmerkung** Die in dieser Tabelle aufgeführten Funktionen befinden sich im Schema `rds_aurora`. Wenn Sie eine Limitless-Database-Funktion verwenden, stellen Sie sicher, dass Sie den vollqualifizierten Objektnamen angeben: `rds_aurora`.`object_name`. | Funktion für Aurora PostgreSQL Limitless Database | Entsprechende Funktion für Aurora PostgreSQL | | --- | --- | | [limitless\$1backend\$1dsid](#limitless_backend_dsid) | pg\$1backend\$1pid | | [limitless\$1cancel\$1session](#limitless_cancel_session) | pg\$1cancel\$1backend | | [limitless\$1stat\$1clear\$1snapshot](#limitless_stat_clear_snapshot) | pg\$1stat\$1clear\$1snapshot | | [limitless\$1stat\$1database\$1size](#limitless_stat_database_size) | pg\$1database\$1size | | [limitless\$1stat\$1get\$1snapshot\$1timestamp](#limitless_stat_get_snapshot_timestamp) | pg\$1stat\$1get\$1snapshot\$1timestamp | | [limitless\$1stat\$1prepared\$1xacts](#limitless_stat_prepared_xacts) | pg\$1prepared\$1xacts | | [limitless\$1stat\$1relation\$1sizes](#limitless_stat_relation_sizes) | pg\$1indexes\$1size, pg\$1relation\$1size, pg\$1table\$1size, pg\$1total\$1relation\$1size | | [limitless\$1stat\$1reset](#limitless_stat_reset) | pg\$1stat\$1reset | | [limitless\$1stat\$1statements\$1reset](#limitless_stat_statements_reset) | pg\$1stat\$1statements\$1reset | | [limitless\$1stat\$1system\$1waits](#limitless_stat_system_waits) | aurora\$1stat\$1system\$1waits | | [limitless\$1terminate\$1session](#limitless_terminate_session) | pg\$1terminate\$1backend | | [limitless\$1wait\$1report](#limitless_wait_report) | aurora\$1wait\$1report | Die folgenden Beispiele enthalten Einzelheiten zu den Funktionen für Aurora PostgreSQL Limitless Database. Weitere Informationen zu PostgreSQL-Funktionen finden Sie unter [Funktionen und Operatoren](https://www.postgresql.org/docs/15/functions.html) in der PostgreSQL-Dokumentation. **limitless\$1backend\$1dsid** Die Funktion `limitless_backend_dsid` gibt die ID der verteilten Sitzung zurück. Eine verteilte Sitzung wird auf einem Router in einer DB-Shard-Gruppe ausgeführt und umfasst Backend-Prozesse auf einem oder mehreren Shards in der DB-Shard-Gruppe. Das folgende Beispiel zeigt, wie die Funktion `limitless_backend_dsid` verwendet werden kann. ``` SELECT rds_aurora.limitless_backend_dsid(); limitless_backend_dsid ------------------------ 8CACD7B04D0FC2A5 (1 row) ``` **limitless\$1cancel\$1session** Die Funktion `limitless_cancel_session` arbeitet ähnlich wie `pg_cancel_backend`, versucht aber, alle Backend-Prozesse im Zusammenhang mit der angegebenen ID einer verteilten Sitzung abzubrechen, indem sie ein `SIGINT` (Unterbrechungssignal) sendet. Es wird der folgende Eingabeparameter verwendet: + `distributed_session_id` (Text): Die ID der verteilten Sitzung, die abgebrochen werden soll. Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `pid` (Text): Die ID des Backend-Prozesses. + `success` (Boolean): Ob der Abbruch erfolgreich war. Das folgende Beispiel zeigt, wie die Funktion `limitless_cancel_session` verwendet werden kann. ``` SELECT * FROM rds_aurora.limitless_cancel_session('940CD5C81E3C796B'); subcluster_id | pid | success ---------------+-------+--------- 1 | 26920 | t (1 row) ``` **limitless\$1stat\$1clear\$1snapshot** Die Funktion `limitless_stat_clear_snapshot` verwirft den aktuellen Statistik-Snapshot oder die zwischengespeicherten Informationen auf allen Knoten. Das folgende Beispiel zeigt, wie die Funktion `limitless_stat_clear_snapshot` verwendet werden kann. ``` SELECT rds_aurora.limitless_stat_clear_snapshot(); ``` **limitless\$1stat\$1database\$1size** Die Funktion `limitless_stat_database_size` gibt die Größen einer Datenbank in der DB-Shard-Gruppe zurück. Es wird der folgende Eingabeparameter verwendet: + `dbname` (Name): Die Datenbank, für die die Größen abgerufen werden sollen. Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `subcluster_type` (Text): Der Typ des Subclusters, zu dem dieser Prozess gehört: `router` oder `shard`. + `db_size`: Die Größe der Datenbank in diesem Subcluster in Byte. Das folgende Beispiel zeigt, wie die Funktion `limitless_stat_database_size` verwendet werden kann. ``` SELECT * FROM rds_aurora.limitless_stat_database_size('postgres_limitless'); subcluster_id | subcluster_type | db_size ---------------+-----------------+---------- 1 | router | 8895919 2 | router | 8904111 3 | shard | 21929391 4 | shard | 21913007 5 | shard | 21831087 (5 rows) ``` **limitless\$1stat\$1get\$1snapshot\$1timestamp** Die Funktion `limitless_stat_get_snapshot_timestamp` gibt den Zeitstempel des aktuellen Statistik-Snapshots zurück, oder `NULL`, wenn kein Statistik-Snapshot erstellt wurde. Ein Snapshot wird erstellt, wenn in einer Transaktion zum ersten Mal auf kumulative Statistiken zugegriffen wird, sofern `stats_fetch_consistency` auf `snapshot` gesetzt ist. Gibt eine konsolidierte Ansicht der Snapshot-Zeitstempel von allen Knoten zurück. Die Spalten `subcluster_id` und `subcluster_type` zeigen, von welchem Knoten die Daten stammen. Das folgende Beispiel zeigt, wie die Funktion `limitless_stat_get_snapshot_timestamp` verwendet werden kann. ``` SELECT * FROM rds_aurora.limitless_stat_get_snapshot_timestamp(); subcluster_id | subcluster_type | snapshot_timestamp ---------------+-----------------+-------------------- 1 | router | 2 | router | 3 | shard | 4 | shard | 5 | shard | (5 rows) ``` **limitless\$1stat\$1prepared\$1xacts** Die Funktion `limitless_stat_prepared_xacts` gibt Informationen über Transaktionen auf allen Knoten zurück, die derzeit für ein zweiphasiges Commit vorbereitet sind. Weitere Informationen finden Sie unter [pg\$1prepared\$1xacts](https://www.postgresql.org/docs/current/view-pg-prepared-xacts.html) in der PostgreSQL-Dokumentation. Das folgende Beispiel zeigt, wie die Funktion `limitless_stat_prepared_xacts` verwendet werden kann. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_prepared_xacts; subcluster_id | subcluster_type | transaction_id | gid | prepared | owner_id | database_id ---------------+-----------------+----------------+------------------------------+-------------------------------+------------+-------------------- 8 | shard | 5815978 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659603+00 | auroraperf | postgres_limitless 12 | shard | 4599138 | 7_4599899_postgres_limitless | 2024-09-03 15:51:17.659637+00 | auroraperf | postgres_limitless (2 rows) ``` **limitless\$1stat\$1relation\$1sizes** Die Funktion `limitless_stat_relation_sizes` gibt die verschiedenen Größen einer Tabelle in der DB-Shard-Gruppe zurück. Es werden folgende Eingabeparameter verwendet: + `relnspname` (Name): Der Name des Schemas, das die Tabelle enthält. + `relname` (Name): Der Name der Tabelle. Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `subcluster_type` (Text): Der Typ des Subclusters, zu dem dieser Prozess gehört: `router` oder `shard`. + `main_size`: Die Größe der Haupt-Datenzweige in diesem Knoten in Byte. + `fsm_size`: Die Größe der Free-Space-Map für die Tabelle in diesem Knoten in Byte. + `vm_size`: Die Größe der Sichtbarkeits-Map für die Tabelle in diesem Knoten in Byte. + `init_size`: Die Größe der Initialisierung der Tabelle in diesem Knoten in Byte. + `toast_size`: Die Größe der Toast-Tabelle in Byte, die der Tabelle in diesem Zweig zugeordnet ist. + `index_size`: Die Größe aller Indizes für die Tabelle in diesem Knoten in Byte. + `total_size`: Die Größe aller Tabellensegmente in diesem Knoten in Byte. Das folgende Beispiel zeigt, wie die Funktion `limitless_stat_relation_sizes` verwendet werden kann (einige Spalten wurden weggelassen). ``` SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public','customers'); subcluster_id | subcluster_type | main_size | fsm_size | vm_size | toast_size | table_size | total_size ---------------+-----------------+-----------+----------+---------+------------+------------+------------ 1 | router | 0 | 0 | 0 | 0 | 0 | 0 2 | router | 0 | 0 | 0 | 0 | 0 | 0 3 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928 4 | shard | 4169728 | 4177920 | 1392640 | 1392640 | 11132928 | 11132928 5 | shard | 3981312 | 4227072 | 1409024 | 1409024 | 11026432 | 11026432 (5 rows) ``` **limitless\$1stat\$1reset** Die Funktion `limitless_stat_reset` setzt alle Statistikzähler für die aktuelle Datenbank auf Null (0) zurück. Wenn `track_functions` aktiviert ist, zeigt die Spalte `stats_reset` in `limitless_stat_database` an, wann die Statistiken für die Datenbank zuletzt zurückgesetzt wurden. `limitless_stat_reset` kann standardmäßig nur von einem Superuser ausgeführt werden. Anderen Benutzern kann mithilfe des Privilegs `EXECUTE` eine entsprechende Berechtigung erteilt werden. Das folgende Beispiel zeigt, wie die Funktion `limitless_stat_reset` verwendet werden kann. ``` SELECT tup_inserted, tup_deleted FROM pg_stat_database WHERE datname = 'postgres_limitless'; tup_inserted | tup_deleted --------------+------------- 896 | 0 (1 row) SELECT rds_aurora.limitless_stat_reset(); limitless_stat_reset --------------------- (1 row) SELECT tup_inserted, tup_deleted FROM pg_stat_database WHERE datname = 'postgres_limitless'; tup_inserted | tup_deleted -------------+------------- 0 | 0 (1 row) ``` **limitless\$1stat\$1statements\$1reset** Die Funktion `limitless_stat_statements_reset` verwirft Statistiken, die inzwischen von `limitless_stat_statements` erfasst wurden, für die festgelegten Parameter `username`, `dbname`, `distributed_query_id` und `queryid`. Wenn einer der Parameter nicht angegeben ist, wird für jeden Parameter der Standardwert `""` oder `0` (ungültig) verwendet, und die Statistiken, die mit anderen Parametern übereinstimmen, werden zurückgesetzt. Wenn kein Parameter angegeben ist oder alle angegebenen Parameter `""` oder `0` (ungültig) lauten, verwirft die Funktion alle Statistiken. Wenn alle Statistiken in der Ansicht `limitless_stat_statements` verworfen werden, setzt die Funktion auch die Statistiken in der Ansicht `limitless_stat_statements_info` zurück. Es werden folgende Eingabeparameter verwendet: + `username` (Name): Der Benutzer, der die Anweisung abgefragt hat. + `dbname` (Name): Die Datenbank, in der die Abfrage ausgeführt wurde. + `distributed_query_id` (bigint): Die Abfrage-ID der übergeordneten Abfrage vom Koordinatorknoten. Diese Spalte lautet `NULL`, wenn es sich um die übergeordnete Abfrage handelt. Der Koordinatorknoten gibt die ID der verteilten Abfrage an die teilnehmenden Knoten weiter. Für die Teilnehmerknoten sind die Werte für die ID der verteilten Abfrage und die ID der Abfrage also unterschiedlich. + `queryid` (bigint): Die Abfrage-ID der Anweisung. Das folgende Beispiel zeigt, wie die Funktion `limitless_stat_statements_reset` verwendet wird, um alle von `limitless_stat_statements` erfassten Statistiken zurückzusetzen. ``` SELECT rds_aurora.limitless_stat_statements_reset(); ``` **limitless\$1stat\$1system\$1waits** Die Funktion `limitless_stat_system_waits` gibt eine konsolidierte Ansicht der Warteereignisdaten aus `aurora_stat_system_waits` von allen Knoten zurück, die systemweite Warteaktivitäten in einer Instance meldet. Die Spalten `subcluster_id` und `subcluster_type` zeigen, von welchem Knoten die Daten stammen. Das folgende Beispiel zeigt, wie die Funktion `limitless_stat_system_waits` verwendet werden kann. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_system_waits() lssw, pg_catalog.aurora_stat_wait_event() aswe WHERE lssw.event_id=aswe.event_id and aswe.event_name='LimitlessTaskScheduler'; subcluster_id | subcluster_type | type_id | event_id | waits | wait_time | event_name ---------------+-----------------+---------+-----------+--------+--------------+------------------------ 1 | router | 12 | 201326607 | 677068 | 616942216307 | LimitlessTaskScheduler 2 | router | 12 | 201326607 | 678586 | 616939897111 | LimitlessTaskScheduler 3 | shard | 12 | 201326607 | 756640 | 616965545172 | LimitlessTaskScheduler 4 | shard | 12 | 201326607 | 755184 | 616958057620 | LimitlessTaskScheduler 5 | shard | 12 | 201326607 | 757522 | 616963183539 | LimitlessTaskScheduler (5 rows) ``` **limitless\$1terminate\$1session** Die Funktion `limitless_terminate_session` arbeitet ähnlich wie `pg_terminate_backend`, versucht aber, alle Backend-Prozesse im Zusammenhang mit der angegebenen ID einer verteilten Sitzung zu beenden, indem sie ein `SIGTERM` (Beendigungssignal) sendet. Es wird der folgende Eingabeparameter verwendet: + `distributed_session_id` (Text): Die ID der verteilten Sitzung, die beendet werden soll. Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `pid` (Text): Die ID des Backend-Prozesses. + `success` (Boolean): Ob der Prozess erfolgreich beendet wurde. Das folgende Beispiel zeigt, wie die Funktion `limitless_terminate_session` verwendet werden kann. ``` SELECT * FROM rds_aurora.limitless_terminate_session('940CD5C81E3C796B'); subcluster_id | pid | success ---------------+-------+--------- 1 | 26920 | t (1 row) ``` **limitless\$1wait\$1report** Die Funktion `limitless_wait_report` gibt die Aktivität „Warteereignis“ über einen bestimmten Zeitraum von allen Knoten zurück. Die Spalten `subcluster_id` und `subcluster_type` zeigen, von welchem Knoten die Daten stammen. Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `subcluster_type` (Text): Der Typ des Subclusters, zu dem dieser Prozess gehört: `router` oder `shard`. Die restlichen Spalten sind dieselben wie in `aurora_wait_report`. Das folgende Beispiel zeigt, wie die Funktion `limitless_wait_report` verwendet werden kann. ``` postgres_limitless=> select * from rds_aurora.limitless_wait_report(); subcluster_id | subcluster_type | type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact ---------------+-----------------+-----------+------------+-------+-----------+-------------+--------------- +------------- 1 | router | Client | ClientRead | 57 | 741550.14 | 13009.652 | 0.19 | 2505.237 5 | shard | Client | ClientRead | 54 | 738897.68 | 13683.290 | 0.18 | 2496.276 4 | shard | Client | ClientRead | 54 | 738859.53 | 13682.584 | 0.18 | 2496.147 2 | router | Client | ClientRead | 53 | 719223.64 | 13570.257 | 0.18 | 2429.810 3 | shard | Client | ClientRead | 54 | 461720.40 | 8550.378 | 0.18 | 1559.86 ``` # Ansichten für Aurora PostgreSQL Limitless Database In der folgenden Tabelle sehen Sie die neuen Ansichten für Aurora PostgreSQL Limitless Database. **Anmerkung** Die in dieser Tabelle aufgeführten Ansichten befinden sich im Schema `rds_aurora`. Wenn Sie eine Limitless-Database-Ansicht verwenden, stellen Sie sicher, dass Sie den vollqualifizierten Objektnamen angeben: `rds_aurora`.`object_name`. | Ansicht für Aurora PostgreSQL Limitless Database | Entsprechende Ansicht für Aurora PostgreSQL | | --- | --- | | [limitless\$1database](#limitless_database) | pg\$1database | | [limitless\$1locks](#limitless_locks) | pg\$1locks | | [limitless\$1stat\$1activity](#limitless_stat_activity) | pg\$1stat\$1activity | | [limitless\$1stat\$1all\$1indexes](#limitless_stat_all_indexes) | pg\$1stat\$1all\$1indexes | | [limitless\$1stat\$1all\$1tables](#limitless_stat_all_tables) | pg\$1stat\$1all\$1tables | | [limitless\$1stat\$1database](#limitless_stat_database) | pg\$1stat\$1database | | [limitless\$1stat\$1progress\$1vacuum](#limitless_stat_progress_vacuum) | pg\$1stat\$1progress\$1vacuum | | [limitless\$1stat\$1statements](#limitless_stat_statements) | pg\$1stat\$1statements | | [limitless\$1stat\$1subclusters](#limitless_stat_subclusters) | Keine | | [limitless\$1stat\$1statements\$1info](#limitless_stat_statements_info) | pg\$1stat\$1statements\$1info | | [limitless\$1statio\$1all\$1indexes](#limitless_statio_all_indexes) | pg\$1statio\$1all\$1indexes | | [limitless\$1statio\$1all\$1tables](#limitless_statio_all_tables) | pg\$1statio\$1all\$1tables | | [limitless\$1tables](#limitless_tables) | pg\$1tables | | [limitless\$1table\$1collocations](#limitless_table_collocations) | Keine | | [limitless\$1table\$1collocation\$1distributions](#limitless_table_collocation_distributions) | Keine | Die folgenden Beispiele enthalten Einzelheiten zu den Ansichten für Aurora PostgreSQL Limitless Database. Weitere Informationen zu PostgreSQL-Ansichten finden Sie unter [Anzeigen von Statistiken](https://www.postgresql.org/docs/15/monitoring-stats.html#MONITORING-STATS-VIEWS) in der PostgreSQL-Dokumentation. **Anmerkung** Einige Statistikansichten können uneinheitliche Ergebnisse liefern, wenn Transaktionen im Gange sind. **limitless\$1database** Diese Ansicht enthält Informationen über die verfügbaren Datenbanken in der DB-Shard-Gruppe. Zum Beispiel: ``` postgres_limitless=> SELECT subcluster_id, subcluster_type, oid, datname, datacl FROM rds_aurora.limitless_database; subcluster_id | subcluster_type | oid | datname | datacl ---------------+-----------------+-------+--------------------+------------------------------------------------------------------------------------------------------------------------ 2 | router | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin} 2 | router | 5 | postgres | 2 | router | 16384 | rdsadmin | {rdsadmin=CTc/rdsadmin,rds_aurora_limitless_metadata_admin=c/rdsadmin,rds_aurora_limitless_heat_mgmt_admin=c/rdsadmin} 2 | router | 16477 | postgres_limitless | 2 | router | 1 | template1 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin} 6 | shard | 4 | template0 | {=c/rdsadmin,rdsadmin=CTc/rdsadmin} ``` Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters (Knoten) + `subcluster_type` (Text): Der Typ des Subclusters (Knoten), Router oder Shard Die restlichen Spalten sind dieselben wie in `pg_database`. **limitless\$1locks** Diese Ansicht enthält eine Zeile pro Prozess und Knoten. Sie bietet Zugriff auf Informationen über die Sperren, die aktive Prozesse im Datenbankserver aufrecht erhalten. **Example Beispiel für das Erstellen einer Sperre mit zwei Transaktionen** In diesem Beispiel führen wir zwei Transaktionen gleichzeitig auf zwei Routern aus. ``` # Transaction 1 (run on router 1) BEGIN; SET search_path = public; SELECT * FROM customers; INSERT INTO customers VALUES (400,'foo','bar'); # Transaction 2 (run on router 2) BEGIN; SET search_path = public; ALTER TABLE customers ADD COLUMN phone VARCHAR; ``` Die erste Transaktion wird ausgeführt. Nachfolgende Transaktionen müssen warten, bis die erste Transaktion abgeschlossen ist. Daher wird die zweite Transaktion durch eine Sperre blockiert. Um die Ursache dafür zu ermitteln, führen wir einen Befehl aus, indem wir `limitless_locks` mit `limitless_stat_activity` vereinen. ``` # Run on router 2 SELECT distributed_session_id, state, usename, query, query_start FROM rds_aurora.limitless_stat_activity WHERE distributed_session_id in ( SELECT distributed_session_id FROM rds_aurora.limitless_locks WHERE relname = 'customers' ); distributed_session_id | state | usename | query | query_start ------------------------+---------------------+--------------------------+---------------------------------- -------------+------------------------------- 47BDE66E9A5E8477 | idle in transaction | limitless_metadata_admin | INSERT INTO customers VALUES (400,'foo','bar'); | 2023-04-13 17:44:45.152244+00 2AD7F370202D0FA9 | active | limitless_metadata_admin | ALTER TABLE customers ADD COLUMN phone VARCHAR; | 2023-04-13 17:44:55.113388+00 47BDE66E9A5E8477 | | limitless_auth_admin | | 2AD7F370202D0FA9 | | limitless_auth_admin | | 47BDE66E9A5E8477 | | limitless_auth_admin | | 2AD7F370202D0FA9 | | limitless_auth_admin | | (6 rows) ``` **Example Beispiel für das explizite Erstellen einer Sperre** In diesem Beispiel erstellen wir explizit eine Sperre und verwenden dann die Ansicht `limitless_locks`, um die Sperren zu sehen (einige Spalten werden weggelassen). ``` BEGIN; SET search_path = public; LOCK TABLE customers IN ACCESS SHARE MODE; SELECT * FROM rds_aurora.limitless_locks WHERE relname = 'customers'; subcluster_id | subcluster_type | distributed_session_id | locktype | datname | relnspname | relname | virtualtransaction | pid | mode ---------------+-----------------+------------------------+----------+--------------------+------------+ ----------+--------------------+-------+----------------- 1 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600787 | 59564 | AccessShareLock 2 | router | 7207702F862FC937 | relation | postgres_limitless | public | customers | 28/600405 | 67130 | AccessShareLock 3 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 15/473401 | 27735 | AccessShareLock 4 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473524 | 27734 | AccessShareLock 5 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/472935 | 27737 | AccessShareLock 6 | shard | 7207702F862FC937 | relation | postgres_limitless | public | customers | 13/473015 | 48660 | AccessShareLock (6 rows) ``` **limitless\$1stat\$1activity** Diese Ansicht enthält eine Zeile pro Prozess und Knoten. Sie kann verwendet werden, um den Gesamtzustand des Systems zu verfolgen und lange dauernde Prozesse zu klassifizieren. Zum Beispiel: ``` postgres=# SELECT subcluster_id, subcluster_type, distributed_session_id, distributed_session_state, datname, distributed_query_id, is_sso_query FROM rds_aurora.limitless_stat_activity WHERE distributed_session_id in ('D2470C97E3D07E06', '5A3CD7B8E5FD13FF') order by distributed_session_id; subcluster_id | subcluster_type | distributed_session_id | distributed_session_state | datname | distributed_query_id | is_sso_query ---------------+-----------------+------------------------+---------------------------+--------------------+----------------------+-------------- 2 | router | 5A3CD7B8E5FD13FF | coordinator | postgres_limitless | | f 3 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 | 4 | shard | 5A3CD7B8E5FD13FF | participant | postgres_limitless | 6808291725541680947 | 2 | router | D2470C97E3D07E06 | coordinator | postgres_limitless | | t 3 | shard | D2470C97E3D07E06 | participant | postgres_limitless | 4058400544464210222 | (5 rows) ``` Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `subcluster_type` (Text): Der Typ des Subclusters, zu dem dieser Prozess gehört: `router` oder `shard`. + `distributed_session_id` (Text): Die ID der verteilten Sitzung, zu der dieser Prozess gehört. + `distributed_session_state` (Text): Ob es sich um einen Koordinator, einen Teilnehmer oder einen eigenständigen/nicht verteilten Prozess handelt (angezeigt als `NULL`). + `datname` (Text): Die Datenbank, mit der dieser Prozess verbunden ist. + `distributed_query_id` (bigint): Die Abfrage-ID der übergeordneten Abfrage vom Koordinatorknoten. Diese Spalte lautet `NULL`, wenn es sich um die übergeordnete Abfrage handelt. Der Koordinatorknoten gibt die ID der verteilten Abfrage an die teilnehmenden Knoten weiter. Für die Teilnehmerknoten sind die Werte für die ID der verteilten Abfrage und die ID der Abfrage also unterschiedlich. + `is_sso_query` (Text): Dadurch erfahren wir, ob die Abfrage für einen einzelnen Shard optimiert ist oder nicht. Die restlichen Spalten sind dieselben wie in `pg_stat_activity`. **limitless\$1stat\$1all\$1indexes** Diese Ansicht enthält Auslastungsstatistiken für Indizes in der DB-Shard-Gruppe. Zum Beispiel: ``` postgres_limitless=> SELECT schemaname, relname, indexrelname, idx_scan FROM rds_aurora.limitless_stat_all_indexes WHERE relname LIKE 'orders_ts%' ORDER BY indexrelname LIMIT 10; schemaname | relname | indexrelname | idx_scan ------------+----------------+---------------------+---------- ec_sample | orders_ts00001 | orders_ts00001_pkey | 196801 ec_sample | orders_ts00002 | orders_ts00002_pkey | 196703 ec_sample | orders_ts00003 | orders_ts00003_pkey | 196376 ec_sample | orders_ts00004 | orders_ts00004_pkey | 197966 ec_sample | orders_ts00005 | orders_ts00005_pkey | 195301 ec_sample | orders_ts00006 | orders_ts00006_pkey | 195673 ec_sample | orders_ts00007 | orders_ts00007_pkey | 194475 ec_sample | orders_ts00008 | orders_ts00008_pkey | 191694 ec_sample | orders_ts00009 | orders_ts00009_pkey | 193744 ec_sample | orders_ts00010 | orders_ts00010_pkey | 195421 (10 rows) ``` **limitless\$1stat\$1all\$1tables** Diese Ansicht enthält Statistiken über alle Tabellen in der aktuellen Datenbank in der DB-Shard-Gruppe. Dies ist nützlich, wenn Sie Bereinigungsvorgänge und DML-Operationen (Data Manipulation Language) verfolgen möchten. Zum Beispiel: ``` postgres_limitless=> SELECT subcluster_id, subcluster_type, relname, n_ins_since_vacuum, n_tup_ins, last_vacuum FROM rds_aurora.limitless_stat_all_tables WHERE relname LIKE 'orders_ts%' ORDER BY relname LIMIT 10; subcluster_id | subcluster_type | relname | n_ins_since_vacuum | n_tup_ins | last_vacuum ---------------+-----------------+----------------+--------------------+-----------+------------- 5 | shard | orders_ts00001 | 34779 | 196083 | 5 | shard | orders_ts00002 | 34632 | 194721 | 5 | shard | orders_ts00003 | 34950 | 195965 | 5 | shard | orders_ts00004 | 34745 | 197283 | 5 | shard | orders_ts00005 | 34879 | 195754 | 5 | shard | orders_ts00006 | 34340 | 194605 | 5 | shard | orders_ts00007 | 33779 | 192203 | 5 | shard | orders_ts00008 | 33826 | 191293 | 5 | shard | orders_ts00009 | 34660 | 194117 | 5 | shard | orders_ts00010 | 34569 | 195560 | (10 rows) ``` Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `subcluster_type` (Text): Der Typ des Subclusters, zu dem dieser Prozess gehört: `router` oder `shard`. + `relname` (Name): Der Name der Tabelle. Die restlichen Spalten sind dieselben wie in `pg_stat_all_tables`. **limitless\$1stat\$1database** Diese Ansicht enthält Statistiken über alle Datenbanken in der DB-Shard-Gruppe. Gibt eine Zeile pro Datenbank und Knoten zurück. Zum Beispiel: ``` postgres_limitless=> SELECT subcluster_id, subcluster_type, datname, blks_read, blks_hit FROM rds_aurora.limitless_stat_database WHERE datname='postgres_limitless'; subcluster_id | subcluster_type | datname | blks_read | blks_hit ---------------+-----------------+--------------------+-----------+---------- 1 | router | postgres_limitless | 484 | 34371314 2 | router | postgres_limitless | 673 | 33859317 3 | shard | postgres_limitless | 1299 | 17749550 4 | shard | postgres_limitless | 1094 | 17492849 5 | shard | postgres_limitless | 1036 | 17485098 6 | shard | postgres_limitless | 1040 | 17437257 (6 rows) ``` Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `subcluster_type` (Text): Der Typ des Subclusters, zu dem dieser Prozess gehört: `router` oder `shard`. + `datname` (Name): Der Name der Datenbank. Die restlichen Spalten sind dieselben wie in `pg_stat_database`. **limitless\$1stat\$1progress\$1vacuum** Diese Ansicht enthält Informationen zu laufenden Bereinigungsvorgängen. Zum Beispiel: ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_progress_vacuum; -[ RECORD 1 ]----------+------------------ subcluster_id | 3 subcluster_type | shard distributed_session_id | A56D96E2A5C9F426 pid | 5270 datname | postgres nspname | public relname | customer_ts2 phase | vacuuming heap heap_blks_total | 130500 heap_blks_scanned | 100036 heap_blks_vacuumed | 0 index_vacuum_count | 0 max_dead_tuples | 11184810 num_dead_tuples | 0 -[ RECORD 2 ]----------+------------------ subcluster_id | 3 subcluster_type | shard distributed_session_id | 56DF26A89EC23AB5 pid | 6854 datname | postgres nspname | public relname | sales_ts1 phase | vacuuming heap heap_blks_total | 43058 heap_blks_scanned | 24868 heap_blks_vacuumed | 0 index_vacuum_count | 0 max_dead_tuples | 8569523 num_dead_tuples | 0 ``` Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `subcluster_type` (Text): Der Typ des Subclusters, zu dem dieser Prozess gehört: `router` oder `shard`. + `distributed_session_id` (Text): Die ID der Sitzung, die den Bereinigungsvorgang initiiert hat. + `datname` (Name): Die Datenbank, in der die Bereinigung durchgeführt wird. + `nspname` (Name): Der Name des Schemas der Tabelle, die bereinigt wird. Der Wert lautet `null`, wenn sich die Tabelle, die bereinigt wird, nicht in derselben Datenbank befindet wie die, mit der der Benutzer verbunden ist. + `relname` (Name): Der Name der Tabelle, die bereinigt wird. Der Wert lautet `null`, wenn sich die Tabelle, die bereinigt wird, nicht in derselben Datenbank befindet wie die, mit der der Benutzer verbunden ist. Die restlichen Spalten sind dieselben wie in `pg_stat_progress_vacuum`. **limitless\$1stat\$1statements** Diese Ansicht bietet die Möglichkeit, Statistiken zur Planung und Ausführung aller SQL-Anweisungen zu verfolgen, die auf allen Knoten ausgeführt werden. Sie müssen die Erweiterung [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) installieren, um die Ansicht `limitless_stat_statements` verwenden zu können. ``` -- CREATE EXTENSION must be run by a superuser CREATE EXTENSION pg_stat_statements; -- Verify that the extension is created on all nodes in the DB shard group SELECT distinct node_id FROM rds_aurora.limitless_stat_statements LIMIT 10; ``` Das folgende Beispiel veranschaulicht die Verwendung der Ansicht `limitless_stat_statements`. ``` postgres_limitless=> SELECT subcluster_id, subcluster_type, distributedqueryid, username, dbname, sso_calls FROM rds_aurora.limitless_stat_statements; subcluster_id | subcluster_type | distributedqueryid | username | dbname | sso_calls ---------------+-----------------+----------------------+-------------------------------------+--------------------+----------- 2 | router | | postgres | postgres_limitless | 0 2 | router | | postgres | postgres_limitless | 0 2 | router | | postgres | postgres_limitless | 0 2 | router | | postgres | postgres_limitless | 0 2 | router | | postgres | postgres_limitless | 0 2 | router | | postgres | postgres_limitless | 1 3 | shard | -7975178695405682176 | postgres | postgres_limitless | [...] ``` Es werden folgende Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. + `subcluster_type` (Text): Der Typ des Subclusters, zu dem dieser Prozess gehört: `router` oder `shard`. + `distributedqueryid` (bigint): Die Abfrage-ID der übergeordneten Abfrage vom Koordinatorknoten. Diese Spalte lautet `NULL`, wenn es sich um die übergeordnete Abfrage handelt. Der Koordinatorknoten gibt die ID der verteilten Abfrage an die teilnehmenden Knoten weiter. Für die Teilnehmerknoten sind die Werte für die ID der verteilten Abfrage und die ID der Abfrage also unterschiedlich. + `username` (Name): Der Benutzer, der die Anweisung abgefragt hat. + `dbname` (Name): Die Datenbank, in der die Abfrage ausgeführt wurde. + `sso_calls` (Name): Gibt an, wie oft die Anweisung für einen einzelnen Shard optimiert wurde. Die restlichen Spalten sind dieselben wie in [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html). **limitless\$1stat\$1statements\$1info** Diese Ansicht enthält Statistiken für die Ansicht `limitless_stat_statements`. Jede Zeile enthält Daten für die Ansicht [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7) von jedem Knoten. Die Spalte `subcluster_id` identifiziert jeden Knoten. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_statements_info; subcluster_id | subcluster_type | dealloc | stats_reset ---------------+-----------------+---------+------------------------------- 1 | router | 0 | 2023-06-30 21:22:09.524781+00 2 | router | 0 | 2023-06-30 21:21:40.834111+00 3 | shard | 0 | 2023-06-30 21:22:10.709942+00 4 | shard | 0 | 2023-06-30 21:22:10.740179+00 5 | shard | 0 | 2023-06-30 21:22:10.774282+00 6 | shard | 0 | 2023-06-30 21:22:10.808267+00 (6 rows) ``` Es wird folgender Ausgabeparameter verwendet: + `subcluster_id` (Text): Die ID des Subclusters, zu dem dieser Prozess gehört. Die restlichen Spalten sind dieselben wie in [pg\$1stat\$1statements\$1info](https://www.postgresql.org/docs/current/pgstatstatements.html#id-1.11.7.41.7). **limitless\$1stat\$1subclusters** Diese Ansicht enthält Netzwerkstatistiken zwischen Routern und anderen Knoten. Sie enthält eine Zeile pro Paar aus Router und anderem Knoten, zum Beispiel: ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_stat_subclusters; orig_subcluster | orig_instance_az | dest_subcluster | dest_instance_az | latency_us | latest_collection | failed_requests | received_bytes | sent_bytes | same_az_requests | cross_az_requests | stat_reset_timestamp -----------------+------------------+-----------------+------------------+------------+-------------------------------+-----------------+----------------+------------+------------------+-------------------+------------------------------- 3 | us-west-2b | 2 | us-west-2a | 847 | 2024-10-07 17:25:39.518617+00 | 0 | 35668633 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.239675+00 3 | us-west-2b | 4 | us-west-2b | 419 | 2024-10-07 17:25:39.546376+00 | 0 | 101190464 | 248795719 | 883478 | 0 | 2024-10-05 12:39:55.231218+00 3 | us-west-2b | 5 | us-west-2c | 1396 | 2024-10-07 17:25:39.52122+00 | 0 | 72864849 | 172086292 | 0 | 557726 | 2024-10-05 12:39:55.196412+00 3 | us-west-2b | 6 | us-west-2c | 729 | 2024-10-07 17:25:39.54828+00 | 0 | 35668584 | 92090171 | 0 | 302787 | 2024-10-05 12:39:55.247334+00 3 | us-west-2b | 7 | us-west-2a | 1702 | 2024-10-07 17:25:39.545307+00 | 0 | 71699576 | 171634844 | 0 | 556278 | 2024-10-05 12:39:52.715168+00 2 | us-west-2a | 3 | us-west-2b | 868 | 2024-10-07 17:25:40.293927+00 | 0 | 35659611 | 92011872 | 0 | 302817 | 2024-10-05 12:39:54.420758+00 2 | us-west-2a | 4 | us-west-2b | 786 | 2024-10-07 17:25:40.296863+00 | 0 | 102437253 | 251838024 | 0 | 895060 | 2024-10-05 12:39:54.404081+00 2 | us-west-2a | 5 | us-west-2c | 1232 | 2024-10-07 17:25:40.292021+00 | 0 | 71990027 | 168828110 | 0 | 545453 | 2024-10-05 12:39:36.769549+00 ``` Es werden folgende Ausgabeparameter verwendet: + `orig_subcluster` (Text): Die ID des Routers, der Absender der Kommunikation ist + `orig_subcluster_az` (Text): Die Availability Zone (AZ) des Absender-Routers + `dest_subcluster` (Text): Die ID des Zielknotens + `dest_subcluster_az` (Text): Die zuletzt erfasste AZ des Zielknotens + `latency_us` (bigint): Die zuletzt erfasste Netzwerklatenz zwischen Knoten in Mikrosekunden. Der Wert lautet `0`, wenn der Knoten nicht erreichbar ist. + `latest_collection` (Zeitstempel): Der Zeitstempel der letzten Erfassung von AZ und Latenz für den Zielknoten + `failed_requests` (bigint): Die Gesamtzahl der fehlgeschlagenen internen Anfragen + `received_bytes` (bigint): Die geschätzte kumulative Anzahl von Byte, die von diesem Knoten empfangen wurden + `sent_bytes` (bigint): Die geschätzte kumulative Anzahl von Byte, die an diesen Knoten gesendet wurden + `same_az_requests` (bigint): Die kumulative Anzahl interner DB-Anfragen an diesen Knoten, wenn er sich in derselben AZ wie der Absender-Router befindet + `cross_az_requests` (bigint): Die kumulative Anzahl interner DB-Anfragen an diesen Knoten, wenn er sich in einer anderen AZ als der Absender-Router befindet + `stat_reset_timestamp` (Zeitstempel): Der Zeitstempel des Zeitpunkts, zu dem die kumulativen Statistiken für diese Ansicht zuletzt zurückgesetzt wurden **limitless\$1statio\$1all\$1indexes** Diese Ansicht enthält Ein/Ausgabe (I/O)-Statistiken für alle Indizes in der DB-Shard-Gruppe. Zum Beispiel: ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_statio_all_indexes WHERE relname like'customers_ts%'; subcluster_id | subcluster_type | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit ---------------+-----------------+------------+-------------------+-------------------------------------+ --------------+-------------- 3 | shard | public | customers_ts00002 | customers_ts00002_customer_name_idx | 1 | 0 3 | shard | public | customers_ts00001 | customers_ts00001_customer_name_idx | 1 | 0 4 | shard | public | customers_ts00003 | customers_ts00003_customer_name_idx | 1 | 0 4 | shard | public | customers_ts00004 | customers_ts00004_customer_name_idx | 1 | 0 5 | shard | public | customers_ts00005 | customers_ts00005_customer_name_idx | 1 | 0 5 | shard | public | customers_ts00006 | customers_ts00006_customer_name_idx | 1 | 0 6 | shard | public | customers_ts00007 | customers_ts00007_customer_name_idx | 1 | 0 6 | shard | public | customers_ts00008 | customers_ts00008_customer_name_idx | 1 | 0 (8 rows) ``` **limitless\$1statio\$1all\$1tables** Diese Ansicht enthält Ein/Ausgabe (I/O)-Statistiken für alle Tabellen in der DB-Shard-Gruppe. Zum Beispiel: ``` postgres_limitless=> SELECT subcluster_id, subcluster_type, schemaname, relname, heap_blks_read, heap_blks_hit FROM rds_aurora.limitless_statio_all_tables WHERE relname LIKE 'customers_ts%'; subcluster_id | subcluster_type | schemaname | relname | heap_blks_read | heap_blks_hit ---------------+-----------------+------------+-------------------+----------------+--------------- 3 | shard | public | customers_ts00002 | 305 | 57780 3 | shard | public | customers_ts00001 | 300 | 56972 4 | shard | public | customers_ts00004 | 302 | 57291 4 | shard | public | customers_ts00003 | 302 | 57178 5 | shard | public | customers_ts00006 | 300 | 56932 5 | shard | public | customers_ts00005 | 302 | 57386 6 | shard | public | customers_ts00008 | 300 | 56881 6 | shard | public | customers_ts00007 | 304 | 57635 (8 rows) ``` **limitless\$1tables** Diese Ansicht enthält Informationen zu Tabellen in Aurora PostgreSQL Limitless Database. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_tables; table_gid | local_oid | schema_name | table_name | table_status | table_type | distribution_key -----------+-----------+-------------+-------------+--------------+-------------+------------------ 5 | 18635 | public | placeholder | active | placeholder | 6 | 18641 | public | ref | active | reference | 7 | 18797 | public | orders | active | sharded | HASH (order_id) 2 | 18579 | public | customer | active | sharded | HASH (cust_id) (4 rows) ``` **limitless\$1table\$1collocations** Diese Ansicht enthält Informationen über zusammengefasste Sharded-Tabellen. Im folgenden Beispiel sind die Tabellen `orders` und `customers` zusammengefasst, und die Tabellen `users` und `followers` ebenso. Zusammengefasste Tabellen haben die gleiche `collocation_id`. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocations ORDER BY collocation_id; collocation_id | schema_name | table_name ----------------+-------------+------------ 2 | public | orders 2 | public | customers 5 | public | users 5 | public | followers (4 rows) ``` **limitless\$1table\$1collocation\$1distributions** Diese Ansicht zeigt die Schlüsselverteilung für jede Kollokation. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocation_distributions ORDER BY collocation_id, lower_bound; collocation_id | subcluster_id | lower_bound | upper_bound ----------------+---------------+----------------------+---------------------- 2 | 6 | -9223372036854775808 | -4611686018427387904 2 | 5 | -4611686018427387904 | 0 2 | 4 | 0 | 4611686018427387904 2 | 3 | 4611686018427387904 | 9223372036854775807 5 | 6 | -9223372036854775808 | -4611686018427387904 5 | 5 | -4611686018427387904 | 0 5 | 4 | 0 | 4611686018427387904 5 | 3 | 4611686018427387904 | 9223372036854775807 (8 rows) ``` # Warteereignisse für Aurora PostgreSQL Limitless Database Ein Warteereignis in Aurora PostgreSQL weist auf eine Ressource hin, auf die eine Sitzung wartet, z. B. Ein-/Ausgabe (I/O) und Sperren. Warteereignisse sind hilfreich, um herauszufinden, warum Sitzungen auf Ressourcen warten, und um Engpässe zu identifizieren. Weitere Informationen finden Sie unter [Aurora PostgreSQL-Warteereignisse](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.waits). Aurora PostgreSQL Limitless Database verfügt über eigene Warteereignisse, die sich auf Router und Shards beziehen. Viele davon beziehen sich auf Router, die darauf warten, dass Shards bestimmte Aufgaben erledigen. Shard-Warteereignisse enthalten Details zu Aufgaben, die gerade ausgeführt werden. **Topics** + [ ## Abfragen von Warteereignissen ](#limitless-monitoring-waits.query) + [ # Warteereignisse für Limitless Database ](limitless-waits-reference.md) ## Abfragen von Warteereignissen Sie können die Ansicht [limitless\$1stat\$1activity](limitless-monitoring-views.md#limitless_stat_activity) verwenden, um Warteereignisse abzufragen, wie im folgenden Beispiel gezeigt. ``` SELECT wait_event FROM rds_aurora.limitless_stat_activity WHERE wait_event_type='AuroraLimitless'; wait_event ---------------------- RemoteStatementSetup RemoteStatementSetup (2 rows) ``` Sie können die Funktion `aurora_stat_system_waits` auch verwenden, um die Anzahl der Warteereignisse und die Gesamtzeit aufzulisten, die für jedes Warteereignis aufgewendet wurde, wie im folgenden Beispiel gezeigt. ``` postgres_limitless=> SELECT type_name,event_name,waits,wait_time FROM aurora_stat_system_waits() NATURAL JOIN aurora_stat_wait_event() NATURAL JOIN aurora_stat_wait_type() WHERE type_name='AuroraLimitless' ORDER BY wait_time DESC; type_name | event_name | waits | wait_time -----------------+---------------------------+---------+------------- AuroraLimitless | RemoteStatementSetup | 7518 | 75236507897 AuroraLimitless | RemoteStatementExecution | 40 | 132986 AuroraLimitless | Connect | 5 | 1453 (3 rows) ``` # Warteereignisse für Limitless Database Die folgenden Wareereignisse gelten für Aurora PostgreSQL Limitless Database. Sie können diese Warteereignisse überwachen, um Engpässe bei der Verarbeitung von Aurora PostgreSQL Limitless Database zu identifizieren. **Topics** + [ ## Warteereignis „IO:TwophaseFilePoolWrite“ ](#limitless-waits-TwophaseFilePoolWrite) + [ ## Warteereignis „IO:TwophaseFilePoolRead“ ](#limitless-waits-TwophaseFilePoolRead) + [ ## Warteereignis „AuroraLimitless:Connect“ ](#limitless-waits-Connect) + [ ## Warteereignis „AuroraLimitless:AsyncConnect“ ](#limitless-waits-AsyncConnect) + [ ## Warteereignis „AuroraLimitless:RemoteStatementSetup“ ](#limitless-waits-RemoteStatementSetup) + [ ## Warteereignis „AuroraLimitless:RemoteDDLExecution“ ](#limitless-waits-RemoteDDLExecution) + [ ## Warteereignis „AuroraLimitless:RemoteStatementExecution“ ](#limitless-waits-RemoteStatementExecution) + [ ## Warteereignis „AuroraLimitless:FetchRemoteResults“ ](#limitless-waits-FetchRemoteResults) + [ ## Warteereignis „AuroraLimitless:AsyncGetInitialResponse“ ](#limitless-waits-AsyncGetInitialResponse) + [ ## Warteereignis „AuroraLimitless:AsyncGetNextResponse“ ](#limitless-waits-AsyncGetNextResponse) + [ ## Warteereignis „AuroraLimitless:AbortedCommandCleanup“ ](#limitless-waits-AbortedCommandCleanup) + [ ## Warteereignis „AuroraLimitless:DistributedCommitPrepare“ ](#limitless-waits-DistributedCommitPrepare) + [ ## Warteereignis „AuroraLimitless:DistributedCommit“ ](#limitless-waits-DistributedCommit) + [ ## Warteereignis „AuroraLimitless:DistributedCommitPrepareThrottle“ ](#limitless-waits-DistributedCommitPrepareThrottle) + [ ## Warteereignis „AuroraLimitless:PreparedTransactionResolution“ ](#limitless-waits-PreparedTransactionResolution) + [ ## Warteereignis „AuroraLimitless:SendPreparedTransactionOutcome“ ](#limitless-waits-SendPreparedTransactionOutcome) + [ ## Warteereignis „AuroraLimitless:CommitClockBarrier“ ](#limitless-waits-CommitClockBarrier) + [ ## Warteereignis „AuroraLimitless:SnapshotClockBarrier“ ](#limitless-waits-SnapshotClockBarrier) + [ ## Warteereignis „AuroraLimitless:ReaderSnapshotClockBarrier“ ](#limitless-waits-ReaderSnapshotClockBarrier) + [ ## Warteereignis „AuroraLimitless:GatherDistributedDeadlockGraph“ ](#limitless-waits-GatherDistributedDeadlockGraph) + [ ## Warteereignis „AuroraLimitless:DistributedDeadlockDetection“ ](#limitless-waits-DistributedDeadlockDetection) + [ ## Warteereignis „AuroraLimitless:DistributedDeadlockAbort“ ](#limitless-waits-DistributedDeadlockAbort) + [ ## Warteereignis „AuroraLimitless:GatherRemoteStats“ ](#limitless-waits-GatherRemoteStats) + [ ## Warteereignis „AuroraLimitless:GlobalSequenceRefresh“ ](#limitless-waits-GlobalSequenceRefresh) + [ ## Warteereignis „AuroraLimitless:GlobalVacuumTimeExchange“ ](#limitless-waits-GlobalVacuumTimeExchange) + [ ## Warteereignis „AuroraLimitless:DistributedTransactionMonitorGather“ ](#limitless-waits-DistributedTransactionMonitorGather) + [ ## Warteereignis „AuroraLimitlessActivity:AdminTaskSchedulerMain“ ](#limitless-waits-AdminTaskSchedulerMain) + [ ## Warteereignis „AuroraLimitlessActivity:AdminTaskExecutorMain“ ](#limitless-waits-AdminTaskExecutorMain) + [ ## Warteereignis „AuroraLimitlessActivity:AdminTaskMonitorMain“ ](#limitless-waits-AdminTaskMonitorMain) + [ ## Warteereignis „AuroraLimitlessActivity:DatabaseCleanupMonitorMain“ ](#limitless-waits-DatabaseCleanupMonitorMain) + [ ## Warteereignis „AuroraLimitlessActivity:TopologyCleanupMonitorMain“ ](#limitless-waits-TopologyCleanupMonitorMain) + [ ## Warteereignis „AuroraLimitlessActivity:ToplogyChangeMonitorMain“ ](#limitless-waits-ToplogyChangeMonitorMain) + [ ## Warteereignis „AuroraLimitlessActivity:DistributedTransactionMonitorMain“ ](#limitless-waits-DistributedTransactionMonitorMain) + [ ## Warteereignis „AuroraLimitlessActivity:GlobalVacuumMonitorMain“ ](#limitless-waits-GlobalVacuumMonitorMain) ## Warteereignis „IO:TwophaseFilePoolWrite“ Warten auf das Schreiben einer zweiphasigen Statusdatei innerhalb des zweiphasigen Statusdateipools. Dies ist ein Aurora-spezifisches Ereignis. ### Ursachen Prozesse, die einen `PREPARED TRANSACTION`-Befehl ausführen, einschließlich Teilnehmern an einer verteilten Transaktion von Limitless Database, müssen den Transaktionsstatus in einer zweiphasigen Datei beibehalten. Aurora verwendet einen Dateipool, um die Leistung dieses Vorgangs zu verbessern. ### Aktion Da es sich um einen synchronen I/O-Schreibvorgang handelt, hat eine hohe Latenz in diesem Fall ähnliche Ursachen wie `IO:XactSync` und kann auf dieselbe Weise untersucht werden. Wenn Sie Limitless Database verwenden, müssen Sie möglicherweise die Anzahl der ausgeführten verteilten Transaktionen reduzieren. ## Warteereignis „IO:TwophaseFilePoolRead“ Warten auf das Lesen einer zweiphasigen Statusdatei innerhalb des zweiphasigen Statusdateipools. ### Ursachen Prozesse, die einen `COMMIT PREPARED`-Befehl für eine zuvor vorbereitete Transaktion ausführen, einschließlich Teilnehmern an einer verteilten Transaktion von Limitless Database, müssen möglicherweise den zuvor gespeicherten Transaktionsstatus aus einer zweiphasigen Datei lesen. Aurora verwendet einen Dateipool, um die Leistung dieses Vorgangs zu verbessern. ### Aktion Dies ist ein I/O-Lesevorgang. Daher hat eine hohe Latenz bei diesem Ereignis ähnliche Ursachen wie `IO:DataFileRead` und kann auf die gleiche Weise untersucht werden. Wenn Sie Limitless Database verwenden, müssen Sie möglicherweise die Anzahl der ausgeführten verteilten Transaktionen reduzieren. ## Warteereignis „AuroraLimitless:Connect“ Der Prozess wartet darauf, dass eine Verbindung zu einem anderen Knoten im Cluster hergestellt wird. ### Ursachen Verbindungen werden zwischen Prozessen und Remote-Knoten hergestellt, um Abfragen, verteilte Transaktionen und DDLs auszuführen. ### Aktion Reduzieren Sie die Anzahl der gleichzeitigen Verbindungen zum Cluster oder optimieren Sie die Verwendung von Cross-Shard-Abfragen. ## Warteereignis „AuroraLimitless:AsyncConnect“ Dieses Ereignis ähnelt `Connect`, stellt aber einen Prozess dar, der darauf wartet, dass parallele Verbindungen zu einer Gruppe von Knoten hergestellt werden. ### Ursachen Der parallele Verbindungsaufbau erfolgt am häufigsten bei der Ausführung von DDL-Anweisungen. ### Aktion Reduzieren Sie die Anzahl der DDL-Anweisungen oder kombinieren Sie mehrere DDLs in derselben Sitzung, um die Wiederverwendung von Verbindungen zu verbessern. ## Warteereignis „AuroraLimitless:RemoteStatementSetup“ Der Prozess wartet auf die Einrichtung der Remoteabfrageausführung, wie z. B. das Öffnen oder Schließen des Cursors oder die Erstellung einer vorbereiteten Anweisung. ### Ursachen Dieses Warteereignis nimmt mit der Anzahl der Scans in Sharde-Tabellen zu, bei denen die Anweisung nicht für ein einzelnes Shard optimiert werden konnte. ### Aktion Optimieren Sie Abfragen, um die Anzahl der Scanvorgänge zu reduzieren oder die Eignung für die Single-Shard-Optimierung zu erhöhen. ## Warteereignis „AuroraLimitless:RemoteDDLExecution“ Der Prozess wartet darauf, dass ein Remote-DDL-Befehl abgeschlossen wird. ### Ursachen Wenn Sie einen DDL-Befehl für eine DB-Shard-Gruppe ausgeben, muss er an andere Router- und Shard-Knoten verteilt werden, bevor der Vorgang bestätigt wird. Einige DDL-Vorgänge können lange dauern, da Daten an Schemaänderungen angepasst werden müssen. ### Aktion Identifizieren Sie DDL-Befehle mit langer Laufzeit, damit Sie sie optimieren können. ## Warteereignis „AuroraLimitless:RemoteStatementExecution“ Der Prozess wartet darauf, dass ein Remote-Befehl abgeschlossen wird. ### Ursachen Ein SQL-Befehl wird auf einem Remote-Knoten ausgeführt. Dieses Ereignis tritt häufig bei der internen Kommunikation auf, z. B. bei `auto_analyze` Heartbeat-Überprüfungen. ### Aktion Identifizieren Sie Befehle mit langer Laufzeit in der Ansicht „limitless\$1stat\$1statements“. In vielen Fällen handelt es sich hierbei um ein erwartetes Ereignis, insbesondere bei Hintergrundprozessen oder internen Prozessen, sodass keine Maßnahmen erforderlich sind. ## Warteereignis „AuroraLimitless:FetchRemoteResults“ Ein Prozess wartet darauf, Zeilen von einem Remote-Knoten abzurufen. ### Ursachen Dieses Warteereignis kann zunehmen, wenn eine große Anzahl von Zeilen aus einer Remote-Tabelle abgerufen wird, z. B. aus einer Sharded- oder Referenztabelle. ### Aktion Identifizieren Sie nicht optimierte `SELECT`-Abfragen in der Ansicht `limitless_stat_statements`. Optimieren Sie Abfragen, um nur die erforderlichen Daten abzurufen. Sie können auch den Parameter `rds_aurora.limitless_maximum_adaptive_fetch_size` anpassen. ## Warteereignis „AuroraLimitless:AsyncGetInitialResponse“ Der Prozess wartet auf eine erste Antwort, wenn der Pipeline-Modus bei der Abfrageausführung verwendet wird. ### Ursachen Dies tritt normalerweise bei der Router-zu-Shard-Ausführung bei Abfragen mit Single-Shard-Datenplatzierung auf und ist ein erwarteter Teil der normalen Ausführung. ### Aktion Es sind keine weiteren Maßnahmen erforderlich. ## Warteereignis „AuroraLimitless:AsyncGetNextResponse“ Der Prozess wartet auf eine zusätzliche Antwort, wenn der Pipeline-Modus bei der Abfrageausführung verwendet wird. ### Ursachen Dies tritt normalerweise bei der Router-zu-Shard-Ausführung bei Abfragen mit Single-Shard-Datenplatzierung auf und ist ein erwarteter Teil der normalen Ausführung. ### Aktion Es sind keine weiteren Maßnahmen erforderlich. ## Warteereignis „AuroraLimitless:AbortedCommandCleanup“ Der Prozess wartet auf das Ergebnis einer Remote-Bereinigungsabfrage. Bereinigungsabfragen werden an Shard-Knoten ausgegeben, um sie nach dem Beenden einer verteilten Transaktion wieder in einen geeigneten Zustand zu versetzen. ### Ursachen Eine Transaktionsbereinigung wird durchgeführt, wenn eine Transaktion abgebrochen wird, weil ein Fehler gefunden wurde oder weil ein Benutzer einen expliziten ABORT-Befehl ausgegeben oder die laufende Abfrage abgebrochen hat. ### Aktion Untersuchen Sie die Ursache für den Abbruch der Transaktion. ## Warteereignis „AuroraLimitless:DistributedCommitPrepare“ Der Prozess schreibt eine verteilte Transaktion fest und wartet darauf, dass alle Teilnehmer den Prepare-Befehl bestätigen. ### Ursachen Transaktionen, die mehrere Knoten ändern, müssen eine verteilte Festschreibung durchführen. Eine lange Wartezeit in `DistributedCommitPrepare` kann durch lange Wartezeiten beim Ereignis `IO:TwophaseFilePoolWrite` auf den teilnehmenden Knoten verursacht werden. ### Aktion Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie `IO:TwophaseFilePoolWrite`-Ereignisse in anderen Knoten des Clusters. ## Warteereignis „AuroraLimitless:DistributedCommit“ Der Prozess schreibt eine verteilte Transaktion fest und wartet darauf, dass der führende Teilnehmer den Prepare-Befehl bestätigt. ### Ursachen Transaktionen, die mehrere Knoten ändern, müssen eine verteilte Festschreibung durchführen. Eine lange Wartezeit in `DistributedCommit` kann durch lange Wartezeiten beim `IO:XactSync`-Ereignis auf den führenden Teilnehmer verursacht werden. ### Aktion Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie `IO:XactSync`-Ereignisse in anderen Knoten des Clusters. ## Warteereignis „AuroraLimitless:DistributedCommitPrepareThrottle“ Der Prozess versucht, eine verteilte Transaktion vorzubereiten, und wird aufgrund vorhandener vorbereiteter Transaktionen auf die Dauer gedrosselt. ### Ursachen Transaktionen, die mehrere Knoten ändern, müssen eine verteilte Festschreibung durchführen. Die Teilnehmer an diesen Transaktionen müssen im Rahmen des Festschreibungsprotokolls einen Vorbereitungsvorgang durchführen. Aurora begrenzt die Anzahl der gleichzeitigen prepare-Vorgänge, und wenn dieses Limit überschritten wird, wartet der Prozess auf das `DistributedCommitPrepareThrottle`-Ereignis. ### Aktion Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie `IO:TwophaseFilePoolWrite`-Ereignisse, da eine längere Dauer dieser Ereignisse dazu führen kann, dass sich bereits vorbereitete Transaktionen ansammeln, was zu einer Drosselung neuer Vorbereitungsversuche führt. ## Warteereignis „AuroraLimitless:PreparedTransactionResolution“ Beim Prozess ist ein Tupel aufgetreten, das durch eine verteilte Transaktion verändert wurde, die sich im Status „Vorbereitet“ befindet. Der Prozess muss ermitteln, ob die verteilte Transaktion in ihrem Snapshot sichtbar wird. ### Ursachen Transaktionen, die mehrere Knoten ändern, müssen eine verteilte Festschreibung durchführen, die eine Vorbereitungsphase beinhaltet. Eine hohe Anzahl verteilter Transaktionen oder eine erhöhte Latenz bei verteilten Festschreibungen können dazu führen, dass bei anderen Prozessen das Warteereignis `PreparedTransactionResolution` auftritt. ### Aktion Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie Ereignisse im Zusammenhang mit verteilten Festschreibungen, da eine längere Dauer dieser Ereignisse die Latenz im Festschreibungspfad verteilter Transaktionen erhöhen könnte. Möglicherweise möchten Sie auch die Netzwerk- und CPU-Auslastung untersuchen. ## Warteereignis „AuroraLimitless:SendPreparedTransactionOutcome“ Der Prozess wird auf einem Knoten ausgeführt, der eine verteilte Transaktion koordiniert, und ein anderer Prozess hat den Status dieser Transaktion abgefragt, oder der Prozess hat eine verteilte Transaktion festgeschrieben und sendet das Ergebnis an die Teilnehmer. ### Ursachen Prozesse, bei denen das Warteereignis `PreparedTransactionResolution` auftritt, fragen den Transaktionskoordinator ab. Bei der Antwort des Transaktionskoordinators tritt SendPreparedTransactionOutcome auf. ### Aktion Reduzieren Sie die Anzahl der Transaktionen, die Daten auf mehreren Knoten ändern. Untersuchen Sie Ereignisse im Zusammenhang mit verteilten Festschreibungen sowie `IO:TwophaseFilePoolWrite`- und `IO:TwophaseFilePoolRead`-Ereignissen, da eine längere Dauer dieser Ereignisse die Latenz im Festschreibungspfad verteilter Transaktionen erhöhen könnte. Möglicherweise möchten Sie auch die Netzwerk- und CPU-Auslastung untersuchen. ## Warteereignis „AuroraLimitless:CommitClockBarrier“ Der Prozess schreibt eine Transaktion fest und muss warten, um sicherzustellen, dass die zugewiesene Festschreibungszeit für alle Knoten im Cluster garantiert in der Vergangenheit liegt. ### Ursachen Eine CPU- oder Netzwerkauslastung kann zu einer erhöhten Taktabweichung führen, was zu einer Verlängerung der Wartezeit bei diesem Warteereignis führt. ### Aktion Untersuchen Sie die CPU- oder Netzwerkauslastung in Ihrem Cluster. ## Warteereignis „AuroraLimitless:SnapshotClockBarrier“ Der Prozess hat eine Snapshot-Zeit von einem anderen Knoten mit einem Takt in der Zukunft empfangen und wartet darauf, dass sein eigener Takt diese Zeit erreicht. ### Ursachen Dies tritt normalerweise auf, nachdem der Prozess Ergebnisse einer Funktion erhalten hat, die auf einen Shard heruntergeschoben wurde, und eine Taktverschiebung zwischen den Knoten vorliegt. Eine CPU- oder Netzwerkauslastung kann zu einer erhöhten Taktabweichung führen, was zu einer Verlängerung der Wartezeit bei diesem Warteereignis führt. ### Aktion Untersuchen Sie die CPU- oder Netzwerkauslastung in Ihrem Cluster. ## Warteereignis „AuroraLimitless:ReaderSnapshotClockBarrier“ Dieses Ereignis tritt auf Leseknoten auf. Der Prozess wartet darauf, dass der Leseknoten den Schreibstream wiedergibt, sodass alle Schreibvorgänge, die vor dem Zeitpunkt des Prozess-Snapshots stattfanden, übernommen wurden. ### Ursachen Eine Zunahme der Aurora-Replikatverzögerung kann in diesem Fall zu längeren Wartezeiten führen. ### Aktion Untersuchen Sie die Aurora-Replikatverzögerung. ## Warteereignis „AuroraLimitless:GatherDistributedDeadlockGraph“ Der Prozess kommuniziert mit anderen Knoten, um im Rahmen der Erkennung verteilter Deadlocks Sperrdiagramme zu erfassen. ### Ursachen Wenn ein Prozess auf eine Sperre wartet, führt er eine Überprüfung auf verteilte Deadlocks durch, nachdem er länger gewartet hat als `rds_aurora.limitless_distributed_deadlock_timeout`. ### Aktion Untersuchen Sie die Ursachen für Sperrkonflikte in Ihrer Anwendung und ziehen Sie eine Optimierung von `rds_aurora.limitless_distributed_deadlock_timeout` in Betracht. ## Warteereignis „AuroraLimitless:DistributedDeadlockDetection“ Der Prozess kommuniziert mit anderen Knoten, um verteilte Deadlocks zu erkennen. ### Ursachen Wenn ein Prozess auf eine Sperre wartet, führt er eine Überprüfung auf verteilte Deadlocks durch, nachdem er länger gewartet hat als `rds_aurora.limitless_distributed_deadlock_timeout`. ### Aktion Untersuchen Sie die Ursachen für Sperrkonflikte in Ihrer Anwendung und ziehen Sie eine Optimierung von `rds_aurora.limitless_distributed_deadlock_timeout` in Betracht. ## Warteereignis „AuroraLimitless:DistributedDeadlockAbort“ Der Prozess kommuniziert mit einem anderen Knoten, um eine Sitzung abzubrechen, die als Opfer in einem verteilten Deadlock ausgewählt wurde. ### Ursachen Anwendungsmuster führen zu verteilten Deadlocks. ### Aktion Untersuchen Sie Anwendungsmuster, die zu verteilten Deadlocks führen. ## Warteereignis „AuroraLimitless:GatherRemoteStats“ Der Prozess sammelt Statistiken von anderen Knoten im Cluster. ### Ursachen Überwachungs- oder Aktivitätsabfragen und -ansichten wie beispielsweise`limitless_stat_activity` rufen Statistiken von anderen Knoten ab. ### Aktion Es sind keine weiteren Maßnahmen erforderlich. ## Warteereignis „AuroraLimitless:GlobalSequenceRefresh“ Der Prozess generiert einen neuen Sequenzwert und muss einen neuen Block aus der globalen Sequenz anfordern. ### Ursachen Eine hohe Rate der Generierung von Sequenzwerten kann in diesem Fall zu Verzögerungen führen, wenn `rds_aurora.limitless_sequence_chunk_size` nicht ausreicht. ### Aktion Dies ist ein normales Ereignis. Wenn Sie feststellen, dass dieses Ereignis zu lange dauert, sollten Sie eine Optimierung von `rds_aurora.limitless_sequence_chunk_size` in Betracht ziehen. Weitere Informationen finden Sie in der Dokumentation zu Sequenzen in Limitless Database. ## Warteereignis „AuroraLimitless:GlobalVacuumTimeExchange“ Der Prozess tauscht Snapshot-Daten zur Unterstützung der Bereinigung aus. ### Ursachen Knoten in Limitless Database tauschen die ältesten aktiven Snapshot-Daten mit anderen Knoten aus, um den korrekten Sperrzeitpunkt für die Ausführung der Bereinigung zu berechnen. ### Aktion Es sind keine weiteren Maßnahmen erforderlich. ## Warteereignis „AuroraLimitless:DistributedTransactionMonitorGather“ Der Prozess sammelt Transaktionsmetadaten von anderen Knoten, um die verteilte Transaktionsbereinigung zu unterstützen. ### Ursachen Knoten in Limitless Database tauschen Transaktionsmetadaten mit anderen Knoten aus, um festzustellen, wann der Status verteilter Transaktionen gelöscht werden kann. ### Aktion Es sind keine weiteren Maßnahmen erforderlich. ## Warteereignis „AuroraLimitlessActivity:AdminTaskSchedulerMain“ Wartet in der Hauptschleife des Aufgabenplanerprozesses. ## Warteereignis „AuroraLimitlessActivity:AdminTaskExecutorMain“ Wartet in der Hauptschleife des Aufgabenausführungsprozesses. ## Warteereignis „AuroraLimitlessActivity:AdminTaskMonitorMain“ Wartet in der Hauptschleife des Aufgabenüberwachungsprozesses. ## Warteereignis „AuroraLimitlessActivity:DatabaseCleanupMonitorMain“ Wartet in der Hauptschleife des Aufgabenüberwachungsprozesses der Datenbank. ## Warteereignis „AuroraLimitlessActivity:TopologyCleanupMonitorMain“ Wartet in der Hauptschleife des Bereinigungsüberwachungsprozesses der Topologie. ## Warteereignis „AuroraLimitlessActivity:ToplogyChangeMonitorMain“ Wartet in der Hauptschleife des Änderungsüberwachungsprozesses der Topologie. ## Warteereignis „AuroraLimitlessActivity:DistributedTransactionMonitorMain“ Wartet in der Hauptschleife des verteilten Transaktionsüberwachungsprozesses. ## Warteereignis „AuroraLimitlessActivity:GlobalVacuumMonitorMain“ Wartet in der Hauptschleife des globalen Bereinigungsüberwachungsprozesses. # Effizientes Bauen mit Funktionen Benutzerdefinierte Funktionen sind standardmäßig nicht für Single-Shard optimiert, können aber so konfiguriert werden, dass sie als Single-Shard-Operationen ausgeführt werden. Funktionen können Logik kapseln und sicherstellen, dass sie auf Single-Shard-optimierte Weise ausgeführt wird. ## Warum Single-Shard-Operationen wichtig sind Die Ressourcennutzung ist wichtig für Leistung und Kosteneffizienz. Single-Shard-Operationen verbrauchen im Vergleich zu Cross-Shard-Operationen deutlich weniger Ressourcen. Wenn beispielsweise eine Funktion zum Einfügen von einer Million Zeilen ausgeführt wird, verbraucht die Single-Shard-Ausführung etwa 90,5 ACUs gegenüber 126,5 ACUs für die Ausführung über mehrere Shards — eine Verbesserung der Ressourceneffizienz um 35%. Die Ausführung mit einem einzigen Shard bietet außerdem: + 35% höherer Durchsatz als bei Cross-Shard-Vorgängen + Vorhersehbarere Reaktionszeiten + Bessere Skalierbarkeit bei wachsendem Datenvolumen ## Single-Shard-Operationen und -Funktionen Funktionen werden auf Shards ausgeführt, wenn eine der folgenden Voraussetzungen erfüllt ist: + Die Funktion wird unveränderlich erstellt und ist in einer für einen einzelnen Shard optimierten Abfrage enthalten + Die Funktion wird von einem Benutzer verteilt Funktionen, die auf Shards ausgeführt werden, sind leistungsfähiger und skalierbarer, da sie dort ausgeführt werden, wo sich die Daten befinden. ## Funktionen und Volatilität Um die Volatilität einer Funktion zu überprüfen, verwenden Sie diese Abfrage für die Systemtabellen von PostgreSQL: ``` SELECT DISTINCT nspname, proname, provolatile FROM pg_proc PRO JOIN pg_namespace NSP ON PRO.pronamespace = NSP.oid WHERE proname IN ('random', 'md5'); ``` Beispielausgabe: ``` nspname | proname | provolatile ------------+---------+------------- pg_catalog | md5 | i pg_catalog | random | v (2 rows) ``` In diesem Beispiel `md5()` ist sie unveränderlich und `random()` volatil. Das bedeutet, dass eine für einzelne Shard optimierte Anweisung, die Folgendes beinhaltet, auch `md5()` weiterhin für einen einzelnen Shard optimiert ist, während eine Anweisung, die Include einschließt, dies nicht tut. `random()` Beispiel mit unveränderlicher Funktion: ``` EXPLAIN ANALYZE SELECT pg_catalog.md5('123') FROM s1.t1 WHERE col_a = 776586194 AND col_b = 654849524 AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5'; ``` ``` QUERY PLAN ---------------------------------------------------- Foreign Scan (cost=100.00..101.00 rows=100 width=0) (actual time=3.409..3.409 rows=1 loops=1) Single Shard Optimized Planning Time: 0.313 ms Execution Time: 4.253 ms (4 rows) ``` Beispiel mit flüchtiger Funktion: ``` EXPLAIN ANALYZE SELECT pg_catalog.random() FROM s1.t1 WHERE col_a = 776586194 AND col_b = 654849524 AND col_c = '3ac2f2affb02987159ccd6ebd23e1ae5'; ``` ``` QUERY PLAN ------------------------------------------------------ Foreign Scan on t1_fs00001 t1 (cost=100.00..15905.15 rows=1 width=8) (actual time=0.658..0.658 rows=1 loops=1) Planning Time: 0.263 ms Execution Time: 2.892 ms (3 rows) ``` Die Ausgabe zeigt, dass nach unten gedrückt und als Single-Shard-Optimierung ausgeführt `md5()` wird, dies aber nicht der Fall `random()` ist. ## Funktionen verteilen Eine Funktion, die nur auf Daten auf einem Shard zugreift, sollte auf diesem Shard ausgeführt werden, um Leistungsvorteile zu erzielen. Die Funktion muss verteilt sein und die Funktionssignatur muss den vollständigen Shard-Schlüssel enthalten — alle Spalten im Shard-Schlüssel müssen als Parameter an die Funktion übergeben werden. Beispielfunktion: ``` CREATE OR REPLACE FUNCTION s1.func1( param_a bigint, param_b bigint, param_c char(100) ) RETURNS int AS $$ DECLARE res int; BEGIN SELECT COUNT(*) INTO res FROM s1.t1 WHERE s1.t1.col_a = param_a AND s1.t1.col_b = param_b AND s1.t1.col_c = param_c; RETURN res; END $$ LANGUAGE plpgsql; ``` Vor der Verteilung ist die Funktion nicht für einen einzelnen Shard optimiert: ``` EXPLAIN ANALYZE SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5'); ``` ``` QUERY PLAN ------------------------------------------------------------------------------------------------------ Function Scan on func1 (cost=0.25..0.26 rows=1 width=4) (actual time=37.503..37.503 rows=1 loops=1) Planning Time: 0.901 ms Execution Time: 51.647 ms (3 rows) ``` Um die Funktion zu verteilen: ``` SELECT rds_aurora.limitless_distribute_function( 's1.func1(bigint,bigint,character)', ARRAY['param_a','param_b','param_c'], 's1.t1' ); ``` Nach der Verteilung ist die Funktion für einen einzelnen Shard optimiert: ``` EXPLAIN ANALYZE SELECT * FROM s1.func1(776586194, 654849524, '3ac2f2affb02987159ccd6ebd23e1ae5'); ``` ``` QUERY PLAN ------------------------------------------------------------------------------------------------ Foreign Scan (cost=100.00..101.00 rows=100 width=0) (actual time=4.332..4.333 rows=1 loops=1) Single Shard Optimized Planning Time: 0.857 ms Execution Time: 5.116 ms (4 rows) ``` Sie können die Single-Shard-Optimierung bestätigen, indem Sie die folgende Spalte markieren: `sso_calls` `rds_aurora.limitless_stat_statements` ``` subcluster_id | subcluster_type | calls | sso_calls | query --------------+-----------------+-------+-----------+-------------------------------------- 2 | router | 2 | 1 | SELECT * FROM s1.func1( $1, $2, $3 ) 3 | router | 1 | 1 | SELECT * FROM s1.func1( $1, $2, $3 ) (2 rows) ``` ## Funktionen und Effizienzmuster Die datennahe Ausführung von Logik ist effizienter, und Funktionen spielen dabei eine Schlüsselrolle. Es gibt zwei Hauptanwendungsfälle für die Verbesserung der Effizienz mit Funktionen: 1. Extrahieren des Shard-Schlüssels aus komplexen Daten, um eine separate, für einzelne Shard optimierte Funktion aufzurufen 1. Umwandlung von Shard-übergreifenden Workloads in Single-Shard-optimierte Workloads, indem Cross-Shard-Logik von Single-Shard-optimierten Anweisungen getrennt wird ### Extrahieren des Shard-Schlüssels aus komplexen Daten Stellen Sie sich eine Funktion mit Signatur vor`s3.func3(p_json_doc json)`, die mehrere Datenbankoperationen ausführt. Diese Operationen werden für alle Shards innerhalb einer Transaktion ausgeführt, die sich über alle Shards erstreckt. Wenn das JSON-Dokument den Shard-Schlüssel enthält, können Sie eine für einzelne Shard optimierte Funktion zur Ausführung der Datenbankoperationen erstellen. Ursprüngliches Muster: ``` s3.func3(p_json_doc json) database operation 1; database operation 2; database operation 3; ``` Optimiertes Muster: ``` s3.func3(p_json_doc json) DECLARE v_a bigint; BEGIN v_a := (p_json_doc->>'field_a')::bigint; SELECT s3.func3_INNER(v_a, p_json_doc); END; ``` Wo die innere Funktion funktioniert: ``` s3.func3_INNER(p_a, p_json_doc) database operation 1 WHERE shard_key = p_a; database operation 2 WHERE shard_key = p_a; database operation 3 WHERE shard_key = p_a; ``` In diesem Muster ist der Shard-Schlüssel in einem komplexen Datentyp gekapselt oder aus anderen Parametern ableitbar. Logik, Datenzugriff und Funktionen können den Shard-Schlüssel bestimmen, extrahieren oder konstruieren und dann eine für einen einzelnen Shard optimierte Funktion aufrufen, die Operationen ausführt, die nur einen einzelnen Shard betreffen. Da sich die Anwendungsschnittstelle nicht ändert, ist die Optimierung vergleichsweise einfach zu testen. ### Den Shard-Schlüssel von anderen Funktionen oder Daten fernhalten Ein anderes Entwurfsmuster gilt, wenn Logik oder Datenzugriff den Shard-Schlüssel berechnet oder bestimmt. Dies ist nützlich, wenn eine Funktion bei den meisten Aufrufen auf einem einzelnen Shard ausgeführt werden kann, gelegentlich aber eine shard-übergreifende Ausführung erfordert. Ursprüngliches Muster: ``` NEWORD(INTEGER, …) RETURNS NUMERIC DECLARE all_whid_local := true; LOOP through the order lines Generate warehouse ID; IF generated warehouse ID == input warehouse ID THEN ol_supply_whid := input warehouse ID; ELSE all_whid_local := false; ol_supply_whid := generated warehouse ID; END IF; … END LOOP; … RETURN no_s_quantity; ``` Optimiertes Muster mit separaten Funktionen: ``` CREATE OR REPLACE FUNCTION NEWORD_sso(no_w_id INTEGER, …) RETURNS NUMERIC … RETURN no_s_quantity; … END; LANGUAGE 'plpgsql'; SELECT rds_aurora.limitless_distribute_function( 'NEWORD_sso(int,…)', ARRAY['no_w_id'], 'warehouse' ); CREATE OR REPLACE FUNCTION NEWORD_crosshard(no_w_id INTEGER, …) RETURNS NUMERIC … RETURN no_s_quantity; … END; LANGUAGE 'plpgsql'; ``` Lassen Sie dann die Hauptfunktion entweder die Single-Shard-optimierte oder die Cross-Shard-Version aufrufen: ``` IF all_whid_local THEN SELECT NEWORD_sso(…) INTO no_s_quantity; ELSE SELECT NEWORD_crosshard(…) INTO no_s_quantity; END IF; ``` Dieser Ansatz ermöglicht es den meisten Aufrufen, von der Single-Shard-Optimierung zu profitieren und gleichzeitig das korrekte Verhalten in Fällen beizubehalten, die eine Shard-übergreifende Ausführung erfordern. ## Es wird nach Single-Shard-Operationen gesucht Wird verwendet`EXPLAIN`, um zu überprüfen, ob eine Anweisung für Single-Shard optimiert ist. In der Ausgabe wird ausdrücklich „Single Shard Optimized“ für optimierte Operationen gemeldet. Shardübergreifender Aufruf vor der Verteilung: ``` QUERY PLAN --------------------------------------------------------------------- Function Scan on func1 (cost=0.25..0.26 rows=1 width=4) (actual time=59.622..59.623 rows=1 loops=1) Planning Time: 0.925 ms Execution Time: 60.211 ms ``` Aufruf eines einzelnen Shards nach der Verteilung: ``` QUERY PLAN ---------------------------------------------------------------------- Foreign Scan (cost=100.00..101.00 rows=100 width=0) (actual time=4.576..4.577 rows=1 loops=1) Single Shard Optimized Planning Time: 1.483 ms Execution Time: 5.404 ms ``` Der Unterschied in den Ausführungszeiten zeigt den Leistungsvorteil der Single-Shard-Optimierung. # Instanzspezifische Leistungs- und Ressourcenüberwachung Die Überwachung auf Instanzebene ist entscheidend, um Verbindungsverzerrungen, Workload- und Datenverzerrungen zu verstehen und zu verstehen, wann Router oder Split-Shards hinzugefügt werden müssen, um einen höheren Durchsatz bei gleichbleibender Latenz zu erreichen. ## -Übersicht Wenn Ihre Anwendung eine Anfrage gegen ausgibt, durchläuft diese Anfrage ein ausgeklügeltes verteiltes System, bevor Ergebnisse zurückgegeben werden. Eine scheinbar einfache `SELECT` Anweisung kann mehrere Datenbankinstanzen betreffen, von denen jede eine unterschiedliche Rolle bei der Verarbeitung Ihrer Anfrage spielt. Das Verständnis dieser Entwicklung — und der Instanzen, die sie ermöglichen — verändert die Art und Weise, wie Sie Anwendungen entwerfen, Überwachungsdaten interpretieren und Leistungsprobleme diagnostizieren. Dieser Leitfaden bietet tiefe technische Einblicke in die Instance-Architektur: + Unbegrenzter Architektur-Refresher, Router und Shards + Wann und wie können Sie die einzelnen Instance-Typen skalieren, um Ihre Leistungs- und Kapazitätsanforderungen zu erfüllen + Wie können Sie die Leistung auf Instanzebene überwachen, Fehler beheben und optimieren + Bewährte Methoden für das Anwendungsdesign, das die verteilte Architektur effektiv nutzt ## Grundlagen der Instanzarchitektur erreicht horizontale Skalierbarkeit durch funktionale Trennung zwischen zwei spezialisierten Instance-Typen: + **Router-Instanzen** stellen die Orchestrierungsebene bereit — sie akzeptieren Client-Verbindungen, analysieren Abfragen, koordinieren verteilte Operationen und aggregieren Ergebnisse. Router sind zustandslos, d. h. sie speichern keine Daten und können ohne Datenmigration hinzugefügt oder entfernt werden. + **Shard-Instanzen** stellen die Daten- und Rechenebene bereit — sie speichern Tabellendaten, führen Abfragen anhand lokaler Daten aus und wickeln Transaktionen ab. Shards sind statusbehaftet und besitzen jeweils eine bestimmte Teilmenge Ihrer Daten, die durch konsistentes Hashing bestimmt wird. Diese Trennung ermöglicht es, Verbindungsverarbeitung, Abfragekoordination und Datenspeicherung unabhängig von Ihren Workload-Merkmalen zu skalieren. ### Vergleich von Router und Shard | Merkmal | Router-Instanzen | Shard-Instanzen | | --- | --- | --- | | Primäre Rolle | Koordination und Verteilung von Abfragen | Datenspeicherung und Ausführung von Abfragen | | Status | Staatenlos (keine Datenspeicherung) | Zuständig (besitzt Daten) | | Skalierbarkeit | Sofort hinzufügen/entfernen | Erfordert einen Datenausgleich | | Fokus auf Ressourcen | CPU für die Koordination; moderater Arbeitsspeicher | CPU für Abfragen; hoher Arbeitsspeicher für den Cache | | Trigger für Skalierung | Hohe Verbindungsanzahl, verteilte TXN-Rate | Hoher CPU-, Datenvolumen- und Abfragedurchsatz | ## Überwachung der Instance-Leistung Für einen effektiven Betrieb ist es entscheidend, die Leistung auf Instanzebene zu verstehen. Die instanzspezifische Überwachung deckt die Verteilungsmuster auf, die sich auf die Leistung auswirken: Verbindungsverzerrungen, Workload-Verzerrungen und Datenverzerrungen. ### Erkennung von Verzerrungen Bei einer idealen Bereitstellung verteilen sich Arbeitslast und Ressourcen gleichmäßig auf die Instanzen. In der Praxis kommt es bei Anwendungen häufig zu Verzerrungen, d. h. einer ungleichmäßigen Verteilung, wodurch die Last auf bestimmte Instanzen konzentriert wird. Es gibt drei Arten von Verzerrungen, die überwacht werden müssen: + **Verbindungsverzerrung**: Ungleichmäßige Verteilung der Client-Verbindungen auf die Router + **Verzerrung der Arbeitslast: Ungleichmäßige** Abfragelast zwischen verschiedenen Shards aufgrund von Hot-Shard-Keys + **Datenverzerrung**: Ungleichmäßiges Datenvolumen zwischen verschiedenen Shards aufgrund der Häufigkeit von Shard-Schlüsseln ### Lastverteilung mit Database Insights Die schnellste Methode zur Beurteilung des Zustands auf Instanzebene ist die Lastverteilungsansicht von Database Insights, die einen sofortigen Überblick darüber bietet, wie sich Active Sessions auf die Instances verteilen. So greifen Sie auf Load Distribution zu: 1. Navigieren Sie zu RDS Console → Your Limitless Cluster 1. Wählen Sie den Tab „Performance Insights“ 1. Klicken Sie auf den Abschnitt „Lastverteilung“ **Fehlerfreies Muster:** Die Last ist relativ gleichmäßig auf die Instanzen verteilt + Router weisen möglicherweise einen etwas höheren AAS als Shards auf (Koordinationsaufwand) + Die AAS-Werte der Shards, die nicht mehr als 20% voneinander abweichen, deuten auf ein ausgewogenes Verhältnis hin **Bezüglich des Musters:** Signifikante Konzentration auf bestimmte Fälle + Ein Router mit > 70% der Routerlast → Verbindungsverzerrung + Ein Shard mit > 50% der Shard-Last → Arbeitslast oder Datenversatz + Große Varianz zwischen Shards → Untersuchen Sie die Verteilung der Shard-Schlüssel ### CloudWatch Metriken CloudWatch Bietet für tiefere Analysen, die über Database Insights hinausgehen, instanzspezifische Metriken, die Muster der Ressourcennutzung aufzeigen. Die `ServerlessDatabaseCapacity` Metrik mit Dimension `DBShardGroupInstance` zeigt den ACU-Verbrauch pro Instanz und bietet so den direktesten Überblick über die Ressourcennutzung. **Wann sollte Folgendes untersucht werden:** + ACU-Varianz des Routers > 30% → Verbindungsverzerrung oder gemeinsame Workload-Konzentration + ACU-Varianz der Shared > 40% → Daten- oder Workload-Verzerrung + Jede Instanz hat konstant die maximale ACU → Kapazitätsbeschränkung ## Router-Überwachung und Fehlerbehebung Bei Routern können Leistungsprobleme hauptsächlich auf zwei Ursachen zurückzuführen sein: ungleichmäßige Verbindungsverteilung und Workload-Konzentration auf mehrere Shards. ### Ungleichmäßig verteilte Sitzungen **Symptom:** Ein Router verarbeitet einen unverhältnismäßigen Anteil an Verbindungen **Hauptursache:** DNS-Caching führt dazu, dass mehrere Verbindungsanfragen auf denselben Router-Endpunkt aufgelöst werden. **Am häufigsten bei:** + Benchmarking mit Tools wie pgbench + Initialisierung des Verbindungspools (viele Verbindungen wurden schnell hergestellt) + Der Anwendungsserver wird neu gestartet **Abhilfemaßnahmen** + Stellen Sie sicher, dass Sie den in der Konsole angegebenen Limitless-Endpunkt verwenden + Manuelles Balancing: Extrahieren Sie Router-Endpunkte und verbinden Sie verschiedene Anwendungen mit verschiedenen Routern + Verwenden Sie für libpq-Anwendungen die Funktion `LOADBALANCEHOSTS` + Verwenden Sie für JDBC-Anwendungen das Limitless Connection Plugin + Verwenden Sie einen NLB, um Sitzungen und Verteilungen zu verwalten ## Shard-Überwachung und Fehlerbehebung Bei Shards treten Leistungsprobleme auf, die hauptsächlich auf drei Ursachen zurückzuführen sind: Ressourcenengpässe, Datenverzerrungen und Workload-Verzerrungen. ### Nutzung von Shard-Ressourcen Ein Shard mit beliebten Shard-Schlüsseln wird mehr Daten und eine höhere Arbeitslast haben. Dies äußert sich in einer Ressourcenauslastung, d. h. die Instanz wird mehr verbrauchen. ACUs **Strategien zur Problembehebung:** 1. Überprüfen **Sie die Auswahl der Shard-Schlüssel erneut:** Überprüfen Sie die Kardinalität und die Zugriffsmuster der Shard-Schlüssel. Ziehen Sie zur besseren Verteilung zusammengesetzte Shard-Schlüssel in Betracht. 1. **Teilen Sie den Shard auf:** Verteilen Sie die Last auf mehrere Shard-Instanzen **Wann sollten Shards aufgeteilt werden:** + Ein einzelner Shard liegt konstant bei einer maximalen ACU von > 80% + Der Abfragedurchsatz ist durch die Kapazität eines einzelnen Shards begrenzt ### Shard-Datenvolumen Verwenden Sie SQL-Funktionen, um Datenmengen abzufragen: ``` SELECT subcluster_id, subcluster_type, pg_size_pretty(db_size) FROM rds_aurora.limitless_stat_database_size('postgres_limitless') ORDER BY 1; ``` So zeigen Sie Daten pro Tabelle und pro Shard an: ``` SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public', 'table_name'); ``` ### Behebung einer ungleichmäßigen Auslastung Wenn sich die Arbeitslast oder der Datenversatz auf bestimmte Shards konzentriert, wird durch die Aufteilung der Shards die Last auf mehrere Instanzen umverteilt. Wichtige Überlegungen: + Welche Shard-Tasten verschoben werden sollen, kann nicht gesteuert werden + Es gibt keine Möglichkeit, einen Split rückgängig zu machen, ohne einen manuellen Snapshot wiederherzustellen, der vor dem Split erstellt wurde + Alle Instanzen, einschließlich eines neuen Shards, verbrauchen im Leerlauf mindestens die ACU der Instanz Das Aufteilen von Shards ermöglicht eine weitere Skalierung, und aufeinanderfolgende Shard-Splits sind der Weg zu höherem Durchsatz und weiterer Skalierung bei gleichzeitiger Beibehaltung einer niedrigen Latenz. ## Einschränkungen Seien Sie sich dieser betrieblichen Einschränkungen bewusst: **Einschränkungen des Routers:** + **Router können nicht entfernt werden** — Einmal hinzugefügt, verbleiben Router im Cluster + Planen Sie das Hinzufügen von Routern sorgfältig, um unnötige Grundkosten zu vermeiden **Einschränkungen bei Shards:** + **Shards können nicht zusammengeführt werden** — Shard-Splits sind unidirektionale Operationen + Einzige Wiederherstellungsoption: Wiederherstellung aus einem Snapshot, der vor dem Teilen erstellt wurde **Strategien zur Schadensbegrenzung:** + Beginnen Sie mit der Mindestanzahl brauchbarer Instanzen + Fügen Sie die Kapazität nach Bedarf schrittweise hinzu + Machen Sie Schnappschüsse, bevor größere Topologieänderungen vorgenommen werden + Überwachen Sie die Basiskosten, wenn der Cluster wächst # Sichern und Wiederherstellen von Aurora PostgreSQL Limitless Database Sie können einen DB-Cluster, der Aurora PostgreSQL Limitless Database verwendet, sichern und wiederherstellen. **Contents** + [ ## Sicheren eines DB-Clusters, der Aurora PostgreSQL Limitless Database verwendet ](#limitless-backup) + [ ### Erstellen eines DB-Cluster-Snapshots ](#limitless-backup-snapshot) + [ ## Wiederherstellen eines DB-Clusters, der Aurora PostgreSQL Limitless Database verwendet ](#limitless-restore) + [ ### Wiederherstellen eines DB-Clusters aus einem DB-Snapshot ](#limitless-restore-snapshot) + [ ### Wiederherstellen eines DB-Clusters mit zeitpunktbezogener Wiederherstellung ](#limitless-restore-pitr) + [ ## PostgreSQL-Dienstprogramme zur Sicherung und Wiederherstellung werden nicht unterstützt ](#limitless-backup-utilities) ## Sicheren eines DB-Clusters, der Aurora PostgreSQL Limitless Database verwendet Die Sicherung eines DB-Clusters mit Aurora PostgreSQL Limitless Database weist im Vergleich zur Sicherung eines standardmäßigen Aurora-DB-Clusters Ähnlichkeiten und Unterschiede in der Funktionalität auf. + Wenn Sie einen manuellen DB-Cluster-Snapshot eines Aurora-DB-Clusters erstellen, der Limitless Database verwendet, enthält der Snapshot Daten aus der DB-Shard-Gruppe. + Kontinuierliche Backups umfassen Daten aus der DB-Shard-Gruppe. + Automatisierte tägliche Snapshots umfassen Daten aus der DB-Shard-Gruppe. + DB-Cluster Snapshots lassen sich kopieren. Weitere Informationen finden Sie unter [Kopieren eines DB-Cluster-Snapshots](aurora-copy-snapshot.md). + DB-Cluster Snapshots lassen sich teilen. Weitere Informationen finden Sie unter [Freigeben eines DB-Cluster-Snapshots](aurora-share-snapshot.md). + Sie können das Dienstprogramm `pg_dump` oder `pg_dumpall` nicht verwenden, um Datenbanken in der DB-Shard-Gruppe zu sichern. + Beim Löschen von DB-Clustern lassen sich für Aurora PostgreSQL Limitless Database finale Snapshots erstellen. + Beim Löschen von DB-Clustern lassen sich für Aurora PostgreSQL Limitless Database keine automatisierten Sicherungen beibehalten. ### Erstellen eines DB-Cluster-Snapshots DB-Cluster-Snapshots von Aurora PostgreSQL Limitless Database erstellt man auf die gleiche Weise wie von einem standardmäßigen Aurora-DB-Cluster, wie im folgenden AWS CLI-Beispiel gezeigt: ``` aws rds create-db-cluster-snapshot \ --db-cluster-identifier my-db-cluster \ --db-cluster-snapshot-identifier my-db-cluster-snapshot ``` Informationen zum Sichern von DB-Clustern finden Sie unter [Übersicht über das Sichern und Wiederherstellen eines Aurora-DB-Clusters](Aurora.Managing.Backups.md). ## Wiederherstellen eines DB-Clusters, der Aurora PostgreSQL Limitless Database verwendet Die Wiederherstellung eines DB-Clusters mit Aurora PostgreSQL Limitless Database weist im Vergleich zur Wiederherstellung eines standardmäßigen Aurora-DB-Clusters Ähnlichkeiten und Unterschiede in der Funktionalität auf. + Sie können einen DB-Cluster von Limitless Database nur aus einem Quell-DB-Cluster wiederherstellen, der eine mit Limitless Database kompatible DB-Engine-Version ausführt, z. B. `16.4-limitless`. + Wenn Sie einen DB-Cluster aus dem manuellen Snapshot eines DB-Clusters wiederherstellen, der Limitless Database verwendet, wird der gesamte DB-Cluster-Speicher wiederhergestellt. Dies umfasst den Speicher der DB-Shard-Gruppe. Sie müssen eine DB-Shard-Gruppe erstellen, um auf den Speicher für Ihre Limitless Database zugreifen zu können. + Mit der zeitpunktbezogenen Wiederherstellung (PITR) können Sie einen DB-Cluster auf jeden beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums wiederherstellen. Der wiederhergestellte DB-Cluster umfasst den Speicher der DB-Shard-Gruppe. Sie müssen eine DB-Shard-Gruppe erstellen, um auf den Speicher für Ihre Limitless Database zugreifen zu können. + PITR wird für gelöschte DB-Cluster von Aurora PostgreSQL Limitless Database nicht unterstützt. + Wenn Sie einen DB-Cluster aus einem automatisierten täglichen Snapshot wiederherstellen, wird auch der Speicher für die DB-Shard-Gruppe wiederhergestellt. + Wenn Sie einen DB-Cluster von Aurora PostgreSQL Limitless Database wiederherstellen, müssen Sie die erweiterte Überwachung und Performance Insights aktivieren. Geben Sie unbedingt die Performance-Insights KMS-Schlüssel-ID an. Nachdem Sie einen DB-Cluster von Aurora PostgreSQL Limitless Database wiederhergestellt haben, sollten Sie dessen Funktionalität überprüfen, indem Sie Ihre Abfragen darauf ausführen. ### Wiederherstellen eines DB-Clusters aus einem DB-Snapshot Die folgenden AWS CLI-Beispiele zeigen, wie Sie einen DB-Cluster von Aurora PostgreSQL Limitless Database aus einem DB-Cluster-Snapshot wiederherstellen. Sie müssen DB-Engine-Version `16.4-limitless` verwenden. **So stellen Sie einen DB-Cluster von Limitless Database aus einem DB-Cluster-Snapshot wieder her** 1. Stellen Sie den DB-Cluster wieder her: ``` aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier my-new-db-cluster \ --snapshot-identifier my-db-cluster-snapshot \ --engine aurora-postgresql \ --engine-version 16.4-limitless \ --enable-performance-insights \ --performance-insights-retention-period 31 \ --performance-insights-kms-key-id arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \ --monitoring-interval 5 \ --monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ``` 1. Erstellen Sie die DB-Shard-Gruppe: ``` aws rds create-db-shard-group \ --db-cluster-identifier my-new-db-cluster \ --db-shard-group-identifier my-new-DB-shard-group \ --max-acu 1000 ``` Weitere Informationen finden Sie unter [Hinzufügen einer DB-Shard-Gruppe zu einem vorhandenen DB-Cluster von Aurora PostgreSQL Limitless Database](limitless-shard-add.md). Weitere Informationen zum Wiederherstellen eines Aurora-DB-Clusters aus DB-Cluster-Snapshots finden Sie unter [Wiederherstellen aus einem DB-Cluster-Snapshot](aurora-restore-snapshot.md). ### Wiederherstellen eines DB-Clusters mit zeitpunktbezogener Wiederherstellung Die folgenden AWS CLI-Beispiele zeigen, wie Sie einen DB-Cluster von Aurora PostgreSQL Limitless Database mit einer zeitpunktbezogenen Wiederherstellung (PITR) wiederherstellen. **So stellen Sie einen DB-Cluster von Limitless Database mit PITR wieder her** 1. Stellen Sie den DB-Cluster wieder her: ``` aws rds restore-db-cluster-to-point-in-time \ --source-db-cluster-identifier my-db-cluster \ --db-cluster-identifier my-new-db-cluster \ --use-latest-restorable-time \ --enable-performance-insights \ --performance-insights-retention-period 31 \ --performance-insights-kms-key-id arn:aws:kms:us-east-1:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \ --monitoring-interval 5 \ --monitoring-role-arn arn:aws:iam::123456789012:role/EMrole ``` 1. Erstellen Sie die DB-Shard-Gruppe: ``` aws rds create-db-shard-group \ --db-cluster-identifier my-new-db-cluster \ --db-shard-group-identifier my-new-DB-shard-group \ --max-acu 1000 ``` Weitere Informationen finden Sie unter [Hinzufügen einer DB-Shard-Gruppe zu einem vorhandenen DB-Cluster von Aurora PostgreSQL Limitless Database](limitless-shard-add.md). Weitere Informationen zu PITR finden Sie unter [Wiederherstellen eines DB-Clusters zu einer bestimmten Zeit](aurora-pitr.md). ## PostgreSQL-Dienstprogramme zur Sicherung und Wiederherstellung werden nicht unterstützt Die folgenden PostgreSQL-Dienstprogramme werden weder für den primären DB-Cluster noch für die DB-Shard-Gruppe unterstützt: + `pg_dump` + `pg_dumpall` + `pg_restore` Sie können sie zwar mit Open-Source-Binärdateien oder alternativen Methoden verwenden, dies kann jedoch zu uneinheitlichen Ergebnissen führen. # Aktualisieren von Amazon Aurora PostgreSQL Limitless Database Für das Upgrade der Aurora PostgreSQL Limitless Database gilt Folgendes: + Es werden Upgrades von Nebenversionen unterstützt. + Das Patching von Aurora PostgreSQL Limitless Database wird unterstützt. Patches werden als ausstehende Wartungsarbeiten angezeigt und müssen während Ihres Wartungsfensters installiert werden. ## Aktualisieren von DB-Clustern, die Amazon Aurora PostgreSQL Limitless Database verwenden Sie aktualisieren einen DB-Cluster, indem Sie ihn ändern und eine neue DB-Engine-Version auswählen. Sie können die AWS-Managementkonsole oder die AWS CLI verwenden. ### Konsole **So aktualisieren Sie Ihren DB-Cluster von Limitless Database** 1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Navigieren Sie zur Seite **Datenbanken**. 1. Wählen Sie den DB-Cluster von Limitless Database aus, dem Sie eine DB-Shard-Gruppe hinzufügen möchten. 1. Wählen Sie **Ändern** aus. Die Seite **DB-Cluster ändern** wird angezeigt. 1. Wählen Sie als **DB-Engine-Version** die neue DB-Engine-Version aus, zum Beispiel **Aurora PostgreSQL mit Limitless Database (mit PostgreSQL 16.6 kompatibel)**. 1. Klicken Sie auf **Weiter**. 1. Legen Sie auf der Zusammenfassungsseite fest, ob die Änderungen sofort oder während des nächsten Wartungszeitraums übernommen werden sollen, und wählen Sie dann **Cluster ändern** aus. ### CLI Verwenden Sie den AWS CLI-Befehl [modify-db-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/modify-db-cluster.html), wie im folgenden Beispiel gezeigt. ``` aws rds modify-db-cluster \ --db-cluster-identifier my-sv2-cluster \ --engine-version 16.6-limitless \ --apply-immediately ``` # Referenz zu Aurora PostgreSQL Limitless Database Wir bieten die folgenden Referenzthemen für Aurora PostgreSQL Limitless Database. **Topics** + [ # Unterstützte und nicht unterstützte Data Definition Language (DDL)-SQL-Befehle ](limitless-reference.DDL-support.md) + [ # DDL-Einschränkungen und andere Informationen für Aurora PostgreSQL Limitless Database ](limitless-reference.DDL-limitations.md) + [ # Unterstützte und nicht unterstützte Data Manipulation Language (DML)- und SQL-Befehle zur Abfrageverarbeitung ](limitless-reference.DML-support.md) + [ # DML-Einschränkungen und andere Informationen für Aurora PostgreSQL Limitless Database ](limitless-reference.DML-limitations.md) + [ # Variablen in Aurora PostgreSQL Limitless Database ](limitless-reference.variables.md) + [ # DB-Cluster-Parameter in der Aurora PostgreSQL Limitless-Datenbank ](limitless-reference.DBCparams.md) # Unterstützte und nicht unterstützte Data Definition Language (DDL)-SQL-Befehle In der folgenden Tabelle sind die DDL-Befehle aufgeführt, die von Aurora PostgreSQL Limitless Database unterstützt und nicht unterstützt werden, mit Verweisen auf Einschränkungen oder weitere Informationen. | Befehl | Unterstützt? | Einschränkungen oder weitere Informationen | | --- | --- | --- | | ALTER AGGREGATE | Nein | Nicht zutreffend | | ALTER COLLATION | Ja | Keine | | ALTER CONVERSION | Ja | Keine | | ALTER DATABASE | Nein | Nicht zutreffend | | ALTER DEFAULT PRIVILEGES | Nein | Nicht zutreffend | | ALTER DOMAIN | Nein | Nicht zutreffend | | ALTER EVENT TRIGGER | Nein | Nicht zutreffend | | ALTER EXTENSION | Ja | [Erweiterungen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Extensions) | | ALTER FOREIGN DATA WRAPPER | Nein | Nicht zutreffend | | ALTER FOREIGN TABLE | Nein | Nicht zutreffend | | ALTER FUNCTION | Ja | [Funktionen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Functions) | | ALTER GROUP | Ja | Keine | | ALTER INDEX | Ja | Keine | | ALTER LANGUAGE | Nein | Nicht zutreffend | | ALTER LARGE OBJECT | Nein | Nicht zutreffend | | ALTER MATERIALIZED VIEW | Nein | Nicht zutreffend | | ALTER OPERATOR | Ja | Keine | | ALTER OPERATOR CLASS | Ja | Keine | | ALTER OPERATOR FAMILY | Ja | Keine | | ALTER POLICY | Nein | Nicht zutreffend | | ALTER PROCEDURE | Ja | Keine | | ALTER PUBLICATION | Nein | Nicht zutreffend | | ALTER ROLE | Ja | Keine | | ALTER ROUTINE | Nein | Nicht zutreffend | | ALTER RULE | Nein | Nicht zutreffend | | ALTER SCHEMA | Ja | Keine | | ALTER SEQUENCE | Ja | [Sequenzen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Sequences) | | ALTER SERVER | Nein | Nicht zutreffend | | ALTER STATISTICS | Nein | Nicht zutreffend | | ALTER SUBSCRIPTION | Nein | Nicht zutreffend | | ALTER SYSTEM | Nein | Nicht zutreffend | | ALTER TABLE | Ja | [ALTER TABLE](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.ALTER_TABLE) | | ALTER TABLESPACE | Nein | Nicht zutreffend | | ALTER TEXT SEARCH CONFIGURATION | Nein | Nicht zutreffend | | ALTER TEXT SEARCH DICTIONARY | Nein | Nicht zutreffend | | ALTER TEXT SEARCH PARSER | Nein | Nicht zutreffend | | ALTER TEXT SEARCH TEMPLATE | Nein | Nicht zutreffend | | ALTER TRIGGER | Nein | Nicht zutreffend | | ALTER TYPE | Ja | Keine | | ALTER USER | Ja | Keine | | ALTER USER MAPPING | Nein | Nicht zutreffend | | ALTER VIEW | Ja | Keine | | COMMENT | Nein | Nicht zutreffend | | CREATE ACCESS METHOD | Nein | Nicht zutreffend | | CREATE AGGREGATE | Nein | Nicht zutreffend | | CREATE CAST | Ja | Keine | | CREATE COLLATION | Ja | Keine | | CREATE CONVERSION | Ja | Keine | | CREATE DATABASE | Ja | [CREATE DATABASE](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.CREATE_DATABASE) | | CREATE DOMAIN | Nein | Nicht zutreffend | | CREATE EVENT TRIGGER | Nein | Nicht zutreffend | | CREATE EXTENSION | Ja | [Erweiterungen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Extensions) | | CREATE FOREIGN DATA WRAPPER | Nein | Nicht zutreffend | | CREATE FOREIGN TABLE | Nein | Nicht zutreffend | | CREATE FUNCTION | Ja | [Funktionen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Functions) | | CREATE GROUP | Ja | Keine | | CREATE INDEX | Ja | [CREATE INDEX](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.CREATE_INDEX) | | CREATE LANGUAGE | Nein | Nicht zutreffend | | CREATE MATERIALIZED VIEW | Nein | Nicht zutreffend | | CREATE OPERATOR | Ja | Keine | | CREATE OPERATOR CLASS | Ja | Keine | | CREATE OPERATOR FAMILY | Ja | Keine | | CREATE POLICY | Ja | Keine | | CREATE PROCEDURE | Ja | Keine | | CREATE PUBLICATION | Nein | Nicht zutreffend | | CREATE ROLE | Ja | Keine | | CREATE RULE | Nein | Nicht zutreffend | | CREATE SCHEMA | Ja | [CREATE SCHEMA](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.CREATE_SCHEMA) | | CREATE SEQUENCE | Ja | [Sequenzen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Sequences) | | CREATE SERVER | Nein | Nicht zutreffend | | CREATE STATISTICS | Nein | Nicht zutreffend | | CREATE SUBSCRIPTION | Nein | Nicht zutreffend | | CREATE TABLE | Ja | [CREATE TABLE](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.CREATE_TABLE) | | CREATE TABLE AS | Ja | [CREATE TABLE AS](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.CREATE_TABLE_AS) | | CREATE TABLESPACE | Nein | Nicht zutreffend | | CREATE TEMPORARY TABLE | Nein | Nicht zutreffend | | CREATE TEMPORARY TABLE AS | Nein | Nicht zutreffend | | CREATE TEXT SEARCH CONFIGURATION | Nein | Nicht zutreffend | | CREATE TEXT SEARCH DICTIONARY | Nein | Nicht zutreffend | | CREATE TEXT SEARCH PARSER | Nein | Nicht zutreffend | | CREATE TEXT SEARCH TEMPLATE | Nein | Nicht zutreffend | | CREATE TRANSFORM | Nein | Nicht zutreffend | | CREATE TRIGGER | Nein | Nicht zutreffend | | CREATE TYPE | Ja | Keine | | CREATE USER | Ja | Keine | | CREATE USER MAPPING | Nein | Nicht zutreffend | | CREATE VIEW | Ja | Keine | | DROP ACCESS METHOD | Nein | Nicht zutreffend | | DROP AGGREGATE | Ja | Keine | | DROP CAST | Ja | Keine | | DROP COLLATION | Ja | Keine | | DROP CONVERSION | Ja | Keine | | DROP DATABASE | Ja | [DROP DATABASE](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.DROP_DATABASE) | | DROP DOMAIN | Nein | Nicht zutreffend | | DROP EVENT TRIGGER | Nein | Nicht zutreffend | | DROP EXTENSION | Ja | [Erweiterungen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Extensions) | | DROP FOREIGN DATA WRAPPER | Nein | Nicht zutreffend | | DROP FOREIGN TABLE | Nein | Nicht zutreffend | | DROP FUNCTION | Ja | [Funktionen](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.Functions) | | DROP GROUP | Ja | Keine | | DROP INDEX | Ja | Keine | | DROP LANGUAGE | Nein | Nicht zutreffend | | DROP MATERIALIZED VIEW | Nein | Nicht zutreffend | | DROP OPERATOR | Ja | Keine | | DROP OPERATOR CLASS | Ja | Keine | | DROP OPERATOR FAMILY | Ja | Keine | | DROP OWNED | Nein | Nicht zutreffend | | DROP POLICY | Nein | Nicht zutreffend | | DROP PROCEDURE | Ja | Keine | | DROP PUBLICATION | Nein | Nicht zutreffend | | DROP ROLE | Ja | Keine | | DROP ROUTINE | Nein | Nicht zutreffend | | DROP RULE | Nein | Nicht zutreffend | | DROP SCHEMA | Ja | Keine | | DROP SEQUENCE | Ja | Keine | | DROP SERVER | Nein | Nicht zutreffend | | DROP STATISTICS | Nein | Nicht zutreffend | | DROP SUBSCRIPTION | Nein | Keine | | DROP TABLE | Ja | Keine | | DROP TABLESPACE | Nein | Nicht zutreffend | | DROP TEXT SEARCH CONFIGURATION | Nein | Nicht zutreffend | | DROP TEXT SEARCH DICTIONARY | Nein | Nicht zutreffend | | DROP TEXT SEARCH PARSER | Nein | Nicht zutreffend | | DROP TEXT SEARCH TEMPLATE | Nein | Nicht zutreffend | | DROP TRANSFORM | Nein | Nicht zutreffend | | DROP TRIGGER | Nein | Nicht zutreffend | | DROP TYPE | Ja | Keine | | DROP USER | Ja | Keine | | DROP USER MAPPING | Nein | Nicht zutreffend | | DROP VIEW | Ja | Keine | | GRANT | Ja | Keine | | REASSIGN OWNED | Nein | Nicht zutreffend | | REVOKE | Ja | Keine | | SECURITY LABEL | Nein | Nicht zutreffend | | SELECT INTO | Ja | [SELECT INTO](limitless-reference.DDL-limitations.md#limitless-reference.DDL-limitations.SELECT_INTO) | | SET | Ja | Keine | | SET CONSTRAINTS | Nein | Nicht zutreffend | | SET ROLE | Ja | Keine | | SET SESSION AUTHORIZATION | Ja | Keine | | SET TRANSACTION | Ja | Keine | | TRUNCATE | Ja | Keine | # DDL-Einschränkungen und andere Informationen für Aurora PostgreSQL Limitless Database In den folgenden Themen werden Einschränkungen beschrieben oder weitere Informationen zu DDL-SQL-Befehlen in Aurora PostgreSQL Limitless Database bereitgestellt. **Topics** + [ ## ALTER TABLE ](#limitless-reference.DDL-limitations.ALTER_TABLE) + [ ## CREATE DATABASE ](#limitless-reference.DDL-limitations.CREATE_DATABASE) + [ ## CREATE INDEX ](#limitless-reference.DDL-limitations.CREATE_INDEX) + [ ## CREATE SCHEMA ](#limitless-reference.DDL-limitations.CREATE_SCHEMA) + [ ## CREATE TABLE ](#limitless-reference.DDL-limitations.CREATE_TABLE) + [ ## CREATE TABLE AS ](#limitless-reference.DDL-limitations.CREATE_TABLE_AS) + [ ## DROP DATABASE ](#limitless-reference.DDL-limitations.DROP_DATABASE) + [ ## SELECT INTO ](#limitless-reference.DDL-limitations.SELECT_INTO) + [ ## Beschränkungen ](#limitless-reference.DDL-limitations.Constraints) + [ ## Standardwerte ](#limitless-reference.DDL-limitations.DefaultValues) + [ ## Erweiterungen ](#limitless-reference.DDL-limitations.Extensions) + [ ## Fremdschlüssel ](#limitless-reference.DDL-limitations.FKs) + [ ## Funktionen ](#limitless-reference.DDL-limitations.Functions) + [ ## Sequenzen ](#limitless-reference.DDL-limitations.Sequences) ## ALTER TABLE Der Befehl `ALTER TABLE` wird in Aurora PostgreSQL Limitless Database in der Regel unterstützt. Weitere Informationen finden Sie im Abschnitt [ALTER TABLE](https://www.postgresql.org/docs/current/sql-altertable.html) der PostgreSQL-Dokumentation. ### Einschränkungen `ALTER TABLE` weist die folgenden Einschränkungen für unterstützte Optionen auf. **Entfernen einer Spalte** + In Sharded-Tabellen können Sie keine Spalten entfernen, die Teil des Shard-Schlüssels sind. + In Referenztabellen können Sie keine Primärschlüsselspalten entfernen. **Ändern des Datentyps einer Spalte** + Der Ausdruck `USING` wird nicht unterstützt. + In Sharded-Tabellen können Sie den Datentyp von Spalten nicht ändern, die Teil des Shard-Schlüssels sind. **Hinzufügen oder Entfernen einer Beschränkung** Einzelheiten darüber, was nicht unterstützt wird, finden Sie unter [Beschränkungen](#limitless-reference.DDL-limitations.Constraints). **Ändern des Standardwerts einer Spalte** Standardwerte werden unterstützt. Weitere Informationen finden Sie unter [Standardwerte](#limitless-reference.DDL-limitations.DefaultValues). ### Nicht unterstützte Optionen Einige Optionen werden nicht unterstützt, da sie von nicht unterstützten Features wie Auslösern abhängen. Die folgenden Optionen auf Tabellenebene für `ALTER TABLE` werden nicht unterstützt: + `ALL IN TABLESPACE` + `ATTACH PARTITION` + `DETACH PARTITION` + `ONLY`-Flag + `RENAME CONSTRAINT` Die folgenden Optionen auf Spaltenebene für `ALTER TABLE` werden nicht unterstützt: + ADD GENERATED + DROP EXPRESSION [IF EXISTS] + DROP IDENTITY [IF EXISTS] + RESET + RESTART + SET + SET COMPRESSION + SET STATISTICS ## CREATE DATABASE In Aurora PostgreSQL Limitless Database werden nur uneingeschränkte Datenbanken unterstützt. Während `CREATE DATABASE` ausgeführt wird, schlagen Datenbanken, die in einem oder mehreren Knoten erfolgreich erstellt wurden, möglicherweise in anderen Knoten fehl, da eine Datenbankerstellung ein nicht-transaktionaler Vorgang ist. In diesem Fall werden Datenbankobjekte, die erfolgreich erstellt wurden, innerhalb eines vordefinierten Zeitraums automatisch von allen Knoten entfernt, damit in der DB-Shard-Gruppe die Konsistenz erhalten bleibt. In diesem Zeitraum kann die Neuerstellung einer Datenbank mit demselben Namen zu einem Fehler führen, der darauf hinweist, dass die Datenbank bereits existiert. Die folgenden Optionen werden unterstützt: + Kollation: ``` CREATE DATABASE name WITH [LOCALE = locale] [LC_COLLATE = lc_collate] [LC_CTYPE = lc_ctype] [ICU_LOCALE = icu_locale] [ICU_RULES = icu_rules] [LOCALE_PROVIDER = locale_provider] [COLLATION_VERSION = collation_version]; ``` + `CREATE DATABASE WITH OWNER`: ``` CREATE DATABASE name WITH OWNER = user_name; ``` Die folgenden Optionen werden nicht unterstützt: + `CREATE DATABASE WITH TABLESPACE`: ``` CREATE DATABASE name WITH TABLESPACE = tablespace_name; ``` + `CREATE DATABASE WITH TEMPLATE`: ``` CREATE DATABASE name WITH TEMPLATE = template; ``` ## CREATE INDEX `CREATE INDEX CONCURRENTLY` wird für Sharded-Tabellen unterstützt: ``` CREATE INDEX CONCURRENTLY index_name ON table_name(column_name); ``` `CREATE UNIQUE INDEX` wird für alle Tabellentypen unterstützt: ``` CREATE UNIQUE INDEX index_name ON table_name(column_name); ``` `CREATE UNIQUE INDEX CONCURRENTLY` wird nicht unterstützt: ``` CREATE UNIQUE INDEX CONCURRENTLY index_name ON table_name(column_name); ``` Weitere Informationen finden Sie unter [UNIQUE](#unique-constraint). Allgemeine Informationen zum Erstellen von Indizes finden Sie im Abschnitt [CREATE INDEX](https://www.postgresql.org/docs/current/sql-createindex.html) der PostgreSQL-Dokumentation. **Anzeigen von Indizes** Nicht alle Indizes sind auf Routern sichtbar, wenn Sie `\d table_name` oder ähnliche Befehle verwenden. Verwenden Sie stattdessen die Ansicht `pg_catalog.pg_indexes`, um Indizes abzurufen, wie im folgenden Beispiel gezeigt. ``` SET rds_aurora.limitless_create_table_mode='sharded'; SET rds_aurora.limitless_create_table_shard_key='{"id"}'; CREATE TABLE items (id int PRIMARY KEY, val int); CREATE INDEX items_my_index on items (id, val); postgres_limitless=> SELECT * FROM pg_catalog.pg_indexes WHERE tablename='items'; schemaname | tablename | indexname | tablespace | indexdef ------------+-----------+----------------+------------+------------------------------------------------------------------------ public | items | items_my_index | | CREATE INDEX items_my_index ON ONLY public.items USING btree (id, val) public | items | items_pkey | | CREATE UNIQUE INDEX items_pkey ON ONLY public.items USING btree (id) (2 rows) ``` ## CREATE SCHEMA `CREATE SCHEMA` mit einem Schemaelement wird nicht unterstützt: ``` CREATE SCHEMA my_schema CREATE TABLE (column_name INT); ``` Es tritt ein Fehler auf, der in etwa folgendermaßen aussieht: ``` ERROR: CREATE SCHEMA with schema elements is not supported ``` ## CREATE TABLE Beziehungen in `CREATE TABLE`-Anweisungen werden nicht unterstützt, zum Beispiel: ``` CREATE TABLE orders (orderid int, customerId int, orderDate date) WITH (autovacuum_enabled = false); ``` `IDENTITY`-Spalten werden nicht unterstützt, zum Beispiel: ``` CREATE TABLE orders (orderid INT GENERATED ALWAYS AS IDENTITY); ``` Aurora PostgreSQL Limitless Database unterstützt bis zu 54 Zeichen für Namen von Sharded-Tabellen. ## CREATE TABLE AS Wenn Sie eine Tabelle mit `CREATE TABLE AS` erstellen möchten, müssen Sie die Variable `rds_aurora.limitless_create_table_mode` verwenden. Für Sharded-Tabellen müssen Sie außerdem die Variable `rds_aurora.limitless_create_table_shard_key` verwenden. Weitere Informationen finden Sie unter [Erstellen von Limitless-Tabellen mithilfe von Variablen](limitless-creating-config.md). ``` -- Set the variables. SET rds_aurora.limitless_create_table_mode='sharded'; SET rds_aurora.limitless_create_table_shard_key='{"a"}'; CREATE TABLE ctas_table AS SELECT 1 a; -- "source" is the source table whose columns and data types are used to create the new "ctas_table2" table. CREATE TABLE ctas_table2 AS SELECT a,b FROM source; ``` Sie können `CREATE TABLE AS` nicht zum Erstellen von Referenztabellen verwenden, da sie Primärschlüsselbeschränkungen erfordern. `CREATE TABLE AS` propagiert Primärschlüssel nicht an neue Tabellen. Allgemeine Informationen finden Sie im Abschnitt [CREATE TABLE AS](https://www.postgresql.org/docs/current/sql-createtableas.html) der PostgreSQL-Dokumentation. ## DROP DATABASE Sie können Datenbanken, die Sie erstellt haben, löschen. Der Befehl `DROP DATABASE` wird asynchron im Hintergrund ausgeführt. Während der Ausführung erhalten Sie eine Fehlermeldung, wenn Sie versuchen, eine neue Datenbank mit demselben Namen zu erstellen. ## SELECT INTO `SELECT INTO` funktioniert ähnlich wie [CREATE TABLE AS](#limitless-reference.DDL-limitations.CREATE_TABLE_AS). Sie müssen die Variable `rds_aurora.limitless_create_table_mode` verwenden. Für Sharded-Tabellen müssen Sie außerdem die Variable `rds_aurora.limitless_create_table_shard_key` verwenden. Weitere Informationen finden Sie unter [Erstellen von Limitless-Tabellen mithilfe von Variablen](limitless-creating-config.md). ``` -- Set the variables. SET rds_aurora.limitless_create_table_mode='sharded'; SET rds_aurora.limitless_create_table_shard_key='{"a"}'; -- "source" is the source table whose columns and data types are used to create the new "destination" table. SELECT * INTO destination FROM source; ``` Derzeit wird der Vorgang `SELECT INTO` über den Router ausgeführt, nicht direkt über die Shards. Dies kann die Leistung beeinträchtigen. Weitere Informationen dazu finden Sie im Abschnitt [SELECT INTO](https://www.postgresql.org/docs/current/sql-selectinto.html) der PostgreSQL-Dokumentation. ## Beschränkungen Die folgenden Einschränkungen gelten für Beschränkungen in Aurora PostgreSQL Limitless Database. **CHECK** Einfache Beschränkungen, die Vergleichsoperatoren mit Literalen beinhalten, werden unterstützt. Komplexere Ausdrücke und Beschränkungen, die Funktionsvalidierungen erfordern, werden nicht unterstützt, wie in den folgenden Beispielen gezeigt. ``` CREATE TABLE my_table ( id INT CHECK (id > 0) -- supported , val INT CHECK (val > 0 AND val < 1000) -- supported , tag TEXT CHECK (length(tag) > 0) -- not supported: throws "Expression inside CHECK constraint is not supported" , op_date TIMESTAMP WITH TIME ZONE CHECK (op_date <= now()) -- not supported: throws "Expression inside CHECK constraint is not supported" ); ``` Sie können Beschränkungen explizite Namen geben, wie im folgenden Beispiel gezeigt. ``` CREATE TABLE my_table ( id INT CONSTRAINT positive_id CHECK (id > 0) , val INT CONSTRAINT val_in_range CHECK (val > 0 AND val < 1000) ); ``` Sie können die Beschränkungssyntax auf Tabellenebene mit der Beschränkung `CHECK` verwenden, wie im folgenden Beispiel gezeigt. ``` CREATE TABLE my_table ( id INT CONSTRAINT positive_id CHECK (id > 0) , min_val INT CONSTRAINT min_val_in_range CHECK (min_val > 0 AND min_val < 1000) , max_val INT , CONSTRAINT max_val_in_range CHECK (max_val > 0 AND max_val < 1000 AND max_val > min_val) ); ``` **EXCLUDE** Ausschlussbeschränkungen werden in Aurora PostgreSQL Limitless Database nicht unterstützt. **FOREIGN KEY** Weitere Informationen finden Sie unter [Fremdschlüssel](#limitless-reference.DDL-limitations.FKs). **NOT NULL** `NOT NULL`-Beschränkungen werden uneingeschränkt unterstützt. **PRIMARY KEY** Der Primärschlüssel impliziert eindeutige Beschränkungen, weshalb die Einschränkungen für eindeutige Beschränkungen auch für den Primärschlüssel gelten. Das bedeutet Folgendes: + Wenn eine Tabelle in eine Sharded-Tabelle konvertiert wird, muss der Shard-Schlüssel eine Teilmenge des Primärschlüssels sein. Das heißt, der Primärschlüssel enthält alle Spalten des Shard-Schlüssels. + Wenn eine Tabelle in eine Referenztabelle konvertiert wird, muss sie einen Primärschlüssel haben. Die folgenden Beispiele veranschaulichen die Verwendung von Primärschlüsseln. ``` -- Create a standard table. CREATE TABLE public.my_table ( item_id INT , location_code INT , val INT , comment text ); -- Change the table to a sharded table using the 'item_id' and 'location_code' columns as shard keys. CALL rds_aurora.limitless_alter_table_type_sharded('public.my_table', ARRAY['item_id', 'location_code']); ``` Hier wird versucht, einen Primärschlüssel hinzuzufügen, der keinen Shard-Schlüssel enthält: ``` -- Add column 'item_id' as the primary key. -- Invalid because the primary key doesnt include all columns from the shard key: -- 'location_code' is part of the shard key but not part of the primary key ALTER TABLE public.my_table ADD PRIMARY KEY (item_id); -- ERROR -- add column "val" as primary key -- Invalid because primary key does not include all columns from shard key: -- item_id and location_code iare part of shard key but not part of the primary key ALTER TABLE public.my_table ADD PRIMARY KEY (item_id); -- ERROR ``` Hier wird versucht, einen Primärschlüssel hinzuzufügen, der einen Shard-Schlüssel enthält: ``` -- Add the 'item_id' and 'location_code' columns as the primary key. -- Valid because the primary key contains the shard key. ALTER TABLE public.my_table ADD PRIMARY KEY (item_id, location_code); -- OK -- Add the 'item_id', 'location_code', and 'val' columns as the primary key. -- Valid because the primary key contains the shard key. ALTER TABLE public.my_table ADD PRIMARY KEY (item_id, location_code, val); -- OK ``` In diesem Beispiel wird eine Standardtabelle in eine Referenztabelle konvertiert: ``` -- Create a standard table. CREATE TABLE zipcodes (zipcode INT PRIMARY KEY, details VARCHAR); -- Convert the table to a reference table. CALL rds_aurora.limitless_alter_table_type_reference('public.zipcode'); ``` Weitere Informationen zum Erstellen von Sharded-Tabellen und Referenztabellen finden Sie unter [Erstellen von Tabellen in Aurora PostgreSQL Limitless Database](limitless-creating.md). **UNIQUE** In Sharded-Tabellen muss der eindeutige Schlüssel den Shard-Schlüssel enthalten, das heißt, der Shard-Schlüssel muss eine Teilmenge des eindeutigen Schlüssels sein. Dies wird überprüft, wenn der Tabellentyp in „Sharded“ geändert wird. In Referenztabellen gibt es keine Einschränkung. ``` CREATE TABLE customer ( customer_id INT NOT NULL , zipcode INT , email TEXT UNIQUE ); ``` `UNIQUE`-Beschränkungen auf Tabellenebene werden unterstützt, wie im folgenden Beispiel gezeigt. ``` CREATE TABLE customer ( customer_id INT NOT NULL , zipcode INT , email TEXT , CONSTRAINT zipcode_and_email UNIQUE (zipcode, email) ); ``` Das folgende Beispiel zeigt die gemeinsame Verwendung eines Primärschlüssels und eines eindeutigen Schlüssels. Beide Schlüssel müssen den Shard-Schlüssel enthalten. ``` SET rds_aurora.limitless_create_table_mode='sharded'; SET rds_aurora.limitless_create_table_shard_key='{"p_id"}'; CREATE TABLE t1 ( p_id BIGINT NOT NULL, c_id BIGINT NOT NULL, PRIMARY KEY (p_id), UNIQUE (p_id, c_id) ); ``` Weitere Informationen finden Sie im Abschnitt [Beschränkungen](https://www.postgresql.org/docs/current/ddl-constraints.html) der PostgreSQL-Dokumentation. ## Standardwerte Aurora PostgreSQL Limitless Database unterstützt Ausdrücke in Standardwerten. Das folgende Beispiel veranschaulicht die Verwendung von Standardwerten. ``` CREATE TABLE t ( a INT DEFAULT 5, b TEXT DEFAULT 'NAN', c NUMERIC ); CALL rds_aurora.limitless_alter_table_type_sharded('t', ARRAY['a']); INSERT INTO t DEFAULT VALUES; SELECT * FROM t; a | b | c ---+-----+--- 5 | NAN | (1 row) ``` Ausdrücke werden unterstützt, wie im folgenden Beispiel gezeigt. ``` CREATE TABLE t1 (a NUMERIC DEFAULT random()); ``` Im folgenden Beispiel wird eine neue Spalte hinzugefügt, die `NOT NULL` ist und einen Standardwert hat. ``` ALTER TABLE t ADD COLUMN d BOOLEAN NOT NULL DEFAULT FALSE; SELECT * FROM t; a | b | c | d ---+-----+---+--- 5 | NAN | | f (1 row) ``` Im folgenden Beispiel wird eine vorhandene Spalte geändert und ein Standardwert hinzugefügt. ``` ALTER TABLE t ALTER COLUMN c SET DEFAULT 0.0; INSERT INTO t DEFAULT VALUES; SELECT * FROM t; a | b | c | d ---+-----+-----+----- 5 | NAN | | f 5 | NAN | 0.0 | f (2 rows) ``` Im folgenden Beispiel wird ein Standardwert entfernt. ``` ALTER TABLE t ALTER COLUMN a DROP DEFAULT; INSERT INTO t DEFAULT VALUES; SELECT * FROM t; a | b | c | d ---+-----+-----+----- 5 | NAN | | f 5 | NAN | 0.0 | f | NAN | 0.0 | f (3 rows) ``` Weitere Informationen finden Sie im Abschnitt [Standardwerte](https://www.postgresql.org/docs/current/ddl-default.html) der PostgreSQL-Dokumentation. ## Erweiterungen Die folgenden PostgreSQL-Erweiterungen werden in Aurora PostgreSQL Limitless Database unterstützt: + `aurora_limitless_fdw`: Diese Erweiterung ist vorinstalliert. Sie können sie nicht löschen. + `aws_s3`: Diese Erweiterung funktioniert in Aurora PostgreSQL Limitless Database ähnlich wie in Aurora PostgreSQL. Sie können Daten aus einem Amazon-S3-Bucket in den DB-Cluster einer Aurora PostgreSQL Limitless Database importieren oder Daten aus dem DB-Cluster einer Aurora PostgreSQL Limitless Database in einen Amazon-S3-Bucket exportieren. Weitere Informationen erhalten Sie unter [Importieren von Amazon S3 in einen Aurora-PostgreSQL-DB-Cluster](USER_PostgreSQL.S3Import.md) und [Exportieren von Daten aus einem/einer Aurora PostgreSQL-DB-Cluster zu Amazon S3](postgresql-s3-export.md). + `btree_gin` + `citext` + `ip4r` + `pg_buffercache`: Diese Erweiterung verhält sich in Aurora PostgreSQL Limitless Database anders als in der PostgreSQL-Community. Weitere Informationen finden Sie unter [pg\$1buffercache-Unterschiede in Aurora PostgreSQL Limitless Database](#limitless-reference.DDL-limitations.Extensions.pg_buffercache). + `pg_stat_statements` + `pg_trgm` + `pgcrypto` + `pgstattuple`: Diese Erweiterung verhält sich in Aurora PostgreSQL Limitless Database anders als in der PostgreSQL-Community. Weitere Informationen finden Sie unter [pgstattuple-Unterschiede in Aurora PostgreSQL Limitless Database](#limitless-reference.DDL-limitations.Extensions.pgstattuple). + `pgvector` + `plpgsql`: Diese Erweiterung ist vorinstalliert, aber Sie können sie löschen. + `PostGIS`: Lange Transaktionen und Tabellenverwaltungsfunktionen werden nicht unterstützt. Die Geo-Referenztabelle lässt sich nicht ändern. + `unaccent` + `uuid` Die meisten PostgreSQL-Erweiterungen werden in Aurora PostgreSQL Limitless Database derzeit nicht unterstützt. Sie können jedoch weiterhin die Konfigurationseinstellung [shared\$1preload\$1libraries](https://www.postgresql.org/docs/current/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-PRELOAD) (SPL) verwenden, um Erweiterungen in den Cluster der primären Aurora PostgreSQL-Datenbank zu laden. Sie werden auch in die Aurora PostgreSQL Limitless Database geladen, funktionieren dort aber möglicherweise nicht richtig. So können Sie beispielsweise die Erweiterung `pg_hint_plan` zwar laden, es bleibt aber ungewiss, ob die in den Abfragekommentaren übergebenen Hinweise verwendet werden. **Anmerkung** Sie können keine Objekte ändern, die der Erweiterung [pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html) zugeordnet sind. Informationen zur Installation von `pg_stat_statements` finden Sie unter [limitless\$1stat\$1statements](limitless-monitoring-views.md#limitless_stat_statements). Sie können die Funktionen `pg_available_extensions` und `pg_available_extension_versions` verwenden, um die Erweiterungen zu finden, die in Aurora PostgreSQL Limitless Database unterstützt werden. Die folgenden DDLs werden für Erweiterungen unterstützt: **CREATE EXTENSION** Sie können Erweiterungen wie in PostgreSQL erstellen. ``` CREATE EXTENSION [ IF NOT EXISTS ] extension_name [ WITH ] [ SCHEMA schema_name ] [ VERSION version ] [ CASCADE ] ``` Weitere Informationen finden Sie im Abschnitt [CREATE EXTENSION](https://www.postgresql.org/docs/current/sql-createextension.html) der PostgreSQL-Dokumentation. **ALTER EXTENSION** Die folgenden DDLs werden unterstützt: ``` ALTER EXTENSION name UPDATE [ TO new_version ] ALTER EXTENSION name SET SCHEMA new_schema ``` Weitere Informationen finden Sie im Abschnitt [ALTER EXTENSION](https://www.postgresql.org/docs/current/sql-alterextension.html) der PostgreSQL-Dokumentation. **DROP EXTENSION** Sie können Erweiterungen wie in PostgreSQL löschen. ``` DROP EXTENSION [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ] ``` Weitere Informationen finden Sie im Abschnitt [DROP EXTENSION](https://www.postgresql.org/docs/current/sql-dropextension.html) der PostgreSQL-Dokumentation. Die folgenden DDLs werden für Erweiterungen nicht unterstützt: **ALTER EXTENSION** Sie können keine Mitgliedsobjekte zu Erweiterungen hinzufügen oder daraus löschen. ``` ALTER EXTENSION name ADD member_object ALTER EXTENSION name DROP member_object ``` ### pg\$1buffercache-Unterschiede in Aurora PostgreSQL Limitless Database Wenn Sie in Aurora PostgreSQL Limitless Database die Erweiterung [pg\$1buffercache](https://www.postgresql.org/docs/current/pgbuffercache.html) installieren und die Ansicht `pg_buffercache` verwenden, erhalten Sie pufferbezogene Informationen nur von dem Knoten, mit dem Sie gerade verbunden sind: dem Router. Ähnlich erhalten Sie bei Verwendung der Funktion `pg_buffercache_summary` oder `pg_buffercache_usage_counts` nur Informationen vom verbundenen Knoten. Sie können über zahlreiche Knoten verfügen und müssen möglicherweise für jeden Knoten einzeln auf Pufferinformationen zugreifen, um Probleme effektiv zu diagnostizieren. Daher stellt Limitless Database die folgenden Funktionen bereit: + `rds_aurora.limitless_pg_buffercache(subcluster_id)` + `rds_aurora.limitless_pg_buffercache_summary(subcluster_id)` + `rds_aurora.limitless_pg_buffercache_usage_counts(subcluster_id)` Durch Eingabe der Subcluster-ID eines beliebigen Knotens, unabhängig davon, ob es sich um einen Router oder einen Shard handelt, können Sie einfach auf die für diesen Knoten spezifischen Pufferinformationen zugreifen. Diese Funktionen sind direkt verfügbar, wenn Sie die Erweiterung `pg_buffercache` in Limitless Database installieren. **Anmerkung** Aurora PostgreSQL Limitless Database unterstützt diese Funktionen für Version 1.4 und höher der Erweiterung `pg_buffercache`. Die in der Ansicht `limitless_pg_buffercache` angezeigten Spalten unterscheiden sich geringfügig von denen in der Ansicht `pg_buffercache`: + `bufferid`: bleibt unverändert gegenüber `pg_buffercache` + `relname`: Anstatt wie in `pg_buffercache` die Dateiknotennummer anzuzeigen, bildet `limitless_pg_buffercache` den zugehörigen `relname` ab, sofern dieser Name in der aktuellen Datenbank oder in gemeinsam genutzten Systemkatalogen verfügbar ist. Andernfalls wird `NULL` angezeigt. + `parent_relname`: In dieser neuen Spalte, die in `pg_buffercache` nicht vorhanden ist, wird der übergeordnete `relname` angezeigt, wenn der Wert in der Spalte `relname` eine partitionierte Tabelle darstellt (im Fall von Sharded-Tabellen). Andernfalls wird `NULL` angezeigt. + `spcname`: Anstatt wie in `pg_buffercache` den Tablespace-Objektbezeichner (OID) anzuzeigen, bildet `limitless_pg_buffercache` den Tablespace-Namen ab. + `datname`: Anstatt wie in `pg_buffercache` die Datenbank-OID anzuzeigen, bildet `limitless_pg_buffercache` den Datenbanknamen ab. + `relforknumber`: bleibt unverändert gegenüber `pg_buffercache` + `relblocknumber`: bleibt unverändert gegenüber `pg_buffercache` + `isdirty`: bleibt unverändert gegenüber `pg_buffercache` + `usagecount`: bleibt unverändert gegenüber `pg_buffercache` + `pinning_backends`: bleibt unverändert gegenüber `pg_buffercache` Die Spalten in den Ansichten `limitless_pg_buffercache_summary` und `limitless_pg_buffercache_usage_counts` sind dieselben wie in den regulären Ansichten `pg_buffercache_summary` und `pg_buffercache_usage_counts`. Mithilfe dieser Funktionen können Sie auf detaillierte Informationen zum Puffercache aller Knoten in Ihrer Limitless-Database-Umgebung zugreifen und so eine effektivere Diagnose und Verwaltung Ihrer Datenbanksysteme ermöglichen. ### pgstattuple-Unterschiede in Aurora PostgreSQL Limitless Database In Aurora PostgreSQL unterstützt die Erweiterung [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html) derzeit keine Fremdtabellen, partitionierten Tabellen oder partitionierten Indizes. In Aurora PostgreSQL Limitless Database gehören jedoch häufig von Benutzern erstellte Objekte zu diesen nicht unterstützten Typen. Zwar gibt es reguläre Tabellen und Indizes (z. B. Katalogtabellen und ihre Indizes), aber die meisten Objekte befinden sich auf fremden Knoten, was sie zu Fremdobjekten für den Router macht. Wir wissen, wie wichtig diese Erweiterung für das Abrufen von Statistiken auf Tupel-Ebene ist – eine wichtige Voraussetzung, um Tabellen- und Indexüberlastungen vermeiden und Diagnoseinformationen erfassen zu können. Daher unterstützt Aurora PostgreSQL Limitless Database die Erweiterung `pgstattuple` in unbegrenzten Datenbanken. Aurora PostgreSQL Limitless Database enthält die folgenden Funktionen im Schema `rds_aurora`: **Funktionen für Statistiken auf Tupel-Ebene** **`rds_aurora.limitless_pgstattuple(relation_name)`** + Zweck: Statistiken auf Tupel-Ebene für Standardtabellen und deren Indizes extrahieren + Eingabe: `relation_name` (Text): der Beziehungsname + Ausgabe: Spalten, die mit denen übereinstimmen, die von der Funktion `pgstattuple` in Aurora PostgreSQL zurückgegeben werden **`rds_aurora.limitless_pgstattuple(relation_name, subcluster_id)`** + Zweck: Statistiken auf Tupel-Ebene für Referenztabellen, Sharded-Tabellen, Katalogtabellen und deren Indizes extrahieren + Eingabe: + `relation_name` (Text): der Beziehungsname + `subcluster_id` (Text): die Subcluster-ID des Knotens, auf dem die Statistiken extrahiert werden sollen + Ausgabe: + Bei Referenz- und Katalogtabellen (einschließlich ihrer Indizes) stimmen die Spalten mit denen in Aurora PostgreSQL überein. + Bei Sharded-Tabellen stellen die Statistiken nur die Partition der Tabelle dar, die sich auf dem angegebenen Subcluster befindet. **Funktionen für Indexstatistiken** **`rds_aurora.limitless_pgstatindex(relation_name)`** + Zweck: Statistiken für B-Baum-Indizes von Standardtabellen extrahieren + Eingabe: `relation_name` (Text): der Name des B-Baum-Indexes + Ausgabe: Alle Spalten außer `root_block_no` werden zurückgegeben. Die zurückgegebenen Spalten stimmen mit denen überein, die die Funktion `pgstatindex` in Aurora PostgreSQL liefert. **`rds_aurora.limitless_pgstatindex(relation_name, subcluster_id)`** + Zweck: Statistiken für B-Baum-Indizes von Referenz-, Sharded- und Katalogtabellen extrahieren + Eingabe: + `relation_name` (Text): der Name des B-Baum-Indexes + `subcluster_id` (Text): die Subcluster-ID des Knotens, auf dem die Statistiken extrahiert werden sollen + Ausgabe: + Bei Indizes von Referenz- und Katalogtabellen werden alle Spalten (außer `root_block_no`) zurückgegeben. Die zurückgegebenen Spalten stimmen mit denen in Aurora PostgreSQL überein. + Bei Sharded-Tabellen stellen die Statistiken nur die Partition des Indexes der Tabelle dar, die sich auf dem angegebenen Subcluster befindet. Die Spalte `tree_level` zeigt den Durchschnitt aller Tabellenausschnitte im angeforderten Subcluster. **`rds_aurora.limitless_pgstatginindex(relation_name)`** + Zweck: Statistiken für GINs (Generalized Inverted Indexes) von Standardtabellen extrahieren + Eingabe: `relation_name` (Text): der Name des GIN + Ausgabe: Spalten, die mit denen übereinstimmen, die von der Funktion `pgstatginindex` in Aurora PostgreSQL zurückgegeben werden **`rds_aurora.limitless_pgstatginindex(relation_name, subcluster_id)`** + Zweck: Statistiken für GINs von Referenz-, Sharded- und Katalogtabellen extrahieren + Eingabe: + `relation_name` (Text): der Name des Indexes + `subcluster_id` (Text): die Subcluster-ID des Knotens, auf dem die Statistiken extrahiert werden sollen + Ausgabe: + Bei GINs von Referenz- und Katalogtabellen stimmen die Spalten mit denen in Aurora PostgreSQL überein. + Bei Sharded-Tabellen stellen die Statistiken nur die Partition des Indexes der Tabelle dar, die sich auf dem angegebenen Subcluster befindet. **`rds_aurora.limitless_pgstathashindex(relation_name)`** + Zweck: Statistiken für Hash-Indizes von Standardtabellen extrahieren + Eingabe: `relation_name` (Text): der Name des Hash-Indexes + Ausgabe: Spalten, die mit denen übereinstimmen, die von der Funktion `pgstathashindex` in Aurora PostgreSQL zurückgegeben werden **`rds_aurora.limitless_pgstathashindex(relation_name, subcluster_id)`** + Zweck: Statistiken für Hash-Indizes von Referenz-, Sharded- und Katalogtabellen extrahieren + Eingabe: + `relation_name` (Text): der Name des Indexes + `subcluster_id` (Text): die Subcluster-ID des Knotens, auf dem die Statistiken extrahiert werden sollen + Ausgabe: + Bei Hash-Indizes von Referenz- und Katalogtabellen stimmen die Spalten mit denen in Aurora PostgreSQL überein. + Bei Sharded-Tabellen stellen die Statistiken nur die Partition des Indexes der Tabelle dar, die sich auf dem angegebenen Subcluster befindet. **Funktionen zur Seitenanzahl** **`rds_aurora.limitless_pg_relpages(relation_name)`** + Zweck: die Seitenanzahl für Standardtabellen und deren Indizes extrahieren + Eingabe: `relation_name` (Text): der Beziehungsname + Ausgabe: die Seitenanzahl der angegebenen Beziehung **`rds_aurora.limitless_pg_relpages(relation_name, subcluster_id)`** + Zweck: die Seitenanzahl für Referenz-, Sharded- und Katalogtabellen (einschließlich ihrer Indizes) extrahieren + Eingabe: + `relation_name` (Text): der Beziehungsname + `subcluster_id` (Text): die Subcluster-ID des Knotens, auf dem die Seitenanzahl extrahiert werden soll + Ausgabe: Bei Sharded-Tabellen entspricht die Seitenanzahl der Summe der Seiten aus allen Tabellenausschnitten des angegebenen Subclusters. **Funktionen für annähernde Statistiken auf Tupel-Ebene** **`rds_aurora.limitless_pgstattuple_approx(relation_name)`** + Zweck: annähernde Statistiken auf Tupel-Ebene für Standardtabellen und deren Indizes extrahieren + Eingabe: `relation_name` (Text): der Beziehungsname + Ausgabe: Spalten, die mit denen übereinstimmen, die von der Funktion pgstattuple\$1approx in Aurora PostgreSQL zurückgegeben werden **`rds_aurora.limitless_pgstattuple_approx(relation_name, subcluster_id)`** + Zweck: annähernde Statistiken auf Tupel-Ebene für Referenz-, Sharded- und Katalogtabellen (sowie deren Indizes) extrahieren + Eingabe: + `relation_name` (Text): der Beziehungsname + `subcluster_id` (Text): die Subcluster-ID des Knotens, auf dem die Statistiken extrahiert werden sollen + Ausgabe: + Bei Referenz- und Katalogtabellen (einschließlich ihrer Indizes) stimmen die Spalten mit denen in Aurora PostgreSQL überein. + Bei Sharded-Tabellen stellen die Statistiken nur die Partition der Tabelle dar, die sich auf dem angegebenen Subcluster befindet. **Anmerkung** Derzeit unterstützt Aurora PostgreSQL Limitless Database die Erweiterung `pgstattuple` für materialisierte Ansichten, TOAST-Tabellen oder temporäre Tabellen nicht. In Aurora PostgreSQL Limitless Database müssen Sie die Eingabe als Text bereitstellen, obwohl Aurora PostgreSQL auch andere Formate unterstützt. ## Fremdschlüssel Beschränkungen bezüglich Fremdschlüsseln (`FOREIGN KEY`) werden mit einigen Einschränkungen unterstützt: + `CREATE TABLE` mit `FOREIGN KEY` wird nur für Standardtabellen unterstützt. Wenn Sie `FOREIGN KEY` verwenden möchten, um eine Sharded- oder Referenztabelle anzufertigen, erstellen Sie zunächst die Tabelle ohne Fremdschlüsselbeschränkung. Ändern Sie sie dann mit der folgenden Anweisung: ``` ALTER TABLE ADD CONSTRAINT; ``` + Eine Standardtabelle kann nicht in eine Sharded- oder Referenztabelle konvertiert werden, wenn für die Tabelle eine Fremdschlüsselbeschränkung gilt. Löschen Sie die Beschränkung und fügen Sie sie nach der Konvertierung hinzu. + Die folgenden Einschränkungen gelten für die verschiedenen Tabellentypen, was Fremdschlüsselbeschränkungen betrifft: + Für eine Standardtabelle kann eine Fremdschlüsselbeschränkung hinsichtlich einer anderen Standardtabelle gelten. + Für eine Sharded-Tabelle kann eine Fremdschlüsselbeschränkung gelten, wenn die übergeordneten und untergeordneten Tabellen nebeneinander angeordnet sind und der Fremdschlüssel eine Obermenge des Shard-Schlüssels bildet. + Für eine Sharded-Tabelle kann eine Fremdschlüsselbeschränkung hinsichtlich einer Referenztabelle gelten. + Für eine Referenztabelle kann eine Fremdschlüsselbeschränkung hinsichtlich einer anderen Referenztabelle gelten. **Topics** + [ ### Fremdschlüsseloptionen ](#limitless-reference.DDL-limitations.FKs.options) + [ ### Beispiele ](#limitless-reference.DDL-limitations.FKs.examples) ### Fremdschlüsseloptionen Fremdschlüssel werden in Aurora PostgreSQL Limitless Database für einige DDL-Optionen unterstützt. In der folgenden Tabelle sind Optionen aufgeführt, die zwischen Tabellen in Aurora PostgreSQL Limitless Database unterstützt und nicht unterstützt werden. | DDL-Option | Referenz zu Referenz | Sharded zu Sharded (nebeneinander angeordnet) | Sharded zu Referenz | Standard zu Standard | | --- | --- | --- | --- | --- | | `DEFERRABLE` | Ja | Ja | Ja | Ja | | `INITIALLY DEFERRED` | Ja | Ja | Ja | Ja | | `INITIALLY IMMEDIATE` | Ja | Ja | Ja | Ja | | `MATCH FULL` | Ja | Ja | Ja | Ja | | `MATCH PARTIAL` | Nein | Nein | Nein | Nein | | `MATCH SIMPLE` | Ja | Ja | Ja | Ja | | `NOT DEFERRABLE` | Ja | Ja | Ja | Ja | | `NOT VALID` | Ja | Nein | Nein | Ja | | `ON DELETE CASCADE` | Ja | Ja | Ja | Ja | | `ON DELETE NO ACTION` | Ja | Ja | Ja | Ja | | `ON DELETE RESTRICT` | Ja | Ja | Ja | Ja | | `ON DELETE SET DEFAULT` | Nein | Nein | Nein | Nein | | `ON DELETE SET NULL` | Ja | Nein | Nein | Ja | | `ON UPDATE CASCADE` | Nein | Nein | Nein | Ja | | `ON UPDATE NO ACTION` | Ja | Ja | Ja | Ja | | `ON UPDATE RESTRICT` | Ja | Ja | Ja | Ja | | `ON UPDATE SET DEFAULT` | Nein | Nein | Nein | Nein | | `ON UPDATE SET NULL` | Ja | Nein | Nein | Ja | ### Beispiele + Standard zu Standard: ``` set rds_aurora.limitless_create_table_mode='standard'; CREATE TABLE products( product_no integer PRIMARY KEY, name text, price numeric ); CREATE TABLE orders ( order_id integer PRIMARY KEY, product_no integer REFERENCES products (product_no), quantity integer ); SELECT constraint_name, table_name, constraint_type FROM information_schema.table_constraints WHERE constraint_type='FOREIGN KEY'; constraint_name | table_name | constraint_type -------------------------+-------------+----------------- orders_product_no_fkey | orders | FOREIGN KEY (1 row) ``` + Sharded zu Sharded (nebeneinander angeordnet): ``` set rds_aurora.limitless_create_table_mode='sharded'; set rds_aurora.limitless_create_table_shard_key='{"product_no"}'; CREATE TABLE products( product_no integer PRIMARY KEY, name text, price numeric ); set rds_aurora.limitless_create_table_shard_key='{"order_id"}'; set rds_aurora.limitless_create_table_collocate_with='products'; CREATE TABLE orders ( order_id integer PRIMARY KEY, product_no integer, quantity integer ); ALTER TABLE orders ADD CONSTRAINT order_product_fk FOREIGN KEY (product_no) REFERENCES products (product_no); ``` + Sharded zu Referenz: ``` set rds_aurora.limitless_create_table_mode='reference'; CREATE TABLE products( product_no integer PRIMARY KEY, name text, price numeric ); set rds_aurora.limitless_create_table_mode='sharded'; set rds_aurora.limitless_create_table_shard_key='{"order_id"}'; CREATE TABLE orders ( order_id integer PRIMARY KEY, product_no integer, quantity integer ); ALTER TABLE orders ADD CONSTRAINT order_product_fk FOREIGN KEY (product_no) REFERENCES products (product_no); ``` + Referenz zu Referenz: ``` set rds_aurora.limitless_create_table_mode='reference'; CREATE TABLE products( product_no integer PRIMARY KEY, name text, price numeric ); CREATE TABLE orders ( order_id integer PRIMARY KEY, product_no integer, quantity integer ); ALTER TABLE orders ADD CONSTRAINT order_product_fk FOREIGN KEY (product_no) REFERENCES products (product_no); ``` ## Funktionen Funktionen werden in Aurora PostgreSQL Limitless Database unterstützt. Die folgenden DDLs werden für Funktionen unterstützt: **CREATE FUNCTION** Mit diesem Befehl können Sie Funktionen wie in Aurora PostgreSQL erstellen. Sie können damit nur nicht ihre Volatilität ändern, während Sie sie ersetzen. Weitere Informationen finden Sie im Abschnitt [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) der PostgreSQL-Dokumentation. **ALTER FUNCTION** Mit diesem Befehl können Sie Funktionen wie in Aurora PostgreSQL ändern, nur nicht ihre Volatilität. Weitere Informationen finden Sie im Abschnitt [ALTER FUNCTION](https://www.postgresql.org/docs/current/sql-alterfunction.html) der PostgreSQL-Dokumentation. **DROP FUNCTION** Sie können Funktionen wie in Aurora PostgreSQL löschen. ``` DROP FUNCTION [ IF EXISTS ] name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] [, ...] [ CASCADE | RESTRICT ] ``` Weitere Informationen finden Sie im Abschnitt [DROP FUNCTION](https://www.postgresql.org/docs/current/sql-dropfunction.html) der PostgreSQL-Dokumentation. **Topics** + [ ### Verteilung der Funktionen ](#limitless-function-distribution) + [ ### Funktionsvolatilität ](#limitless-function-volatility) ### Verteilung der Funktionen Wenn alle Anweisungen einer Funktion auf einen einzelnen Shard ausgerichtet sind, empfiehlt es sich, die gesamte Funktion auf den Ziel-Shard zu übertragen. Auf diese Weise wird das Ergebnis zurück an den Router propagiert und die Funktion wird nicht am Router selbst aufgedröselt. Die Pushdown-Option für Funktionen und gespeicherte Verfahren ist nützlich für Kunden, die ihre Funktion oder ihr gespeichertes Verfahren näher an der Datenquelle, also dem Shard, ausführen möchten. Um eine Funktion zu verteilen, müssen Sie sie zuerst erstellen und dann das Verfahren `rds_aurora.limitless_distribute_function` aufrufen. Für diese Funktion gilt folgende Syntax: ``` SELECT rds_aurora.limitless_distribute_function('function_prototype', ARRAY['shard_key'], 'collocating_table'); ``` Die Funktion nutzt die folgenden Parameter: + `function_prototype`: die Funktion, die verteilt werden soll. Erwähnen Sie nur die Eingabeargumente und keines der Ausgabeargumente. Wenn eines der Argumente als `OUT`-Parameter definiert ist, nehmen Sie seinen Typ nicht in die Argumente von `function_prototype` auf. + `ARRAY['shard_key']`: die Liste der Funktionsargumente, die als Shard-Schlüssel für die Funktion identifiziert wurden + `collocating_table`: die Sharded-Tabelle, die den Datenbereich auf dem Ziel-Shard enthält Um den Shard zu identifizieren, auf dem diese Funktion ausgeführt werden soll, hasht das System das Argument `ARRAY['shard_key']` und erkennt in `collocating_table` den Shard, der den Bereich mit diesem Hash-Wert hostet. **Einschränkungen** Wenn Sie eine Funktion oder ein Verfahren verteilen, befasst sie oder es sich nur mit Daten, die durch den Shard-Schlüsselbereich in diesem Shard begrenzt sind. In Fällen, in denen Funktionen oder Verfahren versuchen, auf Daten von einem anderen Shard zuzugreifen, unterscheiden sich die von den verteilten Funktionen oder Verfahren zurückgegeben Ergebnisse von denen der nicht verteilten Funktionen oder Verfahren. Sie erstellen beispielsweise eine Funktion, die Abfragen enthält, die mehrere Shards betreffen werden, rufen dann aber das Verfahren `rds_aurora.limitless_distribute_function` auf, um sie zu verteilen. Wenn Sie diese Funktion aufrufen, indem Sie Argumente für einen Shard-Schlüssel angeben, werden die Ergebnisse ihrer Ausführung wahrscheinlich durch die in diesem Shard vorhandenen Werte begrenzt. Die Ergebnisse unterscheiden sich von denen, die ohne Verteilung der Funktion generiert wurden. **Beispiele** Nehmen wir an, wir haben die Funktion `func`, die Sharded-Tabelle `customers` und den Shard-Schlüssel `customer_id`. ``` postgres_limitless=> CREATE OR REPLACE FUNCTION func(c_id integer, sc integer) RETURNS int language SQL volatile AS $$ UPDATE customers SET score = sc WHERE customer_id = c_id RETURNING score; $$; ``` Jetzt verteilen wir diese Funktion: ``` SELECT rds_aurora.limitless_distribute_function('func(integer, integer)', ARRAY['c_id'], 'customers'); ``` Im Folgenden sehen Sie Beispiel-Abfragepläne. ``` EXPLAIN(costs false, verbose true) SELECT func(27+1,10); QUERY PLAN -------------------------------------------------- Foreign Scan Output: (func((27 + 1), 10)) Remote SQL: SELECT func((27 + 1), 10) AS func Single Shard Optimized (4 rows) ``` ``` EXPLAIN(costs false, verbose true) SELECT * FROM customers,func(customer_id, score) WHERE customer_id=10 AND score=27; QUERY PLAN --------------------------------------------------------------------- Foreign Scan Output: customer_id, name, score, func Remote SQL: SELECT customers.customer_id, customers.name, customers.score, func.func FROM public.customers, LATERAL func(customers.customer_id, customers.score) func(func) WHERE ((customers.customer_id = 10) AND (customers.score = 27)) Single Shard Optimized (10 rows) ``` Das folgende Beispiel zeigt ein Verfahren mit `IN`- und `OUT`-Parametern als Argumente. ``` CREATE OR REPLACE FUNCTION get_data(OUT id INTEGER, IN arg_id INT) AS $$ BEGIN SELECT customer_id, INTO id FROM customer WHERE customer_id = arg_id; END; $$ LANGUAGE plpgsql; ``` Das folgende Beispiel verteilt das Verfahren nur unter Verwendung von `IN`-Parametern. ``` EXPLAIN(costs false, verbose true) SELECT * FROM get_data(1); QUERY PLAN ----------------------------------- Foreign Scan Output: id Remote SQL: SELECT customer_id FROM get_data(1) get_data(id) Single Shard Optimized (6 rows) ``` ### Funktionsvolatilität Sie können feststellen, ob eine Funktion unveränderlich, stabil oder volatil ist, indem Sie den Wert `provolatile` in der Ansicht [pg\$1proc](https://www.postgresql.org/docs/current/catalog-pg-proc.html) überprüfen. Der Wert `provolatile` gibt an, ob das Ergebnis der Funktion nur von ihren Eingabeargumenten abhängt oder auch von externen Faktoren beeinflusst wird. Der Wert ist einer der folgenden: + `i`: unveränderliche Funktionen, die immer dasselbe Ergebnis für dieselben Eingaben liefern + `s`: stabile Funktionen, deren Ergebnisse (für feste Eingaben) sich innerhalb eines Scans nicht ändern + `v`: flüchtige Funktionen, deren Ergebnisse sich jederzeit ändern können Nutzen Sie `v` auch für Funktionen mit Nebeneffekten, sodass deren Aufrufe nicht einfach optimiert werden können. Die folgenden Beispiele zeigen flüchtige Funktionen. ``` SELECT proname, provolatile FROM pg_proc WHERE proname='pg_sleep'; proname | provolatile ----------+------------- pg_sleep | v (1 row) SELECT proname, provolatile FROM pg_proc WHERE proname='uuid_generate_v4'; proname | provolatile ------------------+------------- uuid_generate_v4 | v (1 row) SELECT proname, provolatile FROM pg_proc WHERE proname='nextval'; proname | provolatile ---------+------------- nextval | v (1 row) ``` Die Volatilität einer vorhandenen Funktion lässt sich in Aurora PostgreSQL Limitless Database nicht ändern. Dies gilt gleichermaßen für Befehle des Typs `ALTER FUNCTION` und des Typs `CREATE OR REPLACE FUNCTION`, wie in den folgenden Beispielen gezeigt. ``` -- Create an immutable function CREATE FUNCTION immutable_func1(name text) RETURNS text language plpgsql AS $$ BEGIN RETURN name; END; $$IMMUTABLE; -- Altering the volatility throws an error ALTER FUNCTION immutable_func1 STABLE; -- Replacing the function with altered volatility throws an error CREATE OR REPLACE FUNCTION immutable_func1(name text) RETURNS text language plpgsql AS $$ BEGIN RETURN name; END; $$VOLATILE; ``` Wir empfehlen Ihnen dringend, Funktionen die richtigen Volatilitäten zuzuweisen. Wenn Ihre Funktion beispielsweise `SELECT` aus mehreren Tabellen verwendet oder auf Datenbankobjekte verweist, legen Sie sie nicht als `IMMUTABLE` fest. Wenn sich der Tabelleninhalt jemals ändert, geht damit die Unveränderlichkeit verloren. Aurora PostgreSQL erlaubt `SELECT` innerhalb von unveränderlichen Funktionen, aber die Ergebnisse könnten falsch sein. Aurora PostgreSQL Limitless Database kann sowohl Fehler als auch falsche Ergebnisse zurückgeben. Weitere Informationen finden Sie im Abschnitt [Volatilitätskategorien von Funktionen](https://www.postgresql.org/docs/current/xfunc-volatility.html) der PostgreSQL-Dokumentation. ## Sequenzen Benannte Sequenzen sind Datenbankobjekte, die eindeutige Zahlen in auf- oder absteigender Reihenfolge generieren. `CREATE SEQUENCE` erstellt einen Generator für neue Sequenznummern. Sequenzwerte sind garantiert eindeutig. Wenn Sie eine benannte Sequenz in Aurora PostgreSQL Limitless Database erstellen, wird ein verteiltes Sequenzobjekt erstellt. Daraufhin verteilt Aurora PostgreSQL Limitless Database nicht überlappende Blöcke von Sequenzwerten auf alle Distributed Transaction Router (Router). Blöcke werden auf Routern als lokale Sequenzobjekte dargestellt; daher werden Sequenzoperationen wie `nextval` und `currval` lokal ausgeführt. Router arbeiten unabhängig voneinander und fordern bei Bedarf neue Blöcke aus der verteilten Sequenz an. Weitere Informationen zu Sequenzen finden Sie im Abschnitt [CREATE SEQUENCE](https://www.postgresql.org/docs/current/sql-createsequence.html) der PostgreSQL-Dokumentation. **Topics** + [ ### Anfordern eines neuen Blocks ](#limitless-reference.DDL-limitations.Sequences.request-chunk) + [ ### Einschränkungen ](#limitless-reference.DDL-limitations.Sequences.limitations) + [ ### Nicht unterstützte Optionen ](#limitless-reference.DDL-limitations.Sequences.unsupported) + [ ### Beispiele ](#limitless-reference.DDL-limitations.Sequences.examples) + [ ### Sequenzansichten ](#limitless-reference.DDL-limitations.Sequences.views) + [ ### Beheben von Sequenzproblemen ](#limitless-reference.DDL-limitations.Sequences.troubleshooting) ### Anfordern eines neuen Blocks Sie konfigurieren die Größe der Blöcke, die Routern zugewiesen werden, mithilfe des Parameters `rds_aurora.limitless_sequence_chunk_size`. Der Standardwert ist `250000`. Jeder Router besitzt zunächst zwei Blöcke: einen aktiven und einen reservierten. Aktive Blöcke werden verwendet, um lokale Sequenzobjekte zu konfigurieren (Einstellung `minvalue` und`maxvalue`), und reservierte Blöcke werden in einer internen Katalogtabelle gespeichert. Wenn ein aktiver Block den Mindest- oder Höchstwert erreicht, wird er durch den reservierten Block ersetzt. Dazu wird `ALTER SEQUENCE` intern verwendet, was bedeutet, dass `AccessExclusiveLock` erworben wird. Hintergrund-Worker werden alle 10 Sekunden auf Router-Knoten ausgeführt, um Sequenzen nach verwendeten reservierten Blöcken zu durchsuchen. Wenn ein verwendeter Block gefunden wird, fordert der Worker bei der verteilten Sequenz einen neuen Block an. Achten Sie darauf, die Blockgröße so festzulegen, dass die Hintergrund-Worker genügend Zeit haben, neue Blöcke anzufordern. Remoteanfragen treten niemals im Kontext von Benutzersitzungen auf, was bedeutet, dass Sie nicht direkt eine neue Sequenz anfordern können. ### Einschränkungen Die folgenden Einschränkungen gelten für Sequenzen in Aurora PostgreSQL Limitless Database: + Der `pg_sequence`-Katalog, die `pg_sequences`-Funktion und die `SELECT * FROM sequence_name`-Anweisung zeigen alle nur den lokalen Sequenzstatus, nicht den verteilten Status. + Sequenzwerte sind garantiert eindeutig und innerhalb einer Sitzung garantiert monoton. Sie können jedoch bei `nextval`-Anweisungen, die in anderen Sitzungen ausgeführt werden, in Unordnung geraten, wenn diese Sitzungen mit anderen Routern verbunden sind. + Stellen Sie sicher, dass die Sequenzgröße (Anzahl der verfügbaren Werte) ausreicht, um auf alle Router verteilt zu werden. Verwenden Sie den Parameter `rds_aurora.limitless_sequence_chunk_size`, um die `chunk_size` zu konfigurieren. (Jeder Router hat zwei Blöcke.) + Die `CACHE`-Option wird unterstützt, aber der Cache muss kleiner sein als `chunk_size`. ### Nicht unterstützte Optionen Die folgenden Optionen werden für Sequenzen in Aurora PostgreSQL Limitless Database nicht unterstützt. **Sequenz-Bearbeitungsfunktionen** Die Funktion `setval` wird nicht unterstützt. Weitere Informationen finden Sie im Abschnitt [Sequenz-Bearbeitungsfunktionen](https://www.postgresql.org/docs/current/functions-sequence.html) in der PostgreSQL-Dokumentation. **CREATE SEQUENCE** Die folgenden Optionen werden nicht unterstützt. ``` CREATE [{ TEMPORARY | TEMP} | UNLOGGED] SEQUENCE [[ NO ] CYCLE] ``` Weitere Informationen finden Sie im Abschnitt [CREATE SEQUENCE](https://www.postgresql.org/docs/current/sql-createsequence.html) der PostgreSQL-Dokumentation. **ALTER SEQUENCE** Die folgenden Optionen werden nicht unterstützt. ``` ALTER SEQUENCE [[ NO ] CYCLE] ``` Weitere Informationen finden Sie im Abschnitt [ALTER SEQUENCE](https://www.postgresql.org/docs/current/sql-altersequence.html) der PostgreSQL-Dokumentation. **ALTER TABLE** Der Befehl `ALTER TABLE` wird für Sequenzen nicht unterstützt. ### Beispiele **CREATE/DROP SEQUENCE** ``` postgres_limitless=> CREATE SEQUENCE s; CREATE SEQUENCE postgres_limitless=> SELECT nextval('s'); nextval --------- 1 (1 row) postgres_limitless=> SELECT * FROM pg_sequence WHERE seqrelid='s'::regclass; seqrelid | seqtypid | seqstart | seqincrement | seqmax | seqmin | seqcache | seqcycle ----------+----------+----------+--------------+--------+--------+----------+---------- 16960 | 20 | 1 | 1 | 10000 | 1 | 1 | f (1 row) % connect to another router postgres_limitless=> SELECT nextval('s'); nextval --------- 10001 (1 row) postgres_limitless=> SELECT * FROM pg_sequence WHERE seqrelid='s'::regclass; seqrelid | seqtypid | seqstart | seqincrement | seqmax | seqmin | seqcache | seqcycle ----------+----------+----------+--------------+--------+--------+----------+---------- 16959 | 20 | 10001 | 1 | 20000 | 10001 | 1 | f (1 row) postgres_limitless=> DROP SEQUENCE s; DROP SEQUENCE ``` **ALTER SEQUENCE** ``` postgres_limitless=> CREATE SEQUENCE s; CREATE SEQUENCE postgres_limitless=> ALTER SEQUENCE s RESTART 500; ALTER SEQUENCE postgres_limitless=> SELECT nextval('s'); nextval --------- 500 (1 row) postgres_limitless=> SELECT currval('s'); currval --------- 500 (1 row) ``` **Sequenz-Bearbeitungsfunktionen** ``` postgres=# CREATE TABLE t(a bigint primary key, b bigint); CREATE TABLE postgres=# CREATE SEQUENCE s minvalue 0 START 0; CREATE SEQUENCE postgres=# INSERT INTO t VALUES (nextval('s'), currval('s')); INSERT 0 1 postgres=# INSERT INTO t VALUES (nextval('s'), currval('s')); INSERT 0 1 postgres=# SELECT * FROM t; a | b ---+--- 0 | 0 1 | 1 (2 rows) postgres=# ALTER SEQUENCE s RESTART 10000; ALTER SEQUENCE postgres=# INSERT INTO t VALUES (nextval('s'), currval('s')); INSERT 0 1 postgres=# SELECT * FROM t; a | b -------+------- 0 | 0 1 | 1 10000 | 10000 (3 rows) ``` ### Sequenzansichten Aurora PostgreSQL Limitless Database bietet die folgenden Ansichten für Sequenzen. **rds\$1aurora.limitless\$1distributed\$1sequence** Diese Ansicht zeigt den Status und die Konfiguration einer verteilten Sequenz. Die Spalten `minvalue`, `maxvalue`, `start`, `inc` und `cache` haben dieselbe Bedeutung wie in der Ansicht [pg\$1sequences](https://www.postgresql.org/docs/current/view-pg-sequences.html) und zeigen die Optionen, mit denen die Sequenz erstellt wurde. Die Spalte `lastval` zeigt den letzten zugewiesenen oder reservierten Wert in einem verteilten Sequenzobjekt. Dies bedeutet nicht, dass der Wert bereits verwendet wurde, da Router Sequenzblöcke lokal speichern. ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_distributed_sequence WHERE sequence_name='test_serial_b_seq'; schema_name | sequence_name | lastval | minvalue | maxvalue | start | inc | cache -------------+-------------------+---------+----------+------------+-------+-----+------- public | test_serial_b_seq | 1250000 | 1 | 2147483647 | 1 | 1 | 1 (1 row) ``` **rds\$1aurora.limitless\$1sequence\$1metadata** Diese Ansicht zeigt verteilte Sequenzmetadaten und aggregiert Sequenzmetadaten von Cluster-Knoten. Sie verwendet die folgenden Spalten: + `subcluster_id`: die ID des Cluster-Knotens, dem ein Block gehört + Aktiver Block: ein Block einer Sequenz, der verwendet wird (`active_minvalue`, `active_maxvalue`) + Reservierter Block: der lokale Block, der als Nächstes verwendet wird (`reserved_minvalue`, `reserved_maxvalue`) + `local_last_value`: der zuletzt beobachtete Wert aus einer lokalen Sequenz + `chunk_size`: die Größe eines Blocks, wie sie bei der Erstellung konfiguriert wurde ``` postgres_limitless=> SELECT * FROM rds_aurora.limitless_sequence_metadata WHERE sequence_name='test_serial_b_seq' order by subcluster_id; subcluster_id | sequence_name | schema_name | active_minvalue | active_maxvalue | reserved_minvalue | reserved_maxvalue | chunk_size | chunk_state | local_last_value ---------------+-------------------+-------------+-----------------+-----------------+-------------------+-------------------+------------+-------------+------------------ 1 | test_serial_b_seq | public | 500001 | 750000 | 1000001 | 1250000 | 250000 | 1 | 550010 2 | test_serial_b_seq | public | 250001 | 500000 | 750001 | 1000000 | 250000 | 1 | (2 rows) ``` ### Beheben von Sequenzproblemen Die folgenden Probleme können bei Sequenzen auftreten. **Blockgröße reicht nicht aus** Wenn für die Blockgröße ein zu geringer Wert festgelegt wurde und die Transaktionsrate hoch ist, haben die Hintergrund-Worker möglicherweise nicht genug Zeit, um neue Blöcke anzufordern, bevor die aktiven Blöcke verbraucht sind. Dies kann zu Konflikten und Warteereignissen wie `LIMITLESS:AuroraLimitlessSequenceReplace`, `LWLock:LockManager`, `Lockrelation` und `LWlock:bufferscontent` führen. Erhöhen Sie den Wert des Parameters `rds_aurora.limitless_sequence_chunk_size`. **Sequenz-Cache zu hoch** In PostgreSQL erfolgt das Sequenz-Caching auf Sitzungsebene. Jede Sitzung weist während eines Zugriffs auf das Sequenzobjekt aufeinanderfolgende Sequenzwerte zu und erhöht den `last_value` des Sequenzobjekts entsprechend. Sobald `nextval` innerhalb dieser Sitzung erneut verwendet wird, werden dann einfach die vorab zugewiesenen Werte zurückgegeben, ohne dass auf das Sequenzobjekt zugegriffen wird. Alle Nummern, die innerhalb einer Sitzung zugewiesen, aber nicht verwendet wurden, gehen verloren, wenn die Sitzung endet, was zu „Lücken“ in der Sequenz führt. Dies kann zu einem raschen Verbrauch des sequence\$1chunk und somit zu Konflikten und Warteereignissen wie `LIMITLESS:AuroraLimitlessSequenceReplace`, `LWLock:LockManager`, `Lockrelation` und `LWlock:bufferscontent` führen. Verringern Sie den festgelegten Wert für den Sequenz-Cache. Die folgende Abbildung zeigt Warteereignisse, die durch Sequenzprobleme verursacht wurden. ![\[Warteereignisse, die durch Sequenzprobleme verursacht wurden\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/limitless_sequence_waits.png) # Unterstützte und nicht unterstützte Data Manipulation Language (DML)- und SQL-Befehle zur Abfrageverarbeitung In der folgenden Tabelle sind die DML-Befehle aufgeführt, die von Aurora PostgreSQL Limitless Database unterstützt und nicht unterstützt werden, mit Verweisen auf Einschränkungen oder weitere Informationen. | Befehl | Unterstützt? | Einschränkungen oder weitere Informationen | | --- | --- | --- | | ABORT | Ja | Keine | | ANALYZE | Ja | [ANALYZE](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.ANALYZE) | | BEGIN | Ja | Keine | | CALL | Ja | Keine | | CHECKPOINT | Ja | Keine | | CLOSE | Ja | Keine | | CLUSTER | Ja | [CLUSTER](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.CLUSTER) | | COMMIT | Ja | Keine | | COMMIT PREPARED | Nein | Nicht zutreffend | | COPY | Ja | Keine | | DEALLOCATE | Ja | Keine | | DECLARE | Ja | Keine | | DELETE | Ja | Keine | | DISCARD | Ja | Keine | | DO | Ja | Keine | | END | Ja | Keine | | EXECUTE | Ja | Keine | | EXPLAIN | Ja | [EXPLAIN](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.EXPLAIN) | | FETCH | Ja | Keine | | IMPORT FOREIGN SCHEMA | Nein | Nicht zutreffend | | INSERT | Ja | [INSERT](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.INSERT) | | LISTEN | Nein | Nicht zutreffend | | LOCK | Ja | Keine | | MERGE | Nein | Nicht zutreffend | | MOVE | Ja | Keine | | NOTIFY | Nein | Nicht zutreffend | | OPEN | Ja | Keine | | PREPARE | Ja | Keine | | PREPARE TRANSACTION | Nein | Nicht zutreffend | | REFRESH MATERIALIZED VIEW | Nein | Nicht zutreffend | | REINDEX | Nein | Nicht zutreffend | | RELEASE SAVEPOINT | Ja | Keine | | ROLLBACK | Ja | Keine | | ROLLBACK PREPARED | Nein | Nicht zutreffend | | ROLLBACK TO SAVEPOINT | Ja | Keine | | SAVEPOINT | Ja | Keine | | SELECT | Ja | Keine | | SELECT INTO | Ja | Keine | | ZEIGEN | Ja | Keine | | START TRANSACTION | Ja | Keine | | UNLISTEN | Nein | Keine | | UPDATE | Ja | [UPDATE](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.UPDATE) | | UPDATE … WHERE CURRENT OF | Nein | Nicht zutreffend | | VACUUM | Ja | [VACUUM](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.VACUUM) | | VALUES | Ja | Keine | # DML-Einschränkungen und andere Informationen für Aurora PostgreSQL Limitless Database In den folgenden Themen werden Einschränkungen beschrieben oder weitere Informationen zu DML und zu SQL-Befehlen für die Abfrageverarbeitung in Aurora PostgreSQL Limitless Database bereitgestellt. **Topics** + [ ## ANALYZE ](#limitless-reference.DML-limitations.ANALYZE) + [ ## CLUSTER ](#limitless-reference.DML-limitations.CLUSTER) + [ ## EXPLAIN ](#limitless-reference.DML-limitations.EXPLAIN) + [ ## INSERT ](#limitless-reference.DML-limitations.INSERT) + [ ## UPDATE ](#limitless-reference.DML-limitations.UPDATE) + [ ## VACUUM ](#limitless-reference.DML-limitations.VACUUM) ## ANALYZE Der Befehl `ANALYZE` sammelt Statistiken über den Inhalt von Tabellen in der Datenbank. Anschließend verwendet der Abfrageplaner diese Statistiken, um die effizientesten Ausführungspläne für Abfragen zu ermitteln. Weitere Informationen finden Sie unter [ANALYZE](https://www.postgresql.org/docs/current/sql-analyze.html) in der PostgreSQL-Dokumentation. In Aurora PostgreSQL Limitless Database sammelt der Befehl `ANALYZE` bei seiner Ausführung Tabellenstatistiken für alle Router und Shards. Um zu verhindern, dass während der Ausführung von `ANALYZE` Statistiken für jeden Router berechnet werden, werden Tabellenstatistiken auf einem der Router berechnet und dann auf Peer-Router kopiert. ## CLUSTER Der Befehl `CLUSTER` ordnet eine Tabelle anhand eines Indexes physisch neu an. Der Index muss zuvor für die Tabelle definiert worden sein. In Aurora PostgreSQL Limitless Database findet das Clustering lokal für den Teil des Index statt, der auf jedem Shard vorhanden ist. Weitere Informationen finden Sie unter [CLUSTER](https://www.postgresql.org/docs/current/sql-cluster.html) in der PostgreSQL-Dokumentation. ## EXPLAIN Sie verwenden den folgenden Parameter, um die Ausgabe des Befehls `EXPLAIN` zu konfigurieren: + `rds_aurora.limitless_explain_options`: Bestimmt, was in die Ausgabe `EXPLAIN` aufgenommen werden soll. Der Standardwert lautet `single_shard_optimization`: Er zeigt an, ob Pläne für Single-Shard optimiert sind, Shard-Pläne sind jedoch nicht enthalten. In diesem Beispiel werden in der Ausgabe `EXPLAIN` keine Pläne aus Shards angezeigt. ``` postgres_limitless=> EXPLAIN SELECT * FROM employees where id =25; QUERY PLAN ------------------------------------------------------ Foreign Scan (cost=100.00..101.00 rows=100 width=0) Single Shard Optimized (2 rows) ``` Jetzt legen wir den Wert `rds_aurora.limitless_explain_options` fest, damit `shard_plans` und `single_shard_optimization` eingeschlossen sind. Wir können die Ausführungspläne von Anweisungen sowohl auf Routern als auch auf Shards anzeigen lassen. Außerdem deaktivieren wir den Parameter `enable_seqscan`, um zu erzwingen, dass der Indexscan auf Shard-Ebene verwendet wird. ``` postgres_limitless=> SET rds_aurora.limitless_explain_options = shard_plans, single_shard_optimization; SET postgres_limitless=> SET enable_seqscan = OFF; SET postgres_limitless=> EXPLAIN SELECT * FROM employees WHERE id = 25; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------- Foreign Scan (cost=100.00..101.00 rows=100 width=0) Remote Plans from Shard postgres_s4: Index Scan using employees_ts00287_id_idx on employees_ts00287 employees_fs00003 (cost=0.14..8.16 rows=1 width=15) Index Cond: (id = 25) Single Shard Optimized (5 rows) ``` Weitere Informationen zum Befehl `EXPLAIN` finden Sie in der PostgreSQL-Dokumentation unter [EXPLAIN](https://www.postgresql.org/docs/current/sql-explain.html). ## INSERT Die meisten `INSERT`-Befehle werden in Aurora PostgreSQL Limitless Database unterstützt. PostgreSQL hat keinen expliziten `UPSERT`-Befehl, unterstützt aber `INSERT ... ON CONFLICT`-Anweisungen. `INSERT ... ON CONFLICT` wird nicht unterstützt, wenn die Konfliktaktion eine Unterabfrage oder eine veränderbare Funktion hat: ``` -- RANDOM is a mutable function. INSERT INTO sharded_table VALUES (1, 100) ON CONFLICT (id) DO UPDATE SET other_id = RANDOM(); ERROR: Aurora Limitless Tables doesn't support pushdown-unsafe functions with DO UPDATE clauses. ``` Weitere Informationen zum Befehl `INSERT` finden Sie in der PostgreSQL-Dokumentation unter [INSERT](https://www.postgresql.org/docs/current/sql-insert.html). ## UPDATE Das Aktualisieren des Shard-Schlüssels wird nicht unterstützt. Sie haben beispielsweise eine Sharded-Tabelle namens `customers` mit dem Shard-Schlüssel `customer_id`. Die folgenden DML-Anweisungen verursachen Fehler: ``` postgres_limitless=> UPDATE customers SET customer_id = 11 WHERE customer_id =1; ERROR: Shard key column update is not supported postgres_limitless=> UPDATE customers SET customer_id = 11 WHERE customer_name='abc'; ERROR: Shard key column update is not supported ``` Um einen Shard-Schlüssel zu aktualisieren, müssen Sie zuerst die Zeile mit dem Shard-Schlüssel löschen (`DELETE`) und dann eine neue Zeile mit dem aktualisierten Shard-Schlüsselwert einfügen (`INSERT`). Weitere Informationen zum Befehl `UPDATE` finden Sie in der PostgreSQL-Dokumentation unter [Aktualisieren von Daten](https://www.postgresql.org/docs/current/dml-update.html). ## VACUUM Sie können sowohl Sharded- als auch Referenztabellen leeren. Die folgenden `VACUUM`-Funktionen werden in Aurora PostgreSQL Limitless Database vollständig unterstützt: + VACUUM + [ANALYZE](#limitless-reference.DML-limitations.ANALYZE) + DISABLE\$1PAGE\$1SKIPPING + FREEZE + FULL + INDEX\$1CLEANUP + PARALLEL + PROCESS\$1TOAST + TRUNCATE + VERBOSE Für `VACUUM` gelten in Aurora PostgreSQL Limitless Database die folgenden Einschränkungen: + Die Erweiterung [pg\$1visibility\$1map](https://www.postgresql.org/docs/current/pgvisibility.html) wird nicht unterstützt. + Die Suche nach ungenutzten Indizes über die Ansicht [pg\$1stat\$1all\$1indexes](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW) wird nicht unterstützt. + Konsolidierte Ansichten für [pg\$1stat\$1user\$1indexes](https://www.postgresql.org/docs/current/monitoring-stats.html), [pg\$1class](https://www.postgresql.org/docs/current/catalog-pg-class.html) und [pg\$1stats](https://www.postgresql.org/docs/current/view-pg-stats.html) sind nicht implementiert. Weitere Informationen zum Befehl `VACUUM` finden Sie in der PostgreSQL-Dokumentation unter [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html). Weitere Informationen zum Leeren von Tabellen in Aurora PostgreSQL Limitless Database finden Sie unter [Zurückgewinnen von Speicherplatz durch Bereinigung](limitless-vacuum.md). # Variablen in Aurora PostgreSQL Limitless Database Sie können die folgenden Variablen verwenden, um Aurora PostgreSQL Limitless Database zu konfigurieren. **rds\$1aurora.limitless\$1active\$1shard\$1key** Legt bei der Abfrage der Datenbank einen einzelnen Shard-Schlüssel fest, wodurch an alle `SELECT`- und DML-Abfragen der Shard-Schlüssel als konstantes Prädikat angehängt wird. Weitere Informationen finden Sie unter [Festlegen eines aktiven Shard-Schlüssels](limitless-query.single-shard.md#limitless-query.single-shard.active). **rds\$1aurora.limitless\$1create\$1table\$1collocate\$1with** Legen Sie für diese Variable einen bestimmten Tabellennamen fest, um neu erstellte Tabellen dieser Tabelle zuzuordnen. Weitere Informationen finden Sie unter [Erstellen von Limitless-Tabellen mithilfe von Variablen](limitless-creating-config.md). **rds\$1aurora.limitless\$1create\$1table\$1mode** Legt den Modus für die Tabellenerstellung fest. Weitere Informationen finden Sie unter [Erstellen von Limitless-Tabellen mithilfe von Variablen](limitless-creating-config.md). **rds\$1aurora.limitless\$1create\$1table\$1shard\$1key** Legen Sie für diese Variable ein Array von Spaltennamen fest, die als Shard-Schlüssel verwendet werden sollen. Weitere Informationen finden Sie unter [Erstellen von Limitless-Tabellen mithilfe von Variablen](limitless-creating-config.md). **rds\$1aurora.limitless\$1explain\$1options** Legt fest, was in die Ausgabe `EXPLAIN` aufgenommen werden soll. Weitere Informationen finden Sie unter [EXPLAIN](limitless-reference.DML-limitations.md#limitless-reference.DML-limitations.EXPLAIN). # DB-Cluster-Parameter in der Aurora PostgreSQL Limitless-Datenbank Sie können die folgenden DB-Cluster-Parameter verwenden, um Aurora PostgreSQL Limitless Database zu konfigurieren. **rds\$1aurora.limitless\$1adaptive\$1fetch\$1size** Verbessert das Vorabrufen von Batches. Wenn dieser Parameter auf `true` gesetzt ist, ermöglicht er eine sich selbst anpassende (adaptive) Abrufgröße für den Vorabruf. Wenn der Parameter auf `false` gesetzt ist, bleibt die Abrufgröße konstant. **rds\$1aurora.limitless\$1auto\$1scale\$1options** Legt die verfügbaren Optionen für das Hinzufügen von Routern oder das Unterteilen von Shards in einer DB-Shard-Gruppe fest. Der Wert kann `add_router`, `split_shard` oder Beides lauten. Weitere Informationen erhalten Sie unter [Hinzufügen eines Routers zu einer DB-Shard-Gruppe](limitless-add-router.md) und [Unterteilen eines Shards in einer DB-Shard-Gruppe](limitless-shard-split.md). **rds\$1aurora.limitless\$1distributed\$1deadlock\$1timeout** Legt die Zeit in Millisekunden fest, die während einer Sperre gewartet wird, bevor geprüft wird, ob ein verteilter Deadlock vorliegt. Der Standardwert ist `1000` (1 Sekunde). Weitere Informationen finden Sie unter [Verteilte Deadlocks in Aurora PostgreSQL Limitless Database](limitless-query.deadlocks.md). **rds\$1aurora.limitless\$1enable\$1auto\$1scale** Ermöglicht das Hinzufügen von Routern und das Unterteilen von Shards in einer DB-Shard-Gruppe. Weitere Informationen erhalten Sie unter [Hinzufügen eines Routers zu einer DB-Shard-Gruppe](limitless-add-router.md) und [Unterteilen eines Shards in einer DB-Shard-Gruppe](limitless-shard-split.md). **rds\$1aurora.limitless\$1finalize\$1split\$1shard\$1mode** Bestimmt, wie vom System initiierte Shard-Splits finalisiert werden. Weitere Informationen finden Sie unter [Unterteilen eines Shards in einer DB-Shard-Gruppe](limitless-shard-split.md). **rds\$1aurora.limitless\$1maximum\$1adaptive\$1fetch\$1size** Legt die Obergrenze für die adaptive Abrufgröße fest. Der Bereich ist `1` bis `INT_MAX`. Der Standardwert ist `1000`.