sql >> Databasteknik >  >> RDS >> PostgreSQL

En översikt över Amazon RDS &Aurora-erbjudanden för PostgreSQL

AWS PostgreSQL-tjänster faller under RDS-paraplyet, som är Amazons DaaS-erbjudande för alla kända databasmotorer.

Hanterade databastjänster erbjuder vissa fördelar som är tilltalande för kunder som söker oberoende av infrastrukturunderhåll och högt tillgängliga konfigurationer. Som alltid finns det ingen lösning som passar alla. De för närvarande tillgängliga alternativen är markerade nedan:

Aurora PostgreSQL

Amazon Aurora FAQ-sidan ger viktiga detaljer som måste övervägas innan du dyker in i produkten. Vi lär oss till exempel att lagringslagret är virtualiserat och sitter på ett proprietärt virtualiserat lagringssystem som säkerhetskopieras av SSD.

Priser

När det gäller prissättning måste det noteras att Aurora PostgreSQL inte är tillgängligt i AWS Free Tier.

Kompatibilitet

Samma FAQ-sida gör det klart att Amazon inte hävdar 100% PostgreSQL-kompatibilitet. De flesta (min betoning) av ansökningarna blir bra, t.ex. AWS PostgreSQL-smaken är trådkompatibel med PostgreSQL 9.6. Som ett resultat kommer Wireshark PostgreSQL Dissector att fungera bra.

Prestanda

Prestanda är också kopplat till instanstypen, till exempel är det maximala antalet anslutningar som standard konfigurerat baserat på instansstorleken.

Också viktigt när det kommer till kompatibilitet är sidstorleken som har hållits på 8KiB vilket är PostgreSQLs standardsidastorlek. På tal om sidor är det värt att citera FAQ:"Till skillnad från traditionella databasmotorer skjuter Amazon Aurora aldrig modifierade databassidor till lagringslagret, vilket resulterar i ytterligare besparingar av IO-förbrukning. ” Detta görs möjligt eftersom Amazon ändrade sättet på hur sidcachen hanteras, så att den kan finnas kvar i minnet i händelse av databasfel. Den här funktionen gynnar också omstarten av databasen efter en krasch, vilket gör att återställningen kan ske mycket snabbare än med den traditionella metoden att spela om loggarna.

Enligt FAQ som refereras till ovan, levererar Aurora PostgreSQL tre gånger prestanda av PostgreSQL på SELECT- och UPDATE-operationer. Enligt Amazons PostgreSQL Benchmark White Paper var verktygen som användes för att mäta prestandan pgbench och sysbench. Anmärkningsvärt är prestandaberoendet på instanstypen, val av region och nätverksprestanda. Undrar du varför INSERT inte nämns? Det beror på att PostgreSQL ACID-kompatibilitet ("C") kräver att en uppdaterad post skapas med en radering följt av en infogning.

För att dra full nytta av prestandaförbättringarna rekommenderar Amazon att applikationer är utformade för att interagera med databasen med stora antal samtidiga frågor och transaktioner . Denna viktiga faktor förbises ofta vilket leder till dålig prestanda som skylls på implementeringen.

Begränsningar

Det finns några begränsningar att tänka på när du planerar migreringen:

  • huge_pages kan inte ändras, men det är på 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 inte användas eftersom det kräver omstart av servern. Som en sidoanteckning måste det vara ett stavfel i Amazons dokumentation, eftersom PostgreSQL bara behöver laddas om. Istället för att förlita sig på pg_hba måste administratörer använda AWS-säkerhetsgrupperna och PostgreSQL GRANT.
  • PITR-granularitet är 5 minuter.
  • Replikering över regioner är för närvarande inte tillgänglig för PostgreSQL.
  • Maximal storlek på tabeller är 64TiB
  • Upp till 15 lästa repliker

Skalbarhet

