Het is tijd.
Ongeveer een jaar geleden publiceerden we PostgreSQL 10 met ondersteuning voor native logische replicatie. Een van de toepassingen van logische replicatie is het toestaan van upgrades met weinig of geen downtime tussen hoofdversies van PostgreSQL. Tot nu toe was PostgreSQL 10 de enige PostgreSQL-release met native logische replicatie, dus er waren niet veel mogelijkheden om op deze manier te upgraden. (Logische replicatie kan ook worden gebruikt voor het verplaatsen van gegevens tussen instanties op verschillende besturingssystemen of CPU-architecturen of met verschillende configuratie-instellingen op laag niveau, zoals blokgrootte of locale - sidegrading als je wilt.) Nu PostgreSQL 11 nabij is, zal er meer redenen om van deze functionaliteit gebruik te maken.
Laten we eerst de drie belangrijkste manieren vergelijken om een PostgreSQL-installatie te upgraden:
- pg_dump en herstel
- pg_upgrade
- logische replicatie
We kunnen deze methoden vergelijken in termen van robuustheid, snelheid, vereiste downtime en beperkingen (en meer, maar we moeten ergens stoppen voor dit artikel).
pg_dump and restore is misschien wel de meest robuuste methode, omdat het de meest geteste methode is en al tientallen jaren in gebruik is. Het heeft ook heel weinig beperkingen in termen van wat het aankan. Het is mogelijk om databases te bouwen die niet kunnen worden gedumpt en hersteld, meestal met betrekking tot bepaalde objectafhankelijkheidsrelaties, maar die zijn zeldzaam en gaan meestal gepaard met ontmoedigde praktijken.
Het probleem met de dump- en herstelmethode is natuurlijk dat deze in feite downtime vereist gedurende de hele tijd dat de dump- en herstelbewerkingen worden uitgevoerd. Hoewel de brondatabase nog steeds leesbaar en beschrijfbaar is terwijl het proces wordt uitgevoerd, gaan alle updates van de brondatabase na het starten van de dump verloren.
pg_upgrade verbetert het pg_dump-proces door rechtstreeks over de gegevensbestanden te gaan zonder ze in een logische tekstvorm te hoeven dumpen. Merk op dat pg_upgrade intern nog steeds pg_dump gebruikt om het schema te kopiëren, maar niet de gegevens. Toen pg_upgrade nieuw was, werd de robuustheid ervan in twijfel getrokken, en het heeft sommige databases onjuist geüpgraded. Maar pg_upgrade is nu behoorlijk volwassen en goed getest, dus je hoeft niet meer te aarzelen om het om die reden te gebruiken. Terwijl pg_upgrade wordt uitgevoerd, is het databasesysteem niet beschikbaar. Maar men kan een keuze maken over hoe lang pg_upgrade loopt. In de standaard kopieermodus bestaat de totale runtime uit de tijd om het schema te dumpen en te herstellen (wat meestal erg snel is, tenzij men duizenden tabellen of andere objecten heeft) plus de tijd om de gegevensbestanden te kopiëren, die afhankelijk is van hoe groot de database is (en het I/O-systeem, bestandssysteem, enz.).
In de optionele koppelingsmodus zijn de gegevensbestanden in plaats daarvan hard-linked naar de nieuwe gegevensdirectory, zodat de tijd slechts de tijd is om een korte kernelbewerking per bestand uit te voeren in plaats van elke byte te kopiëren. Het nadeel is dat als er iets misgaat met de upgrade of je moet terugvallen op de oude installatie, deze operatie je oude database zal vernietigen. (Ik werk aan een best-of-both-worlds-oplossing voor PostgreSQL 12 met behulp van reflinks of bestandskloonbewerkingen op ondersteunde bestandssystemen.)
Logische replicatie is hier de nieuwste van het stel, dus het zal waarschijnlijk enige tijd duren om de knikken op te lossen. Als je geen tijd hebt om te verkennen en te onderzoeken, is dit misschien niet de manier om nu te gaan. (Natuurlijk gebruiken mensen al vele jaren andere niet-kernoplossingen voor logische replicatie, zoals Slony, Londiste en pglogical voor het upgraden van PostgreSQL, dus er is veel ervaring met de principes, zo niet met de details.)
Het voordeel van het gebruik van logische replicatie om te upgraden is dat de toepassing kan blijven draaien op het oude exemplaar terwijl de gegevenssynchronisatie plaatsvindt. Er hoeft slechts een kleine storing te zijn terwijl de clientverbindingen worden omgeschakeld. Dus hoewel een upgrade met logische replicatie waarschijnlijk langzamer van begin tot eind is dan het gebruik van pg_upgrade in de kopieermodus (en zeker langzamer dan het gebruik van de hardlink-modus), maakt het niet veel uit, aangezien de daadwerkelijke downtime veel korter kan zijn.
Houd er rekening mee dat logische replicatie momenteel geen schemawijzigingen repliceert. In deze voorgestelde upgradeprocedure wordt het schema nog steeds gekopieerd via pg_dump, maar daaropvolgende schemawijzigingen worden niet overgedragen. Upgraden met logische replicatie heeft ook een paar andere beperkingen. Bepaalde bewerkingen worden niet vastgelegd door logische replicatie:grote objecten, TRUNCATE, volgordewijzigingen. We zullen later tijdelijke oplossingen voor deze problemen bespreken.
Als je fysieke standbys hebt (en zo niet, waarom niet?), Er zijn ook enkele verschillen waarmee je rekening moet houden tussen de methoden. Bij beide methoden moet u nieuwe fysieke standbys bouwen voor de geüpgradede instantie. Zowel met dump en restore als met logische replicatie kunnen ze worden geplaatst voordat de upgrade begint, zodat de stand-by grotendeels gereed is zodra de initiële synchronisatie van het herstel of de logische replicatie is voltooid, behoudens vertraging van de replicatie.
Met pg_upgrade moeten de nieuwe standbys worden gemaakt nadat de upgrade van de primaire is voltooid. (De pg_upgrade-documentatie beschrijft dit in meer detail.) Als u op fysieke standbys vertrouwt voor hoge beschikbaarheid, moeten de standbys aanwezig zijn voordat u overschakelt naar de nieuwe instantie, dus de instelling van de standbys kan van invloed zijn op uw algehele timingberekeningen.
Maar terug naar logische replicatie. Hier is hoe upgraden met logische replicatie kan worden gedaan:
0. Het oude exemplaar moet worden voorbereid voor logische replicatie. Dit vereist enkele configuratie-instellingen zoals beschreven onder http://www.postgresql.org/docs/10/static/logical-replication-config.html (voornamelijk wal_level = logical . Als blijkt dat u die wijzigingen moet aanbrengen, moet de server opnieuw worden opgestart. Check dit dus ruim van tevoren. Controleer ook of pg_hba.conf op de oude instantie is ingesteld om verbindingen van de nieuwe instantie te accepteren. (Om dat te veranderen is alleen herladen nodig.)
1. Installeer de nieuwe PostgreSQL-versie. U hebt minimaal het serverpakket en het clientpakket nodig dat pg_dump bevat. Veel verpakkingen maken het nu mogelijk om meerdere versies naast elkaar te installeren. Als u virtuele machines of cloudinstanties gebruikt, is het de moeite waard om de nieuwe instantie op een nieuwe host te installeren.
2. Stel een nieuwe instantie in, d.w.z. voer initdb uit. De nieuwe instantie kan andere instellingen hebben dan de oude, bijvoorbeeld landinstelling, WAL-segmentgrootte of checksumming. (Waarom zou u deze mogelijkheid niet gebruiken om gegevenscontrolesommen in te schakelen?)
3. Voordat u de nieuwe instantie start, moet u mogelijk enkele configuratie-instellingen wijzigen. Als de instantie op dezelfde host draait als de oude instantie, moet u een ander poortnummer instellen. Neem ook alle aangepaste wijzigingen over die u heeft aangebracht in postgresql.conf op uw oude instantie, zoals geheugeninstellingen, max_connections , etc. Maak op dezelfde manier pg_hba.conf instellingen die geschikt zijn voor uw omgeving. U kunt meestal beginnen met het kopiëren over de pg_hba.conf bestand van de oude instantie. Als je SSL wilt gebruiken, stel dat dan nu in.
4. Start de nieuwe (lege) instantie en controleer of deze naar tevredenheid werkt. Als u de nieuwe instantie op een nieuwe host instelt, controleert u op dit punt of u een databaseverbinding kunt maken (met psql) van de nieuwe host naar de oude database-instantie. Dat hebben we nodig in de volgende stappen.
5. Kopieer de schemadefinities met pg_dumpall. (Of je kunt het doen met pg_dump voor elke database afzonderlijk, maar vergeet dan globale objecten zoals rollen niet.)
pg_dumpall -s >schemadump.sql psql -d postgres -f schemadump.sql
Eventuele schemawijzigingen na dit punt worden niet gemigreerd. Die zou je zelf moeten beheren. In veel gevallen kunt u de veranderende DDL gewoon op beide hosts toepassen, maar het uitvoeren van opdrachten die de tabelstructuur tijdens een upgrade wijzigen, is waarschijnlijk een uitdaging te ver.
6. Maak in elke database in de broninstantie een publicatie die alle tabellen vastlegt:
CREATE PUBLICATION p_upgrade FOR ALL TABLES;
Logische replicatie werkt afzonderlijk in elke database, dus dit moet in elke database worden herhaald. Aan de andere kant hoef je niet alle databases in één keer te upgraden, dus je kunt dit één database tegelijk doen of sommige databases zelfs niet upgraden.
7. Maak in elke database in de doelinstantie een abonnement dat zich abonneert op de zojuist gemaakte publicatie. Zorg ervoor dat de bron- en doeldatabases correct overeenkomen.
CREATE SUBSCRIPTION s_upgrade CONNECTION 'host=oldhost port=oldport dbname=dbname ...' PUBLICATION p_upgrade;
Stel de verbindingsparameters naar wens in.
8. Nu wacht je tot de abonnementen de initiële gegevens hebben gekopieerd en de uitgever volledig hebben ingehaald. U kunt de initiële synchronisatiestatus van elke tabel in een abonnement controleren in de systeemcatalogus pg_subscription_rel (zoek naar r =klaar in kolom srsubstate ). De algemene status van de replicatie kan worden gecontroleerd in pg_stat_replication aan de verzendende kant en pg_stat_subscription aan de ontvangende kant.
9. Zoals hierboven vermeld, worden sequentieveranderingen niet gerepliceerd. Een mogelijke oplossing hiervoor is om de reekswaarden te kopiëren met pg_dump. U kunt een dump van de huidige reekswaarden krijgen door zoiets als dit te gebruiken:
pg_dump -d dbname --data-only -t '*_seq' >seq-data.sql
(Dit veronderstelt dat de reeksnamen allemaal overeenkomen met *_seq en geen enkele tabel komt overeen met die naam. In meer gecompliceerde gevallen kunt u ook een volledige dump maken en de sequentiegegevens uit de inhoudsopgave van de dump halen.)
Aangezien de reeksen kunnen toenemen terwijl u dit doet, kunt u misschien de seq-data.sql bestand om een beetje speling aan de cijfers toe te voegen.
Zet dat bestand vervolgens terug in de nieuwe database met psql.
10. Showtime:Schakel de toepassingen over naar de nieuwe exemplaren. Dit vereist enig denkwerk van tevoren. In het eenvoudigste scenario stopt u uw applicatieprogramma's, wijzigt u de verbindingsinstellingen en start u opnieuw. Als u een verbindingsproxy gebruikt, kunt u daar de verbinding overschakelen. U kunt ook één voor één van clienttoepassing wisselen, misschien om de zaken een beetje uit te testen of het nieuwe systeem te ontlasten. Dit werkt zolang de applicaties die nog steeds naar de oude server verwijzen en de applicaties die naar de nieuwe server verwijzen geen conflicterende schrijfacties maken. (In dat geval zou je een multimastersysteem draaien, in ieder geval voor een korte tijd, en dat is een andere orde van complexiteit.)
11. Wanneer de upgrade is voltooid, kunt u de replicatie-installatie afbreken. Voer in elke database op de nieuwe instantie
DROP SUBSCRIPTION s_upgrade;
Als u de oude instantie al hebt afgesloten, mislukt dit omdat deze de externe server niet kan bereiken om de replicatiesleuf te verwijderen. Zie de DROP ABONNEMENT man-pagina voor hoe verder te gaan in deze situatie.
U kunt de publicaties ook op de broninstantie neerzetten, maar dat is niet nodig omdat een publicatie geen bronnen bevat.
12. Verwijder ten slotte de oude instanties als u ze niet langer nodig hebt.
Enkele aanvullende opmerkingen over tijdelijke oplossingen voor zaken die logische replicatie niet ondersteunt. Als je grote objecten gebruikt, kun je ze verplaatsen met pg_dump, natuurlijk zolang ze niet veranderen tijdens het upgradeproces. Dit is een aanzienlijke beperking, dus als u veel grote objecten gebruikt, is deze methode misschien niet voor u geschikt. Als uw toepassing TRUNCATE problemen geeft tijdens het upgradeproces, worden deze acties niet gerepliceerd. Misschien kunt u uw toepassing aanpassen om te voorkomen dat deze dat doet tijdens de upgrade, of u kunt in plaats daarvan een DELETE gebruiken. PostgreSQL 11 ondersteunt het repliceren van TRUNCATE, maar dat werkt alleen als zowel de bron- als de bestemmingsinstantie PostgreSQL 11 of nieuwer zijn.
Enkele afsluitende opmerkingen die echt van toepassing zijn op alle upgrade-ondernemingen:
- Toepassingen en alle databaseclientprogramma's moeten worden getest met een nieuwe belangrijke PostgreSQL-versie voordat ze in productie worden genomen.
- Daartoe moet u ook de upgradeprocedure testen voordat u deze in de productieomgeving uitvoert.
- Schrijf dingen op of beter script en automatiseer zoveel mogelijk.
- Zorg ervoor dat uw back-upconfiguratie, bewakingssystemen en eventuele onderhoudstools en -scripts correct zijn aangepast tijdens de upgradeprocedure. Idealiter zijn deze aanwezig en geverifieerd voordat de omschakeling wordt uitgevoerd.
Met dat in gedachten, veel succes en deel je ervaringen.