PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Cloud Anbieter Deep Dive:PostgreSQL auf AWS Aurora

Wie tief sollen wir damit gehen? Ich beginne damit, dass ich zum Zeitpunkt dieses Schreibens nur 3 Bücher bei Amazon über PostgreSQL in der Cloud und 117 Diskussionen auf PostgreSQL-Mailinglisten über Aurora PostgreSQL finden konnte. Das sieht nicht nach viel aus und lässt mich, den neugierigen PostgreSQL-Endbenutzer, mit der offiziellen Dokumentation als einzigem Ort zurück, an dem ich wirklich etwas mehr lernen könnte. Da ich weder die Fähigkeit noch das Wissen habe, mich viel tiefer in Abenteuer zu vertiefen, gibt es AWS re:Invent 2018 für diejenigen, die nach dieser Art von Nervenkitzel suchen. Ich kann mich mit Werners Artikel über die Beschlussfähigkeit begnügen.

Um mich aufzuwärmen, habe ich mit der Aurora PostgreSQL-Homepage begonnen, wo ich festgestellt habe, dass der Benchmark, der zeigt, dass Aurora PostgreSQL dreimal schneller ist als ein Standard-PostgreSQL, das auf derselben Hardware ausgeführt wird, auf PostgreSQL 9.6 zurückgeht. Wie ich später erfahren habe, ist 9.6.9 derzeit die Standardoption beim Einrichten eines neuen Clusters. Das sind sehr gute Nachrichten für diejenigen, die nicht sofort upgraden möchten oder können. Und warum nur 99,99 % Verfügbarkeit? Eine Erklärung findet sich im Artikel von Bruce Momjian.

Kompatibilität

Laut AWS ist Aurora PostgreSQL ein direkter Ersatz für PostgreSQL, und in der Dokumentation heißt es:

Der Code, die Tools und Anwendungen, die Sie heute mit Ihren vorhandenen MySQL- und PostgreSQL-Datenbanken verwenden, können mit Aurora verwendet werden.

Dies wird durch die Aurora-FAQs verstärkt:

Dies bedeutet, dass die meisten Codes, Anwendungen, Treiber und Tools, die Sie bereits heute mit Ihren PostgreSQL-Datenbanken verwenden, mit geringen oder keinen Änderungen mit Aurora verwendet werden können. Die Amazon Aurora-Datenbank-Engine ist kabelkompatibel mit PostgreSQL 9.6 und 10 und unterstützt dieselben PostgreSQL-Erweiterungen, die mit RDS für PostgreSQL 9.6 und 10 unterstützt werden, was das Verschieben von Anwendungen zwischen den beiden Engines vereinfacht.

„Die meisten“ im obigen Text deutet darauf hin, dass es keine 100-prozentige Garantie gibt. In diesem Fall sollten diejenigen, die Sicherheit suchen, in Betracht ziehen, technischen Support entweder von AWS Professional Services oder Amazon Aurora-Partnern zu erwerben. Als Nebenbemerkung habe ich festgestellt, dass keiner der professionellen PostgreSQL-Hosting-Provider, die Mitwirkende der Core-Community beschäftigen, auf dieser Liste steht.

Auf der FAQ-Seite von Aurora erfahren wir auch, dass Aurora PostgreSQL dieselben Erweiterungen wie RDS unterstützt, das wiederum die meisten Community-Erweiterungen und einige Extras auflistet.

Konzepte