Att skala upp och ned i databasinstansen är för närvarande en manuell process, som kan göras via AWS-konsolen eller CLI, även om automatisk skalning fungerar, men enligt Amazon Aurora FAQ kommer den endast att vara tillgänglig för MySQL.

Händelseloggskalning av datorresurser

För att skala horisontellt måste applikationer dra fördel av AWS SDK API:er, till exempel för att uppnå snabb failover.

Hög tillgänglighet

Går vi vidare till hög tillgänglighet, i händelse av primärnodfel, tillhandahåller Aurora PostgreSQL en klusterslutpunkt som en DNS A-post, som automatiskt uppdateras internt för att peka på den replik som valts för att bli master.

Säkerhetskopiering

Värt att nämna att om databasen raderas kommer eventuella manuella säkerhetskopior att behållas, medan automatiska ögonblicksbilder tas bort.

Replikering

Eftersom repliker delar samma underliggande lagring som den primära instansen ligger replikeringsfördröjningen i teorin inom intervallet millisekunder.

Amazon rekommenderar att du läser repliker för att minska failover-varaktigheten. Med en läsreplika i vänteläge tar failover-processen cirka 30 sekunder, medan utan en replik kan du räkna med upp till 15 minuter.

Andra goda nyheter är att logisk replikering också stöds, som visas på sidan 22.

Även om Amazon Aurora FAQ inte ger detaljer om replikering som det gör för MySQL, ger Aurora PostgreSQL Best Practices en användbar fråga för att verifiera replikeringsstatusen:

select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp from
aurora_replica_status();

Ovanstående fråga ger:

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

Eftersom replikering är ett så viktigt ämne var det värt att ställa in pgbench-testet enligt beskrivningen i referensvitboken som refereras till ovan:

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

Tips: Undvik onödigt skrivande genom att skapa en pgpass-fil och exportera värd-, databas- och användarmiljövariabler, t.ex.:

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

[[email protected] ~]$ pgbench -i --fillfactor=90 --scale=10000 postgres

Medan datainitiering körs, fånga replikeringsfördröjningen med ovanstående SQL som anropas från följande skript:

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

Filtrera skärmloggens utdata genom följande 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 visar sig att replikeringen släpade så mycket som 8 sekunder!

På en relaterad notering, AWS CloudWatch-måttet AuroraReplicaLagMaximum stämmer inte överens med resultaten från ovanstående SQL-kommando. Jag skulle vilja veta varför, så feedback är mycket uppskattat.

RDS CloudWatch max replica lag graph

Säkerhet

  • Kryptering är tillgänglig och måste vara aktiverad när databasen skapas, eftersom den inte kan ändras i efterhand.

Felsökning

Det här korta avsnittet är en viktig bit. Se till att PostgreSQL work_mem är korrekt inställd så att sorteringsoperationer inte skriver data till disken.

Inställningar

Följ bara installationsguiden i AWS-konsolen:

  1. Öppna Amazon RDS hanteringskonsol.

    RDS-hanteringskonsol

  2. Välj Amazon Aurora och PostgreSQL upplaga.

    Aurora PostgreSQL-guiden

  3. Ange DB-detaljerna och notera Aurora PostgreSQL-lösenordsbegränsningarna:

    Master Password must be at least eight characters long, as in
