Vorige week was ik op Nordic PGDay 2018 en ik had nogal wat gesprekken over de tool die ik schreef, namelijk pglupgrade , om PostgreSQL-grote versie-upgrades in een replicatieclusterconfiguratie te automatiseren. Ik was heel blij dat het werd gehoord en dat enkele andere mensen in verschillende gemeenschappen lezingen gaven op meetups en andere conferenties over bijna-nul downtime-upgrades met behulp van logische replicatie. Gezien het feit dat er een lezing is die ik heb gegeven op PGDAY'17 Rusland, PGConf.EU 2017 in Warschau en tot slot op FOSDEM PGDay 2018 in Brussel, dacht ik dat het beter was om een blogpost te maken om deze presentatie beschikbaar te houden voor de mensen die dat zouden kunnen niet naar een van de bovengenoemde conferenties gaan. Als u direct het gesprek wilt aangaan en het lezen van deze blogpost wilt overslaan, is hier uw link:Near-Zero Downtime Geautomatiseerde upgrades van PostgreSQL-clusters in de cloud
De belangrijkste motivatie achter het ontwikkelen van deze tool was om een oplossing voor te stellen om de downtime tijdens grote versie-upgrades te minimaliseren, die helaas bijna iedereen die PostgreSQL gebruikt treft. Momenteel hebben we geen tool waarmee PostgreSQL-gebruikers hun databases kunnen upgraden zonder downtime en het is duidelijk een pijnpunt voor veel gebruikers, vooral bedrijven. En als we het upgradeprobleem willen oplossen, moeten we aan meer dan één server denken (zal vanaf nu een cluster worden genoemd), simpelweg omdat niet veel mensen nog maar één databaseserver gebruiken. Het meest voorkomende scenario is het instellen van fysieke streamingreplicatie voor doeleinden van hoge beschikbaarheid of het schalen van de leesquery's.
Database-upgrades
Laten we, voordat we in de oplossing duiken, een beetje bespreken hoe database-upgrades in het algemeen werken. Er zijn vier mogelijke benaderingen voor database-upgrades:
- De eerste benadering zou zijn dat databases hun opslagformaat hetzelfde houden of op zijn minst compatibel houden voor alle versies. Dit is echter moeilijk op lange termijn te garanderen, omdat nieuwe functies mogelijk wijzigingen in de manier waarop gegevens worden opgeslagen of meer metadata-informatie nodig hebben om goed te werken. Ook worden de prestaties vaak verbeterd door de gegevensstructuren te optimaliseren.
- De tweede benadering is om een logische kopie (dump) van de oude server te maken en deze in de nieuwe server te laden. Dit is de meest traditionele aanpak waarbij de oude server geen updates ontvangt tijdens het proces en resulteert in langdurige downtime van uren of zelfs dagen op grote databases.
- De derde optie is om gegevens van het oude formaat naar het nieuwe formaat te converteren. Dit kan ofwel on-the-fly worden gedaan terwijl het nieuwe systeem draait, maar levert prestatieverlies op, wat moeilijk te voorspellen is omdat het afhangt van datatoegangspatronen, of het kan offline worden gedaan terwijl de servers down zijn, wat opnieuw langdurige gevolgen met zich meebrengt uitvaltijden (hoewel vaak korter dan de tweede methode).
- De vierde methode is om logische dump te gebruiken voor het opslaan en herstellen van de database terwijl de wijzigingen die in de tussentijd plaatsvinden worden vastgelegd en ze logisch te repliceren naar de nieuwe database zodra het initiële herstel is voltooid. Deze methode vereist orkestratie van verschillende componenten, maar vermindert ook de tijd dat de database niet kan reageren op vragen.
Upgrade-methoden in PostgreSQL
PostgreSQL-upgrades kunnen worden gecombineerd met de vier hierboven genoemde methoden. Kleinere PostgreSQL-releases, die geen nieuwe functies maar alleen fixes bevatten, veranderen het bestaande gegevensformaat niet en passen bij de eerste benadering. Voor de tweede benadering biedt PostgreSQL tools genaamd pg_dump en pg_restore die de logische back-up en herstel uitvoeren. Er is ook een pg_upgrade-tool (het was een contrib-module en verplaatst naar de hoofdstructuur in PostgreSQL 9.5) die offline (de servers zijn niet actief) de oude gegevensmap naar de nieuwe converteert, wat in de derde optie kan passen. Voor de vierde benadering zijn er op triggers gebaseerde oplossingen van derden, zoals Slony voor het upgraden, maar ze hebben enkele kanttekeningen die we later zullen bespreken.
Traditionele upgrademethoden kunnen alleen upgrade de primaire server terwijl de replicaservers daarna opnieuw moeten worden opgebouwd (offline conversie) . Dit leidt tot extra problemen met zowel de beschikbaarheid als de capaciteit van het cluster, waardoor de gepercipieerde downtime wordt vergroot van de database vanuit het oogpunt van zowel applicaties als gebruikers. Logische replicatie maakt replicatie toe terwijl het systeem in bedrijf is en testinspanningen kunnen in de tussentijd worden afgehandeld (online conversie) .
Er zijn verschillende upgrademethoden die van toepassing zijn op verschillende omgevingen. Bijvoorbeeld pg_dump staat upgrade toe van zeer oude versies (d.w.z. 7.0) naar recente releases, dus als u een antieke versie van PostgreSQL gebruikt, kunt u het beste pg_dump/restore gebruiken (en beter om het nu te doen!). Als uw PostgreSQL versie 8.4 en hoger is je kunt pg_upgrade . gebruiken . Als u PostgreSQL 9.4 en hoger gebruikt, dit betekent dat je in-core “Logische Decodering” . hebt en je kunt de pglogische . gebruiken extensie als upgrademiddel. Tot slot, als u PostgreSQL 10 . gebruikt , krijgt u de kans om uw database te upgraden naar PostgreSQL 11 en hoger (zodra ze beschikbaar zijn) met behulp van in-core “Logische replicatie” (jaja!).
Logische replicatie voor upgrades
Waar is het idee om PostgreSQL te upgraden met behulp van logische replicatie vandaan? Duidelijk, pglogical claimt het upgradedoel niet openlijk zoals pg_upgrade doet (dit was een argument tegen pglogical op het conferentiefeest ), maar dit betekent niet dat we de tool niet kunnen gebruiken voor upgrades. Toen pglogical werd ontworpen, werden upgrades van downtime bijna nul beschouwd als een van de verwachte use-cases door de ontwikkelaars van de extensie.
In tegenstelling tot fysieke replicatie, die wijzigingen in de onbewerkte gegevens op schijf vastlegt, legt de logische replicatie de logische wijzigingen vast in de afzonderlijke records in de database en repliceert deze. De logische records werken voor grote releases , vandaar dat logische replicatie kan worden gebruikt om te upgraden van de ene uitgave naar de andere. Het idee om logische replicatie te gebruiken als middel voor versie-upgrade is verre van nieuw, op triggers gebaseerde replicatietools hebben upgrades op een logische manier uitgevoerd door de wijzigingen vast te leggen en te verzenden via triggers (omdat triggers ook kunnen werken ongeacht de databaseversies! ).
Als u op triggers gebaseerde replicatie-oplossingen kunt gebruiken voor minimale downtime-upgrades, waarom zou u dan de voorkeur geven aan logische replicatie? In een op triggers gebaseerd mechanisme worden alle wijzigingen vastgelegd met behulp van triggers en in wachtrijtabellen geschreven. Deze procedure verdubbelt de schrijfbewerkingen, verdubbelt logbestanden en vertraagt het systeem omdat alle wijzigingen twee keer moeten worden geschreven; wat resulteert in meer schijf-I/O en belasting op de bronserver. Daarentegen is in-core logische replicatie (hetzelfde geldt voor pglogical extension) bovenop logische decodering gebouwd. Logische decodering is een mechanisme dat informatie uit WAL-bestanden extraheert in logische wijzigingen (INSERT/UPDATE/DELETE). Aangezien de gegevens van het WAL-mechanisme worden gebruikt door de transactielogboeken te decoderen, is er geen schrijfversterking zoals in het geval van op triggers gebaseerde replicatie-oplossingen, daarom presteert deze methode beter . Dientengevolge hebben op logische decodering gebaseerde oplossingen gewoon een lagere impact op het systeem dan op triggers gebaseerde oplossingen.
Conclusie
In deze inleidende post wilde ik een idee geven waarom we zouden moeten overwegen logische replicatie te gebruiken om minimale downtime te bereiken tijdens grote versie-upgrades. We zullen in de volgende post doorgaan met de details van de architectuur en implementatie van de tool.