Als Teil von Amazon RDS verfügt Aurora PostgreSQL über eine eigene Terminologie:

  • Cluster:Eine primäre DB-Instance im Lese-/Schreibmodus und null oder mehr Aurora-Replicas. Die primäre Datenbank wird in „AWS-Diagrammen“ oft als „Master“ oder in der AWS-Konsole als „Writer“ bezeichnet. Anhand des Referenzdiagramms können wir eine interessante Beobachtung machen:Aurora schreibt dreimal. Da die Latenz zwischen den AZs normalerweise höher ist als innerhalb derselben AZ, gilt die Transaktion als festgeschrieben, sobald sie auf die Datenkopie innerhalb derselben AZ geschrieben wird, andernfalls die Latenz und potenzielle Ausfälle zwischen AZs.
  • Cluster-Volume:Speichervolume für virtuelle Datenbanken, das sich über mehrere AZs erstreckt.
  • Aurora-URL:Ein `Host:Port`-Paar.
  • Cluster-Endpunkt:Aurora-URL für die primäre DB. Es gibt einen Cluster-Endpunkt.
  • Reader-Endpunkt:Aurora-URL für den Replikatsatz. Um eine Analogie zu DNS herzustellen, handelt es sich um einen Alias ​​(CNAME). Leseanforderungen werden zwischen verfügbaren Replikaten ausgeglichen.
  • Benutzerdefinierter Endpunkt:Aurora-URL zu einer Gruppe, die aus einer oder mehreren DB-Instances besteht.
  • Instance-Endpunkt:Aurora-URL zu einer bestimmten DB-Instance.
  • Aurora-Version:Produktversion zurückgegeben von `SELECT AURORA_VERSION();`.

PostgreSQL-Leistung und -Überwachung auf AWS Aurora

Größe

Aurora PostgreSQL wendet eine Best-Guess-Konfiguration an, die auf der Größe und Speicherkapazität der DB-Instance basiert, und überlässt die weitere Abstimmung dem DBA durch die Verwendung von DB-Parametergruppen.

Basieren Sie bei der Auswahl der DB-Instance auf dem gewünschten Wert für max_connections.

Skalierung

Aurora PostgreSQL bietet automatische und manuelle Skalierung. Die horizontale Skalierung von Lesereplikaten wird durch die Verwendung von Leistungsmetriken automatisiert. Die vertikale Skalierung kann über APIs automatisiert werden.

Durch die horizontale Skalierung wird der Computer für einige Minuten offline geschaltet, während die Compute-Engine ersetzt und Wartungsvorgänge (Upgrades, Patches) durchgeführt werden. Daher empfiehlt AWS, solche Vorgänge während Wartungsfenstern durchzuführen.

Skalierung in beide Richtungen ist ein Kinderspiel:

Vertikale Skalierung:Ändern der Instance-Klasse Horizontale Skalierung:Lesereplikat hinzufügen.

Auf der Speicherebene wird Speicherplatz in 10-GB-Schritten hinzugefügt. Zugewiesener Speicherplatz wird nie zurückgefordert, siehe unten, wie Sie diese Einschränkung beheben können.

Speicherung

Wie oben erwähnt, wurde Aurora PostgreSQL entwickelt, um Quoren zu nutzen, um die Leistungskonsistenz zu verbessern.

Da der zugrunde liegende Speicher von allen DB-Instances innerhalb desselben Clusters gemeinsam genutzt wird, sind keine zusätzlichen Schreibvorgänge auf Standby-Knoten erforderlich. Außerdem ändert das Hinzufügen oder Entfernen von DB-Instances die zugrunde liegenden Daten nicht.

Ich frage mich, was diese IOs Einheiten bedeuten auf der Monatsrechnung? Die Aurora-FAQ kommt wieder zu Hilfe, um zu erklären, was ein IO ist ist, im Rahmen der Überwachung und Abrechnung. Ein Lese-E/A als Äquivalent einer 8-KiB-Datenbankseite, die gelesen wird, und ein Schreib-E/A als Äquivalent von 4 KiB, die in die Speicherschicht geschrieben werden.

Hohe Gleichzeitigkeit

Um das High-Concurrency-Design von Aurora voll auszuschöpfen, wird empfohlen, Anwendungen so zu konfigurieren, dass sie eine große Anzahl gleichzeitiger Abfragen und Transaktionen steuern.

Anwendungen, die darauf ausgelegt sind, Lese- und Schreibabfragen an Standby- und primäre Datenbankknoten zu leiten, profitieren vom Aurora PostgreSQL Reader Replica Endpoint.

Verbindungen werden zwischen Read Replicas geladen.

Mithilfe von benutzerdefinierten Endpunkten können Datenbankinstanzen mit mehr Kapazität gruppiert werden, um eine intensive Arbeitslast wie Analysen auszuführen.

DB-Instance-Endpunkte können für feinkörnigen Lastenausgleich oder schnelles Failover verwendet werden.

Beachten Sie, dass jede Abfrage als neue Verbindung gesendet werden muss, damit die Reader-Endpunkte einzelne Abfragen ausgleichen können.

