Delen via


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. Zie Premigration-validaties voor meer informatie.

Configuratie van flexibele server van doel

Tijdens de eerste basiskopie van gegevens worden meerdere invoeginstructies uitgevoerd op het doel, waarmee write-ahead-logboeken (WAL's) 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 databases die moeten worden gemigreerd:

SELECT pg_size_pretty( pg_database_size('dbname') );

U wordt aangeraden voldoende opslagruimte toe te wijzen op de flexibele server, gelijk aan 1,25 keer of 25% meer opslagruimte dan wordt gebruikt per uitvoer van de voorgaande opdracht. U kunt ook Automatische groei van Opslag gebruiken.

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 exemplaar van Azure Database for PostgreSQL - Flexible Server is een uitstekende plek om te beginnen. Zie Compute- en opslagopties in Azure Database for PostgreSQL - Flexible Server voor meer informatie over elke serverconfiguratie.

Belangrijk

Zodra de flexibele server is gemaakt, moet u de password_encryption-serverparameter op uw flexibele server wijzigen van SCRAM-SHA-256 in MD5 voordat u de migratie initiëren. Dit is essentieel voor de bestaande referenties op één server om te werken op uw flexibele server

Tijdlijn voor migratie

Elke migratie heeft een maximale levensduur van zeven dagen (168 uur) nadat deze is gestart en er treedt een time-out op na zeven dagen. U kunt de migratie- en toepassingsknipsel voltooien nadat de gegevensvalidatie is voltooid en alle controles zijn voltooid om te voorkomen dat er een time-out optreedt voor de migratie. Na het voltooien 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 het verkeer tijdens de migratie laag.

De meeste niet-productieservers (dev, UAT, test en fasering) worden gemigreerd met behulp van offlinemigraties. Omdat deze servers minder gegevens hebben dan de productieservers, is de migratie snel. 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. Met zoveel factoren die van invloed kunnen zijn op de migratietijd, is het moeilijk om de totale tijd te schatten voor een migratie die moet worden voltooid. De beste methode is om een testmigratie uit te voeren 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 (PITR) van uw productieserver uit te voeren en de offlinemigratie uit te voeren op deze zojuist herstelde server.

  • Migratie van buffer: Nadat u de vorige stap hebt voltooid, kunt u de werkelijke productiemigratie plannen 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 moet de grootteverhoging niet significant genoeg zijn.

  • Gegevensvalidatie: nadat de migratie voor de productieserver is voltooid, moet u controleren of de gegevens op de flexibele server een exacte kopie van het bronexemplaar zijn. U kunt opensource- of hulpprogramma's van derden gebruiken of u kunt de validatie handmatig uitvoeren. Bereid de validatiestappen voor die u wilt uitvoeren vóór de daadwerkelijke migratie. 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 en indexen).

    • Vergelijking van maximum- of minimum-id's van sleuteltoepassingsgerelateerde kolommen.

      Notitie

      De vergelijkende grootte van databases is niet de juiste meetwaarde voor validatie. Het bronexemplaren kan bloats of dode tuples hebben, waardoor de grootte van het bronexemplaren kan worden vergroot. Het is normaal dat er grootteverschillen zijn tussen bronexemplaren en doelservers. Een probleem in de voorgaande drie stappen van de validatie duidt op een probleem 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 onvoorziene gebeurtenissen te plannen 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).

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

De voorgaande 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

Hoewel de Burstable-SKU geen beperking is, is het raadzaam om een hogere SKU te kiezen voor uw flexibele server om snellere migraties uit te voeren. Azure Database for PostgreSQL - Flexible Server ondersteunt bijna nul downtime en 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

We raden een krachtige SKU aan voor het doel omdat de PostgreSQL-migratieservice geen container meer 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 als de gegevensdistributie tussen de tabellen evenwichtiger moet zijn of als 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, waardoor een knelpunt ontstaat. Splits dus grote tabellen in kleinere segmenten, die vervolgens parallel worden gemigreerd. Deze functie is van toepassing op tabellen die groter zijn dan 20 GB. 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 smallint, integer of big int.

    Notitie

    In het geval van de eerste of tweede benadering moet u 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, moet u doorgaan met de wijzigingen.

  • Als de tabel geen eenvoudige primaire sleutel of unieke index van het type smallintinteger heeft of big int een kolom heeft die voldoet aan de criteria van het gegevenstype, kan de kolom worden geconverteerd naar een unieke index met behulp van de volgende 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 , of integer big int primaire sleutel of unieke index of een kolom bevat smallintdie voldoet aan de criteria voor het gegevenstype, kunt u een dergelijke kolom toevoegen met BEHULP van ALTER en deze na de migratie verwijderen. Voor het uitvoeren van de ALTER opdracht is een vergrendeling voor de tabel vereist.

        alter table <table name> add column <column name> big serial unique;
    

Als aan een van de voorgaande voorwaarden wordt voldaan, wordt de tabel gemigreerd in meerdere partities parallel, wat een toename van de migratiesnelheid zou moeten opleveren.

Hoe het werkt

  • De migratieservice zoekt de grootte van een tabel op om te controleren of deze groter is dan 20 GB.
  • Als de grootte groter is dan 20 GB en er een smallint, integer of big int primaire sleutel of unieke index is, 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 bevat een kolom met een eenvoudige primaire sleutel of een unieke index van het type smallint, integer of big int.
  • De tabelgrootte is groter dan 20 GB.
  • 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 om efficiënt gebruik van opslag te garanderen. Het helpt ook om snellere migratie te garanderen, omdat de migratietijd een functie is van de databasegrootte.

PostgreSQL biedt de opdracht voor het VACUUM vrijmaken van opslag die wordt bezet door dode rijen. De ANALYZE optie verzamelt ook statistieken om queryplanning verder te optimaliseren. Voor tabellen met zware schrijfactiviteit kan het VACUUM proces agressiever zijn door gebruik te maken VACUUM FULLvan, maar het vereist meer tijd om uit te voeren.

  • Standaard vacuüm

    VACUUM your_table;
    
  • Vacuüm met analyse

    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 ruimte efficiënt vrij te maken, 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.

  • Grote objecten vacuümen

    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 u rekening mee moet houden voordat u verdergaat met een zelfstudie of module. Deze voorwaarden kunnen specifieke softwareversies, hardwarevereisten of andere hulpprogramma's bevatten die nodig zijn voor een geslaagde voltooiing van de leerinhoud.

Online migratie

Onlinemigratie maakt gebruik van pgcopydb volgen en sommige van de logische decoderingsbeperkingen zijn van toepassing. U wordt ook aangeraden een primaire sleutel te hebben in alle tabellen van een database die onlinemigratie ondergaat. Als een primaire sleutel afwezig is, resulteert de tekortkomingen in alleen insert bewerkingen die tijdens de migratie worden doorgevoerd, met uitzondering van updates of verwijderingen. Voeg een tijdelijke primaire sleutel toe aan de relevante tabellen voordat u verdergaat met de onlinemigratie.

Notitie

In het geval van onlinemigratie van tabellen zonder primaire sleutel worden alleen insert bewerkingen op het doel afgespeeld. Dit kan leiden tot inconsistentie in de database als records die op de bron zijn bijgewerkt of verwijderd, niet op het doel worden weergegeven.

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 postgres_fdw voor refererende gegevens, 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.

  1. Verwijder de refererende gegevenswikkelaar tijdelijk (ontkoppelen) op het bronexemplaren.
  2. Voer gegevensmigratie van de rest uit met behulp van de migratieservice.
  3. 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 treedt deze fout op wanneer u een migratie start:

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 scenario 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 uitvoert.