Best practices voor naadloze migratie naar Azure Database for PostgreSQL
VAN TOEPASSING OP:
Azure Database for PostgreSQL - Flexibele server
In dit artikel worden veelvoorkomende valkuilen en aanbevolen procedures beschreven om een soepele en succesvolle migratie naar Azure Database for PostgreSQL te garanderen.
Premigratievalidatie
Als eerste stap in de migratie voert u de premigratievalidatie uit voordat u een migratie uitvoert. U kunt de opties Valideren en Valideren en Migreren gebruiken op de pagina migratie-instelling. Premigratievalidatie voert grondige controles uit op basis van een vooraf gedefinieerde regelset. Het doel is om potentiële problemen te identificeren en bruikbare inzichten te bieden voor herstelacties. Blijf premigratievalidatie uitvoeren totdat deze de status Geslaagd heeft. Selecteer premigratievalidaties om meer te weten te komen.
Configuratie van flexibele doelserver
Tijdens de eerste basiskopie van gegevens worden meerdere invoeginstructies uitgevoerd op het doel, waarmee WAL's (Write Ahead Logs) worden gegenereerd. Totdat deze WAL's zijn gearchiveerd, verbruiken de logboeken opslag op het doel en de opslag die nodig is voor de database.
Als u het getal wilt berekenen, meldt u zich aan bij het bronexemplaren en voert u deze opdracht uit voor alle database(s) die moeten worden gemigreerd:
SELECT pg_size_pretty( pg_database_size('dbname') );
Het is raadzaam om voldoende opslagruimte toe te wijzen op de flexibele server, gelijk aan 1,25 keer of 25% meer opslagruimte dan wordt gebruikt per uitvoer voor de bovenstaande opdracht. Automatische groei van opslag kan ook worden gebruikt.
Belangrijk
De opslaggrootte kan niet worden verkleind in handmatige configuratie of automatische groei van opslag. Elke stap in het opslagconfiguratiespectrum verdubbelt in grootte, dus het schatten van de vereiste opslag vooraf is verstandig.
De quickstart voor het maken van een flexibele Azure Database for PostgreSQL-server met behulp van de portal is een uitstekende plek om te beginnen. Compute- en opslagopties in Azure Database for PostgreSQL - Flexible Server biedt ook gedetailleerde informatie over elke serverconfiguratie.
Tijdlijn voor migratie
Elke migratie heeft een maximale levensduur van zeven dagen (168 uur) zodra deze wordt gestart en treedt er een time-out op na zeven dagen. U kunt uw migratie- en toepassingsknipsel voltooien zodra de gegevensvalidatie is voltooid en alle controles zijn voltooid om te voorkomen dat er een time-out optreedt voor de migratie. Na voltooiing van de eerste basismigratie duurt het cutover-venster drie dagen (72 uur) voordat er een time-out optreedt. Bij offlinemigraties moeten de toepassingen stoppen met schrijven naar de database om gegevensverlies te voorkomen. Houd voor onlinemigratie ook verkeer laag tijdens de migratie.
De meeste niet-prod-servers (dev, UAT, test, fasering) worden gemigreerd met behulp van offlinemigraties. Omdat deze servers minder gegevens hebben dan de productieservers, wordt de migratie snel voltooid. Voor migratie van productieservers moet u weten hoe lang het duurt om de migratie te voltooien om deze vooraf te plannen.
De tijd die nodig is om de migratie te voltooien, is afhankelijk van verschillende factoren. Het bevat het aantal databases, de grootte, het aantal tabellen in elke database, het aantal indexen en de gegevensdistributie tussen tabellen. Het is ook afhankelijk van de SKU van de doelserver en de IOPS die beschikbaar zijn op het bronexemplaren en de doelserver. Gezien de vele factoren die van invloed kunnen zijn op de migratietijd, is het moeilijk om de totale tijd te schatten voordat de migratie is voltooid. U kunt het beste een testmigratie uitvoeren met uw workload.
De volgende fasen worden overwogen voor het berekenen van de totale downtime voor het uitvoeren van migratie van productieservers.
Migratie van PITR : de beste manier om een goede schatting te krijgen van de tijd die nodig is om uw productiedatabaseserver te migreren, is door een herstel naar een bepaald tijdstip van uw productieserver uit te voeren en de offlinemigratie uit te voeren op deze zojuist herstelde server.
Migratie van buffer : nadat u de bovenstaande stap hebt voltooid, kunt u plannen voor de werkelijke productiemigratie gedurende een periode waarin het toepassingsverkeer laag is. Deze migratie kan op dezelfde dag of waarschijnlijk een week worden gepland. Op dit moment is de grootte van de bronserver mogelijk toegenomen. Werk de geschatte migratietijd voor uw productieserver bij op basis van de hoeveelheid van deze toename. Als de toename aanzienlijk is, kunt u overwegen een andere test uit te voeren met behulp van de PITR-server. Maar voor de meeste servers zou de grootteverhoging niet significant genoeg moeten zijn.
Gegevensvalidatie : zodra de migratie voor de productieserver is voltooid, moet u controleren of de gegevens op de flexibele server een exacte kopie van het bronexemplaar zijn. Klanten kunnen opensource-/hulpprogramma's van derden gebruiken of de validatie handmatig uitvoeren. Bereid de validatiestappen voor die u vóór de daadwerkelijke migratie wilt uitvoeren. Validatie kan het volgende omvatten:
Overeenkomen met het aantal rijen voor alle tabellen die betrokken zijn bij de migratie.
Overeenkomende aantallen voor alle databaseobjecten (tabellen, reeksen, extensies, procedures, indexen)
Maximale of minimale id's van sleuteltoepassingsgerelateerde kolommen vergelijken
Notitie
De grootte van databases moet de juiste meetwaarde zijn voor validatie. Het bronexemplaren kan bloats/dode tuples hebben, waardoor de grootte van het bronexemplaren kan worden vergroot. Het is volledig normaal om grootteverschillen te hebben tussen bronexemplaren en doelservers. Als er een probleem is in de eerste drie stappen van de validatie, geeft dit een probleem aan met de migratie.
Migratie van serverinstellingen : aangepaste serverparameters, firewallregels (indien van toepassing), tags en waarschuwingen moeten handmatig worden gekopieerd van het bronexemplaren naar het doel.
Wijzigen van verbindingsreeks s- De toepassing moet de verbindingsreeks s wijzigen in een flexibele server na een geslaagde validatie. Deze activiteit wordt gecoördineerd met het toepassingsteam om alle verwijzingen te wijzigen van verbindingsreeks s die verwijzen naar het bronexemplaren. Op de flexibele server kan de gebruikersparameter worden gebruikt in de notatie user=username in de verbindingsreeks.
Bijvoorbeeld: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1
Hoewel een migratie vaak zonder problemen wordt uitgevoerd, is het raadzaam om te plannen voor onvoorziene gebeurtenissen als er meer tijd nodig is voor foutopsporing of als een migratie opnieuw moet worden gestart.
Benchmarking voor migratiesnelheid
In de volgende tabel ziet u de tijd die nodig is voor het uitvoeren van migraties voor databases van verschillende grootten met behulp van de migratieservice. De migratie is uitgevoerd met behulp van een flexibele server met de SKU: Standard_D4ds_v4(4 kernen, 16 GB geheugen, schijf van 128 GB en 500 iops)
| Databaseomvang | Geschatte tijd (UU:MM) |
|---|---|
| 1 GB | 00:01 |
| 5 GB | 00:03 |
| 10 GB | 00:08 |
| 50 GB | 00:35 |
| 100 GB | 01:00 |
| 500 GB | 04:00 |
| 1000 GB | 07:00 |
Notitie
De bovenstaande getallen geven u een benadering van de tijd die nodig is om de migratie te voltooien. We raden u ten zeerste aan een testmigratie uit te voeren met uw workload om een nauwkeurige waarde te krijgen voor het migreren van uw server.
Belangrijk
Kies een hogere SKU voor uw flexibele server om snellere migraties uit te voeren. Azure Database for PostgreSQL Flexibele server ondersteunt bijna nul downtime Compute & IOPS-schaalaanpassing, zodat de SKU kan worden bijgewerkt met minimale downtime. U kunt de SKU altijd wijzigen zodat deze overeenkomt met de toepassing die na de migratie nodig is.
Migratiesnelheid verbeteren - parallelle migratie van tabellen
Een krachtige SKU wordt aanbevolen voor het doel, omdat de PostgreSQL-migratieservice geen container op de flexibele server heeft. Met een krachtige SKU kunnen meer tabellen parallel worden gemigreerd. U kunt de SKU na de migratie terugschalen naar uw voorkeursconfiguratie. Deze sectie bevat stappen om de migratiesnelheid te verbeteren voor het geval de gegevensdistributie tussen de tabellen evenwichtiger moet zijn en/of een krachtigere SKU de migratiesnelheid niet aanzienlijk beïnvloedt.
Als de gegevensdistributie op de bron sterk scheef is, waarbij de meeste gegevens in één tabel aanwezig zijn, moet de toegewezen berekening voor migratie volledig worden gebruikt en ontstaat er een knelpunt. Daarom splitsen we grote tabellen op in kleinere segmenten, die vervolgens parallel worden gemigreerd. Deze functie is van toepassing op tabellen met meer dan 10000000 tuples (10 m). Het splitsen van de tabel in kleinere segmenten is mogelijk als aan een van de volgende voorwaarden wordt voldaan.
De tabel moet een kolom hebben met een eenvoudige (niet samengestelde) primaire sleutel of een unieke index van het type int of significant int.
Notitie
In het geval van benaderingen #2 of #3 moet de gebruiker zorgvuldig de gevolgen evalueren van het toevoegen van een unieke indexkolom aan het bronschema. Pas na bevestiging dat het toevoegen van een unieke indexkolom geen invloed heeft op de toepassing als de gebruiker doorgaat met de wijzigingen.
Als de tabel geen eenvoudige primaire sleutel of unieke index van het type int of significant int heeft, maar een kolom heeft die voldoet aan de criteria voor het gegevenstype, kan de kolom worden geconverteerd naar een unieke index met behulp van de onderstaande opdracht. Voor deze opdracht is geen vergrendeling van de tabel vereist.
create unique index concurrently partkey_idx on <table name> (column name);Als de tabel geen eenvoudige primaire sleutel of unieke index of een kolom bevat die voldoet aan de criteria van het gegevenstype, kunt u een dergelijke kolom toevoegen met ALTER en deze na de migratie neerzetten. Voor het uitvoeren van de opdracht ALTER is een vergrendeling in de tabel vereist.
alter table <table name> add column <column name> big serial unique;
Als aan een van de bovenstaande voorwaarden wordt voldaan, wordt de tabel gemigreerd in meerdere partities parallel, wat een gemarkeerde toename van de migratiesnelheid moet bieden.
Hoe het werkt
- De migratieservice zoekt de maximum- en minimumwaarde voor gehele getallen op van de primaire sleutel/unieke index van de tabel die parallel moet worden gesplitst en gemigreerd.
- Als het verschil tussen de minimum- en maximumwaarde groter is dan 100000000 (10 m), wordt de tabel gesplitst in meerdere delen en wordt elk onderdeel parallel gemigreerd.
Kortom, de PostgreSQL-migratieservice migreert een tabel in parallelle threads en vermindert de migratietijd als:
- De tabel heeft een kolom met een eenvoudige primaire sleutel of een unieke index van het type int of significant int.
- De tabel heeft ten minste 10000000 rijen (10 m), zodat het verschil tussen de minimum- en maximumwaarde van de primaire sleutel meer dan 100000000 (10 m) is.
- De gebruikte SKU heeft niet-actieve kernen, die kunnen worden gebruikt voor het parallel migreren van de tabel.
Vacuüm-bloat in de PostgreSQL-database
Wanneer gegevens na verloop van tijd worden toegevoegd, bijgewerkt en verwijderd, kan PostgreSQL dode rijen en verspilde opslagruimte verzamelen. Deze bloat kan leiden tot hogere opslagvereisten en verminderde queryprestaties. Vacuuming is een cruciale onderhoudstaak die helpt deze verspilde ruimte vrij te maken en ervoor zorgt dat de database efficiënt werkt. Vacuuming lost problemen op, zoals dode rijen en tabelbloat, waardoor efficiënt gebruik van opslag wordt gegarandeerd. Belangrijker is dat het zorgt voor een snellere migratie, omdat de migratietijd een functie is van de databasegrootte.
PostgreSQL biedt de opdracht VACUUM voor het vrijmaken van opslag die wordt bezet door dode rijen. De ANALYZE optie verzamelt ook statistieken, waardoor queryplanning verder wordt geoptimaliseerd. Voor tabellen met zware schrijfactiviteit kan het VACUUM proces agressiever zijn, VACUUM FULLmaar het vereist meer tijd om uit te voeren.
- Standaard vacuüm
VACUUM your_table;
- Vacuüm met Analyseren
VACUUM ANALYZE your_table;
- Agressief vacuüm voor zware schrijftabellen
VACUUM FULL your_table;
Vervang in dit voorbeeld your_table door de werkelijke tabelnaam. De VACUUM opdracht zonder FULL maakt ruimte efficiënt vrij, terwijl VACUUM ANALYZE queryplanning wordt geoptimaliseerd. De VACUUM FULL optie moet zorgvuldig worden gebruikt vanwege de zwaardere invloed op de prestaties.
In sommige databases worden grote objecten, zoals afbeeldingen of documenten, opgeslagen die in de loop van de tijd kunnen bijdragen aan databasebloat. De VACUUMLO opdracht is ontworpen voor grote objecten in PostgreSQL.
- Vacuüm grote objecten
VACUUMLO;
Het regelmatig integreren van deze vacuümstrategieën zorgt voor een goed onderhouden PostgreSQL-database.
Speciale overweging
Er zijn speciale voorwaarden die doorgaans verwijzen naar unieke omstandigheden, configuraties of vereisten waar cursisten rekening mee moeten houden voordat ze verdergaan met een zelfstudie of module. Deze voorwaarden kunnen specifieke softwareversies, hardwarevereisten of aanvullende hulpprogramma's bevatten die nodig zijn voor een geslaagde voltooiing van de leerinhoud.
Online migratie
Onlinemigratie maakt gebruik van pgcopydb volgen en enkele van de logische decoderingsbeperkingen zijn van toepassing. Daarnaast is het raadzaam om een primaire sleutel te hebben in alle tabellen van een database die onlinemigratie ondergaan. Als de primaire sleutel afwezig is, kan de tekortkomingen ertoe leiden dat alleen invoegbewerkingen worden doorgevoerd tijdens de migratie, met uitzondering van updates of verwijderingen. Voeg een tijdelijke primaire sleutel toe aan de relevante tabellen voordat u doorgaat met de onlinemigratie.
Een alternatief is om de ALTER TABLE opdracht te gebruiken waarbij de actie REPLICA IDENTIY is met de FULL optie. Met FULL de optie worden de oude waarden van alle kolommen in de rij vastgelegd, zodat zelfs bij afwezigheid van een primaire sleutel alle CRUD-bewerkingen worden weergegeven op het doel tijdens de onlinemigratie. Als geen van deze opties werkt, voert u een offlinemigratie uit als alternatief.
Database met postgres_fdw-extensie
De postgres_fdw-module biedt de wrapper voor refererende gegevens postgres_fdw, die kan worden gebruikt voor toegang tot gegevens die zijn opgeslagen op externe PostgreSQL-servers. Als uw database deze extensie gebruikt, moeten de volgende stappen worden uitgevoerd om een geslaagde migratie te garanderen.
- Verwijder tijdelijk (ontkoppelen) Externe gegevens wrapper op het bronexemplaren.
- Voer gegevensmigratie van rust uit met behulp van de Migration Service.
- Herstel de rollen, gebruikers en koppelingen naar het doel na de migratie.
Database met postGIS-extensie
De Postgis-extensie heeft belangrijke wijzigingen/compacte problemen tussen verschillende versies. Als u migreert naar een flexibele server, moet de toepassing worden gecontroleerd op basis van de nieuwere postGIS-versie om ervoor te zorgen dat de toepassing niet wordt beïnvloed of dat de benodigde wijzigingen moeten worden aangebracht. De postGIS-nieuws - en releaseopmerkingen zijn een goed uitgangspunt om inzicht te krijgen in de belangrijke wijzigingen in verschillende versies.
Opschoning van databaseverbinding
Soms kan deze fout optreden bij het starten van een migratie:
CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.
In dit geval kunt u de migration user machtiging verlenen om alle actieve verbindingen met de database te sluiten of de verbindingen handmatig te sluiten voordat u de migratie opnieuw probeert uit te voeren.