Caching

Aurora PostgreSQL verwendet eine Survivable Cache Warming-Technik, die sicherstellt, dass das Datum im Puffercache erhalten bleibt, sodass der Cache nach einem Datenbankneustart nicht neu gefüllt oder aufgewärmt werden muss.

Replikation

Die Replikationsverzögerungszeit zwischen Replikaten wird innerhalb einer einstelligen Millisekunde gehalten. Obwohl für PostgreSQL nicht verfügbar, ist es gut zu wissen, dass die regionsübergreifende Replikationsverzögerung innerhalb von 10 Millisekunden gehalten wird.

Laut Dokumentation nimmt die Replikationsverzögerung in Zeiten hoher Schreibanforderungen zu.

Abfrageausführungspläne

Basierend auf der Annahme, dass die Abfrageleistung im Laufe der Zeit aufgrund verschiedener Datenbankänderungen abnimmt, besteht die Rolle dieser Aurora PostgreSQL-Komponente darin, eine Liste genehmigter oder abgelehnter Abfrageausführungspläne zu führen.

Pläne werden mit proaktiven oder reaktiven Methoden genehmigt oder abgelehnt.

Wenn ein Ausführungsplan als abgelehnt markiert wird, setzt der Abfrageausführungsplan die Entscheidungen des PostgreSQL-Optimierers außer Kraft und verhindert, dass der „schlechte“ Plan ausgeführt wird.

Diese Funktion erfordert Aurora 2.1.0 oder höher.

Hochverfügbarkeit und Replikation von PostgreSQL auf AWS Aurora

Auf der Speicherebene sorgt Aurora PostgreSQL für Langlebigkeit, indem es alle 10 GB des Speichervolumens sechsmal über 3 AZs repliziert (jede Region besteht normalerweise aus 3 AZs) und dabei eine physische synchrone Replikation verwendet. Dadurch ist es möglich, dass Datenbankschreibvorgänge auch dann weiter funktionieren, wenn zwei Datenkopien verloren gehen. Die Leseverfügbarkeit überlebt den Verlust von 3 Datenkopien.

Read Replicas stellen sicher, dass eine ausgefallene primäre Instanz schnell ersetzt werden kann, indem eine der 15 verfügbaren Replikate hochgestuft wird. Bei Auswahl einer Multi-AZ-Bereitstellung wird automatisch eine Read Replica erstellt. Failover erfordert keinen Benutzereingriff und der Datenbankbetrieb wird in weniger als 30 Sekunden fortgesetzt.

Bei Single-AZ-Bereitstellungen umfasst das Wiederherstellungsverfahren eine Wiederherstellung aus der letzten als funktionierend bekannten Sicherung. Laut Aurora FAQs ist der Vorgang in weniger als 15 Minuten abgeschlossen, wenn die Datenbank in einem anderen AZ wiederhergestellt werden muss. Die Dokumentation ist nicht so spezifisch und behauptet, dass es weniger als 10 Minuten dauert, um den Wiederherstellungsprozess abzuschließen.

Auf der Anwendungsseite ist keine Änderung erforderlich, um eine Verbindung zur neuen DB-Instance herzustellen, da sich der Cluster-Endpunkt während einer Replica-Hochstufung oder Instance-Wiederherstellung nicht ändert.

Schritt 1:Löschen Sie die primäre Instanz, um ein Failover zu erzwingen:

Automatisches Failover Schritt 1:Primäre löschen

Schritt 2:Automatisches Failover abgeschlossen

Automatisches Failover Schritt 2:Failover abgeschlossen.

Bei ausgelasteten Datenbanken wird die Wiederherstellungszeit nach einem Neustart oder Absturz drastisch verkürzt, da Aurora PostgreSQL die Transaktionsprotokolle nicht erneut wiedergeben muss.

Als Teil des vollständig verwalteten Dienstes werden fehlerhafte Datenblöcke und Festplatten automatisch ersetzt.

Failover, wenn Replikate vorhanden sind, dauert bis zu 120 Sekunden, oft unter 60 Sekunden. Kürzere Wiederherstellungszeiten können erreicht werden, wenn Failover-Bedingungen vorab festgelegt werden, in welchem ​​Fall Replikate Failover-Prioritäten zugewiesen werden können.

