Cloud Vendor Deep-Dive:PostgreSQL op AWS Aurora

Hoe diep moeten we hierin gaan? Ik zal beginnen met te zeggen dat ik op het moment van schrijven slechts 3 boeken op Amazon kon vinden over PostgreSQL in de cloud, en 117 discussies over PostgreSQL-mailinglijsten over Aurora PostgreSQL. Dat lijkt niet veel, en het laat me, de nieuwsgierige PostgreSQL-eindgebruiker, achter met de officiële documentatie als de enige plek waar ik echt wat meer zou kunnen leren. Omdat ik niet het vermogen, noch de kennis heb om mezelf veel dieper te avontuur, is er AWS re:Invent 2018 voor degenen die op zoek zijn naar dat soort spanning. Ik kan genoegen nemen met Werners artikel over quorums.

Om op te warmen, begon ik vanaf de Aurora PostgreSQL-homepage, waar ik opmerkte dat de benchmark die aantoont dat Aurora PostgreSQL drie keer sneller is dan een standaard PostgreSQL die op dezelfde hardware draait, teruggaat tot PostgreSQL 9.6. Zoals ik later heb geleerd, is 9.6.9 momenteel de standaardoptie bij het opzetten van een nieuw cluster. Dat is heel goed nieuws voor degenen die niet meteen willen of kunnen upgraden. En waarom slechts 99,99% beschikbaarheid? Een verklaring is te vinden in het artikel van Bruce Momjian.

Compatibiliteit

Volgens AWS is Aurora PostgreSQL een drop-in vervanging voor PostgreSQL, en in de documentatie staat:

De code, tools en applicaties die u vandaag gebruikt met uw bestaande MySQL- en PostgreSQL-databases, kunnen worden gebruikt met Aurora.

Dat wordt versterkt door de veelgestelde vragen van Aurora:

Het betekent dat de meeste code, applicaties, stuurprogramma's en tools die u vandaag al gebruikt met uw PostgreSQL-databases, met weinig of geen verandering met Aurora kunnen worden gebruikt. De Amazon Aurora-database-engine is ontworpen om wire-compatibel te zijn met PostgreSQL 9.6 en 10, en ondersteunt dezelfde set PostgreSQL-extensies die worden ondersteund met RDS voor PostgreSQL 9.6 en 10, waardoor het eenvoudig is om applicaties tussen de twee engines te verplaatsen.

"de meeste" in de bovenstaande tekst suggereert dat er geen 100% garantie is, in welk geval degenen die zekerheid zoeken, zouden moeten overwegen technische ondersteuning aan te schaffen bij AWS Professional Services of Aamazon Aurora-partners. Even terzijde, ik heb gemerkt dat geen van de professionele PostgreSQL-hostingproviders die medewerkers van de kerngemeenschap in dienst hebben, op die lijst staan.

Van de Aurora FAQ-pagina leren we ook dat Aurora PostgreSQL dezelfde extensies ondersteunt als RDS, die op zijn beurt de meeste community-extensies en een paar extra's vermeldt.

Begrippen

Als onderdeel van Amazon RDS wordt Aurora PostgreSQL geleverd met zijn eigen terminologie:

• Cluster:een primaire DB-instantie in lees-/schrijfmodus en nul of meer Aurora-replica's. De primaire DB wordt vaak een Master genoemd in `AWS-diagrammen`_ of Writer in de AWS-console. Op basis van het referentiediagram kunnen we een interessante observatie doen:Aurora schrijft drie keer. Aangezien de latentie tussen de AZ's doorgaans hoger is dan binnen dezelfde AZ, wordt de transactie als vastgelegd beschouwd zodra deze op de gegevenskopie binnen dezelfde AZ is geschreven, anders de latentie en mogelijke uitval tussen AZ's.
• Clustervolume:virtueel database-opslagvolume dat meerdere AZ's omspant.
• Aurora-URL:een `host:poort`-paar.
• Clustereindpunt:Aurora-URL voor de primaire database. Er is één clustereindpunt.
• Reader-eindpunt:Aurora-URL voor de replicaset. Om een ​​analogie te maken met DNS is het een alias (CNAME). Leesverzoeken worden verdeeld over beschikbare replica's.
• Aangepast eindpunt:Aurora URL naar een groep bestaande uit een of meer DB-instanties.
• Instance Endpoint:Aurora URL naar een specifieke DB-instantie.
• Aurora-versie:productversie geretourneerd door `SELECT AURORA_VERSION();`.

