Gør det nemmere at administrere en PostgreSQL-produktionsdatabase

De seneste mange år har der været en stigende anvendelse af PostgreSQL. PostgreSQL er en fantastisk relationel database. Funktionsmæssigt er det deroppe med de bedste, hvis ikke de bedste. Der er mange ting, jeg elsker ved det – PL/PG SQL, smarte standardindstillinger, replikering (der faktisk fungerer ud af boksen) og et aktivt og levende open source-fællesskab. Men ud over funktionerne er der andre vigtige aspekter af en database, der skal overvejes. Hvis du planlægger at bygge en stor 24/7-operation, bliver muligheden for nemt at betjene databasen, når den først er i produktion, en meget vigtig faktor. I dette aspekt holder PostgreSQL ikke særlig godt. I dette blogindlæg vil vi detaljere nogle af disse operationelle udfordringer med PostgreSQL. Der er ikke noget, der fundamentalt kan løses her, kun et spørgsmål om prioritering. Forhåbentlig kan vi skabe tilstrækkelig interesse i open source-fællesskabet til at prioritere disse funktioner.

1. Ingen automatisk klientdriverregistrering af masterfailover

PostgreSQL-klientdriveren registrerer ikke automatisk, når der har været en master-failover (og en ny master er blevet valgt). For at omgå dette skal administratorer installere et proxy-lag på serversiden. De populære valg er DNS-mapping, virtuel IP-mapping, PgPool og HAProxy. Alle disse muligheder kan fås til at fungere godt, men der er en betydelig ekstra lærings- og administratorindsats påkrævet. I det tilfælde, hvor en proxy introduceres i datastien, er der også en betydelig effekt på ydeevnen. Dette er en standard indbygget funktion i mange af de nye NoSQL-databaser, og PostgreSQL ville gøre godt for at tage et blad ud af deres bøger, når det kommer til operationer.

2. Ingen indbygget automatisk failover mellem master og standby

Når en PostgreSQL-master fejler, skal en af ​​standby-serverne vælges til at mastere. Denne mekanisme er ikke indbygget i PostgreSQL. Typisk bruges tredjepartssoftwareværktøjer som Patroni, Pacemaker osv. til at håndtere dette scenarie. Hvorfor ikke have dette indbygget i serveren? Disse tredjepartsværktøjer ser vildledende enkle ud, men det kræver en betydelig indsats, viden og test fra administratorens side for at få dette rigtigt. Ved at bygge dette ind i databasen gør du en enorm tjeneste for din databaseadministrator.

3. Ingen større opgradering af nedetid

Det er ikke muligt at opgradere din PostgreSQL-database fra en større version til en anden uden nedetid. Du skal i bund og grund lukke alle dine servere og bruge pg_upgrade til at opgradere dine data til den nyere version. Nedetiden er ikke stor, da der ikke er nogen datakopi involveret, dog er der stadig nedetid. Hvis du kører en 24/7 operation, er dette muligvis ikke en mulighed for dig.

Med udgivelsen af ​​logisk replikering har vi en alternativ mulighed for online opgradering.

1. Byg en helt ny PostgreSQL Master-Standby-opsætning med den nye version.
2. Konfigurer logisk replikering til at replikere fra den ældre version til den nyere version.
3. Når du er klar, skal du ændre din forbindelsesstreng til at pege fra den ældre opsætning til den nye opsætning.

Igen kan dette fås til at fungere, men overheaden er enorm. Ideelt set er det, der er nødvendigt her, en måde at opgradere på stedet på en rullende måde over en master standby-opsætning. MySQL-opgradering giver dig mulighed for at opgradere dine slaver på stedet til den nye version og derefter udløse en failover.

4. Ingen in-Place VAKUUM FULD

Autovacuum/VACUUM er meget nyttigt og hjælper til en vis grad med at løse dette problem. Du bør regelmæssigt undersøge svulsten på dine borde for at sikre, at dine autovakuumindstillinger er passende og fungerer godt til dit bord. Autovacuum går dog ikke hele vejen – det ender faktisk ikke med at flette og slette siderne. Hvis du har et stort antal opdateringer, indsætter og sletter arbejdsbelastninger, vil dine sider ende med at blive fragmenterede, hvilket påvirker din ydeevne. Den eneste måde at undgå dette på er at køre VACUUM FULL, som grundlæggende vil genopbygge alle siderne for at eliminere fragmentering. Denne proces kan dog kun udføres med nedetid - dit bord er nede, så længe VACUUM FULL varer. For store datasæt kan dette ende med at tage flere timer og er ikke et praktisk alternativ, hvis du vil køre en 24/7 operation.

Bemærk:Fællesskabet har allerede startet arbejdet med zheap-lagringsmotoren, der overvinder denne begrænsning.

Hvis der er andre forbedringer, som du mener ville være nyttige, er du velkommen til at efterlade en kommentar.