PostgreSQL wordt geleverd met een uitstekende set functies, ongeëvenaard in de open-sourceRDBMS-ruimte. Het is meestal gemakkelijk te leren en te gebruiken, vooral voor applicatieontwikkelaars. Sommige onderdelen zijn echter, nou ja, gewoon niet gemakkelijk. Ze vereisen werk om in te stellen en goed te krijgen, en zijn meestal ook bedrijfskritisch.
Verbindingsbeheer
PostgreSQL lanceert een nieuw proces, genaamd een backend proces , om elke verbinding af te handelen. Dit in tegenstelling tot moderne, op eventloop/threadpool gebaseerde verbindingsafhandelingsarchitecturen die worden aangetroffen in andere vergelijkbare serversoftware. Het tot stand brengen van een volledig proces kost meer tijd en middelen, en manifesteert zich als verhoogde querylatenties in toepassingen waar verbindingen in een hoog tempo worden geopend en gesloten.
Bij de meeste implementaties is pooling van verbindingen op een bepaald niveau vereist. Op een applicatieniveau kan dit uw programmeertaal/bibliotheekfuncties gebruiken.Sql/DB.SetMaxIdleConn kan bijvoorbeeld worden gebruikt om het hergebruik van verbindingen vanuit een enkele Go-applicatie te vergroten.
Vaak moet u echter een oplossing voor pooling of load balancing van derden gebruiken. Verbindingspoolers onderhouden een pool van inactieve verbindingen met de upstream Postgres-server, die worden toegewezen aan en als proxy worden verzonden naar inkomende clientverbindingen. Ze parsen meestal de SQL die door clients wordt verzonden om transactiegrenzen te herkennen en DML's voor het wijzigen van gegevens om functies zoals verbindingspooling op transactieniveau en leesreplica's te implementeren.
PgBouncer is een populaire, lichtgewicht pooler voor enkelvoudige binaire verbindingen en wordt vaak naast PostgreSQL in hetzelfde systeem uitgevoerd.
PgPool is veelzijdiger dan PgBouncer. Het kan bijvoorbeeld ook load balancing en replicatie uitvoeren.
Verbindingspooling brengt echter zijn eigen problemen met zich mee. Ten eerste is het een extra bewegend onderdeel dat in uw implementatie moet worden gehandhaafd. Het instellen van authenticatie is ook lastig als je clients hebt die verschillende inloggegevens of authenticatiemechanismen gebruiken. Sommige functies op verbindingsniveau, zoals LISTEN/NOTIFY, voorbereide instructies, tijdelijke tabellen en dergelijke, vereisen mogelijk extra configuratie of wijzigingen aan de clientzijde om te werken.
Nul downtime-upgrades
Het upgraden van PostgreSQL tussen secundaire versies (13.x -> 13.y) omvat de installatie van het nieuwe pakket en het herstarten van het serverproces. Hoewel het herstarten van het serverproces noodzakelijkerwijs alle aangesloten clients zal verstoren, is het nog steeds een redelijke vraag, aangezien de downtime gebonden is aan de duur van een herstart van de service.
Upgraden tussen grote (12.x -> 13.y) versies is echter een veel grotere deal. Meestal geldt:hoe meer gegevens er zijn, hoe pijnlijker het proces is.
De eenvoudigste methode, die alleen werkt voor kleine hoeveelheden gegevens (bijvoorbeeld tientallen GB's), is om de gegevens van de oude versie te dumpen en te herstellen naar een server met een nieuwe versie. Een andere optie is om pg_upgrade te gebruiken, waarvoor een georkestreerde dans nodig is waarbij binaire bestanden van beide versies van Postgres betrokken zijn.
In beide gevallen zouden de databases gedurende een aanzienlijke tijd niet beschikbaar zijn.
Idealiter zou het mogelijk moeten zijn om naar een nieuwe versieserver te repliceren en de nieuwe versieserver als de primaire te promoten. Het is echter niet mogelijk om streaming-replicatie uit te voeren naar een standby-server met een andere hoofdversie. Logische replicatie, hoewel het er geschikt uitziet voor de taak, heeft bepaalde problemen die moeten worden opgelost om volledige replicatie te garanderen.
De meeste HA-oplossingen voor Postgres zijn afhankelijk van streamingreplicatie, en daarom kunt u nodes in een cluster niet één voor één upgraden.
De huidige stand van de techniek zou zijn om logische replicatie te gebruiken, terwijl de beperkingen van logische replicatie worden omzeild, en mogelijk met beperkende functies die applicaties kunnen gebruiken (zoals DDL's) tijdens de upgradefase.
Hoge beschikbaarheid
PostgreSQL wordt geleverd met alle functies op laag niveau die nodig zijn om een HA-oplossing te bouwen:replicatie met feedback, trapsgewijze replicatie, synchrone replicatie, standbys, hot standbys, standby-promotie enzovoort. Het biedt echter niet echt een HA-oplossing uit de doos. Er zijn geen frameworks of tools om de gezondheid te bewaken en automatisch over te schakelen naar een standby-modus. Er is geen idee van een HA-cluster met meerdere knooppunten.
U moet een oplossing van derden instellen en uitvoeren om Postgres-implementaties met hoge beschikbaarheid te maken. Huidige favorieten zijnpg_auto_failover en Patroni. Terwijl Patroni vertrouwt op een bestaande, zeer beschikbare configuratiewinkel zoals ZooKeeper of etcd, kan pg_auto_failover het zonder een doen.
Het evalueren, inzetten en testen van een van deze in productie kost tijd en moeite. Controle-, waarschuwings- en ops-playbooks moeten worden ingesteld en onderhouden.
Bloat-beheer
De MVCC-architectuur van PostgreSQL betekent dat er nooit gegevens worden overschreven - het wijzigen van een rij resulteert alleen in een nieuwe versie van de rij die naar de schijf wordt weggeschreven. Een rij verwijderen betekent alleen opnemen dat de rij onzichtbaar is voor toekomstige transacties. Wanneer een rijversie niet toegankelijk is voor lopende of toekomstige transacties, heeft deze geen zin meer en wordt deze "bloat" genoemd. Het proces van het verzamelen van afval van deze bloat wordt "vacuüm" genoemd.
Bloat is onzichtbaar voor applicaties en wordt alleen de DBA's hoofdpijn. Voor tabellen met veel updates is het controleren en beheren van een bloat een niet-triviaal probleem. Het autovacuümproces helpt veel, maar de drempels moeten mogelijk worden afgestemd op een globale of per- tablelevel om ervoor te zorgen dat de tafelgroottes niet onhandelbaar groot worden.
Indexen worden ook beïnvloed door een opgeblazen gevoel en autovacuüm helpt hier niet. Het verwijderen van rijen en het bijwerken van geïndexeerde kolommen leiden tot dode vermeldingen in indexen. Update-zware workloads met upates naar geïndexeerde kolommen kunnen leiden tot constant groeiende en inefficiënte indexen. Er is geen equivalent van vacuüm voor indexen. De enige oplossing is om de hele index opnieuw op te bouwen met REINDEX of VACUUM FULL op de tafel te gebruiken.
Afgezien van een enkele waarde per tabel (pg_stat_all_tables.n_dead_tup), biedt Postgres niets in de manier om de bloat in een tabel te schatten, en helemaal niets voor indexen. De meest praktische manier blijft nog steeds het uitvoeren van een eng uitziende vraag van check_postgres.
pgmetrics bevat de query van check_postgres en kan JSON- en CSV-uitvoer produceren met informatie over grootte en bloat voor alle tabellen en indexen; die kunnen worden ingevoerd in monitoring- of automatiseringstools.
pg_repack is een populair alternatief voor VACUUM FULL - het kan hetzelfde werk doen, maar zonder sloten. Als je gedwongen bent om regelmatig VACUUM FULL te doen, is het een hulpmiddel dat je moet onderzoeken.
zheap is de nieuwe opslagengine voor Postgres die al jaren in ontwikkeling is en die belooft de opgeblazenheid te verminderen door middel van interne updates.
Queryplanbeheer
Core PostgreSQL biedt slechts twee rudimentaire tools in deze ruimte:
- pg_stat_statements extensie voor queryanalyse - dit geeft het totaal en gemiddelden van queryplanning en uitvoeringstijden, schijf- en geheugengebruik
- auto_explain extensie, die uitvoeringsplannen voor query's kan afdrukken in de Postgres-logbestemming
Hoewel de statistieken van pg_stat_statements net genoeg zijn om rond te komen, gebruik je auto_explain om plannen in logbestanden te forceren en ze vervolgens te extraheren, is niet echt meer dan een hack, vooral in vergelijking met commerciële concurrenten van Postgres, die plangeschiedenis, basislijning en beheerfuncties bieden.
De huidige stand van de techniek met Postgres is om de logfile forquery-plannen te ontginnen en ze ergens anders op te slaan. Maar misschien is het meest invaliderende probleem het niet kunnen associëren van het queryplan met de bijbehorende analyses van pg_stat_statements. De manier waarop pgDash dit doet, is door zowel de SQL-queryteksten van pg_stat_statements als de auto_explain-uitvoer te ontleden, aan te passen voor het mangelen dat wordt gedaan door pg_stat_statements, en proberen de twee te matchen. Het vereist een volledige PostgreSQL-dialect SQL-parser.
Baselining, beleid instellen voor planselectie, enz. zijn momenteel gewoon niet mogelijk in de kern van PostgreSQL.
Er zijn een paar extensies die in wezen verbeterde versies zijn van pg_stat_statements, maar de extra stappen die nodig zijn om een extensie van derden te gebruiken, maken het voor de meeste mensen een uitdaging, vooral als ze een beheerde Postgres-provider gebruiken.
Afstemming
PostgreSQL heeft een overvloed aan afstemmingsopties, te beginnen met de instelling under-configured-by-defaultshared_buffers. Sommige zijn gemakkelijk te begrijpen en in te stellen, zoals het aantal parallelle werkers voor verschillende bewerkingen (max_worker_processen, max_parallel_* enz.). Anderen zijn een beetje obscuur (wal_compression, random_page_cost, enz.) Maar over het algemeen gunstig. De meest irritante zijn echter degenen die kwantificeerbare informatie over de werklast nodig hebben.
Als bijvoorbeeld work_mem is te laag, kunnen query's tijdelijke schijfbestanden gebruiken; als deze te hoog zijn en er voldoende gelijktijdige query's zijn, kunnen de backendprocessen van Postgres OOM worden uitgeschakeld. Dus hoe kom je erachter op welk nummer je het moet instellen?
In de praktijk, vooral bij OLTP-workloads en webapplicatie-workloads, is het onmogelijk om te voorspellen wat de piekgeheugenvraag voor query's zou zijn. U kunt het beste een redelijke waarde instellen en vervolgens de zoekopdrachten controleren om te zien of een van hen baat had kunnen hebben bij een hogere waarde van work_mem.
En hoe doe je dat? U heeft de extensie auto_explain nodig om de query-uitvoeringsplannen van elke query te loggen, deze uit de logbestanden van Postgres te extraheren, elk queryplan te onderzoeken om te zien of het externe samenvoegingen op schijf of een bitmap-heapscan met lossy heap-blokken gebruikt.
Niet onmogelijk, gewoon moeilijk.