PostgreSQL-prestaties en monitoring op AWS Aurora

Maatmaat

Aurora PostgreSQL past een configuratie naar beste schatting toe die is gebaseerd op de grootte van de DB-instantie en de opslagcapaciteit, waardoor verdere afstemming op de DBA wordt overgelaten door het gebruik van DB-parametergroepen.

Wanneer u de DB-instantie selecteert, baseert u uw selectie op de gewenste waarde voor max_connections.

Schaal

Aurora PostgreSQL biedt automatische en handmatige schaling. Horizontaal schalen van leesreplica's wordt geautomatiseerd door het gebruik van prestatiestatistieken. Verticaal schalen kan worden geautomatiseerd via API's.

Horizontaal schalen zorgt ervoor dat de computer een paar minuten offline is, terwijl de compute-engine wordt vervangen en onderhoudswerkzaamheden worden uitgevoerd (upgrades, patches). Daarom raadt AWS aan om dergelijke bewerkingen uit te voeren tijdens onderhoudsvensters.

Schalen in beide richtingen is een makkie:

Op opslagniveau wordt ruimte toegevoegd in stappen van 10G. Toegewezen opslagruimte wordt nooit teruggevorderd, zie hieronder hoe u deze beperking kunt verhelpen.

Opslag

Zoals hierboven vermeld, is Aurora PostgreSQL ontwikkeld om gebruik te maken van quorums om de prestatieconsistentie te verbeteren.

Aangezien de onderliggende opslag wordt gedeeld door alle DB-instanties binnen hetzelfde cluster, zijn er geen extra schrijfbewerkingen op stand-by-knooppunten vereist. Het toevoegen of verwijderen van DB-instanties verandert ook niets aan de onderliggende gegevens.

Benieuwd wat die IO's eenheden betekenen op de maandelijkse factuur? Aurora FAQ's komt weer te hulp om uit te leggen wat een IO is, in het kader van monitoring en facturatie. Een lees-IO als het equivalent van een 8KiB-databasepagina die wordt gelezen en een schrijf-IO als het equivalent van 4KiB dat naar de opslaglaag wordt geschreven.

Hoge gelijktijdigheid

Om optimaal te profiteren van Aurora's ontwerp met hoge gelijktijdigheid, wordt aanbevolen dat applicaties worden geconfigureerd om een ​​groot aantal gelijktijdige zoekopdrachten en transacties aan te sturen.

Toepassingen die zijn ontworpen om lees- en schrijfquery's naar respectievelijk standby- en primaire databaseknooppunten te leiden, zullen profiteren van het Aurora PostgreSQL-lezerreplica-eindpunt.

Verbindingen zijn load-balanced tussen leesreplica's.

Met behulp van aangepaste endpoints kunnen database-instanties met meer capaciteit worden gegroepeerd om een ​​intensieve werklast uit te voeren, zoals analyses.

DB Instance Endpoints kunnen worden gebruikt voor fijnmazige taakverdeling of snelle failover.

Houd er rekening mee dat om ervoor te zorgen dat de Reader-eindpunten afzonderlijke query's verdelen, elke query als een nieuwe verbinding moet worden verzonden.

Caching

Aurora PostgreSQL gebruikt een Survivable Cache Warming-techniek die ervoor zorgt dat de datum in de buffercache behouden blijft, waardoor het niet meer nodig is om de cache opnieuw te vullen of op te warmen na het opnieuw opstarten van de database.

Replicatie

De vertragingstijd van de replicatie tussen replica's wordt binnen milliseconden van één cijfer gehouden. Hoewel niet beschikbaar voor PostgreSQL, is het goed om te weten dat de replicatievertraging tussen regio's binnen 10 seconden van milliseconden wordt gehouden.

Volgens documentatie neemt de replicavertraging toe tijdens perioden van zware schrijfverzoeken.

