Het gemakkelijker maken om een ​​PostgreSQL-productiedatabase te beheren

De afgelopen jaren is de acceptatie van PostgreSQL toegenomen. PostgreSQL is een geweldige relationele database. Qua functionaliteit is het de beste, zo niet de beste. Er zijn veel dingen die ik leuk vind:PL/PG SQL, slimme standaardinstellingen, replicatie (die echt uit de doos werkt) en een actieve en levendige open source-community. Naast de functies zijn er echter nog andere belangrijke aspecten van een database waarmee rekening moet worden gehouden. Als u van plan bent om een ​​grote 24/7-operatie te bouwen, wordt de mogelijkheid om de database eenvoudig te bedienen zodra deze in productie is, een zeer belangrijke factor. In dit opzicht houdt PostgreSQL niet zo goed stand. In deze blogpost gaan we in op enkele van deze operationele uitdagingen met PostgreSQL. Er is hier niets fundamenteel onherstelbaars, alleen een kwestie van prioriteiten stellen. Hopelijk kunnen we voldoende interesse genereren in de open source-gemeenschap om prioriteit te geven aan deze functies.

1. Geen automatische detectie van clientstuurprogramma's van hoofdfailover

Het PostgreSQL-clientstuurprogramma detecteert niet automatisch wanneer er een masterfailover is geweest (en er een nieuwe master is gekozen). Om dit te omzeilen, moeten beheerders een proxylaag aan de serverzijde implementeren. De populaire keuzes zijn DNS-toewijzing, virtuele IP-toewijzing, PgPool en HAProxy. Al deze opties kunnen zo worden gemaakt dat ze goed werken, maar er zijn aanzienlijke extra leer- en beheerdersinspanningen vereist. In het geval dat een proxy wordt geïntroduceerd in het gegevenspad, is er ook een aanzienlijke prestatie-impact. Dit is een standaard ingebouwde functie in veel van de nieuwe NoSQL-databases, en PostgreSQL zou er goed aan doen om een ​​blad uit hun boeken te halen als het op bewerkingen aankomt.

2. Geen ingebouwde automatische failover tussen master en stand-by

Als een PostgreSQL-master faalt, moet een van de standby-servers worden gekozen als master. Dit mechanisme is niet ingebouwd in PostgreSQL. Meestal worden softwaretools van derden zoals Patroni, Pacemaker, enz. Gebruikt om dit scenario af te handelen. Waarom dit niet in de server laten inbouwen? Deze hulpprogramma's van derden zien er bedrieglijk eenvoudig uit, maar het vereist veel inspanning, kennis en testen van de kant van de beheerder om dit goed te krijgen. Door dit in de database in te bouwen, bewijst u uw databasebeheerder een enorm plezier.

3. Geen uitvaltijd Grote upgrade

Het is niet mogelijk om uw PostgreSQL-database te upgraden van de ene hoofdversie naar de andere zonder downtime. U moet in wezen al uw servers afsluiten en pg_upgrade gebruiken om uw gegevens naar de nieuwere versie te upgraden. De downtime is niet groot omdat er geen gegevenskopie bij betrokken is, maar er is nog steeds downtime. Als u 24/7 werkt, is dit misschien geen optie voor u.

Met de release van logische replicatie hebben we een alternatieve optie voor online upgrade.

1. Bouw een geheel nieuwe PostgreSQL Master-Standby-configuratie met de nieuwe versie.
2. Stel logische replicatie in om te repliceren van de oudere versie naar de nieuwere versie.
3. Zodra u klaar bent, wijzigt u uw verbindingsreeks zodat deze van de oudere setup naar de nieuwe setup verwijst.

Nogmaals, dit kan worden gerealiseerd, maar de overhead is enorm. In het ideale geval is hier een manier nodig om ter plaatse op een rollende manier te upgraden via een master-standby-opstelling. Met MySQL-upgrade kunt u uw slaves ter plaatse upgraden naar de nieuwe versie en vervolgens een failover activeren.

4. Geen in-place VACUM VOL

Autovacuum/VACUUM is erg handig en helpt dit probleem tot op zekere hoogte aan te pakken. U moet regelmatig de zwelling op uw tafels onderzoeken om er zeker van te zijn dat uw autovacuüminstellingen geschikt zijn en goed werken voor uw tafel. Autovacuüm werkt echter niet helemaal - het leidt niet echt tot het samenvoegen en verwijderen van de pagina's. Als je een groot aantal updates hebt, workloads invoegt en verwijdert, zullen je pagina's gefragmenteerd raken, wat van invloed is op je prestaties. De enige manier om dit te omzeilen is om VACUUM FULL uit te voeren, waarmee in feite alle pagina's opnieuw worden opgebouwd om fragmentatie te elimineren. Dit proces kan echter alleen worden uitgevoerd met downtime - uw tafel is gedurende de VACUUM FULL uitgeschakeld. Voor grote datasets kan dit enkele uren duren en is dit geen praktisch alternatief als u 24/7 wilt werken.

Opmerking:de community is al begonnen met het werken aan de zheap-opslagengine die deze beperking overwint.

Als er andere verbeteringen zijn waarvan je denkt dat ze nuttig zijn, laat dan gerust een reactie achter.