sql >> Database teknologi >  >> RDS >> PostgreSQL

Cloud Vendor Deep-Dive:PostgreSQL på Microsoft Azure

Hvis du har fulgt Microsoft på det seneste, kommer det ikke som nogen overraskelse, at udbyderen af ​​et konkurrerende databaseprodukt, nemlig SQL Server, også hoppede med på PostgreSQL-vognen. Fra at frigive 60.000 patenter til OIN til at være Platinum-sponsor hos PGCon, Microsoft som en af ​​PostgreSQL-virksomhedens støtteorganisationer. Benyttede enhver lejlighed til at vise, at du ikke kun kan køre PostgreSQL på Microsoft, men også det omvendte er tilfældet:Microsoft kan gennem sit cloud-udbud køre PostgreSQL for dig. Udtalelsen blev endnu mere klar med købet af Citus Data og frigivelsen af ​​deres flagskibsprodukt i Azure Cloud under navnet Hyperscale. Det er sikkert at sige, at PostgreSQL-adoptionen vokser, og nu er der endnu flere gode grunde til at vælge det.

Min rejse gennem Azure-skyen startede lige ved landingssiden, hvor jeg møder konkurrenterne:Single Server og en forhåndsvisning (med andre ord ingen SLA leveret) udgivelse af Hyperscale (Citus). Denne blog vil fokusere på førstnævnte. Mens jeg var på denne rejse, havde jeg mulighed for at øve mig i, hvad open source handler om – at give tilbage til fællesskabet – i dette tilfælde ved at give feedback til dokumentationen om, at de, til Microsofts ære, gør dette meget nemt ved at sende feedbacken direkte. ind i Github:

PostgreSQL-kompatibilitet med Azure

Versionering

Ifølge produktdokumentationen er Single Server målrettet efter PostgreSQL-versioner i n-2 hovedsortimentet:

Som en løsning bygget til ydeevne anbefales Single Server til datasæt 100 GB og større. Serverne leverede forudsigelig ydeevne — databaseforekomsterne kommer med et foruddefineret antal vCores og IOPS (baseret på størrelsen af ​​klargjort lagerplads).

Udvidelser

Der er et rimeligt antal understøttede udvidelser, hvor nogle af dem installeres ud af boksen:

[email protected]:5432 postgres> vælg navn, default_version, installed_version fra pg_available_extensions hvor navn !~ '^postgis' rækkefølge efter navn; navn | default_version | installed_version--------------------------------------+----------------+ -------------------address_standardizer | 2.4.3 |address_standardizer_data_us | 2.4.3 |btree_gin | 1.2 |btree_gist | 1.5 |chkpass | 1.0 |citext | 1.4 |terning | 1.2 |dblink | 1.2 |dict_int | 1.0 |jordafstand | 1.1 |fuzzystrmatch | 1.1 |hstore | 1.4 |hypopg | 1.1.1 |inarray | 1.2 |isn | 1.1 |ltræ | 1.1 |orafce | 3.7 |pg_buffercache | 1.3 | 1.3pg_partman | 2.6.3 |pg_prewarm | 1.1 |pg_qs | 1.1 |pg_stat_statements | 1,6 | 1.6pg_trgm | 1.3 |pg_wait_sampling | 1.1 |pgcrypto | 1.3 |pgrouting | 2.5.2 |pgrowlocks | 1.2 |pgstattuple | 1.5 |plpgsql | 1,0 | 1.0plv8 | 2.1.0 |postgres_fdw | 1.0 |tablefunc | 1.0 |timescaledb | 1.1.1 |uaccent | 1.1 |uuid-ossp | 1.1 |(35 rækker) 

PostgreSQL-overvågning på Azure

Serverovervågning er afhængig af et sæt metrics, der pænt kan grupperes for at skabe et brugerdefineret dashboard:

De, der er fortrolige med Graphviz eller Blockdiag, vil sandsynligvis sætte pris på muligheden for at eksportere hele dashboardet til en JSON-fil:

Yderligere metrics kan - og de bør - være knyttet til advarsler:

Forespørgselsstatistik kan spores ved hjælp af Query Store og visualiseres med Query Performance Indsigt. Til det skal et par Azure-specifikke parametre aktiveres:

[email protected]:5432 postgres> vælg * fra pg_settings, hvor navn ~ 'pgms_wait_sampling.query_capture_mode|pg_qs.query_capture_mode';-[ RECORD 1 ]---+--------- -------------------------------------------------- -------------------------------------------------- -----navn | pg_qs.query_capture_modesetting | topenhed |kategori | Customized Optionsshort_desc | Vælger, hvilke udsagn der spores af pg_qs. Skal genindlæse konfigurationen for at få ændringen til at træde i kraft.extra_desc |context | superbrugervartype | enumsource | konfiguration filemin_val |max_val |enumvals | {none,top,all}boot_val | nonereset_val | topkildefil |kildelinje |pending_restart | f-[ RECORD 2 ]---+---------------------------------------- -------------------------------------------------- --------------------navn | pgms_wait_sampling.query_capture_modesetting | allunit |kategori | Customized Optionsshort_desc | Udvalgte typer ventehændelser spores af denne udvidelse. Skal genindlæse konfigurationen for at få ændringen til at træde i kraft.extra_desc |context | superbrugervartype | enumsource | konfiguration filemin_val |max_val |enumvals | {none,all}boot_val | nonereset_val | allsourcefile |sourceline |pending_restart | f 

For at visualisere de langsomme forespørgsler og ventetider fortsætter vi til Query Performance-widgetten:

Langevarende forespørgsler​​​

Ventstatistik

PostgreSQL-logning på Azure

StandardpostgreSQL-logfilerne kan downloades eller eksporteres til Log Analytics for mere avanceret parsing:

PostgreSQL-ydeevne og skalering med Azure

Mens antallet af vCores nemt kan øges eller reduceres, vil denne handling udløse en servergenstart:

For at opnå nul nedetid skal applikationer være i stand til elegant at håndtere forbigående fejl .

Til justering af forespørgsler giver Azure DBA'en ydeevneanbefalinger ud over de forudindlæste pg_statements og pg_buffercache-udvidelser:

Høj tilgængelighed og replikering på Azure

Databaseserverens høje tilgængelighed opnås ved hjælp af en nodebaseret hardwarereplikering. Dette sikrer, at i tilfælde af hardwarefejl, kan en ny node hentes frem inden for ti sekunder.

Azure giver en redundant gateway som et netværksforbindelsesslutpunkt for alle databaseservere i en region.

PostgreSQL-sikkerhed på Azure

Som standard nægter firewallregler adgang til PostgreSQL-forekomsten. Da en Azure-databaseserver svarer til en databaseklynge, gælder adgangsreglerne for alle databaser, der er hostet på serveren.

Ud over IP-adresser kan firewall-regler referere til virtuelt netværk, en funktion, der kun er tilgængelig for niveauer til generelle formål og hukommelsesoptimerede.

En ting, jeg fandt mærkelig i firewallens webgrænseflade — jeg kunne ikke navigere væk fra siden, mens ændringerne blev gemt:

Data i hvile er krypteret ved hjælp af en server-administreret nøgle, og cloud-brugere kan ikke deaktiver krypteringen. Data i transit er også krypteret - SSL påkrævet kan kun ændres, efter at databaseserveren er oprettet. Ligesom data i hvile, er sikkerhedskopier krypteret, og kryptering kan ikke deaktiveres.

Avanceret trusselsbeskyttelse giver advarsler og anbefalinger om en række anmodninger om databaseadgang, der betragtes som en sikkerhedsrisiko. Funktionen er i øjeblikket i preview. For at demonstrere simulerede jeg et brute force-angreb med password:

~ $ while :; gør psql -U $(pwgen -s 20 1)@pg10; søvn 0,1; donepsql:dødelig:adgangskodegodkendelse mislykkedes for brugeren "AAPT6Z4XUZPYNJWINAYF" PSQL:FATAL:Adgangskodningsgodkendelse mislykkedes for brugeren "GANEW8VSIFLKDNNZSPNV" PSQL:FATTAL:Adgangskode Autentificering mislykkedes for brugeren "swzny7wgtxdltlcbqnUw" psql:Fatal:Adgangskode -autentificering mislykkedes for brugeren "swzny7wgtxdltlcbqnu FATAL:adgangskodegodkendelse mislykkedes for brugeren "um9kqUxPIxeQrzWQXr2v"psql:FATAL:adgangskodegodkendelse mislykkedes for brugeren "8BGXyg3KHF3Eq3yHpik1"psql:FATAL:adgangskodegodkendelse mislykkedes for brugeren "5Lcesjwd7code...

Tjek PostgreSQL-logfilerne:

2019-08-19 07:13:50 UTC-5d5a4c2e.138-FATAL:adgangskodegodkendelse mislykkedes for brugeren "AApT6z4xUzpynJwiNAYf"2019-08-19 07:13:50 UTC-5d51. Ro4c-5d51. "AApT6z4xUzpynJwiNAYf" eksisterer ikke. Forbindelsen matchede pg_hba.conf linje 3:"host all all 173.180.222.170/32 password"2019-08-19 07:13:51 UTC-5d5a4c2f.13c-LOG:forbindelse modtaget:host=173.180.222.222. 3162019-08-19 07:13:51 UTC-5d5a4c2f.13c-FATAL:adgangskodegodkendelse mislykkedes for brugeren "gaNeW8VSIflkdnNZSpNV"2019-08-19 07:13:51 UTC-5d5d5a4c2cDEnfGaNvGaNvGaNfLgNvNfLgNfLgNfLgNvNfLgNfLgNfLgNfL eksisterer. Forbindelse matchede pg_hba.conf linje 3:"vært alle alle 173.180.222.170/32 password"2019-08-19 07:13:52 UTC-5d5a4c30.140-LOG:forbindelse modtaget:host=173.180.222. 3202019-08-19 07:13:52 UTC-5d5a4c30.140-FATAL:adgangskodegodkendelse mislykkedes for brugeren "SWZnY7wGTxdLTLcbqnUW"2019-08-19 07:13:52 UTC-5d14A eksisterer. Forbindelse matchede pg_hba.conf linje 3:"vært alle alle 173.180.222.170/32 password"2019-08-19 07:13:53 UTC-5d5a4c31.148-LOG:forbindelse modtaget:host=173.180.222.222.d=3217804 port 3282019-08-19 07:13:53 UTC-5d5a4c31.148-FATAL:adgangskodegodkendelse mislykkedes for brugeren "BVH2SC12m9js9vZHcuBd"2019-08-19 07:13:53 "Ro8c-31BHcuBd20192000000000000000000000000000000000000000000000000000000" eksisterer. Forbindelse matchede pg_hba.conf linje 3:"vært alle alle 173.180.222.170/32 adgangskode"2019-08-19 07:13:53 UTC-5d5a4c31.14c-LOG:forbindelse modtaget:host=173.180.222 port=431704 pi=431704. 3322019-08-19 07:13:54 UTC-5D5A4C31.14C-Fatal:Adgangskode-godkendelse mislykkedes for brugeren "UM9KQUXPIXEQRZWQXR2V" 2019-08-19 07:13:54 UTC-5D5A4C31.14C-DETAIL:ROLE "UM9KQUXPIXPIKTEQRZWQX" eksisterer. Forbindelse matchede pg_hba.conf linje 3:"vært alle alle 173.180.222.170/32 password"2019-08-19 07:13:54 UTC-5d5a4c32.150-LOG:forbindelse modtaget:host=173.180.222 port=271702. 3362019-08-19 07:13:54 UTC-5d5a4c32.150-FATAL:adgangskodegodkendelse mislykkedes for brugeren "8BGXyg3KHF3Eq3yHpik1"2019-08-19 07:13:54 "Rou5c0301GYG3d31GYg10000000000000000000000000000000000000000000000000000000000000. eksisterer. Forbindelse matchede pg_hba.conf linje 3:"vært alle alle 173.180.222.170/32 adgangskode"2019-08-19 07:13:55 UTC-5d5a4c33.154-LOG:forbindelse modtaget:host=173.180.222 port=127102. 3402019-08-19 07:13:55 UTC-5d5a4c33.154-FATAL:adgangskodegodkendelse mislykkedes for brugeren "5LsVrtBjcewd77Q4kaj1"2019-08-19 07:13:55 "Royce4c301900000000000000000000000000000000000000000000000000000001" eksisterer. 