Plannen voor het uitvoeren van query's

Op basis van de veronderstelling dat de prestaties van query's in de loop van de tijd afnemen als gevolg van verschillende databasewijzigingen, is de rol van deze Aurora PostgreSQL-component het bijhouden van een lijst met goedgekeurde of afgewezen plannen voor het uitvoeren van query's.

Plannen worden goedgekeurd of afgewezen met behulp van proactieve of reactieve methoden.

Wanneer een uitvoeringsplan wordt gemarkeerd als afgewezen, overschrijft het uitvoeringsplan voor de query de beslissingen van de PostgreSQL-optimalisatie en voorkomt het dat het "slechte" plan wordt uitgevoerd.

Deze functie vereist Aurora 2.1.0 of hoger.

Hoge beschikbaarheid en replicatie van PostgreSQL op AWS Aurora

Op de opslaglaag zorgt Aurora PostgreSQL voor duurzaamheid door elk 10 GB opslagvolume zes keer te repliceren over 3 AZ's (elke regio bestaat doorgaans uit 3 AZ's) met behulp van fysieke synchrone replicatie. Dat maakt het mogelijk dat databaseschrijfbewerkingen blijven werken, zelfs wanneer 2 kopieën van gegevens verloren gaan. Leesbeschikbaarheid overleeft het verlies van 3 kopieën van gegevens.

Leesreplica's zorgen ervoor dat een mislukte primaire instantie snel kan worden vervangen door een van de 15 beschikbare replica's te promoten. Bij het selecteren van een multi-AZ-implementatie wordt automatisch één leesreplica gemaakt. Failover vereist geen tussenkomst van de gebruiker en databasebewerkingen worden in minder dan 30 seconden hervat.

Voor implementaties met één AZ omvat de herstelprocedure een herstel vanaf de laatst bekende goede back-up. Volgens de veelgestelde vragen van Aurora is het proces in minder dan 15 minuten voltooid als de database in een ander AZ moet worden hersteld. De documentatie is niet zo specifiek en beweert dat het minder dan 10 minuten duurt om het herstelproces te voltooien.

Er is geen wijziging vereist aan de toepassingskant om verbinding te maken met de nieuwe DB-instantie, aangezien het clustereindpunt niet verandert tijdens een replica-promotie of instantieherstel.

Stap 1:verwijder de primaire instantie om een ​​failover te forceren:

Stap 2:automatische failover voltooid

Voor drukke databases wordt de hersteltijd na een herstart of crash drastisch verminderd, aangezien Aurora PostgreSQL de transactielogboeken niet opnieuw hoeft af te spelen.

Als onderdeel van een volledig beheerde service worden slechte datablokken en schijven automatisch vervangen.

Failover wanneer er replica's bestaan, duurt maximaal 120 seconden met vaak minder dan 60 seconden. Snellere hersteltijden kunnen worden bereikt wanneer de failover-voorwaarden vooraf zijn bepaald, in welk geval aan replica's failover-prioriteiten kunnen worden toegewezen.

Aurora PostgreSQL speelt goed met Amazon RDS - een Aurora-instantie kan fungeren als een leesreplica voor een primaire RDS-instantie.

Aurora PostgreSQL ondersteunt logische replicatie die, net als in de communityversie, kan worden gebruikt om ingebouwde replicatiebeperkingen te omzeilen. Er is geen automatisering of AWS-console-interface.

Beveiliging voor PostgreSQL op AWS Aurora

Op netwerkniveau maakt Aurora PostgreSQL gebruik van AWS-kerncomponenten, VPC voor isolatie van cloudnetwerken en beveiligingsgroepen voor netwerktoegangscontrole.

Er is geen superuser-toegang. Bij het maken van een cluster maakt Aurora PostgreSQL een hoofdaccount aan met een subset van superuser-machtigingen:

