AWS PostgreSQL-tjenester falder ind under RDS-paraplyen, som er Amazons DaaS-tilbud til alle kendte databasemotorer.
Administrerede databasetjenester tilbyder visse fordele, der appellerer til kunden, der søger uafhængighed af infrastrukturvedligeholdelse og meget tilgængelige konfigurationer. Som altid er der ikke en løsning, der passer til alle. De aktuelt tilgængelige muligheder er fremhævet nedenfor:
Aurora PostgreSQL
Amazon Aurora FAQ-siden giver vigtige detaljer, der skal overvejes, før du dykker ned i produktet. For eksempel lærer vi, at lagerlaget er virtualiseret og sidder på et proprietært virtualiseret lagersystem, der er sikkerhedskopieret af SSD.
Priser
Med hensyn til prisfastsættelse skal det bemærkes, at Aurora PostgreSQL ikke er tilgængelig i AWS Free Tier.
Kompatibilitet
Den samme FAQ-side gør det klart, at Amazon ikke hævder 100% PostgreSQL-kompatibilitet. De fleste (min fremhævelse) af ansøgningerne vil være fine, f.eks. AWS PostgreSQL-smag er trådkompatibel med PostgreSQL 9.6. Som et resultat vil Wireshark PostgreSQL Dissector fungere fint.
Ydeevne
Ydeevne er også knyttet til instanstypen, for eksempel er det maksimale antal forbindelser som standard konfigureret baseret på instansstørrelsen.
Også vigtigt, når det kommer til kompatibilitet, er sidestørrelsen, der er blevet holdt på 8KiB, hvilket er PostgreSQL-standardsidestørrelsen. Når vi taler om sider, er det værd at citere ofte stillede spørgsmål:"I modsætning til traditionelle databasemotorer skubber Amazon Aurora aldrig modificerede databasesider til lagerlaget, hvilket resulterer i yderligere IO-forbrugsbesparelser. ” Dette er gjort muligt, fordi Amazon ændrede måden, sidecachen administreres på, så den forbliver i hukommelsen i tilfælde af databasefejl. Denne funktion gavner også genstart af databasen efter et nedbrud, hvilket tillader gendannelsen at ske meget hurtigere end ved den traditionelle metode til genafspilning af logfilerne.
I henhold til ovenstående FAQ, leverer Aurora PostgreSQL tre gange så meget som PostgreSQL på SELECT og UPDATE operationer. I henhold til Amazons PostgreSQL Benchmark White Paper var værktøjerne, der blev brugt til at måle ydeevnen, pgbench og sysbench. Bemærkelsesværdig er ydeevneafhængigheden af instanstypen, områdevalg og netværksydelse. Gad vide, hvorfor INSERT ikke er nævnt? Det er fordi PostgreSQL ACID compliance ("C") kræver, at en opdateret post oprettes ved hjælp af en sletning efterfulgt af en indsættelse.
For at drage fuld fordel af ydeevneforbedringerne anbefaler Amazon, at applikationer er designet til at interagere med databasen ved hjælp af et stort antal samtidige forespørgsler og transaktioner . Denne vigtige faktor bliver ofte overset, hvilket fører til dårlig ydeevne, skylden på implementeringen.
Grænser
Der er nogle begrænsninger, der skal tages i betragtning, når du planlægger migreringen:
-
huge_pages kan ikke ændres, men det er slået til som standard:
template1=> select aurora_version(); aurora_version ---------------- 1.0.11 (1 row) template1=> show huge_pages ; huge_pages ------------ on (1 row) - pg_hba kan ikke bruges, da det kræver genstart af serveren. Som en sidebemærkning må det være en tastefejl i Amazons dokumentation, da PostgreSQL kun skal genindlæses. I stedet for at stole på pg_hba, skal administratorer bruge AWS-sikkerhedsgrupperne og PostgreSQL GRANT.
- PITR-granularitet er 5 minutter.
- Tværregionsreplikering er i øjeblikket ikke tilgængelig for PostgreSQL.
- Maksimal størrelse af tabeller er 64TiB
- Op til 15 læste replikaer
Skalerbarhed
Op- og nedskalering af databaseinstansen er i øjeblikket en manuel proces, der kan udføres via AWS-konsollen eller CLI, selvom automatisk skalering er i gang, men ifølge Amazon Aurora FAQ vil den kun være tilgængelig for MySQL.
Hændelseslog skalering af computerressourcer For at skalere horisontalt skal applikationer drage fordel af AWS SDK API'er, for eksempel for at opnå hurtig failover.
Høj tilgængelighed
Går vi videre til høj tilgængelighed, i tilfælde af primær knudefejl, leverer Aurora PostgreSQL et klyngeendepunkt som en DNS A-post, som automatisk opdateres internt for at pege på den replika, der er valgt til at blive master.
Sikkerhedskopier
Værd at nævne, at hvis databasen slettes, bevares eventuelle manuelle backup-snapshots, mens automatiske snapshots fjernes.
Replikering
Da replikaer deler det samme underliggende lager som den primære instans, er replikeringsforsinkelse i teorien i intervallet millisekunder.
Amazon anbefaler at læse replikaer for at reducere failover-varigheden. Med en læst replika på standby tager failover-processen omkring 30 sekunder, mens der uden en replika kan forventes op til 15 minutter.
En anden god nyhed er, at logisk replikering også understøttes, som vist på side 22.
Selvom Amazon Aurora FAQ ikke giver detaljer om replikering, som det gør for MySQL, giver Aurora PostgreSQL Best Practices en nyttig forespørgsel til at verificere replikeringsstatussen:
select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp from
aurora_replica_status(); Ovenstående forespørgsel giver:
-[ RECORD 1 ]--------------+-------------------------------------
server_id | testdb
session_id | 9e268c62-9392-11e8-87fc-a926fa8340fe
highest_lsn_rcvd | 46640889
cur_replay_latency_in_usec | 8830
now | 2018-07-29 20:14:55.434701-07
last_update_timestamp | 2018-07-29 20:14:54-07
-[ RECORD 2 ]--------------+-------------------------------------
server_id | testdb-us-east-1b
session_id | MASTER_SESSION_ID
highest_lsn_rcvd |
cur_replay_latency_in_usec |
now | 2018-07-29 20:14:55.434701-07
last_update_timestamp | 2018-07-29 20:14:55-07 Da replikering er et så vigtigt emne, var det værd at konfigurere pgbench-testen som beskrevet i den benchmark-hvidbog, der henvises til ovenfor:
[[email protected] ~]$ whoami
ec2-user
[[email protected] ~]$ tail -n 2 .bashrc
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
export PATH=$PATH:/usr/local/pgsql/bin/
[[email protected] ~]$ which pgbench
/usr/local/pgsql/bin/pgbench
[[email protected] ~]$ pgbench --version
pgbench (PostgreSQL) 9.6.8 Tip: Undgå unødvendig indtastning ved at oprette en pgpass-fil og eksportere værts-, database- og brugermiljøvariabler, f.eks.:
[[email protected] ~]# tail -n 3 ~/.bashrc export
PGUSER=dbadmin
export PGHOST=c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
export PGDATABASE=template1
[[email protected] ~]# cat ~/.pgpass
*:*:*:dbadmin:password Kør datainitialiseringskommandoen:
[[email protected] ~]$ pgbench -i --fillfactor=90 --scale=10000 postgres Mens datainitialisering kører, skal du fange replikeringsforsinkelsen ved hjælp af ovenstående SQL kaldet fra følgende script:
while : ; do
psql -t -q \
-c 'select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp
from aurora_replica_status();' postgres
sleep 1
done Filtrering af screenlog-output gennem følgende kommando:
[[email protected] ~]# awk -F '|' '{print $4,$5,$6}' screenlog.2 | sort -k1,1 -n | tail
513116 2018-07-30 04:30:44.394729+00 2018-07-30 04:30:43+00
529294 2018-07-30 04:20:54.261741+00 2018-07-30 04:20:53+00
544139 2018-07-30 04:41:57.538566+00 2018-07-30 04:41:57+00
1001902 2018-07-30 04:42:54.80136+00 2018-07-30 04:42:53+00
2376951 2018-07-30 04:38:06.621681+00 2018-07-30 04:38:06+00
2376951 2018-07-30 04:38:07.672919+00 2018-07-30 04:38:07+00
5365719 2018-07-30 04:36:51.608983+00 2018-07-30 04:36:50+00
5365719 2018-07-30 04:36:52.912731+00 2018-07-30 04:36:51+00
6308586 2018-07-30 04:45:22.951966+00 2018-07-30 04:45:21+00
8210986 2018-07-30 04:46:14.575385+00 2018-07-30 04:46:13+00 Det viser sig, at replikationen haltede så meget som 8 sekunder!
På en relateret note er AWS CloudWatch-metrikken AuroraReplicaLagMaximum ikke enig med resultaterne fra ovenstående SQL-kommando. Jeg vil gerne vide hvorfor, så feedback er meget værdsat.
RDS CloudWatch max replika lag graf Sikkerhed
-
Kryptering er tilgængelig, og den skal være aktiveret, når databasen oprettes, da den ikke kan ændres efterfølgende.
Fejlfinding
Dette korte afsnit er en vigtig del. Sørg for, at PostgreSQL work_mem er indstillet korrekt, så sorteringsoperationer ikke skriver data til disken.
Opsætning
Bare følg opsætningsguiden i AWS-konsollen:
-
Åbn Amazon RDS administrationskonsol.
RDS-administrationskonsol -
Vælg Amazon Aurora og PostgreSQL udgave.
Aurora PostgreSQL-guiden -
Angiv DB-detaljerne og bemærk Aurora PostgreSQL-adgangskodebegrænsningerne:
Master Password must be at least eight characters long, as in "mypassword". Can be any printable ASCII character except "/", """, or "@".
Aurora PostgreSQL-guidedatabasedetaljer -
Konfigurer databaseindstillingerne:
- På dette tidspunkt er kun PostgreSQL 9.6 tilgængelig. Brug PostgreSQL på Amazon RDS, hvis du har brug for support til nyere versioner, inklusive beta-forhåndsvisninger.
-
Konfigurer failover-prioriteten, og vælg antallet af replikaer.
Fotobeskrivelse -
Indstil backup-retention (maksimalt er 35 dage).
Aurora PostgreSQL-guidens backup-opbevaring -
Vælg vedligeholdelsesplanen. Automatiske mindre versionsopgraderinger er tilgængelige, men det er vigtigt at verificere med AWS-support, om deres programrettelsesplan kan fremskyndes i tilfælde af, at PostgreSQL-projektet frigiver presserende opdateringer. Som et eksempel tog det mere end to måneder for AWS at skubbe 2018-05-10-opdateringerne.
Aurora PostgreSQL-guidens vedligeholdelsesplan -
Hvis databasen er blevet oprettet, vises et link til instruktioner om, hvordan du forbinder til den:
Opsætning af Aurora PostgreSQL-guiden fuldført
Opretter forbindelse til databasen
Gennemgå detaljerede instruktioner for tilgængelige forbindelsesmuligheder baseret på infrastrukturopsætningen. I det enkleste scenarie sker forbindelsen via en offentlig EC2-instans.
Bemærk:Klienten skal være kompatibel med PostgreSQL 9.6.3 eller nyere.
[[email protected] ~]# psql -U dbadmin -h c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com template1
Password for user dbadmin:
psql (9.6.8, server 9.6.3)
SSL connection (protocol: TLSv1.2, cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help. Overvågning
Amazon tilbyder forskellige metrics til overvågning af databasen, et eksempel nedenfor, der viser forekomstmålinger:
RDS-forekomstmålingerDownload Whitepaper Today PostgreSQL Management &Automation med ClusterControlFå flere oplysninger om, hvad du har brug for at implementere, overvåge, vide administrer og skaler PostgreSQLDownload hvidbogen RDS til PostgreSQL
Dette er et tilbud, der tillader mere granularitet med hensyn til konfigurationsvalg. For eksempel, i modsætning til Aurora, der bruger et proprietært lagringssystem, tilbyder RDS konfigurerbar lagring ved hjælp af EBS-volumener, der kan være enten General Purpose SSD (GP2) eller Provisioned IOPS eller magnetisk (anbefales ikke).
For at hjælpe store installationer, der kræver tilpasning, der ikke er tilgængelig i Aurora-tilbuddet, har Amazon for nylig udgivet anbefalingerne for bedste praksis, kun tilgængelige for RDS.
Høj tilgængelighed skal konfigureres manuelt (eller automatiseres ved hjælp af et af de kendte AWS-værktøjer), og det anbefales at konfigurere en Multi-AZ-implementering.
Replikering implementeres ved hjælp af PostgreSQL native replikering.
Der er nogle begrænsninger for PostgreSQL DB-forekomster, der skal tages i betragtning.
Med ovenstående noter i tankerne er her en gennemgang til opsætning af et RDS PostgreSQL Multi-AZ-miljø:
-
Fra RDS Management Console start guiden
RDS PostgreSQL-guide -
Vælg mellem et produktions- og et udviklingssetup.
RDS PostgreSQL-guidens brugscasevalg -
Indtast detaljerne om din nye databaseklynge.
RDS PostgreSQL guiden DB detaljer 
RDS PostgreSQL-guidens databaseindstillinger -
Opsætning af netværk, sikkerhed og vedligeholdelsesplan på næste side:
Avancerede indstillinger for RDS PostgreSQL-guiden 
RDS PostgreSQL-guidens sikkerhed og vedligeholdelse
Konklusion
Amazon RDS-tjenester til PostgreSQL inkluderer RDS PostgreSQL og Aurora PostgreSQL, der begge er administrerede DaaS-tilbud. Spækket med masser af funktioner og solid backend-lagring, de har nogle begrænsninger i forhold til den traditionelle opsætning, men med omhyggelig planlægning kan disse tilbud give et velafbalanceret forhold mellem omkostninger og funktionalitet. Amazon RDS til PostgreSQL er rettet mod brugere, der har brug for flere muligheder for at konfigurere deres miljøer, og er generelt dyrere. Flertallet af brugere vil drage fordel af at starte op med Aurora PostgreSQL og arbejde sig ind i mere komplekse konfigurationer.