Jag tillbringade en vecka i den magnifika staden Lissabon och deltog i den årliga Europeiska PostgeSQL-konferensen. Detta markerade 10-årsjubileet sedan den första europeiska PostgreSQL-konferensen och sjätte gången jag deltog.
Första intryck
Staden var fantastisk, stämningen var fantastisk och det verkade som att det skulle bli en mycket produktiv och informativ vecka full av intressanta samtal med intelligenta och vänliga människor. Så det allra första coola jag lärde mig i Lissabon är hur fantastiska Lissabon och Portugal är, men jag antar att du kom hit för resten av historien!
Delade buffertar
Vi deltog i utbildningssessionen "PostgreSQL DBA toolbelt for day-to-day operations"
av Kaarel Moppel (Cybertec) . En sak jag noterade var inställningen av shared_buffers. Eftersom shared_buffers faktiskt konkurrerar eller kompletterar systemets cache bör den inte ställas in på något värde mellan 25 % och 75 % av det totala tillgängliga RAM-minnet. Så även om den rekommenderade inställningen för typiska arbetsbelastningar i allmänhet är 25 % av RAM-minnet, kan den ställas in på>=75 % för speciella fall, men inte däremellan.
Andra saker vi lärde oss under den här sessionen:
- tyvärr är enkel online (eller offline) aktivering/aktivering av datakontrollsummor ännu inte i 11 (initdb/logisk replikering är fortfarande det enda alternativet)
- akta dig för vm.overcommit_memory, du bör inaktivera det genom att ställa in det på 2. Ställ in vm.overcommit_ratio till cirka 80.
Avancerad logisk replikering
I talet om Petr Jelinek (2:a kvadranten) , de ursprungliga författarna av logisk replikering, lärde vi oss om mer avancerad användning av denna nya spännande teknik:
- Centraliserad datainsamling:vi kan ha flera utgivare och sedan ett centralt system med en prenumerant på var och en av dessa utgivare, vilket gör data från olika källor tillgänglig i ett centralt system. (vanlig användning:OLAP)
- Delad global data eller med andra ord ett centralt system för att upprätthålla globala data och parametrar (såsom valutor, aktier, marknads-/varuvärden, väder etc) som publiceras till en eller flera prenumeranter. Då upprätthålls dessa data endast i ett system men tillgängliga i alla abonnenter.
- Logisk replikering kan vara asynkron men också synkron (garanterat vid commit)
- Nya möjligheter med logisk avkodning:
- integration med Debezium/Kafka via logiska avkodningsplugins
- wal2json plugin
- Dubbelriktad replikering
- Nära noll uppgraderingar av driftstopp:
- ställ in logisk replikering på den nya servern (möjligen initdb med aktiverande datakontrollsummor)
- vänta tills fördröjningen är relativt liten
- från pgbouncer pausa databasen/databaserna
- vänta tills fördröjningen är noll
- ändra pgbouncer-konfigurationen så att den pekar på den nya servern, ladda om pgbouncers conf
- från pgbouncer återuppta databasen/databaserna
Vad är nytt i PostgreSQL 11
I denna spännande presentation, Magnus Hagander (Redpill Linpro AB) introducerade oss underverken i PostgreSQL 11:
- pg_stat_statements stöder queryid på 64-bitars.
- pg_prewarm (en metod för att värma upp systemets cache eller delade buffertar):tillägg av nya konfigurationsparametrar
- Nya standardroller gör det enkelt att flytta bort från postgres (användaren menar jag :) )
- Lagrade procedurer med xactional control
- Förbättrad fulltextsökning
- Logisk replikering stöder TRUNCATE
- Basbackuper (pg_basebackup) validerar kontrollsummor
- Flera förbättringar av parallellisering av frågor
- Partitionering ännu mer förfinad än i 10
- standardpartition
- uppdateringar över partitioner (flyttar rad från en partition till en annan)
- lokala partitionsindex
- unik nyckel över alla partitioner (fortfarande inte referensbar ännu)
- hash-partitionering
- partitionsmässiga kopplingar
- partitionsmässiga aggregat
- partitioner kan vara främmande tabeller på olika främmande servrar. Detta öppnar stora möjligheter för finare skärning.
- JIT-kompilering
zheap:An Answer to PostgreSQL Bloat Woes
Det här är fortfarande inte i 11, men det låter så lovande att jag var tvungen att ta med det i listan över coola saker. Presentationen hölls av Amit Kapila (EnterpriseDB) en av huvudförfattarna till denna nya teknik som syftar till att så småningom integreras i PostgreSQL-kärnan som en alternativ typ av hög. Detta kommer att integreras med det nya Pluggable Storage API i PostgreSQL, som kommer att stödja flera tabellåtkomstmetoder (på samma sätt som de olika [Index] åtkomstmetoderna som behandlas i min första blogg).
Detta kommer att försöka lösa de kroniska bristerna som PostgreSQL har med:
- bordsvällning
- behöver (auto)dammsuga
- potentiellt ett transaktions-id omslutande
Alla dessa är inte ett problem för den genomsnittliga medelstora till stora verksamheten (även om detta är mycket relativt), vi känner till banker och andra finansiella institutioner som driver PostgreSQL med tiotals TB data och flera tusentals transaktioner/sekund utan problem. Bordsvällning hanteras av autovakuum och radfrysning löser problemet med transaktions-id-omslutning, men detta är fortfarande inte underhållsfritt. PostgreSQL-communityt arbetar mot en verkligt underhållsfri databas, därför föreslås zheap-arkitekturen. Detta ger:
- en ny ångra logg
- ÅNGRA logg kommer att göra data synliga för gamla transaktioner med de gamla versionerna
- ÅNGA kommer att användas för att vända effekterna av avbrutna transaktioner
- förändringar sker på plats. Gamla versioner sparas inte längre i datafilerna.
Mål på hög nivå:
- bättre kontroll över uppblåsthet
- färre skriver
- mindre tuppelrubriker
Detta kommer att göra PostgreSQL i nivå med MySql och Oracle i detta avseende.
Parallell fråga i PostgreSQL:Hur man inte (fel)använder den?
I den här presentationen av Amit Kapila och Rafia Sabih (EnterpriseDB) lärde vi oss de inre bitarna av parallellisering och även tips för att undvika vanliga misstag samt några rekommenderade GUC-inställningar:
- parallellism stöder endast B-trädindex
- max_parallel_workers_per_gather satt till 1→ 4 (beroende på tillgängliga kärnor)
- var uppmärksam på följande inställningar:
- parallel_tuple_cost:kostnad för att överföra en tupel från en parallell arbetsprocess till en annan process
- parallel_setup_cost:kostnad för att starta parallella arbetare och initiera dynamiskt delat minne
- min_parallel_table_scan_size:den minsta storleken på relationer som ska beaktas för parallellsekvenssökning
- min_parallel_index_scan_size:den minsta storleken på index som ska beaktas för en parallell skanning
- random_page_cost:uppskattad kostnad för att komma åt en slumpmässig sida på disken