Dela via

Metodtips för sömlös migrering till Azure Database for PostgreSQL

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

I den här artikeln beskrivs vanliga fallgropar och metodtips för att säkerställa en smidig och lyckad migrering till Azure Database for PostgreSQL.

Validering av förflyttning

Som ett första steg i migreringen kör du valideringen före migreringen innan du utför en migrering. Du kan använda alternativen Verifiera och verifiera och migrera på sidan För migreringskonfiguration. Förmigrationsverifiering utför noggranna kontroller mot en fördefinierad regeluppsättning. Målet är att identifiera potentiella problem och tillhandahålla användbara insikter för åtgärdsåtgärder. Fortsätt att köra validering före utvandring tills det resulterar i tillståndet Lyckades . Mer information finns i Validering av förflyttning.

Målkonfiguration för flexibel server

Under den första baskopian av data körs flera infogningssatser på målet, vilket genererar loggningsloggar (WALs). Tills dessa WAL:er arkiveras förbrukar loggarna lagring vid målet och den lagring som krävs av databasen.

Om du vill beräkna talet loggar du in på källinstansen och kör det här kommandot för att alla databaser ska migreras:

SELECT pg_size_pretty( pg_database_size('dbname') );

Vi rekommenderar att du allokerar tillräckligt med lagringsutrymme på den flexibla servern, vilket motsvarar 1,25 gånger eller 25 % mer lagringsutrymme än vad som används per utdata till föregående kommando. Du kan också använda Storage Autogrow.

Viktigt!

Lagringsstorleken kan inte minskas i manuell konfiguration eller automatiskt lagringsutrymme. Varje steg i lagringskonfigurationsspektrumet fördubblas i storlek, så det är klokt att beräkna den nödvändiga lagringen i förväg.

Snabbstarten för att skapa en Azure Database for PostgreSQL – flexibel serverinstans med hjälp av portalen är en utmärkt plats att börja på. Mer information om varje serverkonfiguration finns i Beräknings- och lagringsalternativ i Azure Database for PostgreSQL – flexibel server.

Tidslinje för migrering

Varje migrering har en maximal livslängd på sju dagar (168 timmar) efter att den startar, och tidsgränsen uppnås efter sju dagar. Du kan slutföra migreringen och programskärningen efter dataverifieringen och alla kontroller är slutförda för att undvika att migreringen överskrider tidsgränsen. När den första baskopian har slutförts i onlinemigreringar varar snabbfönstret tre dagar (72 timmar) innan tidsgränsen nås. Vid offlinemigreringar bör programmen sluta skriva till databasen för att förhindra dataförlust. För onlinemigrering bör du också hålla trafiken låg under hela migreringen.

De flesta icke-produktionsservrar (dev, UAT, test och mellanlagring) migreras med hjälp av offlinemigreringar. Eftersom dessa servrar har mindre data än produktionsservrarna är migreringen snabb. För migrering av produktionsserver måste du veta vilken tid det tar att slutföra migreringen för att planera för den i förväg.

Den tid det tar för migreringen att slutföras beror på flera faktorer. Den innehåller antalet databaser, storlek, antal tabeller i varje databas, antal index och datadistribution mellan tabeller. Det beror också på målserverns SKU och den IOPS som är tillgänglig på källinstansen och målservern. Med så många faktorer som kan påverka migreringstiden är det svårt att uppskatta den totala tiden för migreringen att slutföras. Det bästa sättet är att utföra en testmigrering med din arbetsbelastning.

Följande faser beaktas vid beräkning av den totala stilleståndstiden för att utföra migrering av produktionsservern:

  • Migrering av PITR: Det bästa sättet att få en bra uppskattning av hur lång tid det tar att migrera din produktionsdatabasserver är att ta en återställning till tidpunkt (PITR) för produktionsservern och köra offlinemigreringen på den nyligen återställda servern.

  • Migrering av buffert: När du har slutfört föregående steg kan du planera för faktisk produktionsmigrering under en tidsperiod när programtrafiken är låg. Den här migreringen kan planeras samma dag eller förmodligen en vecka bort. Vid den här tiden kan storleken på källservern ha ökat. Uppdatera din uppskattade migreringstid för produktionsservern baserat på den här ökningen. Om ökningen är betydande bör du överväga att göra ett nytt test med hjälp av PITR-servern. Men för de flesta servrar bör storleksökningen inte vara tillräckligt stor.

  • Dataverifiering: När migreringen är klar för produktionsservern måste du kontrollera om data på den flexibla servern är en exakt kopia av källinstansen. Du kan använda verktyg med öppen källkod eller tredje part eller så kan du göra valideringen manuellt. Förbered de valideringssteg som du vill utföra före den faktiska migreringen. Validering kan omfatta:

    • Radantalmatchning för alla tabeller som ingår i migreringen.

    • Matchande antal för alla databasobjekt (tabeller, sekvenser, tillägg, procedurer och index).

    • Jämföra maximalt eller minsta ID för viktiga programrelaterade kolumner.

      Kommentar

      Databasernas jämförande storlek är inte rätt mått för validering. Källinstansen kan ha uppblåsthet eller döda tupplar, vilket kan öka storleken på källinstansen. Det är normalt att ha storleksskillnader mellan källinstanser och målservrar. Ett problem i de föregående tre valideringsstegen indikerar ett problem med migreringen.

  • Migrering av serverinställningar: Alla anpassade serverparametrar, brandväggsregler (om tillämpligt), taggar och aviseringar måste kopieras manuellt från källinstansen till målet.

  • Ändra niska veze: Programmet bör ändra sina niska veze till en flexibel server efter valideringen. Den här aktiviteten samordnas med programteamet för att ändra alla referenser till niska veze som pekar på källinstansen. På den flexibla servern kan användarparametern användas i formatet user=username i niska veze.