[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  |                 |

Om gegevens tijdens het transport te beveiligen, biedt Aurora PostgreSQL native SSL/TLS-ondersteuning die kan worden geconfigureerd per DB-instantie.

Alle gegevens in rust kunnen worden versleuteld met minimale prestatie-impact. Dit geldt ook voor back-ups, snapshots en replica's.

Verificatie wordt beheerd door IAM-beleid en tagging biedt meer controle over wat gebruikers mogen doen en op welke bronnen.

API-aanroepen die door alle cloudservices worden gebruikt, worden geregistreerd in CloudTrail.

Beperkt wachtwoordbeheer aan de clientzijde is beschikbaar via de parameter rds.restrict_password_commands.

PostgreSQL-back-up en herstel op AWS Aurora

Back-ups zijn standaard ingeschakeld en kunnen niet worden uitgeschakeld. Ze bieden herstel op een bepaald tijdstip met een volledige dagelijkse momentopname als basisback-up.

Herstellen vanaf een geautomatiseerde back-up heeft een aantal nadelen:de hersteltijd kan enkele uren in beslag nemen en gegevensverlies kan tot 5 minuten voorafgaand aan de storing zijn. Amazon RDS Multi-AZ-implementaties lossen dit probleem op door een leesreplica te promoveren naar primair, zonder gegevensverlies.

Database-snapshots zijn snel en hebben geen invloed op de clusterprestaties. Ze kunnen worden gekopieerd of gedeeld met andere gebruikers.

Het maken van een momentopname is bijna onmiddellijk:

Het herstellen van een snapshot gaat ook snel. Vergelijk met PITR:

Back-ups en snapshots worden opgeslagen in S3, die elf 9's duurzaamheid biedt.

Afgezien van back-ups en snapshots, maakt Aurora PostgreSQL het mogelijk databases te klonen. Dit is een efficiënte methode om kopieën van grote datasets te maken. Het klonen van meerdere terabytes aan gegevens duurt bijvoorbeeld slechts enkele minuten en heeft geen invloed op de prestaties.

Aurora PostgreSQL - Point-in-Time Recovery Demo

Verbinding maken met cluster:

~ $ 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.

Vul een tabel met gegevens:

[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)

Start het herstel:

Zodra het herstel is voltooid, logt u in en controleert u:

~ $ 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)

Beste praktijken

Bewaking en controle

• Integreer database-activiteitsstromen met monitoring van derden om database-activiteit te controleren op naleving en wettelijke vereisten.
• Een volledig beheerde databaseservice betekent niet een gebrek aan verantwoordelijkheid - definieer meetwaarden om de CPU-, RAM-, schijfruimte-, netwerk- en databaseverbindingen te bewaken.
• Aurora PostgreSQL kan worden geïntegreerd met de AWS-standaard monitoringtool CloudWatch, en biedt ook extra monitoren voor Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL-replicatie, en ook voor RDS Metrics die verder kunnen worden gegroepeerd op RDS Dimensions.
• Bewaak het gemiddelde aantal actieve sessies DB Load by Wacht op tekenen van overhead voor verbindingen, SQL-query's die moeten worden aangepast, resourceconflicten of een ondermaatse DB-instantieklasse.
• Gebeurtenismeldingen instellen.
• Configureer foutenlogboekparameters.
• Bewaak configuratiewijzigingen in databaseclustercomponenten:instanties, subnetgroepen, snapshots, beveiligingsgroepen.

Replicatie

• Gebruik native tabelpartitionering voor workloads die de maximale DB-instantieklasse en opslagcapaciteit overschrijden

Encryptie

• Voor de versleutelde database moeten back-ups zijn ingeschakeld om ervoor te zorgen dat gegevens kunnen worden hersteld in het geval dat de encryptiesleutel wordt ingetrokken.

Hoofdaccount

• Gebruik psql niet om het hoofdgebruikerswachtwoord te wijzigen.

Maatmaat

• Overweeg om verschillende instantieklassen in een cluster te gebruiken om de kosten te verlagen.

Parametergroepen

• Verfijn met behulp van parametergroepen om $$$ te besparen.

Demo parametergroepen

Huidige instellingen:

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

Maak een nieuwe parametergroep en stel de nieuwe clusterbrede waarde in:

Koppel de aangepaste parametergroep aan het cluster:

Start de schrijver opnieuw op en controleer de waarde:

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

• Stel de lokale tijdzone in