"mypassword". Can be any printable ASCII character except "/", """, or "@".
    Aurora PostgreSQL-guidens databasdetaljer

  4. Konfigurera databasalternativen:

    • När detta skrivs är endast PostgreSQL 9.6 tillgängligt. Använd PostgreSQL på Amazon RDS om du behöver stöd för nyare versioner, inklusive betaförhandsvisningar.

  5. Konfigurera failover-prioriteten och välj antalet repliker.

    Fotobeskrivning

  6. Ställ in säkerhetskopieringslagringen (maximalt är 35 dagar).

    Retention av säkerhetskopiering av Aurora PostgreSQL-guiden

  7. Välj underhållsschema. Automatiska mindre versionsuppgraderingar är tillgängliga, men det är viktigt att verifiera med AWS-support huruvida deras patchschema kan påskyndas om PostgreSQL-projektet släpper några brådskande uppdateringar. Som ett exempel tog det mer än två månader för AWS att driva uppdateringarna 2018-05-10.

    Underhållsschema för Aurora PostgreSQL-guiden

  8. Om databasen har skapats kommer en länk till instruktioner om hur man ansluter till den att visas:

    Aurora PostgreSQL-guiden har konfigurerats

Ansluter till databasen

Granska detaljerade instruktioner för tillgängliga anslutningsalternativ, baserat på infrastrukturinställningen. I det enklaste scenariot görs anslutningen via en offentlig EC2-instans.

Obs! Klienten måste vara kompatibel med PostgreSQL 9.6.3 eller senare. 

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

Övervakning

Amazon tillhandahåller olika mätvärden för att övervaka databasen, ett exempel nedan som visar instansmätningar:

RDS-instansstatistik Ladda ner Whitepaper Today PostgreSQL Management &Automation med ClusterControlLäs om vad du behöver för att distribuera, övervaka, veta hantera och skala PostgreSQLDladda Whitepaper

RDS för PostgreSQL

Detta är ett erbjudande som tillåter mer granularitet när det gäller konfigurationsval. Till exempel, till skillnad från Aurora som använder ett proprietärt lagringssystem, erbjuder RDS konfigurerbar lagring med EBS-volymer som kan vara antingen General Purpose SSD (GP2), eller Provisioned IOPS, eller magnetisk (rekommenderas inte).

För att hjälpa stora installationer, som kräver anpassning som inte finns i Aurora-erbjudandet, har Amazon nyligen släppt rekommendationerna för bästa praxis, endast tillgängliga för RDS.

Hög tillgänglighet måste konfigureras manuellt (eller automatiseras med något av de kända AWS-verktygen) och det rekommenderas att konfigurera en Multi-AZ-distribution.

Replikering implementeras med hjälp av PostgreSQL-replikeringen.

Det finns vissa gränser för PostgreSQL DB-instanser som måste beaktas.

Med ovanstående anteckningar i åtanke är här en genomgång för att ställa in en RDS PostgreSQL Multi-AZ-miljö:

  1. Från RDS Management Console starta guiden

    RDS PostgreSQL-guiden

  2. Välj mellan en produktions- och en utvecklingsuppsättning.

    Val av användningsfall för RDS PostgreSQL-guidens databas

  3. Ange detaljerna om ditt nya databaskluster.

    RDS PostgreSQL-guidens DB-detaljer RDS PostgreSQL-guidens databasinställningar

  4. På nästa sida ställer in nätverk, säkerhet och underhållsschema:

    Avancerade inställningar för RDS PostgreSQL-guiden RDS PostgreSQL-guidens säkerhet och underhåll

Slutsats

Amazon RDS-tjänster för PostgreSQL inkluderar RDS PostgreSQL och Aurora PostgreSQL, båda hanterade DaaS-erbjudanden. Fullpackade med massor av funktioner och solid backend-lagring har de vissa begränsningar jämfört med den traditionella installationen, men med noggrann planering kan dessa erbjudanden ge ett välbalanserat förhållande mellan kostnad och funktionalitet. Amazon RDS för PostgreSQL är inriktat på användare som behöver fler alternativ för att konfigurera sina miljöer och är generellt sett dyrare. Majoriteten av användarna kommer att dra nytta av att starta med Aurora PostgreSQL och arbeta sig in i mer komplexa konfigurationer.


  1. Förbättra partitionsunderhåll med inkrementell statistik

  2. Ändra hur isql kör SQL

  3. Tips för att övervaka MariaDB-replikering med ClusterControl

  4. funktion för att kontrollera om SQLite använder journal_mode=WAL eller journal_mode=DELETE