Aurora PostgreSQL spielt gut mit Amazon RDS – eine Aurora-Instance kann als Read Replica für eine primäre RDS-Instance fungieren.

Aurora PostgreSQL unterstützt die logische Replikation, die genau wie in der Community-Version verwendet werden kann, um integrierte Replikationsbeschränkungen zu überwinden. Es gibt keine Automatisierungs- oder AWS-Konsolenschnittstelle.

Sicherheit für PostgreSQL auf AWS Aurora

Auf Netzwerkebene nutzt Aurora PostgreSQL AWS-Kernkomponenten, VPC für die Isolierung von Cloud-Netzwerken und Sicherheitsgruppen für die Netzwerkzugriffskontrolle.

Es gibt keinen Superuser-Zugriff. Beim Erstellen eines Clusters erstellt Aurora PostgreSQL ein Hauptkonto mit einer Teilmenge von Superuser-Berechtigungen:

[email protected]:5432 postgres> \du+ postgres
                               List of roles
 Role name |          Attributes               |    Member of       | Description
-----------+-------------------------------+-----------------+-------------
 postgres  | Create role, Create DB           +| {rds_superuser} |
            | Password valid until infinity  |                 |

Um Daten während der Übertragung zu sichern, bietet Aurora PostgreSQL native SSL/TLS-Unterstützung, die pro DB-Instance konfiguriert werden kann.

Alle ruhenden Daten können mit minimaler Auswirkung auf die Leistung verschlüsselt werden. Dies gilt auch für Backups, Snapshots und Replicas.

Verschlüsselung im Ruhezustand.

Die Authentifizierung wird durch IAM-Richtlinien gesteuert, und Tagging ermöglicht eine weitere Kontrolle darüber, was Benutzer tun dürfen und auf welchen Ressourcen.

API-Aufrufe, die von allen Cloud-Diensten verwendet werden, werden in CloudTrail protokolliert.

Die clientseitige eingeschränkte Passwortverwaltung ist über den Parameter rds.restrict_password_commands verfügbar.

PostgreSQL-Sicherung und -Wiederherstellung auf AWS Aurora

Sicherungen sind standardmäßig aktiviert und können nicht deaktiviert werden. Sie bieten Point-in-Time-Recovery mit einem vollständigen täglichen Snapshot als Basis-Backup.

Die Wiederherstellung aus einem automatisierten Backup hat einige Nachteile:Die Wiederherstellungszeit kann mehrere Stunden betragen und der Datenverlust kann bis zu 5 Minuten vor dem Ausfall auftreten. Amazon RDS Multi-AZ-Bereitstellungen lösen dieses Problem, indem sie eine Read Replica ohne Datenverlust zur primären hochstufen.

Datenbank-Snapshots sind schnell und wirken sich nicht auf die Clusterleistung aus. Sie können kopiert oder mit anderen Benutzern geteilt werden.

Das Erstellen eines Schnappschusses erfolgt fast augenblicklich:

Schnappschusszeit.

Auch das Wiederherstellen eines Snapshots geht schnell. Vergleiche mit PITR:

Backups und Snapshots werden in S3 gespeichert, das elf 9 an Haltbarkeit bietet.

Abgesehen von Backups und Snapshots ermöglicht Aurora PostgreSQL das Klonen von Datenbanken. Dies ist eine effiziente Methode zum Erstellen von Kopien großer Datensätze. Beispielsweise dauert das Klonen von mehreren Terabyte an Daten nur wenige Minuten und hat keine Auswirkungen auf die Leistung.

Aurora PostgreSQL – Point-in-Time-Recovery-Demo

Mit Cluster verbinden:

~ $ export PGUSER=postgres PGPASSWORD=postgres PGHOST=s9s-us-east-1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
~ $ psql
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Füllen Sie eine Tabelle mit Daten:

[email protected]:5432 postgres> create table s9s (id serial not null, msg text, created timestamptz not null default now());
CREATE TABLE

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
7 | test | 2019-06-25 07:59:59.5233+00
8 | test | 2019-06-25 08:00:00.318474+00
9 | test | 2019-06-25 08:00:11.153298+00
10 | test | 2019-06-25 08:00:12.287245+00
(10 rows)

