AWS PostgreSQL-services vallen onder de RDS-paraplu, het DaaS-aanbod van Amazon voor alle bekende database-engines.
Beheerde databaseservices bieden bepaalde voordelen die aantrekkelijk zijn voor de klant die onafhankelijkheid zoekt van infrastructuuronderhoud en configuraties met hoge beschikbaarheid. Zoals altijd is er geen one size fits all-oplossing. De momenteel beschikbare opties worden hieronder gemarkeerd:
Aurora PostgreSQL
De pagina met veelgestelde vragen over Amazon Aurora biedt belangrijke details waarmee u rekening moet houden voordat u in het product duikt. We leren bijvoorbeeld dat de opslaglaag gevirtualiseerd is en zich op een eigen gevirtualiseerd opslagsysteem bevindt met een back-up van SSD.
Prijzen
Wat de prijs betreft, moet worden opgemerkt dat Aurora PostgreSQL niet beschikbaar is in de AWS Free Tier.
Compatibiliteit
Dezelfde pagina met veelgestelde vragen maakt duidelijk dat Amazon geen 100% PostgreSQL-compatibiliteit claimt. Meeste (mijn nadruk) van de toepassingen zal goed zijn, b.v. de AWS PostgreSQL-smaak is draad-compatibel met PostgreSQL 9.6. Als resultaat zal de Wireshark PostgreSQL Dissector prima werken.
Prestaties
Prestaties zijn ook gekoppeld aan het instantietype, het maximale aantal verbindingen wordt bijvoorbeeld standaard geconfigureerd op basis van de instantiegrootte.
Ook belangrijk als het gaat om compatibiliteit, is het paginaformaat dat op 8KiB is gehouden, wat het standaard PostgreSQL-paginaformaat is. Over pagina's gesproken, het is de moeite waard om de FAQ te citeren:"In tegenstelling tot traditionele database-engines pusht Amazon Aurora nooit gewijzigde databasepagina's naar de opslaglaag, wat resulteert in verdere IO-consumptiebesparingen. Dit wordt mogelijk gemaakt omdat Amazon de manier heeft gewijzigd waarop de paginacache wordt beheerd, waardoor deze in het geheugen kan blijven in geval van een databasefout. Deze functie komt ook ten goede aan het opnieuw opstarten van de database na een crash, waardoor het herstel veel sneller kan plaatsvinden dan bij de traditionele methode om de logs opnieuw af te spelen.
Volgens de veelgestelde vragen waarnaar hierboven wordt verwezen, levert Aurora PostgreSQL drie keer de prestaties van PostgreSQL op SELECT- en UPDATE-bewerkingen. Volgens Amazon's PostgreSQL Benchmark White Paper waren de tools die werden gebruikt om de prestaties te meten pgbench en sysbench. Opvallend is de prestatie-afhankelijkheid van het instantietype, de regioselectie en de netwerkprestaties. Vraagt u zich af waarom INSERT niet wordt genoemd? Het is omdat PostgreSQL ACID-compliance (de "C") vereist dat een bijgewerkte record wordt gemaakt met behulp van een verwijdering gevolgd door een invoeging.
Om optimaal gebruik te kunnen maken van de prestatieverbeteringen, raadt Amazon aan om applicaties te ontwerpen voor interactie met de database met behulp van grote aantallen gelijktijdige zoekopdrachten en transacties . Deze belangrijke factor wordt vaak over het hoofd gezien en leidt tot slechte prestaties vanwege de implementatie.
Grenzen
Er zijn enkele beperkingen waarmee rekening moet worden gehouden bij het plannen van de migratie:
-
enorme_pagina's kunnen niet worden gewijzigd, maar het is standaard ingeschakeld:
template1=> select aurora_version(); aurora_version ---------------- 1.0.11 (1 row) template1=> show huge_pages ; huge_pages ------------ on (1 row) - pg_hba kan niet worden gebruikt omdat de server opnieuw moet worden opgestart. Even terzijde:dat moet een typfout zijn in de documentatie van Amazon, aangezien PostgreSQL alleen opnieuw hoeft te worden geladen. In plaats van te vertrouwen op pg_hba, moeten beheerders de AWS-beveiligingsgroepen en PostgreSQL GRANT gebruiken.
- PITR-granulariteit is 5 minuten.
- Replicatie tussen regio's is momenteel niet beschikbaar voor PostgreSQL.
- Maximale grootte van tabellen is 64TiB
- Tot 15 gelezen replica's
Schaalbaarheid
Het op- en afschalen van de database-instantie is momenteel een handmatig proces, dat kan worden gedaan via de AWS-console of CLI, hoewel automatisch schalen in de maak is, maar volgens Amazon Aurora FAQ zal het alleen beschikbaar zijn voor MySQL.
Gebeurtenislogboek schaling computerbronnen Om horizontaal te schalen moeten applicaties profiteren van AWS SDK API's, bijvoorbeeld om snelle failover te realiseren.
Hoge beschikbaarheid
Door naar hoge beschikbaarheid te gaan, biedt Aurora PostgreSQL in het geval van een storing van het primaire knooppunt een clustereindpunt als een DNS A-record, dat automatisch intern wordt bijgewerkt om te verwijzen naar de replica die is geselecteerd om master te worden.
Back-ups
Vermeldenswaard is dat als de database wordt verwijderd, eventuele handmatige back-upmomentopnamen worden bewaard, terwijl automatische momentopnamen worden verwijderd.
Replicatie
Aangezien replica's dezelfde onderliggende opslag delen als de primaire instantie, is de replicatievertraging in theorie in het bereik van milliseconden.
Amazon raadt leesreplica's aan om de duur van de failover te verkorten. Met een leesreplica in stand-by duurt het failoverproces ongeveer 30 seconden, terwijl zonder replica tot 15 minuten duurt.
Ander goed nieuws is dat logische replicatie ook wordt ondersteund, zoals weergegeven op pagina 22.
Hoewel de Amazon Aurora FAQ geen details geeft over replicatie zoals voor MySQL, bieden de Aurora PostgreSQL Best Practices een nuttige vraag om de replicatiestatus te verifiëren:
select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp from
aurora_replica_status();De bovenstaande zoekopdracht levert:
-[ 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-07Aangezien replicatie zo'n belangrijk onderwerp is, was het de moeite waard om de pgbench-test op te zetten zoals beschreven in het benchmark-witboek waarnaar hierboven wordt verwezen:
[[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.8Hint: Vermijd onnodig typen door een pgpass-bestand te maken en de host-, database- en gebruikersomgevingsvariabelen te exporteren, bijvoorbeeld:
[[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:passwordVoer de opdracht voor gegevensinitialisatie uit:
[[email protected] ~]$ pgbench -i --fillfactor=90 --scale=10000 postgresTerwijl de gegevensinitialisatie wordt uitgevoerd, legt u de replicatievertraging vast met behulp van de bovenstaande SQL die wordt aangeroepen vanuit het volgende 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
doneDe uitvoer van het schermlogboek filteren met de volgende opdracht:
[[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+00Het blijkt dat de replicatie maar liefst 8 seconden achterbleef!
In een verwante opmerking, AWS CloudWatch-metrische AuroraReplicaLagMaximum is het niet eens met de resultaten van de bovenstaande SQL-opdracht. Ik zou graag willen weten waarom, dus feedback wordt zeer op prijs gesteld.
Grafiek RDS CloudWatch max replica-vertraging Beveiliging
-
Versleuteling is beschikbaar en moet worden ingeschakeld wanneer de database wordt gemaakt, omdat deze daarna niet meer kan worden gewijzigd.
Problemen oplossen
Dit korte gedeelte is een belangrijk onderdeel. Zorg ervoor dat de PostgreSQL work_mem correct is afgesteld, zodat sorteerbewerkingen geen gegevens naar schijf schrijven.
Instellen
Volg gewoon de installatiewizard in de AWS-console:
-
Open de Amazon RDS beheerconsole.
RDS-beheerconsole -
Selecteer Amazon Aurora en PostgreSQL editie.
Aurora PostgreSQL-wizard -
Specificeer de DB-details en let op de Aurora PostgreSQL-wachtwoordbeperkingen:
Master Password must be at least eight characters long, as in "mypassword". Can be any printable ASCII character except "/", """, or "@".
Aurora PostgreSQL-wizard databasegegevens -
Configureer de database-opties:
- Op het moment van schrijven is alleen PostgreSQL 9.6 beschikbaar. Gebruik PostgreSQL op Amazon RDS als je ondersteuning nodig hebt voor recentere versies, inclusief bètavoorbeelden.
-
Configureer de failover-prioriteit en selecteer het aantal replica's.
Fotobeschrijving -
Stel de back-upretentie in (maximaal 35 dagen).
Aurora PostgreSQL-wizard back-upbehoud -
Selecteer het onderhoudsschema. Automatische kleine versie-upgrades zijn beschikbaar, maar het is belangrijk om met AWS-ondersteuning te controleren of hun patchschema kan worden versneld in het geval dat het PostgreSQL-project dringende updates uitbrengt. Het duurde bijvoorbeeld meer dan twee maanden voordat AWS de updates van 2018-05-10 pushte.
Aurora PostgreSQL-wizard onderhoudsschema -
Als de database met succes is gemaakt, wordt een link weergegeven naar instructies over hoe u er verbinding mee kunt maken:
Aurora PostgreSQL-wizard installatie voltooid
Verbinding maken met database
Bekijk gedetailleerde instructies voor beschikbare verbindingsopties, gebaseerd op de infrastructuurconfiguratie. In het eenvoudigste scenario wordt de verbinding tot stand gebracht via een openbare EC2-instantie.
Opmerking:de client moet compatibel zijn met PostgreSQL 9.6.3 of hoger.
[[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.Bewaking
Amazon biedt verschillende statistieken voor het bewaken van de database, een voorbeeld hieronder toont instantiestatistieken:
RDS-instantiestatistiekenDownload vandaag de whitepaper PostgreSQL Management &Automation met ClusterControlLeer over wat u moet weten om te implementeren, bewaken, beheer en schaal PostgreSQLDownload de whitepaper RDS voor PostgreSQL
Dit is een aanbod dat meer granulariteit mogelijk maakt in termen van configuratiekeuzes. In tegenstelling tot Aurora die een eigen opslagsysteem gebruikt, biedt RDS bijvoorbeeld configureerbare opslag met behulp van EBS-volumes die ofwel General Purpose SSD (GP2), Provisioned IOPS of magnetisch kunnen zijn (niet aanbevolen).
Om grote installaties te ondersteunen, waarvoor maatwerk nodig is die niet beschikbaar is in het Aurora-aanbod, heeft Amazon onlangs de aanbevelingen voor best practices uitgebracht, die alleen beschikbaar zijn voor RDS.
Hoge beschikbaarheid moet handmatig worden geconfigureerd (of geautomatiseerd met behulp van een van de bekende AWS-tools) en het wordt aanbevolen om een Multi-AZ-implementatie in te stellen.
Replicatie wordt geïmplementeerd met behulp van de native PostgreSQL-replicatie.
Er zijn enkele limieten voor PostgreSQL DB-instanties waarmee rekening moet worden gehouden.
Met de bovenstaande opmerkingen in gedachten volgt hier een overzicht voor het opzetten van een RDS PostgreSQL Multi-AZ-omgeving:
-
Vanuit de RDS-beheerconsole start de wizard
RDS PostgreSQL-wizard -
Kies tussen een productie- en een ontwikkelingsopstelling.
Selectie van gebruiksscenario's voor databases van de RDS PostgreSQL-wizard -
Voer de details van uw nieuwe databasecluster in.
RDS PostgreSQL-wizard DB-details 
RDS PostgreSQL-wizard database-instellingen -
Op de volgende pagina stelt u het netwerk-, beveiligings- en onderhoudsschema in:
Geavanceerde instellingen van de RDS PostgreSQL-wizard 
RDS PostgreSQL-wizard beveiliging en onderhoud
Conclusie
Amazon RDS-services voor PostgreSQL omvatten RDS PostgreSQL en Aurora PostgreSQL, beide beheerde DaaS-aanbiedingen. Ze zitten boordevol functies en solide backend-opslag, maar hebben enkele beperkingen ten opzichte van de traditionele configuratie, maar met een zorgvuldige planning kunnen deze aanbiedingen een goed uitgebalanceerde kosten-functionaliteitsverhouding bieden. Amazon RDS voor PostgreSQL is bedoeld voor gebruikers die meer opties nodig hebben voor het configureren van hun omgeving, en is over het algemeen duurder. De meeste gebruikers zullen profiteren van het opstarten met Aurora PostgreSQL en zich een weg banen naar complexere configuraties.