E-mail-advarslen ankom ca. 30 minutter senere:

For at tillade finkornet adgang til databaseserveren leverer Azure RBAC, som er en cloud-native adgangskontrolfunktion, blot endnu et værktøj i arsenalet af PostgreSQL Cloud DBA. Dette er så tæt som vi kan komme på de allestedsnærværende pg_hba adgangsregler.

PostgreSQL sikkerhedskopiering og gendannelse på Azure

Uanset prisniveauer opbevares sikkerhedskopier mellem 7 og 35 dage. Prisniveauet påvirker også muligheden for at gendanne data.

Point-in-time gendannelse er tilgængelig via Azure Portal eller CLI og i henhold til dokumentationen så detaljeret som op til fem minutter. Portalfunktionaliteten er ret begrænset - datovælger-widgetten viser blindt de sidste 7 dage som mulige datoer at vælge, selvom jeg oprettede serveren i dag. Der er heller ingen verifikation udført på gendannelsesmåltiden - jeg forventede, at indtastning af en værdi uden for gendannelsesintervallet ville udløse en fejl, der forhindrer guiden i at fortsætte:

Når gendannelsesprocessen er startet, opstår der en fejl, angiveligt forårsaget af udgangen af intervalværdi, vil dukke op omkring et minut senere:

...men fejlmeddelelsen var desværre ikke særlig nyttig:

Sidst er sikkerhedskopiering gratis i opbevaringsperioder på op til 7 dage. Det kan vise sig at være ekstremt praktisk for udviklingsmiljøer.

Tip og tips

Grænser

Vænt dig til Single Server Limits.

Forbindelse

Brug altid forbindelsesstrengen, for at forbindelsen kan dirigeres til den korrekte databaseserver.

replikering

For gendannelsesscenarier skal du finde læste replikaer i et af de parrede områder.

Roller

Ligesom det er tilfældet med AWS og GCloud, er der ingen superbrugeradgang.

GUC'er

Parametre, der kræver genstart af serveren, eller superbrugeradgang kan ikke konfigureres.

Skalering

Under automatisk skalering bør applikationer prøve igen, indtil den nye node vises.

Hukommelsesmængde og IOPS kan ikke angives — hukommelse tildeles i enheder på GB pr. vCore, op til et maksimum på 320 GB (32 vCores x 10 GB), og IOPS er afhængige af størrelsen af ​​det klargjorte lager til maksimalt 6000 IOPS. På nuværende tidspunkt tilbyder Azure en stor lagerforhåndsvisningsmulighed med et maksimum på 20.000 IOPS.

Servere, der er oprettet i Basic-niveauet, kan ikke opgraderes til General Purpose eller Memory Optimized.

Lagring

Sørg for, at funktionen til automatisk vækst er aktiveret - hvis mængden af ​​data overstiger den tilvejebragte lagerplads, vil databasen gå i skrivebeskyttet tilstand.

Opbevaring kan kun skaleres op. Ligesom med alle de andre cloud-udbydere kan lagerallokering ikke reduceres, og jeg kunne ikke støde på nogen forklaring. I betragtning af det avancerede udstyr, har de store cloud-spillere råd til, burde der ikke være nogen grund til ikke at levere funktioner, der ligner LVM online-dataflytning. Opbevaring er virkelig billigt i dag, der er virkelig ingen grund til at tænke på at skalere ned indtil den næste større versionsopgradering.