Starten Sie die Wiederherstellung:

Point-in-Time-Wiederherstellung:Wiederherstellung initiieren.

Sobald die Wiederherstellung abgeschlossen ist, melden Sie sich an und überprüfen Sie:

~ $ psql -h pg107-dbt3medium-restored-cluster.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

[email protected]:5432 postgres> select * from s9s;
id | msg  |            created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
(6 rows)

Best Practices

Überwachung und Prüfung

  • Integrieren Sie Datenbankaktivitätsströme in die Überwachung durch Dritte, um die Datenbankaktivität auf Compliance und regulatorische Anforderungen zu überwachen.
  • Ein vollständig verwalteter Datenbankdienst bedeutet nicht mangelnde Verantwortung – definieren Sie Metriken zur Überwachung von CPU, RAM, Speicherplatz, Netzwerk und Datenbankverbindungen.
  • Aurora PostgreSQL lässt sich in das AWS-Standardüberwachungstool CloudWatch integrieren und bietet zusätzliche Monitore für Aurora-Metriken, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL Replication und auch für RDS-Metriken, die weiter nach RDS-Dimensionen gruppiert werden können.
  • Überwachen Sie die durchschnittliche DB-Last aktiver Sitzungen, indem Sie auf Anzeichen von Verbindungs-Overhead, SQL-Abfragen, die optimiert werden müssen, Ressourcenkonflikte oder eine zu kleine DB-Instance-Klasse warten.
  • Ereignisbenachrichtigungen einrichten.
  • Fehlerprotokollparameter konfigurieren.
  • Überwachen Sie Konfigurationsänderungen an Datenbank-Cluster-Komponenten:Instanzen, Subnetzgruppen, Snapshots, Sicherheitsgruppen.

Replikation

  • Verwenden Sie native Tabellenpartitionierung für Workloads, die die maximale DB-Instance-Klasse und Speicherkapazität überschreiten

Verschlüsselung

  • Für verschlüsselte Datenbanken müssen Sicherungen aktiviert sein, um sicherzustellen, dass Daten wiederhergestellt werden können, falls der Verschlüsselungsschlüssel widerrufen wird.

Hauptkonto

  • Verwenden Sie nicht psql, um das Master-Benutzerkennwort zu ändern.

Größe

  • Erwägen Sie die Verwendung verschiedener Instanzklassen in einem Cluster, um die Kosten zu senken.

Parametergruppen

  • Feinabstimmung mit Parametergruppen, um $$$ zu sparen.

Parametergruppen-Demo

Aktuelle Einstellungen:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)

Erstellen Sie eine neue Parametergruppe und legen Sie den neuen clusterweiten Wert fest:

Clusterweite Aktualisierung von shared_buffers.

Ordnen Sie die benutzerdefinierte Parametergruppe dem Cluster zu:

Starten Sie den Writer neu und überprüfen Sie den Wert:

[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)
  • Stellen Sie die lokale Zeitzone ein

Standardmäßig ist die Zeitzone in UTC:

[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)

Einstellen der neuen Zeitzone:

Zeitzone konfigurieren

Und prüfen Sie dann:

[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)

Beachten Sie, dass die Liste der von Amazon Aurora akzeptierten Zeitzonenwerte nicht die Zeitzonensätze sind, die in Upstream-PostgreSQL gefunden werden.

  • Prüfen Sie Instanzparameter, die von Clusterparametern überschrieben werden
  • Verwenden Sie das Parametergruppen-Vergleichstool.

Schnappschüsse

  • Vermeiden Sie zusätzliche Speichergebühren, indem Sie die Snapshots mit anderen Konten teilen, um die Wiederherstellung in deren jeweiligen Umgebungen zu ermöglichen.

Wartung

  • Ändern Sie das Standardwartungsfenster gemäß dem Zeitplan der Organisation.

Failover

  • Verbessern Sie die Wiederherstellungszeit durch Konfigurieren der Cluster-Cache-Verwaltung.
  • Senken Sie die TCP-Keepalive-Werte des Kernels auf dem Client und konfigurieren Sie den Anwendungs-DNS-Cache und die TTL- und PostgreSQL-Verbindungszeichenfolgen.