De tijdzone is standaard in UTC:

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

De nieuwe tijdzone instellen:

En controleer dan:

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

Houd er rekening mee dat de lijst met tijdzonewaarden die door Amazon Aurora wordt geaccepteerd, niet de tijdzonesets zijn die worden gevonden in upstream PostgreSQL.

• Bekijk instantieparameters die worden overschreven door clusterparameters
• Gebruik de tool voor het vergelijken van parametergroepen.

Momentopnamen

• Vermijd extra opslagkosten door de snapshots te delen met andere accounts zodat ze kunnen worden hersteld in hun respectievelijke omgevingen.

Onderhoud

• Wijzig de standaard onderhoudsperiode volgens het schema van de organisatie.

Failover

• Verbeter de hersteltijd door Cluster Cache Management te configureren.
• Verlaag de kernel-TCP keepalive-waarden op de client en configureer de applicatie DNS-cache en TTL, en PostgreSQL-verbindingsreeksen.

DBA Pas op!

Vermijd, naast de bekende beperkingen, het volgende, of let op:

Encryptie

• Als een database eenmaal is gemaakt, kan de coderingsstatus niet meer worden gewijzigd.

Aurora Serverloos

• Op dit moment is de PostgreSQL-versie van Aurora Serverless alleen beschikbaar in beperkte preview.

Parallelle zoekopdracht

• Amazon Parallel Query is niet beschikbaar, hoewel de functie met dezelfde naam beschikbaar is sinds PostgreSQL 9.6.

Eindpunten

Van Amazon Connection Management:

• 5 aangepaste eindpunten per cluster
• Aangepaste eindpuntnamen mogen niet langer zijn dan 63 tekens
• Clustereindpuntnamen zijn uniek binnen dezelfde regio
• Zoals te zien is in de bovenstaande schermafbeelding (aurora-custom-endpoint-details) READER en ELKE custom endpoint-types zijn niet beschikbaar, gebruik de CLI
• Aangepaste eindpunten weten niet dat replica's tijdelijk niet meer beschikbaar zijn

Replicatie

• Bij het promoten van een replica naar primair, kunnen verbindingen via het Reader-eindpunt nog een korte tijd worden omgeleid naar de gepromote replica.
• Replica's in verschillende regio's worden niet ondersteund
• Hoewel het eind november 2017 werd uitgebracht, is de Amazon Aurora Multi-Master-preview nog steeds niet beschikbaar voor PostgreSQL
• Let op prestatievermindering wanneer logische replicatie is ingeschakeld op het cluster.
• Voor logische replicatie is een gepubliceerde, draaiende PostgreSQL-engine 10.6 of hoger vereist.

Opslag

• De maximale toegewezen opslagruimte wordt niet kleiner wanneer gegevens worden verwijderd, en er wordt ook geen ruimte teruggewonnen door te herstellen vanaf snapshots. De enige manier om ruimte terug te winnen is door een logische dump in een nieuw cluster uit te voeren.

Back-up en herstel

• Het bewaren van back-ups wordt niet verlengd als het cluster is gestopt.
• Maximale bewaarperiode is 35 dagen — gebruik handmatige momentopnamen voor een langere bewaarperiode.
• point-in-time herstel herstelt naar een nieuw DB-cluster.
• korte onderbreking van het lezen tijdens failover naar replica's.
• Scenario's voor noodherstel zijn niet beschikbaar voor regio's.

Momentopnamen

• Herstellen vanaf snapshot creëert een nieuw eindpunt (snapshots kunnen alleen worden hersteld naar een nieuw cluster).
• Na een snapshotherstel moeten aangepaste eindpunten opnieuw worden gemaakt.
• Herstellen vanaf snapshots reset de lokale tijdzone naar UTC.
• Herstellen vanaf momentopnamen behoudt de aangepaste beveiligingsgroepen niet.
• Momentopnamen kunnen worden gedeeld met maximaal 20 AWS-account-ID's.
• Momentopnamen kunnen niet tussen regio's worden gedeeld.
• Incrementele snapshots worden altijd gekopieerd als volledige snapshots, tussen regio's en binnen dezelfde regio.
• Het kopiëren van snapshots tussen regio's behoudt de niet-standaard parametergroepen niet.