Firewall

I nogle tilfælde kan det tage op til fem minutter at udbrede opdateringer af firewallregler.

En server er placeret i det samme undernet, da applikationsserverne ikke vil være tilgængelige, før de relevante firewallregler er på plads.

Virtuelle netværksregler tillader ikke adgang på tværs af regioner, og som følge heraf kan dblink og postgres_fdw ikke bruges til at oprette forbindelse til databaser uden for Azure-skyen.

VNet/Subnet-tilgangen kan ikke anvendes på webapps, da deres forbindelser stammer fra offentlige IP-adresser.

Store virtuelle netværk vil være utilgængelige, mens tjenestens slutpunkter er aktiveret.

Kryptering

For applikationer, der kræver servercertifikatvalidering, er filen tilgængelig til download fra Digicert. Microsoft gjorde det nemt, og du skal ikke bekymre dig om fornyelse før 2025:

~ $ openssl x509 -i BaltimoreCyberTrustRoot.crt.pem -noout -datesnotBefore=12. maj 18:46:00 2000 GMTnotAfter=12. maj 23:59:00 2025 GMT 

Intrusion Detection System

Preview-udgivelsen af ​​Advanced Threat Protection er ikke tilgængelig for Basic-tier-forekomsterne.

Sikkerhedskopiering og gendannelse

For programmer, der ikke har råd til en regionsnedetid, kan du overveje at konfigurere serveren med geo-redundant backuplager. Denne mulighed kan kun aktiveres på tidspunktet for oprettelse af databaseserveren.

Kravet om at omkonfigurere cloud firewall-reglerne efter en PITR-operation er særligt vigtigt.

Sletning af en databaseserver fjerner alle sikkerhedskopier.

Efter gendannelsen er der visse post-gendannelsesopgaver, der skal udføres.

Ikke-loggede tabeller anbefales til bulkinserts for at øge ydeevnen, men de bliver ikke replikeret.

Overvågning

Metrics optages hvert minut og gemmes i 30 dage.

Logføring

Query Store er en global mulighed, hvilket betyder, at den gælder for alle databaser. Skrivebeskyttede transaktioner og forespørgsler længere end 6.000 bytes er problematiske. Som standard gemmes de registrerede forespørgsler i 7 dage.

Ydeevne

Anbefalinger af forespørgselsydeevneindsigt er i øjeblikket begrænset til at oprette og slette indeks.

Deaktiver pg_stat_staements, når det ikke er nødvendigt.

Erstat uuid_generate_v4 med gen_random_uuid(). Dette er i tråd med anbefalingen i den officielle PostgreSQL-dokumentation, se Building uuid-ossp.

Høj tilgængelighed og replikering

Der er en grænse på fem læste replikaer. Skrivetunge applikationer bør undgå at bruge læsereplikaer, da replikeringsmekanismen er asynkron, hvilket introducerer nogle forsinkelser, som applikationer skal kunne tolerere. Læste replikaer kan være placeret i en anden region.

REPLICA-understøttelse kan kun aktiveres, efter at serveren er oprettet. Funktionen kræver en servergenstart:

Læse replikaer arver ikke firewall-reglerne fra master node:

Failover til at læse replika er ikke automatisk. Failover-mekanismen er nodebaseret.

Der er en lang liste over overvejelser, der skal gennemgås, før du konfigurerer læsereplikaer.

Oprettelse af replikaer tager lang tid, selv når jeg testede med et relativt lille datasæt:

 Støvsuger

Støvsug

Gennemgå nøgleparametrene, da Azure Database for PostgreSQL leveres med opstrøms vakuumstandardværdier:

[email protected]:5432 postgres> vælg navn, indstilling fra pg_settings, hvor navn ~ '^autovacuum.*'; navn | indstilling---------------------------------------------+------------ autovakuum | onautovacuum_analyze_scale_factor | 0,05autovacuum_analyze_threshold | 50autovacuum_freeze_max_age | 200000000autovacuum_max_workers | 3autovacuum_multixact_freeze_max_age | 400000000autovacuum_naptime | 15autovacuum_vacuum_cost_delay | 20autovacuum_vacuum_cost_limit | -1autovacuum_vacuum_scale_factor | 0,05autovacuum_vacuum_threshold | 50autovacuum_work_mem | -1(12 rækker) 

Opgraderinger

Automatiske større opgraderinger understøttes ikke. Som tidligere nævnt er dette en mulighed for at spare omkostninger ved at nedskalere det automatisk dyrkede lager.

PostgreSQL Azure-forbedringer

Tidsserier

TimescaleDB er tilgængelig som en udvidelse (ikke en del af PostgreSQL-modulerne), men det er kun et par klik væk. Den eneste ulempe er den ældre version 1.1.1, mens upstream-versionen i øjeblikket er 1.4.1 (2019-08-01).

[email protected]:5432 postgres> OPRET UDVIDELSE, HVIS IKKE FINNES timescaledb CASCADE;ADVARSEL:VELKOMMEN TIL_____ _ _ ____________|_ _(_) | | | _ \ ___ \| | _ _ __ ___ ___ ___ ___ __ _| | ___| | | | |_/ /| | | | _ ` _ \ / _ \/ __|/ __/ _` | |/ _ \ | | | ___ \| | | | | | | | | __/\__ \ (_| (_| | | __/ |/ /| |_/ /|_| |_|_| |_| |_|\___||___/\___\__,_| _|\___|___/ \____/ Kører version 1.1.1For mere information om TimescaleDB, besøg venligst følgende links:1. Kom godt i gang:https://docs.timescale.com/getting-started2. API-referencedokumentation:https ://docs.timescale.com/api3. Sådan er TimescaleDB designet:https://docs.timescale.com/introduction/architectureCREATE [email protected]:5432 postgres> \dx timescaledb Liste over installerede udvidelser Navn | Version | Skema | Beskrivelse-------------+---------+--------+--------- -------------------------------------------------- --timescaledb | 1.1.1 | offentlig | Aktiverer skalerbare indsættelser og komplekse forespørgsler til tidsseriedata (1 række) 

Logføring

Ud over PostgreSQL-logningsmuligheder kan Azure Database for PostgreSQL konfigureres til at registrere yderligere diagnosticeringshændelser.

Firewall

Azure Portal indeholder en praktisk funktion til at tillade forbindelser fra de IP-adresser, der er logget ind på portalen:

Jeg bemærkede funktionen, da den gør det nemt for udviklere og systemadministratorer at tillade sig selv at komme ind, og det skiller sig ud som en funktion, der ikke tilbydes af hverken AWS eller GCloud.

Konklusion

Azure Database for PostgreSQL Single Server tilbyder tjenester på virksomhedsniveau, men mange af disse tjenester er stadig i preview-tilstand:Query Store, Performance Insight, Performance Recommendation, Advanced Threat Protection, Large Storage, Cross-region Læs replikaer.

Selvom der ikke længere kræves kendskab til operativsystemet for at administrere PostgreSQL i Azure-skyen, forventes DBA at tilegne sig færdigheder, som ikke er begrænset til selve databasen — Azure-netværk (VNet), forbindelsessikkerhed (firewall) ), logfremviser og analyser sammen med KQL, Azure CLI til praktisk scripting, og listen fortsætter.

Til sidst, for dem, der planlægger at migrere deres PostgreSQL-arbejdsbelastninger til Azure, er der en række ressourcer tilgængelige sammen med en udvalgt liste over Azure-partnere, herunder Credativ, en af ​​PostgreSQL's store sponsorer og bidragydere.


  1. Hvordan YEARWEEK() fungerer i MariaDB

  2. Sådan fungerer UPDATEXML() i MariaDB

  3. Opdater forespørgsel for at opdatere rækker i MySQL

  4. Hvordan tester man, om en MySQL-forespørgsel lykkedes med at ændre databasetabeldata?