Een van de interessante functies in PostgreSQL sinds versie 9.4 is de mogelijkheid om het verwijderen van WAL-bestanden te regelen met behulp van replicatieslots. De duistere kant is dat replicatieslots ervoor kunnen zorgen dat schijven vol raken met oude WAL, waardoor de hoofdproductieserver wordt vernietigd. In dit artikel leg ik PostgreSQL-replicatieslots uit en hoe een nieuwe functie in PostgreSQL 13 dit probleem helpt voorkomen.

WAL-productie

Zoals u weet, wordt WAL geproduceerd voor databasewijzigingen op een primaire server:inserts, updates, et cetera . Een actievere database zal meer WAL produceren — op een zeer actieve server kan er elke minuut vele gigabytes aan WAL worden geproduceerd. WAL wordt geschreven naar bestanden met namen in een toenemende numerieke volgorde, en de bestanden hebben altijd dezelfde grootte (16 MB is standaard en typisch). Zodra de gegevens in een bestand niet langer nodig zijn, kan dat bestand gerecycleerd worden , wat betekent dat de naam moet worden gewijzigd in een hoger genummerde positie in de reeks, zodat deze later met nieuwe gegevens kan worden gevuld.

(Er zijn speciale situaties, zoals een toename van activiteit die leidt tot het aanmaken van extra bestanden; wanneer de toename later afneemt, worden die extra bestanden verwijderd in plaats van gerecycled.)

Omdat alle schrijfactiviteiten in de database WAL produceren, is het van cruciaal belang dat er schijfruimte beschikbaar is. Wanneer de schijf met WAL vol is, kan de server geen nieuwe transacties verwerken en kan hij vastlopen, of erger:hij kan volledig omvallen. Dit is dus een situatie die met alle mogelijke middelen moet worden vermeden.

Replicatieslots

Replicatie in PostgreSQL werkt door WAL-bestanden te verwerken. Om dit te laten werken, moeten alle WAL-bestanden tijdelijk beschikbaar zijn totdat ze worden verwerkt. Daarom is er een mechanisme nodig om het hoofd WAL-beheer te vertellen bestanden niet te recyclen of te verwijderen.

Voer replicatieslots in. Slots zijn een mechanisme dat aangeeft dat dit back-up die we nemen, vereist dat WAL-bestand, en kunt u het alstublieft nog niet verwijderen; of deze replica heeft dat nog steeds niet verwerkt WAL-bestand, dus kan het een tijdje met rust worden gelaten.

Op zichzelf nemen replicatieslots zeer weinig schijfruimte in beslag. Ze slaan slechts een klein beetje metadata op, inclusief een verwijzing naar een positie in WAL. Maar de WAL-gegevens die het beschermt, is een andere zaak:in een zeer actieve server kan het worden gemeten in gigabytes of erger.

WAL-verbruik

Het invoeren van gegevens naar een fysieke replica betekent het kopiëren van de WAL-gegevens van de primaire server. Evenzo moet een logische replica WAL-gegevens lezen (en een geïnterpreteerde versie naar de replica verzenden). De WAL-positie die wordt gelezen, is wat de sleuf bijhoudt. Zodra de replica de WAL-gegevens op de een of andere manier heeft beveiligd, kan de sleuf worden gevorderd; dit vertelt WAL-beheer in het primaire dat het WAL-bestand dan beschikbaar is voor verwijdering. Dit gebeurt continu wanneer de replica actief is, zodat WAL in de primaire server dezelfde hoeveelheid schijfruimte zal gebruiken of misschien net iets meer. Zelfs twee keer zoveel of tien keer zoveel kan acceptabel zijn, afhankelijk van de omstandigheden.

Het probleem is dat als een replica volledig sterft en gedurende een lange periode niet herstelt; of de replica wordt vernietigd en de DBA vergeet de replicatiesleuf te verwijderen; of de slot is een vergeten overblijfsel van een experiment; of zelfs de replica wordt gevoed via een langzame netwerkverbinding, dan zal de gereserveerde WAL onbeperkt groeien. En dat wordt een tikkende bom.

Sleufgrootte beperken

Om dit probleem aan te pakken, werkte Kyotaro Horiguchi sinds februari 2017 aan een PostgreSQL-patch om de grootte van de door een slot gereserveerde WAL te beperken. Na een zeer lang beoordelings- en herbewerkingsproces heb ik het geïntegreerd voor PostgreSQL 13, waardoor het beheer van PostgreSQL-farms met hoge beschikbaarheid is verbeterd.

Het belangrijkste principe is dat het beter is om een replica te doden (door op de een of andere manier de sleuf ongeldig te maken; meer daarover hieronder) dan de primaire server te doden die die replica voedt en alle productie ermee stop te zetten.

De manier waarop het werkt is vrij eenvoudig:stel max_slot_wal_keep_size in (documentatie) in postgresql.conf tot de maximale hoeveelheid schijfruimte van WAL die replicatieslots mogen reserveren. Als een slot dat punt bereikt en er een controlepunt optreedt, wordt dat slot als ongeldig gemarkeerd en kunnen sommige WAL-bestanden worden verwijderd. Als het slot actief werd gebruikt door een walsender proces, zal dat proces worden gesignaleerd zodat het wordt beëindigd. Als de walsender opnieuw start, zal hij merken dat de benodigde WAL-bestanden er niet meer zijn. De replica die dat slot gebruikt, moet opnieuw worden gekloond.

Als max_slot_wal_keep_size nul is, wat de standaardwaarde is, dan is er geen limiet. Ik raad dit niet aan, omdat het tot storingen leidt wanneer slots de schijf vullen.

De gezondheid van slots bewaken

Ook inbegrepen zijn enkele bewakingsfuncties. Twee kolommen in pg_replication_slots zijn relevant. De meest kritische is wal_status . Als die kolom reserved is , dan wijst het slot naar gegevens binnen max_wal_size; als het extended is toen overschreed het max_wal_size , maar wordt nog steeds beschermd door wal_keep_size of max_slot_wal_keep_size (inclusief wanneer max_slot_wal_keep_size nul is). Beide toestanden zijn goed en normaal. Wanneer een slot echter de limiet overschrijdt, wordt het eerst unreserved , wat betekent dat het in direct gevaar verkeert, maar nog steeds kan herstellen als het snel genoeg is. Ten slotte wordt de status lost wanneer WAL-bestanden zijn verwijderd en er geen herstel mogelijk is.

De andere kolom is safe_wal_size :het toont het aantal bytes WAL dat kan worden geschreven voordat dit slot het gevaar loopt dat WAL-bestanden worden verwijderd. We raden u aan deze kolom in uw monitoringsysteem goed in de gaten te houden en waarschuwingen te geven wanneer deze laag wordt. Nul of negatief betekent dat je replica dood is zodra een checkpoint plaatsvindt:

SELECT slot_name, active, wal_status, safe_wal_size
  FROM pg_catalog.pg_replication_slots;

Wij zijn van mening dat deze nieuwe functie het onderhoud van replica's eenvoudiger en robuuster maakt; hopelijk zullen we door deze problemen geen rampen meer zien met een productieonderbreking.

(Een opmerking:safe_wal_size werd geïntroduceerd in 13beta3, dus zorg ervoor dat u up-to-date documentatie raadpleegt, anders ziet u min_safe_lsn in plaats van. Negeer dat.)

Bedankt