DBA aufgepasst!

Zusätzlich zu den bekannten Einschränkungen vermeiden oder beachten Sie Folgendes:

Verschlüsselung

  • Sobald eine Datenbank erstellt wurde, kann der Verschlüsselungsstatus nicht mehr geändert werden.

Aurora ohne Server

  • Derzeit ist die PostgreSQL-Version von Aurora Serverless nur in einer eingeschränkten Vorschau verfügbar.

Parallele Abfrage

  • Amazon Parallel Query ist nicht verfügbar, obwohl die gleichnamige Funktion seit PostgreSQL 9.6 verfügbar ist.

Endpunkte

Von der Amazon-Verbindungsverwaltung:

  • 5 benutzerdefinierte Endpunkte pro Cluster
  • Benutzerdefinierte Endpunktnamen dürfen nicht länger als 63 Zeichen sein
  • Clusterendpunktnamen sind innerhalb derselben Region eindeutig
  • Wie im obigen Screenshot (aurora-custom-endpoint-details) zu sehen ist, sind READER und ANY benutzerdefinierte Endpunkttypen nicht verfügbar, verwenden Sie die CLI
  • Benutzerdefinierte Endpunkte wissen nicht, dass Replikate vorübergehend nicht verfügbar sind

Replikation

  • Beim Heraufstufen eines Replikats zum primären Replikat können Verbindungen über den Reader-Endpunkt für kurze Zeit weiterhin zum heraufgestuften Replikat geleitet werden.
  • Regionsübergreifende Replikate werden nicht unterstützt
  • Auch wenn die Amazon Aurora Multi-Master-Vorschau Ende November 2017 veröffentlicht wurde, ist sie immer noch nicht für PostgreSQL verfügbar
  • Achten Sie auf Leistungseinbußen, wenn die logische Replikation auf dem Cluster aktiviert ist.
  • Für die logische Replikation ist eine veröffentlichte PostgreSQL-Engine 10.6 oder höher erforderlich.

Speicherung

  • Der maximal zugewiesene Speicher schrumpft nicht, wenn Daten gelöscht werden, und es wird auch kein Speicherplatz durch die Wiederherstellung aus Snapshots zurückgewonnen. Die einzige Möglichkeit, Speicherplatz zurückzugewinnen, besteht darin, einen logischen Speicherauszug in einen neuen Cluster durchzuführen.

Sicherung und Wiederherstellung

  • Die Aufbewahrung von Sicherungen wird nicht verlängert, während der Cluster angehalten ist.
  • Die maximale Aufbewahrungsdauer beträgt 35 Tage – verwenden Sie manuelle Snapshots für eine längere Aufbewahrungsdauer.
  • Wiederherstellung zu einem bestimmten Zeitpunkt in einem neuen DB-Cluster.
  • kurze Unterbrechung der Lesevorgänge während des Failovers auf Replikate.
  • Disaster Recovery-Szenarien sind nicht regionsübergreifend verfügbar.

Schnappschüsse

  • Die Wiederherstellung aus einem Snapshot erstellt einen neuen Endpunkt (Snapshots können nur in einem neuen Cluster wiederhergestellt werden).
  • Nach einer Snapshot-Wiederherstellung müssen benutzerdefinierte Endpunkte neu erstellt werden.
  • Das Wiederherstellen von Snapshots setzt die lokale Zeitzone auf UTC zurück.
  • Bei der Wiederherstellung aus Snapshots bleiben die benutzerdefinierten Sicherheitsgruppen nicht erhalten.
  • Snapshots können mit maximal 20 AWS-Konto-IDs geteilt werden.
  • Schnappschüsse können nicht zwischen Regionen geteilt werden.
  • Inkrementelle Snapshots werden immer als vollständige Snapshots zwischen Regionen und innerhalb derselben Region kopiert.
  • Beim Kopieren von Snapshots über Regionen hinweg werden die nicht standardmäßigen Parametergruppen nicht beibehalten.

Abrechnung

  • Die 10-Minuten-Rechnung gilt für neue Instanzen sowie nach einer Kapazitätsänderung (Computing oder Speicher).

Authentifizierung

  • Die Verwendung der IAM-Datenbankauthentifizierung begrenzt die Anzahl der Verbindungen pro Sekunde.
  • Dem Hauptkonto wurden bestimmte Superuser-Privilegien entzogen.

