Den nye Hot Standby-funktion i den kommende PostgreSQL 9.0 tillader at køre forespørgsler mod standby-noder, der tidligere ikke gjorde andet end at udføre en gendannelsesproces. To almindelige forventninger, jeg har hørt fra brugere, der forudser denne funktion, er, at den vil tillade enten at distribuere korte forespørgsler på tværs af begge noder eller tillade at køre lange rapporter mod standby uden at bruge ressourcer på masteren. Disse er begge mulige at gøre lige nu, men medmindre du forstår de afvejninger, der er involveret i, hvordan Hot Standby fungerer, kan der være noget uventet adfærd her.
Standard langvarige forespørgsler
Et af de traditionelle problemer i en database, der bruger MVCC, som PostgreSQL, er, at en langvarig forespørgsel skal holde en ressource åben – kaldet et øjebliksbillede i den aktuelle Postgres-implementering – for at forhindre databasen i at fjerne data, som forespørgslen skal operere. For eksempel, bare fordi en anden klient har slettet en række og forpligtet sig, hvis en allerede kørende forespørgsel har brug for den række for at fuldføre, kan du faktisk ikke slette de fysiske diskblokke, der er relateret til den række endnu. Du skal vente, indtil der stadig ikke findes nogen åbne forespørgsler, der forventer, at den række er synlig.
Hot Standby-begrænsninger
Hvis du har en langvarig forespørgsel, du vil have Hot Standby til at udføre, er der et par typer dårlige ting, der kan ske, når gendannelsesprocessen anvender opdateringer. Disse er beskrevet detaljeret i Hot Standby-dokumentationen. Nogle af disse dårlige ting vil få forespørgsler, der kører på standby, til at blive annulleret af årsager, der måske ikke er intuitivt indlysende:
- En HOT opdatering eller VACUUM relateret opdatering ankommer for at slette noget, som forespørgslen forventer at være synligt
- En B-træsletning vises
- Der er et låseproblem mellem den forespørgsel, du kører, og hvilke låse der kræves for at opdateringen kan behandles.
Låsesituationen er svær at håndtere, men det er ikke særlig sandsynligt, at det sker i praksis så længe, hvis du bare kører skrivebeskyttede forespørgsler på standby, fordi de vil blive isoleret via MVCC. De to andre er ikke svære at løbe ind i. Den grundlæggende ting at forstå er, at enhver OPDATERING eller SLET på masteren kan føre til at afbryde enhver forespørgsel på standby; er ligegyldigt, om ændringerne overhovedet vedrører det, forespørgslen gør.
Godt, hurtigt, billigt:vælg to
Grundlæggende er der tre ting, folk måske vil prioritere:
- Undgå masterbegrænsning:Tillad xids og tilknyttede snapshots at bevæge sig ubegrænset frem på masteren, så VACUUM og lignende oprydning ikke holdes tilbage af, hvad standbyen gør
- Ubegrænset forespørgsel:Kør forespørgsler på standby i en hvilken som helst vilkårlig periode
- Aktuel gendannelse:Hold genoprettingsprocessen på standby-tilstand opdateret med, hvad der sker på masteren, hvilket muliggør hurtig fail-over for HA
I enhver situation med Hot Standby er det bogstaveligt talt umuligt at have alle tre på én gang. Du kan kun vælge din afvejning. De tilgængelige indstillelige parametre giver dig allerede mulighed for at optimere på et par måder:
- Hvis du deaktiverer alle disse indstillinger for forsinkelse/udskydelse, optimeres til altid aktuel gendannelse, men så vil du opdage, at forespørgsler er mere tilbøjelige til at blive annulleret, end du måske forventer.
- max_standby_delay optimerer til længere forespørgsler på bekostning af at holde genoprettelsen opdateret. Dette forsinker anvendelsen af opdateringer til standby, når en, der vil forårsage et problem (HOT, VACUUM, B-tree sletning osv.), vises.
- vacuum_defer_cleanup_age og nogle snapshot-hacks kan introducere nogle master-begrænsninger for at forbedre de to andre problemer, men med en svag brugergrænseflade til at gøre det. vacuum_defer_cleanup_age er i enheder af transaktions-id'er. Du skal have en ide om den gennemsnitlige mængde xid-churn på dit system pr. tidsenhed for at ændre den måde, folk tænker på dette problem (“udskyd med mindst 1 time, så mine rapporter kører”) til en indstilling for denne værdi. xid forbrugshastighed er bare ikke en almindelig eller endda rimelig ting at måle/forudsige. Alternativt kan du åbne et øjebliksbillede på den primære, før du starter en langvarig forespørgsel på standby. dblink er foreslået i Hot Standby-dokumentationen som en måde at opnå dette på. Teoretisk set kunne en dæmon på standby skrives i brugerland, som bor på det primære, for også at løse dette problem (Simon har et grundlæggende design til en). Grundlæggende starter du en række processer, som hver især får et øjebliksbillede og derefter sover i en periode, før du frigiver det. Ved at skelne mellem, hvor længe de hver sov i, kunne du sikre, at xid-snapshots aldrig rykkede frem for hurtigt på masteren. Det burde allerede lyde indlysende, hvor meget af et frygteligt hack dette ville være.
Potentielle forbedringer
Den eneste af disse, du virkelig kan gøre noget ved rent, er at stramme op og forbedre brugergrænsefladen for masterbegrænsningen. Det gør dette til det traditionelle problem, der allerede er til stede i databasen:en langvarig forespørgsel holder et øjebliksbillede åbent (eller i det mindste begrænser fremrykningen af synlighedsrelaterede transaktions-id'er) på masteren, hvilket forhindrer masteren i at fjerne ting, der er nødvendige for at forespørgslen komplet. Du kan alternativt tænke på dette som en auto-tuning vacuum_defer_cleanup_age.
Spørgsmålet er, hvordan man laver den primære respekter behovene for langvarige forespørgsler på standby . Dette kan være muligt, hvis flere oplysninger om kravene til transaktionssynlighed for standbyen blev delt med masteren. At lave den slags udveksling ville virkelig være noget mere passende for den nye streamingreplikeringsimplementering at dele. Den måde, hvorpå en simpel Hot Standby-server er klargjort, giver ikke nogen feedback til masteren, der er egnet til, at disse data kan udveksles, udover tilgange som det allerede nævnte dblink-hack.
Med PostgreSQL 9.0 lige ved at nå en fjerde alfa-udgivelse, kan der muligvis der er stadig tid til at se nogle forbedringer på dette område endnu før 9.0-udgivelsen. Det ville være rart at se Hot Standby og Streaming Replication virkelig integreret sammen på en måde, der udfører ting, som ingen af dem er fuldt ud i stand til at gøre på egen hånd, før kodningen på denne udgivelse fryser fuldstændigt.