Jeg tilbragte en uge i den storslåede by Lissabon, hvor jeg deltog i den årlige europæiske PostgeSQL-konference. Dette markerede 10-årsdagen siden den første europæiske PostgreSQL-konference og min sjette gang, jeg deltog.
Første indtryk
Byen var fantastisk, stemningen var fantastisk, og det så ud til, at det ville blive en meget produktiv og informativ uge fuld af interessante samtaler med intelligente og venlige mennesker. Så dybest set er den allerførste seje ting, jeg lærte i Lissabon, hvor fantastiske Lissabon og Portugal er, men jeg tror du kom her for resten af historien!
Delte buffere
Vi deltog i træningssessionen "PostgreSQL DBA toolbelt for day-to-day operations"
af Kaarel Moppel (Cybertec) . En ting, jeg bemærkede, var indstillingen af shared_buffers. Da shared_buffers faktisk konkurrerer eller komplementerer systemets cache, bør den ikke indstilles til nogen værdi mellem 25 % og 75 % af den samlede tilgængelige RAM. Så selvom den anbefalede indstilling for typiske arbejdsbelastninger generelt er 25 % af RAM, kan den sættes til>=75 % for særlige tilfælde, men ikke midt imellem.
Andre ting, vi lærte i denne session:
- Desværre er nem online (eller offline) aktivering/aktivering af datakontrolsummer endnu ikke i 11 (initdb/logisk replikering er fortsat den eneste mulighed)
- pas på vm.overcommit_memory, du må hellere deaktivere den ved at indstille den til 2. Indstil vm.overcommit_ratio til ca. 80.
Avanceret logisk replikering
I talen om Petr Jelinek (2. kvadrant) , de oprindelige forfattere af logisk replikering, lærte vi om mere avanceret anvendelse af denne nye spændende teknologi:
- Centraliseret dataindsamling:Vi kan have flere udgivere og derefter et centralt system med en abonnent på hver af disse udgivere, der gør data fra forskellige kilder tilgængelige i et centralt system. (typisk brug:OLAP)
- Delt globale data eller med andre ord et centralt system til at vedligeholde globale data og parametre (såsom valutaer, aktier, markeds-/vareværdier, vejr osv.), som udgiver til en eller flere abonnenter. Så vedligeholdes disse data kun i ét system, men tilgængelige i alle abonnenter.
- Logisk replikering kan være asynkron, men også synkron (garanteret ved commit)
- Nye muligheder med logisk afkodning:
- integration med Debezium/Kafka via logiske afkodningsplugins
- wal2json plugin
- Tovejsreplikering
- Tæt på nul nedetidsopgraderinger:
- opsæt logisk replikering på den nye server (muligvis initdb med aktivering af datakontrolsummer)
- vent, indtil forsinkelsen er relativt lille
- fra pgbouncer pause databasen(erne)
- vent, indtil forsinkelsen er nul
- ændre pgbouncer-konfigurationen til at pege på den nye server, genindlæs pgbouncer's conf
- fra pgbouncer genoptag databasen(erne)
Hvad er nyt i PostgreSQL 11
I denne spændende præsentation, Magnus Hagander (Redpill Linpro AB) introducerede os til vidunderne ved PostgreSQL 11:
- pg_stat_statements understøtter queryid på 64-bit.
- pg_prewarm (en metode til at opvarme systemets cache eller delte buffere):tilføjelse af nye konfigurationsparametre
- Nye standardroller gør det nemt at flytte væk fra postgres (brugeren mener jeg :) )
- Lagrede procedurer med xactional kontrol
- Forbedret fuldtekstsøgning
- Logisk replikering understøtter TRUNCATE
- Basissikkerhedskopier (pg_basebackup) validerer kontrolsummer
- Flere forbedringer i parallelisering af forespørgsler
- Partitionering endnu mere raffineret end i 10
- standardpartition
- opdateringer på tværs af partitioner (flytter række fra en partition til en anden)
- lokale partitionsindekser
- unik nøgle på tværs af alle partitioner (stadig ikke referencebar endnu)
- hash-partitionering
- partitionsmæssige joinforbindelser
- partitionsmæssige aggregater
- partitioner kan være fremmede tabeller på forskellige fremmede servere. Dette åbner op for store muligheder for finere kornskæring.
- JIT-kompilering
zheap:An Answer to PostgreSQL Bloat Woes
Dette er stadig ikke i 11, men det lyder så lovende, at jeg var nødt til at inkludere det på listen over fede ting. Præsentationen blev holdt af Amit Kapila (EnterpriseDB) en af hovedforfatterne af denne nye teknologi, som sigter mod i sidste ende at blive integreret i PostgreSQL-kernen som en alternativ form for hob. Dette vil blive integreret med den nye Pluggable Storage API i PostgreSQL, som kommer til at understøtte flere tabeladgangsmetoder (på samme måde som de forskellige [Index]-adgangsmetoder, der er dækket i min første blog).
Dette vil forsøge at løse de kroniske mangler PostgreSQL har med:
- oppustet bord
- behov for at (auto)støvsuge
- potentielt en transaktions-id-omslutning
Alle disse er ikke et problem for den gennemsnitlige mellemstore til store virksomhed (selvom dette er meget relativt), vi kender banker og andre finansielle institutioner, der kører PostgreSQL på snesevis af TB data og adskillige 1000-transaktioner/sek. uden problemer. Table bloat håndteres af autovakuum og rækkefrysning løser problemet med transaktions-id-omvikling, men stadig er dette ikke vedligeholdelsesfrit. PostgreSQL-fællesskabet arbejder hen imod en virkelig vedligeholdelsesfri database, derfor foreslås zheap-arkitekturen. Dette vil bringe:
- en ny FORTRYD-log
- UNDO-log vil gøre data synlige for gamle transaktioner, når de ser de gamle versioner
- UNDO vil blive brugt til at vende virkningerne af afbrudte transaktioner
- ændringer sker på plads. Gamle versioner gemmes ikke længere i datafilerne.
Mål på højt niveau:
- bedre kontrol med oppustethed
- færre skriver
- mindre tuple-overskrifter
Dette vil bringe PostgreSQL på niveau med MySql og Oracle i denne henseende.
Parallel forespørgsel i PostgreSQL:Hvordan man ikke (mis)bruger det?
I denne præsentation af Amit Kapila og Rafia Sabih (EnterpriseDB) lærte vi de indre dele af parallelisering og også tips til at undgå almindelige fejl samt nogle anbefalede GUC-indstillinger:
- parallelisme understøtter kun B-træindekser
- max_parallel_workers_per_gather indstillet til 1→ 4 (afhængigt af tilgængelige kerner)
- vær opmærksom på følgende indstillinger:
- parallel_tuple_cost:omkostninger ved at overføre en tuple fra en parallel arbejdsproces til en anden proces
- parallel_setup_cost:omkostninger ved at starte parallelle arbejdere og initialisere dynamisk delt hukommelse
- min_parallel_table_scan_size:minimumsstørrelsen af relationer, der skal tages i betragtning ved parallelsekvensscanning
- min_parallel_index_scan_size:den mindste størrelse af indekset, der skal tages i betragtning ved en parallel scanning
- random_page_cost:estimerede omkostninger ved at få adgang til en tilfældig side på disken