Starten und Stoppen

Aus Übersicht über das Stoppen und Starten eines Aurora-DB-Clusters:

  • Cluster können nicht auf unbestimmte Zeit angehalten bleiben, da sie nach 7 Tagen automatisch gestartet werden.
  • Einzelne DB-Instanzen können nicht gestoppt werden.

Upgrades

  • In-Place-Hauptversions-Upgrades werden nicht unterstützt.
  • Änderungen an Parametergruppen für DB-Instances und DB-Cluster brauchen mindestens 5 Minuten, um weitergegeben zu werden.

Klonen

  • 15 Klone pro Datenbank (Original oder Kopie).
  • Klone werden beim Löschen der Quelldatenbank nicht entfernt.

Skalierung

  • Auto-Scaling erfordert, dass alle Replikate verfügbar sind.
  • Es kann nur `eine Autoscaling-Richtlinie`_ pro Metrik pro Cluster geben.
  • Die horizontale Skalierung der primären DB-Instance (Instance-Klasse) erfolgt nicht vollautomatisch. Vor der Skalierung löst der Cluster ein automatisches Failover auf eines der Replikate aus. Nach Abschluss der Skalierung muss die neue Instanz manuell vom Reader zum Writer heraufgestuft werden:Nach Änderung der DB-Instance-Klasse bleibt die neue Instance im Lesemodus.

Überwachung

  • Das Veröffentlichen von PostgreSQL-Protokollen in CloudWatch erfordert eine Datenbank-Engine-Mindestversion von 9.6.6 und 10.4.
  • Nur einige Aurora-Metriken sind in der RDS-Konsole verfügbar und andere Metriken haben andere Namen und Maßeinheiten.
  • Standardmäßig werden Enhanced Monitoring-Protokolle 30 Tage lang in CloudWatch aufbewahrt.
  • Die Metriken von Cloudwatch und Enhanced Monitoring unterscheiden sich, da sie Daten vom Hypervisor bzw. dem Agenten sammeln, der auf der Instanz ausgeführt wird.
  • Performance Insights_ aggregiert die Metriken über alle Datenbanken innerhalb einer DB-Instance.
  • SQL-Anweisungen sind auf 500 Zeichen beschränkt, wenn sie mit AWS Performance Insights CLI und API angezeigt werden.

Migration

  • Nur unverschlüsselte RDS-DB-Snapshots können im Ruhezustand verschlüsselt werden.
  • Migrationen mit der Aurora Read Replica-Technik dauern mehrere Stunden pro TiB.

Größe

  • Die kleinste verfügbare Instance-Klasse ist db.t3.medium und die größte db.r5.24xlarge. Zum Vergleich bietet die MySQL-Engine db.t2.small und db.t2.medium, jedoch kein db.r5.24xlarge im oberen Bereich.
  • max_connections Obergrenze ist 262.143.

Abfrageplanverwaltung

  • Anweisungen innerhalb von PL/pgSQL-Funktionen werden nicht unterstützt.

Migration

Aurora PostgreSQL bietet keine direkten Migrationsdienste, sondern die Aufgabe wird an ein spezialisiertes AWS-Produkt, nämlich AWS DMS, ausgelagert.

Schlussfolgerung

Als vollständig verwalteter Drop-in-Ersatz für das Upstream-PostgreSQL nutzt Amazon Aurora PostgreSQL die Technologien, die die AWS-Cloud antreiben, um die Komplexität zu beseitigen, die zum Einrichten von Diensten wie Auto-Skalierung, Lastausgleich für Abfragen und Low-Level-Daten erforderlich ist Replikation, inkrementelle Backups und Verschlüsselung.

Die Architektur und ein konservativer Ansatz zur Aktualisierung der PostgreSQL-Engine bieten die Leistung und die Stabilität, nach der Unternehmen von klein bis groß suchen.

Die inhärenten Einschränkungen sind nur ein Beweis dafür, dass der Aufbau einer groß angelegten Database as a Service eine komplexe Aufgabe ist, die den hochspezialisierten PostgreSQL-Hostinganbietern einen Nischenmarkt lässt, den sie erschließen können.