Till exempel: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

Även om en migrering ofta körs utan problem är det bra att planera för oförutsedda händelser om det krävs mer tid för felsökning eller om en migrering behöver startas om.

Prestandamått för migreringshastighet

I följande tabell visas den tid det tar att utföra migreringar för databaser av olika storlekar med hjälp av migreringstjänsten. Migreringen utfördes med hjälp av en flexibel server med SKU-Standard_D4ds_v4 (4 kärnor, 16 GB minne, 128 GB disk och 500 IOPS).

Databasstorlek Ungefärlig tid (HH: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
1 000 GB 07:00

Föregående tal ger dig en uppskattning av den tid det tar att slutföra migreringen. Vi rekommenderar starkt att du kör en testmigrering med din arbetsbelastning för att få ett exakt värde för migrering av servern.

Viktigt!

Välj en högre SKU för din flexibla server för att utföra snabbare migreringar. Azure Database for PostgreSQL – Flexibel server stöder nästan noll nedtidsberäkning och IOPS-skalning, så att SKU:n kan uppdateras med minimal stilleståndstid. Du kan alltid ändra SKU:n så att den matchar programmets behov efter migreringen.

Förbättra migreringshastigheten: Parallell migrering av tabeller

Vi rekommenderar en kraftfull SKU för målet eftersom PostgreSQL-migreringstjänsten får slut på en container på den flexibla servern. Med en kraftfull SKU kan fler tabeller migreras parallellt. Du kan skala tillbaka SKU:n till önskad konfiguration efter migreringen. Det här avsnittet innehåller steg för att förbättra migreringshastigheten om datafördelningen mellan tabellerna behöver vara mer balanserad eller om en kraftfullare SKU inte påverkar migreringshastigheten avsevärt.

Om datafördelningen på källan är mycket skev, med de flesta data i en tabell, måste den allokerade beräkningen för migrering utnyttjas fullt ut, vilket skapar en flaskhals. Dela därför upp stora tabeller i mindre segment, som sedan migreras parallellt. Den här funktionen gäller för tabeller med fler än 1 000 000 tupplar (1 m). Det är möjligt att dela upp tabellen i mindre segment om något av följande villkor uppfylls:

  • Tabellen måste ha en kolumn med en enkel primärnyckel (inte sammansatt) eller ett unikt index av typen int eller significant int.

    Kommentar

    När det gäller den första eller andra metoden måste du noggrant utvärdera konsekvenserna av att lägga till en unik indexkolumn i källschemat. Först efter bekräftelsen att tillägg av en unik indexkolumn inte påverkar programmet om du fortsätter med ändringarna.

  • Om tabellen inte har en enkel primärnyckel eller ett unikt index av typen int , eller significant int om den har en kolumn som uppfyller datatypsvillkoren, kan kolumnen konverteras till ett unikt index med hjälp av följande kommando. Det här kommandot kräver inget lås i tabellen.

        create unique index concurrently partkey_idx on <table name> (column name);

  • Om tabellen inte har en primärnyckel eller ett simple int/big int unikt index eller en kolumn som uppfyller datatypsvillkoren kan du lägga till en sådan kolumn med hjälp av ALTER och släppa den efter migreringen. För att ALTER köra kommandot krävs ett lås på tabellen.

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

Om något av ovanstående villkor uppfylls migreras tabellen parallellt i flera partitioner, vilket bör ge en ökning av migreringshastigheten.

Hur det fungerar

  • Migreringstjänsten letar upp det maximala och minsta heltalsvärdet för tabellens primära nyckel/unika index som måste delas upp och migreras parallellt.
  • Om skillnaden mellan det lägsta och högsta värdet är mer än 1 000 000 (1 m), delas tabellen upp i flera delar och varje del migreras parallellt.

Sammanfattningsvis migrerar PostgreSQL-migreringstjänsten en tabell i parallella trådar och minskar migreringstiden om:

  • Tabellen har en kolumn med en enkel primärnyckel eller unikt index av typen int eller betydande int.
  • Tabellen har minst 1 000 000 (1 m) rader så att skillnaden mellan den primära nyckelns lägsta och högsta värde är mer än 1 000 000 (1 m).
  • Den SKU som används har inaktiva kärnor, som kan användas för att migrera tabellen parallellt.

Dammsugare i PostgreSQL-databasen

Med tiden, när data läggs till, uppdateras och tas bort, kan PostgreSQL ackumulera döda rader och bortkastat lagringsutrymme. Den här uppblåstheten kan leda till ökade lagringskrav och lägre frågeprestanda. Dammsugning är en viktig underhållsuppgift som hjälper dig att frigöra det här bortkastade utrymmet och ser till att databasen fungerar effektivt. Dammsugning löser problem som döda rader och uppsvälld tabell för att säkerställa effektiv användning av lagring. Det hjälper också till att säkerställa snabbare migrering eftersom migreringstiden är en funktion av databasstorleken.

PostgreSQL tillhandahåller VACUUM kommandot för att frigöra lagring som upptas av döda rader. Alternativet ANALYZE samlar också in statistik för att ytterligare optimera frågeplaneringen. För tabeller med tung skrivaktivitet VACUUM kan processen vara mer aggressiv med hjälp VACUUM FULLav , men det kräver mer tid att köra.

  • Standardvakuum

    VACUUM your_table;

  • Vakuum med analys

    VACUUM ANALYZE your_table;

  • Aggressivt vakuum för tunga skrivtabeller

    VACUUM FULL your_table;

I det här exemplet ersätter du your_table med det faktiska tabellnamnet. Kommandot VACUUM utan FULL frigör utrymme effektivt, medan VACUUM ANALYZE optimerar frågeplaneringen. Alternativet VACUUM FULL bör användas omdömesgillt på grund av dess tyngre prestandapåverkan.

Vissa databaser lagrar stora objekt, till exempel bilder eller dokument, som kan bidra till att databasen blir uppsvälld över tid. Kommandot VACUUMLO är utformat för stora objekt i PostgreSQL.

  • Dammsug stora objekt

    VACUUMLO;

Genom att regelbundet införliva dessa dammsugningsstrategier säkerställs en väl underhållen PostgreSQL-databas.

Särskilt övervägande

Det finns särskilda villkor som vanligtvis refererar till unika omständigheter, konfigurationer eller krav som du måste känna till innan du fortsätter med en självstudie eller modul. Dessa villkor kan omfatta specifika programvaruversioner, maskinvarukrav eller andra verktyg som är nödvändiga för att slutföra inlärningsinnehållet.

Onlinemigrering

Onlinemigrering använder pgcopydb follow och vissa av de logiska avkodningsbegränsningarna gäller. Vi rekommenderar också att du har en primärnyckel i alla tabeller i en databas som genomgår onlinemigrering. Om en primärnyckel saknas resulterar bristen endast insert i åtgärder som återspeglas under migreringen, exklusive uppdateringar eller borttagningar. Lägg till en tillfällig primärnyckel i de relevanta tabellerna innan du fortsätter med onlinemigreringen.

Kommentar

Vid onlinemigrering av tabeller utan primärnyckel spelas endast insert åtgärder upp på målet. Detta kan potentiellt medföra inkonsekvens i databasen om poster som uppdateras eller tas bort på källan inte reflekterar över målet.

Ett alternativ är att använda ALTER TABLE kommandot där åtgärden är REPLICA IDENTIY med alternativet FULL . Alternativet FULL registrerar de gamla värdena för alla kolumner på raden så att även om det inte finns någon primärnyckel återspeglas alla CRUD-åtgärder på målet under onlinemigreringen. Om inget av dessa alternativ fungerar utför du en offlinemigrering som ett alternativ.

Databas med postgres_fdw-tillägg

Modulen postgres_fdw innehåller den externa dataomslutningen postgres_fdw, som kan användas för att komma åt data som lagras på externa PostgreSQL-servrar. Om databasen använder det här tillägget måste följande steg utföras för att säkerställa en lyckad migrering.

  1. Ta tillfälligt bort (ta bort länk) den externa dataomslutningen på källinstansen.
  2. Utför datamigrering av resten med hjälp av migreringstjänsten.
  3. Återställ omslutningsrollerna, användaren och länkarna till målet efter migreringen.

Databas med postGIS-tillägg

PostGIS-tillägget har icke-bakåtkompatibla ändringar/kompakta problem mellan olika versioner. Om du migrerar till en flexibel server bör programmet kontrolleras mot den nyare postGIS-versionen för att säkerställa att programmet inte påverkas eller att nödvändiga ändringar måste göras. PostGIS-nyheterna och viktig information är en bra utgångspunkt för att förstå de icke-bakåtkompatibla ändringarna i olika versioner.

Rensning av databasanslutning

Ibland kan det här felet uppstå när du startar en migrering:

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.

I det här scenariot kan du ge migration user behörighet att stänga alla aktiva anslutningar till databasen eller stänga anslutningarna manuellt innan du försöker migrera igen.

Relaterat innehåll