De nieuwe Hot Standby-functie in de aankomende PostgreSQL 9.0 maakt het mogelijk om query's uit te voeren op standby-knooppunten die voorheen niets anders deden dan een herstelproces uitvoeren. Twee algemene verwachtingen die ik heb gehoord van gebruikers die op deze functie anticiperen, is dat het ofwel korte query's over beide knooppunten kan verspreiden, of dat lange rapporten kunnen worden uitgevoerd tegen de stand-by zonder bronnen op de master te gebruiken. Deze zijn beide nu mogelijk, maar tenzij u de compromissen begrijpt die betrokken zijn bij de werking van Hot Standby, kan hier sprake zijn van onvoorzien gedrag.
Standaard langlopende zoekopdrachten
Een van de traditionele problemen in een database die gebruikmaakt van MVCC, zoals PostgreSQL, is dat een langlopende query een bron moet openhouden – in de huidige Postgres-implementatie een momentopname genoemd – om te voorkomen dat de database gegevens verwijdert die de query nodig heeft om bedienen. Bijvoorbeeld, alleen omdat een andere client een rij heeft verwijderd en vastlegt, als een reeds lopende query die rij nodig heeft om te voltooien, kunt u de fysieke schijfblokken die aan die rij zijn gerelateerd, nog niet echt wissen. Je moet wachten tot er geen open vragen meer zijn die verwachten dat die rij zichtbaar is.
Beperkingen voor hete stand-by
Als je een langlopende query hebt die Hot Standby moet uitvoeren, zijn er een aantal soorten slechte dingen die kunnen gebeuren wanneer het herstelproces updates toepast. Deze worden in detail beschreven in de Hot Standby-documentatie. Sommige van deze slechte dingen zorgen ervoor dat query's die in de standby-modus worden uitgevoerd, worden geannuleerd om redenen die intuïtief niet duidelijk zijn:
- Er komt een HOT-update of VACUUM-gerelateerde update om iets te verwijderen waarvan de query verwacht dat het zichtbaar is
- Er verschijnt een B-tree-verwijdering
- Er is een vergrendelingsprobleem tussen de query die u uitvoert en welke vergrendelingen vereist zijn om de update te verwerken.
De lock-situatie is moeilijk om mee om te gaan, maar het is niet erg waarschijnlijk dat dit in de praktijk zo lang zal gebeuren als je alleen-lezen-query's op de standby-modus uitvoert, omdat die via MVCC worden geïsoleerd. De andere twee zijn niet moeilijk om tegen te komen. Het belangrijkste om te begrijpen is dat elke UPDATE of DELETE op de master kan ertoe leiden dat elke vraag op de standby wordt onderbroken; maakt niet uit of de wijzigingen zelfs maar betrekking hebben op wat de zoekopdracht doet.
Goed, snel, goedkoop:kies er twee
In wezen zijn er drie dingen die mensen misschien prioriteit willen geven:
- Vermijd masterbeperking:laat xids en bijbehorende snapshots onbegrensd doorgaan op de master, zodat VACUUM en soortgelijke opschoning niet worden tegengehouden door wat de stand-by doet
- Onbeperkte zoekopdrachten:voer zoekopdrachten uit in de standby-modus voor een willekeurige tijdsperiode
- Huidig herstel:houd het herstelproces in de standby-modus up-to-date met wat er op de master gebeurt, waardoor snelle fail-over voor HA mogelijk wordt
In elke situatie met Hot Standby is het letterlijk onmogelijk om alle drie tegelijk te hebben. U kunt alleen uw afweging maken. Met de beschikbare afstembare parameters kunt u al op een aantal manieren optimaliseren:
- Het uitschakelen van al deze vertragings-/uitstelinstellingen optimaliseert voor altijd actueel herstel, maar dan zul je ontdekken dat de kans groter is dat zoekopdrachten worden geannuleerd dan je zou verwachten.
- max_standby_delay optimaliseert voor langere zoekopdrachten, ten koste van het up-to-date houden van het herstel. Dit vertraagt het toepassen van updates op de stand-by zodra er een verschijnt die een probleem veroorzaakt (HOT, VACUUM, B-tree delete, enz.).
- vacuum_defer_cleanup_age en sommige snapshot-hacks kunnen een aantal masterbeperkingen introduceren om de andere twee problemen te verbeteren, maar met een zwakke gebruikersinterface om dat te doen. vacuum_defer_cleanup_age is in eenheden van transactie-ID's. U moet een idee hebben van de gemiddelde hoeveelheid xid churn op uw systeem per tijdseenheid om de manier waarop mensen over dit probleem denken (“uitstellen met ten minste 1 uur zodat mijn rapporten worden uitgevoerd”) om te zetten in een instelling voor deze waarde. xid consumptiepercentage is gewoon niet gebruikelijk of zelfs maar redelijk om te meten / voorspellen. U kunt ook een momentopname openen op de primaire voordat u een langlopende query op de secundaire stand start. dblink wordt voorgesteld in de Hot Standby-documentatie als een manier om dat te bereiken. Theoretisch zou een daemon op de stand-by kunnen worden geschreven in gebruikersland, levend op de primaire, om ook dit probleem te omzeilen (Simon heeft er een basisontwerp voor). Kortom, u start een reeks processen die elk een momentopname maken en vervolgens een tijdje slapen voordat u deze vrijgeeft. Door uit te splitsen hoe lang ze elk sliepen, kon je ervoor zorgen dat xid-snapshots nooit te snel vooruitgingen op de master. Het zou al duidelijk moeten klinken hoeveel van een vreselijke hack dit zou zijn.
Potentiële verbeteringen
De enige waar je echt iets aan kunt doen, is het aanscherpen en verbeteren van de gebruikersinterface voor de masterbeperking. Dat verandert dit in het traditionele probleem dat al in de database aanwezig is:een langlopende query houdt een momentopname open (of beperkt op zijn minst de opmars van aan zichtbaarheid gerelateerde transactie-ID's) op de master, waardoor de master niet de dingen kan verwijderen die nodig zijn voor die query om compleet. Je zou dit ook kunnen zien als een automatisch afstemmende vacuum_defer_cleanup_age.
De vraag is hoe je de primaire respecteer de behoeften van langlopende zoekopdrachten in de stand-by . Dit zou mogelijk zijn als er meer informatie over de transactiezichtbaarheidsvereisten van de stand-by zou worden gedeeld met de master. Het doen van dat soort uitwisseling zou echt iets meer geschikt zijn voor de nieuwe Streaming Replication-implementatie om te delen. De manier waarop een eenvoudige Hot Standby-server is ingericht, geeft geen feedback naar de master die geschikt is om deze gegevens uit te wisselen, afgezien van benaderingen zoals de reeds genoemde dblink-hack.
Met PostgreSQL 9.0 die net een vierde alfa-release bereikt, kan er het is nog steeds tijd om enkele verbeteringen op dit gebied te zien, nog vóór de 9.0-release. Het zou leuk zijn om Hot Standby en Streaming Replication echt samen te zien integreren op een manier die dingen bereikt die geen van beiden volledig alleen kunnen doen voordat de codering op deze release volledig vastloopt.