Facturering

• De rekening van 10 minuten is van toepassing op nieuwe instanties, maar ook na een capaciteitswijziging (rekenkracht of opslag).

Verificatie

• Het gebruik van IAM-databaseverificatie legt een limiet op het aantal verbindingen per seconde.
• Voor het hoofdaccount zijn bepaalde superuser-privileges ingetrokken.

Starten en stoppen

Uit overzicht van stoppen en staren naar een Aurora DB-cluster:

• Clusters kunnen niet voor onbepaalde tijd worden gestopt omdat ze automatisch worden gestart na 7 dagen.
• Individuele DB-instanties kunnen niet worden gestopt.

Upgrades

• In-place grote versie-upgrades worden niet ondersteund.
• Parametergroepwijzigingen voor zowel DB-instantie als DB-cluster duren ten minste 5 minuten om door te voeren.

Klonen

• 15 klonen per database (origineel of kopie).
• Klonen worden niet verwijderd bij het verwijderen van de brondatabase.

Schaal

• Voor automatisch schalen moeten alle replica's beschikbaar zijn.
• Er kan slechts `één beleid voor automatisch schalen`_ per metriek per cluster zijn.
• Horizontaal schalen van de primaire DB-instantie (instantieklasse) is niet volledig automatisch. Voordat het cluster wordt geschaald, wordt een automatische failover naar een van de replica's geactiveerd. Nadat het schalen is voltooid, moet de nieuwe instantie handmatig worden gepromoveerd van lezer naar schrijver:Nieuwe instantie achtergelaten in leesmodus na wijziging van klasse van DB-instantie.

Bewaking

• Het publiceren van PostgreSQL-logboeken naar CloudWatch vereist een minimale database-engineversie van 9.6.6 en 10.4.
• Er zijn slechts enkele Aurora-statistieken beschikbaar in de RDS-console en andere statistieken hebben andere namen en meeteenheden.
• Standaard worden Enhanced Monitoring-logboeken 30 dagen bewaard in CloudWatch.
• De statistieken van Cloudwatch en Enhanced Monitoring zullen verschillen, aangezien ze gegevens verzamelen van de hypervisor en respectievelijk de agent die op de instantie draait.
• Performance Insights_ verzamelt de statistieken over alle databases binnen een DB-instantie.
• SQL-statements zijn beperkt tot 500 tekens wanneer ze worden bekeken met AWS Performance Insights CLI en API.

Migratie

• Alleen RDS-niet-versleutelde DB-snapshots kunnen in rust worden versleuteld.
• Migraties met behulp van de Aurora Read Replica-techniek duren enkele uren per TiB.

Maatmaat

• De kleinste beschikbare instantieklasse is db.t3.medium en de grootste db.r5.24xlarge. Ter vergelijking:de MySQL-engine biedt db.t2.small en db.t2.medium, maar geen db.r5.24xlarge in het hogere bereik.
• max_connections bovengrens is 262.143.

Beheer van queryplan

• Statements binnen PL/pgSQL-functies worden niet ondersteund.

Migratie

Aurora PostgreSQL biedt geen directe migratieservices, maar de taak wordt overgedragen aan een gespecialiseerd AWS-product, namelijk AWS DMS.

Conclusie

Als een volledig beheerde drop-in-vervanging voor de upstream PostgreSQL, maakt Amazon Aurora PostgreSQL gebruik van de technologieën die de AWS-cloud aandrijven om de complexiteit weg te nemen die nodig is om services in te stellen, zoals automatisch schalen, taakverdeling voor query's, gegevens op laag niveau replicatie, incrementele back-ups en codering.

De architectuur en een conservatieve benadering voor het upgraden van de PostgreSQL-engine biedt de prestaties en de stabiliteit die organisaties van klein tot groot zoeken.

De inherente beperkingen zijn slechts een bewijs dat het bouwen van een grootschalige Database as a Service een complexe taak is, waardoor de zeer gespecialiseerde PostgreSQL-hostingproviders een nichemarkt hebben die ze kunnen aanboren.