Hur djupt ska vi gå med detta? Jag börjar med att säga att när detta skrivs kunde jag bara hitta 3 böcker på Amazon om PostgreSQL i molnet, och 117 diskussioner på PostgreSQL e-postlistor om Aurora PostgreSQL. Det ser inte ut som mycket, och det lämnar mig, den nyfikna PostgreSQL-slutanvändaren, med den officiella dokumentationen som det enda stället där jag verkligen kunde lära mig mer. Eftersom jag inte har förmågan eller kunskapen att äventyra mig mycket djupare, finns det AWS re:Invent 2018 för dem som letar efter den typen av spänning. Jag kan nöja mig med Werners artikel om kvorum.
För att bli uppvärmd började jag från Aurora PostgreSQL-hemsidan där jag noterade att riktmärket som visar att Aurora PostgreSQL är tre gånger snabbare än en standard PostgreSQL som körs på samma hårdvara går tillbaka till PostgreSQL 9.6. Som jag har lärt mig senare är 9.6.9 för närvarande standardalternativet när du konfigurerar ett nytt kluster. Det är mycket goda nyheter för dem som inte vill eller inte kan uppgradera direkt. Och varför bara 99,99% tillgänglighet? En förklaring finns i Bruce Momjians artikel.
Kompatibilitet
Enligt AWS är Aurora PostgreSQL en drop-in-ersättning för PostgreSQL, och dokumentationen säger:
Koden, verktygen och applikationerna du använder idag med dina befintliga MySQL- och PostgreSQL-databaser kan användas med Aurora.
Det förstärks av Auroras vanliga frågor:
Det betyder att det mesta av koden, applikationerna, drivrutinerna och verktygen du redan använder idag med dina PostgreSQL-databaser kan användas med Aurora med liten eller ingen förändring. Amazon Aurora-databasmotorn är designad för att vara trådkompatibel med PostgreSQL 9.6 och 10, och stöder samma uppsättning PostgreSQL-tillägg som stöds med RDS för PostgreSQL 9.6 och 10, vilket gör det enkelt att flytta applikationer mellan de två motorerna.
"de flesta" i texten ovan antyder att det inte finns en 100 % garanti i vilket fall de som söker säkerhet bör överväga att köpa teknisk support från antingen AWS Professional Services eller Aamazon Aurora-partners. Som en sidoanteckning märkte jag att ingen av PostgreSQL-professionella värdleverantörer som anställer kärngemenskapsbidragsgivare finns på den listan.
Från sidan med vanliga frågor om Aurora får vi också veta att Aurora PostgreSQL stöder samma tillägg som RDS, som i sin tur listar de flesta communitytilläggen och några extrafunktioner.
Koncept
Som en del av Amazon RDS kommer Aurora PostgreSQL med sin egen terminologi:
- Kluster:En primär DB-instans i läs-/skrivläge och noll eller fler Aurora-repliker. Den primära DB är ofta märkt som en Master i `AWS-diagram`_, eller Writer i AWS-konsolen. Utifrån referensdiagrammet kan vi göra en intressant observation:Aurora skriver tre gånger. Eftersom latensen mellan A-Ö vanligtvis är högre än inom samma A-Ö, anses transaktionen vara genomförd så snart den skrivs på datakopian inom samma A-Ö, annars fördröjningen och potentiella avbrott mellan A-Ö.
- Klustervolym:Virtuell databaslagringsvolym som spänner över flera A-Ö.
- Aurora URL:Ett `värd:port`-par.
- Klusterslutpunkt:Aurora-URL för den primära databasen. Det finns en klusterändpunkt.
- Läsarslutpunkt:Aurora-URL för replikuppsättningen. För att göra en analogi med DNS är det ett alias (CNAME). Läsbegäranden är belastningsbalanserade mellan tillgängliga repliker.
- Anpassad slutpunkt:Aurora-URL till en grupp som består av en eller flera DB-instanser.
- Instansslutpunkt:Aurora-URL till en specifik DB-instans.
- Aurora-version:Produktversionen returneras av `SELECT AURORA_VERSION();`.
PostgreSQL-prestanda och övervakning på AWS Aurora
Storlek
Aurora PostgreSQL tillämpar en bästa gissningskonfiguration som är baserad på DB-instansens storlek och lagringskapacitet, vilket lämnar ytterligare inställning till DBA genom att använda DB-parametergrupper.
När du väljer DB-instansen, basera ditt val på det önskade värdet för max_connections.
Skalning
Aurora PostgreSQL har automatisk och manuell skalning. Horisontell skalning av läsrepliker automatiseras genom användning av prestandamått. Vertikal skalning kan automatiseras via API:er.
Horisontell skalning tar offline i några minuter medan beräkningsmotorn byts ut och underhållsåtgärder utförs (uppgraderingar, lappar). Därför rekommenderar AWS att du utför sådana operationer under underhållsfönster.
Det går enkelt att skala åt båda hållen:
Vertikal skalning:ändrar instansklass 
Horisontell skalning:lägger till läsarreplik. På lagringsnivå läggs utrymme till i steg om 10G. Tilldelad lagring återvinns aldrig, se nedan för hur du åtgärdar denna begränsning.
Lagring
Som nämnts ovan, konstruerades Aurora PostgreSQL för att dra fördel av kvorum för att förbättra prestandakonsistensen.
Eftersom den underliggande lagringen delas av alla DB-instanser inom samma kluster, krävs inga ytterligare skrivningar på standbynoder. Att lägga till eller ta bort DB-instanser ändrar inte heller de underliggande data.
Undrar vad dessa IOs enheter betyder på månadsräkningen? Aurora FAQs kommer till undsättning igen för att förklara vad en IO är, i samband med övervakning och fakturering. En Read IO som motsvarigheten till en 8KiB databassida läst, och en Write IO som motsvarigheten till 4KiB skriven till lagringslagret.
Hög samtidighet
För att kunna dra full nytta av Auroras design med hög samtidighet, rekommenderas det att applikationer konfigureras för att driva ett stort antal samtidiga frågor och transaktioner.
Applikationer utformade för att dirigera läs- och skrivfrågor till standby- respektive primära databasnoder kommer att dra nytta av Aurora PostgreSQL-läsarreplikslutpunkt.
Anslutningar är lastbalanserade mellan läsrepliker.
Genom att använda anpassade slutpunkter kan databasinstanser med större kapacitet grupperas för att köra en intensiv arbetsbelastning som analys.
DB Instance Endpoints kan användas för finkornig lastbalansering eller snabb failover.
Observera att för att Reader Endpoints ska kunna lastbalansera enskilda frågor måste varje fråga skickas som en ny anslutning.
Cachning
Aurora PostgreSQL använder en Survivable Cache Warming-teknik som säkerställer att datumet i buffertcachen bevaras, vilket eliminerar behovet av att fylla på eller värma upp cachen efter en omstart av databasen.
Replikering
Replikeringsfördröjningen mellan replikerna hålls inom ensiffrig millisekund. Även om det inte är tillgängligt för PostgreSQL, är det bra att veta att replikeringsfördröjning mellan regioner hålls inom 10s av millisekunder.
Enligt dokumentationen ökar replikfördröjningen under perioder med tunga skrivförfrågningar.
Frågeexekveringsplaner
Baserat på antagandet att frågeprestanda försämras med tiden på grund av olika databasändringar, är rollen för denna Aurora PostgreSQL-komponent att upprätthålla en lista över godkända eller avvisade frågekörningsplaner.
Planer godkänns eller avvisas med antingen proaktiva eller reaktiva metoder.
När en exekveringsplan markeras som avvisad åsidosätter Query Execution Plan PostgreSQL-optimerarens beslut och förhindrar att den "dåliga" planen exekveras.
Den här funktionen kräver Aurora 2.1.0 eller senare.
PostgreSQL hög tillgänglighet och replikering på AWS Aurora
På lagringslagret säkerställer Aurora PostgreSQL hållbarhet genom att replikera varje 10 GB lagringsvolym, sex gånger över 3 A-Ö (varje region består vanligtvis av 3 A-Ö) med hjälp av fysisk synkron replikering. Det gör det möjligt för databasskrivningar att fortsätta fungera även när 2 kopior av data går förlorade. Lästillgänglighet överlever förlusten av 3 kopior av data.
Läs repliker säkerställer att en misslyckad primär instans snabbt kan ersättas genom att marknadsföra en av de 15 tillgängliga replikerna. När du väljer en multi-AZ-distribution skapas en läsreplika automatiskt. Failover kräver inget användaringripande och databasoperationer återupptas på mindre än 30 sekunder.
För en-AZ-distributioner inkluderar återställningsproceduren en återställning från den senast kända bra säkerhetskopian. Enligt Auroras vanliga frågor slutförs processen på mindre än 15 minuter om databasen behöver återställas i en annan A-Ö. Dokumentationen är inte så specifik och hävdar att det tar mindre än 10 minuter att slutföra återställningsprocessen.
Ingen ändring krävs på applikationssidan för att ansluta till den nya DB-instansen eftersom klustrets slutpunkt inte ändras under en replikkampanj eller instansåterställning.
Steg 1:ta bort den primära instansen för att tvinga fram en failover:
Automatisk failover Steg 1:ta bort primär Steg 2:automatisk failover slutförd
Automatisk failover Steg 2:failover slutförd. För upptagna databaser reduceras återställningstiden efter en omstart eller krasch dramatiskt eftersom Aurora PostgreSQL inte behöver spela upp transaktionsloggarna igen.
Som en del av fullständigt hanterad tjänst ersätts dåliga datablock och diskar automatiskt.
Failover när repliker finns tar upp till 120 sekunder, ofta under 60 sekunder. Snabbare återställningstider kan uppnås när failover-villkor är förutbestämda, i vilket fall repliker kan tilldelas failover-prioriteter.
Aurora PostgreSQL spelar bra med Amazon RDS – en Aurora-instans kan fungera som en läsreplika för en primär RDS-instans.
Aurora PostgreSQL stöder logisk replikering som, precis som i communityversionen, kan användas för att övervinna inbyggda replikeringsbegränsningar. Det finns ingen automatisering eller AWS-konsolgränssnitt.
Säkerhet för PostgreSQL på AWS Aurora
På nätverksnivå använder Aurora PostgreSQL AWS kärnkomponenter, VPC för molnnätverksisolering och säkerhetsgrupper för nätverksåtkomstkontroll.
Det finns ingen superanvändaråtkomst. När du skapar ett kluster skapar Aurora PostgreSQL ett huvudkonto med en undergrupp av superanvändarbehörigheter:
[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 | |För att säkra data under överföring tillhandahåller Aurora PostgreSQL inbyggt SSL/TLS-stöd som kan konfigureras per DB-instans.
All data i vila kan krypteras med minimal prestandapåverkan. Detta gäller även säkerhetskopior, ögonblicksbilder och repliker.
Kryptering i vila. Autentisering styrs av IAM-policyer och taggning ger ytterligare kontroll över vad användare får göra och på vilka resurser.
API-anrop som används av alla molntjänster loggas i CloudTrail.
Begränsad lösenordshantering på klientsidan är tillgänglig via parametern rds.restrict_password_commands.
PostgreSQL säkerhetskopiering och återställning på AWS Aurora
Säkerhetskopiering är aktiverat som standard och kan inte inaktiveras. De tillhandahåller punkt-i-tid-återställning med hjälp av en fullständig daglig ögonblicksbild som en bas backup.
Återställning från en automatisk säkerhetskopia har ett par nackdelar:återställningstiden kan vara flera timmar och dataförlust kan vara upp till 5 minuter före avbrottet. Amazon RDS Multi-AZ-distributioner löser detta problem genom att främja en läsreplika till primär, utan dataförlust.
Databasögonblicksbilder är snabba och påverkar inte klustrets prestanda. De kan kopieras eller delas med andra användare.
Att ta en ögonblicksbild är nästan omedelbart:
Snapshottid. Det går också snabbt att återställa en ögonblicksbild. Jämför med PITR:
Säkerhetskopieringar och ögonblicksbilder lagras i S3 som erbjuder elva 9:or av hållbarhet.
Bortsett från säkerhetskopior och ögonblicksbilder tillåter Aurora PostgreSQL att databaser kan klonas. Detta är en effektiv metod för att skapa kopior av stora datamängder. Till exempel tar kloning av flera terabyte data bara några minuter och det påverkar inte prestanda.
Aurora PostgreSQL - Point-in-Time Recovery Demo
Ansluter till kluster:
~ $ 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.Fyll i en tabell med data:
[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)Starta återställningen:
Point-in-Time Recovery:initiera återställning. 
När återställningen är klar logga in och kontrollera:
~ $ 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)Bästa metoder
Övervakning och revision
- Integrera databasaktivitetsströmmar med tredjepartsövervakning för att övervaka databasaktivitet för efterlevnad och regulatoriska krav.
- En fullständigt hanterad databastjänst betyder inte brist på ansvar – definiera mätvärden för att övervaka CPU, RAM, diskutrymme, nätverk och databasanslutningar.
- Aurora PostgreSQL integreras med AWS-standardövervakningsverktyget CloudWatch, samt tillhandahåller ytterligare monitorer för Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL-replikering och även för RDS-mått som kan grupperas ytterligare efter RDS-dimensioner.
- Övervaka genomsnittliga aktiva sessioner DB laddas genom att vänta på tecken på anslutningar, SQL-frågor som behöver justering, resurskonflikt eller en underdimensionerad DB-instansklass.
- Konfigurera händelseaviseringar.
- Konfigurera felloggparametrar.
- Övervaka konfigurationsändringar av databasklusterkomponenter:instanser, undernätsgrupper, ögonblicksbilder, säkerhetsgrupper.
Replikering
- Använd inbyggd tabellpartitionering för arbetsbelastningar som överskrider den maximala DB-instansklassen och lagringskapaciteten
Kryptering
- Krypterad databas måste ha säkerhetskopior aktiverade för att säkerställa att data kan återställas om krypteringsnyckeln återkallas.
Masterkonto
- Använd inte psql för att ändra huvudanvändarlösenordet.
Storlek
- Överväg att använda olika instansklasser i ett kluster för att minska kostnaderna.
Parametergrupper
- Finjustera med hjälp av parametergrupper för att spara $$$.
Demo av parametergrupper
Aktuella inställningar:
[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)Skapa en ny parametergrupp och ställ in det nya klusteromfattande värdet:
Uppdaterar delade_buffertar-klustret. Associera den anpassade parametergruppen med klustret:
Starta om skrivaren och kontrollera värdet:
[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)- Ställ in den lokala tidszonen
Som standard är tidszonen i UTC:
[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)Ställa in den nya tidszonen:
Konfigurera tidszon Och kontrollera sedan:
[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)Observera att listan över tidszonsvärden som accepteras av Amazon Aurora inte är de tidszonuppsättningar som finns i uppströms PostgreSQL.
- Granska instansparametrar som åsidosätts av klusterparametrar
- Använd verktyget för jämförelse av parametergrupper.
Ögonblicksbilder
- Undvik ytterligare lagringskostnader genom att dela ögonblicksbilderna med andra konton för att möjliggöra återställning till deras respektive miljöer.
Underhåll
- Ändra standardunderhållsfönstret enligt organisationens schema.
Failover
- Förbättra återställningstiden genom att konfigurera Cluster Cache Management.
- Sänk kärnans TCP Keepalive-värden på klienten och konfigurera applikationens DNS-cache och TTL- och PostgreSQL-anslutningssträngar.
DBA Akta dig!
Utöver de kända begränsningarna undvik eller var medveten om följande:
Kryptering
- När en databas väl har skapats kan krypteringsläget inte ändras.
Aurora Serverless
- För närvarande är PostgreSQL-versionen av Aurora Serverless endast tillgänglig i begränsad förhandsvisning.
Parallell fråga
- Amazon Parallel Query är inte tillgänglig, även om funktionen med samma namn är tillgänglig sedan PostgreSQL 9.6.
Slutpunkter
Från Amazon Connection Management:
- 5 anpassade slutpunkter per kluster
- Anpassade slutpunktsnamn får inte överstiga 63 tecken
- Klusterslutpunktsnamn är unika inom samma region
- Som framgår av skärmdumpen ovan (aurora-custom-endpoint-details) READER och EVENTUELLA anpassade slutpunktstyper är inte tillgängliga, använd CLI
- Anpassade slutpunkter är omedvetna om att repliker blir tillfälligt otillgängliga
Replikering
- När du marknadsför en replik till Primär kan anslutningar via Reader Endpoint fortsätta att dirigeras under en kort stund till den marknadsförda repliken.
- Replika över regioner stöds inte
- Medan den släpptes i slutet av november 2017 är Amazon Aurora Multi-Master-förhandsvisningen fortfarande inte tillgänglig för PostgreSQL
- Se efter prestandaförsämring när logisk replikering är aktiverad i klustret.
- Logisk replikering kräver en publicerad PostgreSQL-motor 10.6 eller senare.
Lagring
- Maximalt tilldelat lagringsutrymme krymper inte när data raderas, och utrymmet återtas inte heller genom återställning från ögonblicksbilder. Det enda sättet att återta utrymme är genom att utföra en logisk dumpning till ett nytt kluster.
Säkerhetskopiering och återställning
- Säkerhetskopiering förlängs inte när klustret är stoppat.
- Maximal lagringsperiod är 35 dagar – använd manuella ögonblicksbilder för en längre lagringsperiod.
- återställning vid tidpunkten återställs till ett nytt DB-kluster.
- kort avbrott av läsningar under failover till repliker.
- Scenarier för katastrofåterställning är inte tillgängliga över regioner.
Ögonblicksbilder
- Återställning från ögonblicksbild skapar en ny slutpunkt (ögonblicksbilder kan bara återställas till ett nytt kluster).
- Efter en ögonblicksbildsåterställning måste anpassade slutpunkter återskapas.
- Återställning från ögonblicksbilder återställer den lokala tidszonen till UTC.
- Återställning från ögonblicksbilder bevarar inte de anpassade säkerhetsgrupperna.
- Ögonblicksbilder kan delas med maximalt 20 AWS-konto-ID.
- Ögonblicksbilder kan inte delas mellan regioner.
- Inkrementella ögonblicksbilder kopieras alltid som fullständiga ögonblicksbilder, mellan regioner och inom samma region.
- Att kopiera ögonblicksbilder över regioner bevarar inte de icke-standardparametergrupper.
Fakturering
- 10-minutersräkningen gäller för nya instanser, såväl som efter en kapacitetsändring (dator eller lagring).
Autentisering
- Användning av IAM-databasautentisering innebär en gräns för antalet anslutningar per sekund.
- Masterkontot har återkallat vissa superanvändarbehörigheter.
Starta och stoppa
Från översikt över att stoppa och stirra ett Aurora DB-kluster:
- Kluster kan inte lämnas stoppade på obestämd tid eftersom de startas automatiskt efter 7 dagar.
- Enskilda DB-instanser kan inte stoppas.
Uppgraderingar
- Större versionsuppgraderingar på plats stöds inte.
- Parametergruppändringar för både DB-instansen och DB-klustret tar minst 5 minuter att spridas.
Klonning
- 15 kloner per databas (original eller kopia).
- Kloner tas inte bort när källdatabasen tas bort.
Skalning
- Automatisk skalning kräver att alla repliker är tillgängliga.
- Det kan bara finnas en "automatisk skalningspolicy"_ per mätvärde per kluster.
- Horisontell skalning av den primära DB-instansen (instansklassen) är inte helt automatisk. Innan skalning utlöser klustret en automatisk failover till en av replikerna. När skalningen är klar måste den nya instansen flyttas upp manuellt från läsare till författare:
Ny instans kvar i läsarläge efter DB-instansklassändring.
Övervakning
- Att publicera PostgreSQL-loggar till CloudWatch kräver en minsta databasmotorversion 9.6.6 och 10.4.
- Endast vissa Aurora-mått är tillgängliga i RDS-konsolen och andra mätvärden har andra namn och måttenheter.
- Som standard sparas loggar för förbättrad övervakning i CloudWatch i 30 dagar.
- Mätvärden för Cloudwatch och Enhanced Monitoring kommer att skilja sig, eftersom de samlar in data från hypervisorn respektive agenten som körs på instansen.
- Performance Insights_ samlar mätvärdena över alla databaser i en DB-instans.
- SQL-satser är begränsade till 500 tecken när de visas med AWS Performance Insights CLI och API.
Migrering
- Endast RDS okrypterade DB Snapshots kan krypteras i vila.
- Migrationer med Aurora Read Replica-tekniken tar flera timmar per TiB.
Storlek
- Den minsta tillgängliga instansklassen är db.t3.medium och den största db.r5.24xlarge. Som jämförelse erbjuder MySQL-motorn db.t2.small och db.t2.medium, dock ingen db.r5.24xlarge i det övre intervallet.
- max_connections övre gräns är 262 143.
Frågeplanshantering
- Uttalanden i PL/pgSQL-funktioner stöds inte.
Migrering
Aurora PostgreSQL tillhandahåller inga direkta migreringstjänster, utan uppgiften överförs till en specialiserad AWS-produkt, nämligen AWS DMS.
Slutsats
Som en fullt hanterad drop-in-ersättning för uppströms PostgreSQL, drar Amazon Aurora PostgreSQL fördel av de teknologier som driver AWS-molnet för att ta bort komplexiteten som krävs för att konfigurera tjänster som automatisk skalning, belastningsbalansering av frågor, lågnivådata replikering, inkrementella säkerhetskopior och kryptering.
Arkitekturen och ett konservativt tillvägagångssätt för att uppgradera PostgreSQL-motorn ger prestanda och stabilitet som organisationer från små till stora letar efter.
De inneboende begränsningarna är bara ett bevis på att att bygga en storskalig Databas as a Service är en komplex uppgift, vilket lämnar de högt specialiserade PostgreSQL-värdleverantörerna med en nischmarknad de kan utnyttja.