In de afgelopen paar maanden heb ik gewerkt aan online upgrades voor zeer grote databases als onderdeel van het AXLE-project en ik wil graag mijn mening delen over het onderwerp en welke vooruitgang we recentelijk hebben geboekt.
Voordat ik bij 2ndQuadrant kwam, werkte ik in Skype, waar het bedrijf geen onderhoudsperiode voor onze databases toestond. Dit betekende dat er geen downtime was toegestaan voor implementaties, upgrades, enz. Dat soort regel zorgt ervoor dat je de manier waarop je dingen doet veranderen. De meeste wijzigingen zijn klein, je doet geen zware sloten, je hebt replica's om snelle fail-over mogelijk te maken. Maar hoewel u uw releases klein en niet-blokkerend kunt maken, wat gebeurt er als u een grote versie-upgrade van de PostgreSQL-database moet uitvoeren?
U bevindt zich mogelijk in een andere situatie, aangezien de meeste bedrijven een upgradevenster hebben, en u zich dus enige downtime tijdens de upgrade kunt veroorloven. Dit brengt echter twee problemen met zich mee. Ten eerste houdt geen enkel bedrijf van de uitvaltijden, zelfs als ze zijn toegestaan. En wat nog belangrijker is, als uw database groter wordt dan gigabytes in het bereik van terabytes of honderden terabytes, kan de downtime dagen of zelfs weken duren en kan niemand het zich veroorloven om hun activiteiten zo lang te stoppen. Het resultaat is dat veel bedrijven belangrijke upgrades vaak overslaan, waardoor de volgende zelfs nog pijnlijker wordt. En de ontwikkelaars missen nieuwe functies, prestatieverbeteringen. Zij (de bedrijven) lopen soms zelfs het risico een PostgreSQL-versie te gebruiken die niet langer wordt ondersteund en bekende gegevenscorruptie of beveiligingsproblemen heeft. In de volgende paragrafen zal ik wat vertellen over mijn werk om de upgrades minder tijdrovend en daardoor minder pijnlijk en hopelijk frequenter te maken.
Laat ik eerst beginnen met een beetje geschiedenis. Vóór PostgreSQL 9.0 was de enige manier om een grote versie-upgrade uit te voeren, het uitvoeren van pg_dump en het herstellen van de dump in een instantie met een nieuwere versie van PostgreSQL. Voor deze methode moesten de structuur en alle gegevens uit de database worden gelezen en in een bestand worden geschreven. Lees dan uit het bestand en plaats het in een nieuwe database, indexen moeten opnieuw worden opgebouwd, enz.
Zoals u zich kunt voorstellen, kan dit proces behoorlijk wat tijd in beslag nemen. Prestatieverbeteringen zijn gemaakt in 8.4 voor pg_restore met de -j optie toegevoegd waar je kon specificeren hoeveel parallelle jobs uitgevoerd moesten worden. Dit maakt het mogelijk om meerdere tabellen (indexen, enz.) parallel te herstellen, waardoor het herstelproces sneller gaat voor dumps met aangepast formaat. De 9.3-versie voegde een vergelijkbare optie toe aan pg_dump, waardoor de prestaties nog verder werden verbeterd. Maar gezien hoe snel de datavolumes groeien, is de parallellisatie zelf niet voldoende om serieuze winst te maken in de tijd die nodig is voor de upgrade.
Toen arriveerde in PostgreSQL 9.0 een hulpprogramma genaamd pg_upgrade. Pg_upgrade dumpt alleen de structuren en herstelt ze in het nieuwe cluster. Maar het kopieert de gegevensbestanden zoals ze op de schijf staan, wat veel sneller is dan ze in een logisch formaat te dumpen en vervolgens opnieuw in te voegen. Dit is goed genoeg voor kleine databases omdat het een uitvaltijd van minuten of uren betekent, een tijd die voor veel scenario's acceptabel is. Er is ook de link-modus die alleen harde links maakt (knooppunten op Windows), wat dit proces nog sneller maakt. Maar vanuit mijn persoonlijk oogpunt is het te gevaarlijk om zo'n setup op een productiemasterserver te draaien. Ik zal kort uitleggen waarom. Als er iets misgaat, heb je, zodra je je nieuwe server start die is geüpgraded met behulp van de link-modus, plotseling geen productiedatabase en moet je een failover uitvoeren, of erger nog, je moet herstellen vanaf een back-up. Dat betekent dat je niet alleen niet hebt geüpgraded, maar dat je alleen maar extra downtime hebt veroorzaakt! Veel succes met het verkrijgen van goedkeuring de volgende keer.
Nu gebruiken veel mensen die zich geen lange uitvaltijden voor upgrades kunnen veroorloven, de op triggers gebaseerde replicatie-oplossingen zoals Slony of Londiste om de upgrade uit te voeren. Dit is een goede oplossing omdat u uw gegevens kunt repliceren terwijl de oorspronkelijke server draait en vervolgens kunt overschakelen met minimale downtime. In de praktijk zijn er echter verschillende problemen. Een daarvan is dat de op triggers gebaseerde oplossingen vaak onhandig zijn om in te stellen, vooral als je het maar eens in de paar jaar doet en alleen om de upgrade uit te voeren. Het is ook gemakkelijk om een tafel te missen of om tabellen in de verkeerde volgorde toe te voegen en dus niet de volledige kopie te krijgen. Ik heb dit in de praktijk gezien en mensen die de upgrade uitvoerden, werkten dagelijks met de op triggers gebaseerde replicatie . Een ander probleem is dat de op triggers gebaseerde oplossingen de brondatabase aanzienlijk belasten, waardoor de upgrade soms onmogelijk wordt omdat de databaseserver overbelast raakt zodra de replicatie is geactiveerd. En last but not least kan het erg lang duren voordat de op triggers gebaseerde replicatie de gegevens daadwerkelijk naar de nieuwe server verplaatst. De laatste keer dat ik betrokken was bij een upgradeproject, kostte de triggergebaseerde oplossing ongeveer een maand om de database te kopiëren en de wijzigingen in te halen. Ja, een maand.
Met PostgreSQL 9.4 arriveert de logische decoderingsfunctie die een frisse start biedt voor het ontwerpen van een nieuwe en betere online upgrade-probleemoplossing. Wat we deden, als onderdeel van het AXLE-project, is een tool maken die de logische decodering combineert met de hierboven beschreven technieken. De oplossing lost de meeste problemen van eerdere benaderingen op. De Uni-Directional Replication PostgreSQL-extensie (afgekort UDR) voert logische replicatie uit met behulp van logische decodering van het write-ahead log (WAL). Hierdoor is de impact op de masterserver bijna gelijk aan die van de fysieke streamingreplicatie, dus de extra belasting die wordt veroorzaakt door een voortdurende upgrade is minimaal op het draaiende systeem. Het biedt ook tools om nieuwe knooppunten te initialiseren, zowel met fysieke als logische back-up. U kunt zelfs bestaande fysieke stand-by omzetten in UDR stand-by. En omdat het een logisch replicatiesysteem is, is het mogelijk om het zo te ontwerpen dat replicatie tussen verschillende versies wordt ondersteund.
Dit alles betekent dat we UDR nu kunnen gebruiken in combinatie met pg_upgrade om een online upgrade van de belangrijkste PostgreSQL-versie uit te voeren met minimale downtime, in korte absolute tijd en met minimale impact op het draaiende systeem.
Een voorbeeld hoe dit er in de praktijk uit kan zien:
- Doe pg_basebackup van bestaande instantie.
- Stel de UDR-replicatie in tussen de oorspronkelijke instantie en degene die door basebackup is gemaakt.
- Pg_upgrade de nieuwe instantie.
- Laat UDR de wijzigingen herhalen die in de tussentijd zijn doorgevoerd.
- Schakel het verkeer naar de nieuwe instantie.
Voor instructies met meer gedetailleerde instructies, zie de UDR Online Upgrade-gids op de PostgreSQL-wiki. De UDR-bronnen zijn beschikbaar in de 2ndquadrant_bdr-repository op de PostgreSQL git-server (bdr-plugin/next branch).
Ten slotte, aangezien UDR niet alleen een online upgradetool is, maar ook een replicatieoplossing, kan het worden gebruikt voor uw normale replicatiebehoeften, in plaats van de fysieke streamingreplicatie. Bovendien biedt het verschillende voordelen, zoals het maken van tijdelijke tabellen, het repliceren van meerdere OLTP-databases naar één grote datawarehouse-database of het repliceren van slechts een deel van de database.
Ik hoop dat deze inspanning zal betekenen dat downtime-overwegingen niet langer een probleem zijn als het gaat om het upgraden van PostgreSQL 9.4 en hoger naar een nieuwe hoofdversie.
Het onderzoek dat tot deze resultaten heeft geleid, heeft financiering ontvangen van het zevende kaderprogramma van de Europese Unie (FP7/2007-2013) onder subsidieovereenkomst nr. 318633.