Dela via

Självstudie: Migrera online från Amazon RDS for PostgreSQL till Azure Database for PostgreSQL med förhandsversionen av migreringstjänsten

  • Artikel

Den här artikeln beskriver hur du migrerar din PostgreSQL-databas från Amazon RDS for PostgreSQL till Azure Database for PostgreSQL online.

Migreringstjänsten i Azure Database for PostgreSQL är en fullständigt hanterad tjänst som är integrerad i Azure Portal och Azure CLI. Den är utformad för att förenkla migreringsresan till Azure Database for PostgreSQL-servern.

  • Förutsättningar
  • Utföra migreringen
  • Övervaka migreringen
  • Snabb
  • Kontrollera migreringen när den är klar

Förutsättningar

För att slutföra migreringen behöver du följande krav:

Innan du påbörjar migreringen med Azure Database for PostgreSQL-migreringstjänsten är det viktigt att uppfylla följande krav, särskilt utformade för onlinemigreringsscenarier.

Verifiera källversionen

PostgreSQL-källserverversionen måste vara 9.5 eller senare.

Om postgreSQL-källversionen är mindre än 9,5 uppgraderar du den till 9,5 eller senare innan du påbörjar migreringen.

Installera test_decoding – Källkonfiguration

  • test_decoding tar emot WAL via den logiska avkodningsmekanismen och avkodar den till textrepresentationer av de åtgärder som utförs.
  • I Amazon RDS för PostgreSQL är plugin-programmet test_decoding förinstallerat och redo för logisk replikering. På så sätt kan du enkelt konfigurera logiska replikeringsfack och strömma WAL-ändringar, vilket underlättar användningsfall som cdc (change data capture) eller replikering till externa system.
  • Mer information om plugin-programmet för test avkodning finns i PostgreSQL-dokumentationen

Konfigurera målkonfiguration

  • Innan du migrerar måste Azure Database for PostgreSQL – flexibel server skapas.
  • SKU som etablerats för Azure Database for PostgreSQL – flexibel server ska matcha med källan.
  • Om du vill skapa en ny Azure Database for PostgreSQL går du till Skapa en Azure Database for PostgreSQL

Aktivera CDC som källa

  • test_decoding plugin-programmet för logisk avkodning samlar in ändrade poster från källan.
  • Kör följande kommando för att tillåta migreringsanvändaren att komma åt replikeringsprivilegier:
GRANT rds_replication TO <<username>>;

  • I källan PostgreSQL-instansen ändrar du följande parametrar genom att skapa en ny parametergrupp:

    • Ställa rds.logical_replication = 1
    • Ange max_replication_slots till ett värde som är större än ett. Värdet ska vara större än det antal databaser som valts för migrering.
    • Ange max_wal_senders till ett värde som är större än ett. Det bör vara minst samma som , plus antalet avsändare som max_replication_slotsredan används på din instans.
    • Parametern wal_sender_timeout avslutar inaktiva replikeringsanslutningar längre än det angivna antalet millisekunder. Standardvärdet för en AWS RDS för PostgreSQL-instans är 30000 milliseconds (30 seconds). Om värdet anges till 0 (noll) inaktiveras tidsgränsmekanismen och är en giltig inställning för migrering.

  • För att förhindra att onlinemigreringen tar slut för lagring för att lagra loggarna i målet Flexibel server, kontrollerar du att du har tillräckligt med utrymme för tablespace med hjälp av en etablerad hanterad disk. För att uppnå detta inaktiverar du serverparametern azure.enable_temp_tablespaces_on_local_ssd under migreringens varaktighet och återställer den till det ursprungliga tillståndet efter migreringen.

Konfigurera nätverkskonfiguration

Nätverkskonfigurationen är avgörande för att migreringstjänsten ska fungera korrekt. Se till att PostgreSQL-källservern kan kommunicera med Azure Database for PostgreSQL-målservern. Följande nätverkskonfigurationer är viktiga för en lyckad migrering.

Information om nätverkskonfiguration finns i Nätverksguide för migreringstjänsten.

Aktivera tillägg

För att säkerställa en lyckad migrering med hjälp av migreringstjänsten i Azure Database for PostgreSQL kan du behöva verifiera tillägg till postgreSQL-källinstansen. Tillägg innehåller funktioner och funktioner som kan krävas för ditt program. Kontrollera att du verifierar tilläggen på PostgreSQL-källinstansen innan du påbörjar migreringsprocessen.

I målinstansen av Azure Database for PostgreSQL – flexibel server aktiverar du tillägg som stöds som identifieras i postgreSQL-källinstansen.

Mer information finns i Tillägg i Azure Database for PostgreSQL.

Kommentar

En omstart krävs när du gör ändringar i parametern shared_preload_libraries .

Kontrollera serverparametrar

Dessa parametrar migreras inte automatiskt till målmiljön och måste konfigureras manuellt.

  • Matcha serverparametervärden från PostgreSQL-källdatabasen till Azure Database for PostgreSQL genom att komma åt avsnittet "Serverparametrar" i Azure Portal och uppdatera värdena manuellt.

  • Spara parameterändringarna och starta om Azure Database for PostgreSQL för att tillämpa den nya konfigurationen om det behövs.

Kontrollera användare och roller

När du migrerar till Azure Database for PostgreSQL är det viktigt att hantera migreringen av användare och roller separat, eftersom de kräver manuella åtgärder:

  • Manuell migrering av användare och roller: Användare och deras associerade roller måste migreras manuellt till Azure Database for PostgreSQL. För att underlätta den här processen kan du använda pg_dumpall verktyget med --globals-only flaggan för att exportera globala objekt som roller och användarkonton. Kör följande kommando och ersätt <<username>> med det faktiska användarnamnet och <<filename>> med önskat filnamn för utdata:

    pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql

  • Begränsning av superanvändarroller: Azure Database for PostgreSQL stöder inte superanvändarroller. Därför måste användare med superanvändarbehörighet få dessa privilegier borttagna före migreringen. Se till att du justerar behörigheterna och rollerna i enlighet med detta.

Genom att följa dessa steg kan du se till att användarkonton och roller migreras korrekt till Azure Database for PostgreSQL utan att stöta på problem som rör begränsningar för superanvändare.

Inaktivera hög tillgänglighet (tillförlitlighet) och läsrepliker i målet

  • Det är viktigt att inaktivera hög tillgänglighet (tillförlitlighet) och läsa repliker i målmiljön. Dessa funktioner bör aktiveras först när migreringen har slutförts.

  • Genom att följa dessa riktlinjer kan du säkerställa en smidig migreringsprocess utan de tillagda variablerna som introduceras av HA och Read Replicas. När migreringen är klar och databasen är stabil kan du fortsätta med att aktivera dessa funktioner för att förbättra tillgängligheten och skalbarheten för databasmiljön i Azure.

Utföra migreringen

Du kan migrera med hjälp av Azure Portal eller Azure CLI.

Azure Portal ger en enkel och intuitiv guidebaserad upplevelse som vägleder dig genom migrering. Genom att följa de steg som beskrivs i den här självstudien kan du sömlöst överföra databasen till Azure Database for PostgreSQL – flexibel server och dra nytta av dess kraftfulla funktioner och skalbarhet.

Om du vill migrera med Azure Portal konfigurerar du först migreringsuppgiften, ansluter till källan och målet och utför sedan migreringen.

Konfigurera migreringsuppgiften

Migreringstjänsten har en enkel, guidebaserad upplevelse av Azure Portal. Så här börjar du:

  1. Öppna webbläsaren och gå till portalen. Ange dina autentiseringsuppgifter för att logga in. Standardvyn är instrumentpanelen.

  2. Gå till ditt Azure Database for PostgreSQL–mål för flexibel server.

  3. På fliken Översikt för flexibel server på den vänstra menyn rullar du ned till Migrering och väljer den.

    Skärmbild av migreringsvalet.

  4. Välj knappen Skapa för att migrera från Amazon RDS for PostgreSQL till Azure Database for PostgreSQL – flexibel server. Om det här är första gången du använder migreringstjänsten visas ett tomt rutnät med en uppmaning om att påbörja din första migrering.

    Skärmbild av hur du skapar en migrering.

    Om du redan har skapat migreringar till ditt Azure Database for PostgreSQL-mål innehåller rutnätet information om migreringsförsök.

  5. Markera knappen Skapa. Sedan går du igenom en guidebaserad serie flikar för att skapa en migrering till det här Azure Database for PostgreSQL-målet från PostgreSQL-källinstansen.

Ställ in

Den första fliken är fliken Installation , där användaren måste ange migreringsinformation som källtyp för migreringsnamn för att initiera migreringarna.

Skärmbild av installationsmigreringen i Azure Portal.

  • Migreringsnamnet är den unika identifieraren för varje migrering till det här målet för flexibel server. Det här fältet accepterar endast alfanumeriska tecken och accepterar inte några specialtecken förutom ett bindestreck (-). Namnet kan inte börja med ett bindestreck och bör vara unikt för en målserver. Inga två migreringar till samma mål för flexibel server kan ha samma namn.

  • Källservertyp – Beroende på din PostgreSQL-källa kan du välja motsvarande källtyp, till exempel en molnbaserad PostgreSQL-tjänst, en lokal installation eller en virtuell dator.

  • Med migreringsalternativet kan du utföra valideringar innan du utlöser en migrering. Du kan välja något av följande alternativ:

    • Verifiera – Kontrollerar serverns och databasens beredskap för migrering till målet.
    • Migrera – Hoppar över valideringar och startar migreringar.
    • Verifiera och migrera – Utför validering innan en migrering utlöses. Migreringen utlöses endast om det inte finns några verifieringsfel.

Det är alltid bra att välja alternativet Verifiera eller verifiera och migrera när du utför valideringar före migreringen innan du kör migreringen. Mer information om valideringen före utvandring finns i den här dokumentationen.

  • Med migreringsläget kan du välja läget för migreringen. Offline är standardalternativet.

Välj knappen Nästa: Anslut till källan.

Välj Runtime Server

Runtime Server för migrering är en specialiserad funktion inom migreringstjänsten som är utformad för att fungera som mellanliggande server under migreringen. Det är en separat Azure Database for PostgreSQL – flexibel serverinstans som inte är målservern, men som används för att underlätta migreringen av databaser från en källmiljö som endast är tillgänglig via ett privat nätverk.

Mer information om Runtime Server finns på Migreringskörningsservern.

Skärmbild av sidan Migreringskörningsserver.

Ansluta till källan

På fliken Anslut till källa uppmanas du att ange information om den källa som valts på fliken Installation, som är källan till databaserna.

Skärmbild av Connectsourcemigration.

  • Servernamn – Ange värdnamnet eller IP-adressen för postgreSQL-källinstansen
  • Port – Portnummer för källservern
  • Inloggningsnamn för serveradministratör – Användarnamn för postgreSQL-källservern
  • Lösenord – Lösenord för PostgreSQL-källservern
  • SSL-läge – De värden som stöds föredras och krävs. När SSL på PostgreSQL-källservern är AV använder du SSLMODE=prefer. Om SSL på källservern är PÅ använder du SSLMODE=require. SSL-värden kan fastställas i postgresql.conf-filen.
  • Testanslutning – Utför anslutningstestet mellan målet och källan. När anslutningen har slutförts kan användarna fortsätta med nästa steg. Annars måste vi identifiera nätverksproblemen mellan målet och källan och verifiera användarnamnet/lösenordet för källan. Det tar några minuter att upprätta en testanslutning.

Efter den lyckade testanslutningen väljer du Nästa: Välj migreringsmål

Välj migreringsmål

Fliken Välj migreringsmål visar metadata för målet flexibel server, till exempel prenumerationsnamn, resursgrupp, servernamn, plats och PostgreSQL-version.

Skärmbild av skärmen för att ansluta målmigrering.

  • Administratörsanvändarnamn – Administratörsanvändarnamn för PostgreSQL-målservern
  • Lösenord – Lösenord för postgreSQL-målservern
  • Anpassat FQDN/IP (valfritt): Det anpassade FQDN/IP-fältet är valfritt och kan användas när målet ligger bakom en anpassad DNS-server eller har anpassade DNS-namnområden, vilket gör det endast tillgängligt via specifika FQDN eller IP-adresser. Detta kan till exempel innehålla poster som flexibleserver.example.com, 198.1.0.2eller ett PostgreSQL FQDN, flexibleserver.postgres.database.azure.comtill exempel , om den anpassade DNS-servern innehåller DNS-zonen postgres.database.azure.com eller vidarebefordrar frågor för den här zonen till 168.63.129.16, där FQDN löses i den offentliga eller privata DNS-zonen i Azure.
  • Testanslutning – Utför anslutningstestet mellan målet och källan. När anslutningen har slutförts kan användarna fortsätta med nästa steg. Annars måste vi identifiera nätverksproblemen mellan målet och källan och verifiera användarnamnet/lösenordet för målet. Testanslutningen tar några minuter att upprätta en anslutning mellan målet och källan.

Efter den lyckade testanslutningen väljer du Nästa: Välj databaser för migrering

Välj databaser för migrering

Under den här fliken finns en lista över användardatabaser i källservern som valts på fliken Installation. Du kan välja och migrera upp till åtta databaser i ett enda migreringsförsök. Om det finns fler än åtta användardatabaser upprepas migreringsprocessen mellan käll- och målservrarna för nästa uppsättning databaser.

Skärmbild av FetchDBmigration.

När du har valt databaserna väljer du Nästa: Sammanfattning

Sammanfattning

Fliken Sammanfattning sammanfattar all käll- och målinformation för att skapa verifieringen eller migreringen. Granska informationen och välj startknappen.

Skärmbild av sammanfattningsmigrering.

Övervaka migreringen

När du har valt startknappen visas ett meddelande om att verifieringen eller migreringen lyckas om några sekunder. Sedan omdirigeras du automatiskt till migreringssidan för flexibel server, som har en ny post för den nyligen skapade verifieringen eller migreringen.

Skärmbild av Övervaka migrering.

Rutnätet som visar migreringarna har följande kolumner: Namn, Status, Migreringsläge, Migreringstyp, Källservertyp, Databas, Varaktighet och Starttid. Posterna visas i fallande ordning på starttiden, med den senaste posten högst upp. Du kan använda uppdateringsknappen för att uppdatera statusen för valideringen eller migreringen. Välj migreringsnamnet i rutnätet för att se den associerade informationen.

När valideringen eller migreringen skapas flyttas den till inprogresstillståndet och PerformingPreRequisiteSteps-substratet. Arbetsflödet tar 2–3 minuter att konfigurera migreringsinfrastrukturen och nätverksanslutningarna.

Information om migrering

På fliken Installation har vi valt migreringsalternativet Som Migrera och Verifiera. I det här scenariot utförs valideringar först innan migreringen startar. När undertillståndet PerformingPreRequisiteSteps har slutförts flyttas arbetsflödet till undertillståndet validering pågår.

  • Om verifieringen har fel flyttas migreringen till ett feltillstånd .
  • Om verifieringen slutförs utan fel startar migreringen och arbetsflödet flyttas till undertillståndet Migrera data.

Du kan se resultatet av validering och migrering på instans- och databasnivå.

Skärmbild av informationsmigrering.

Några möjliga migreringstillstånd:

Migreringstillstånd

Stat/län beskrivning
InProgress Installationen av migreringsinfrastrukturen pågår eller så pågår den faktiska datamigreringen.
Avbruten Migreringen avbryts eller tas bort.
Misslyckades Migreringen misslyckades.
Verifieringen misslyckades Verifieringen misslyckades.
Lyckades Migreringen har slutförts.
WaitingForUserAction Gäller endast för onlinemigrering. Väntar på att användaråtgärden ska utföra snabb användning.

Undertillstånd för migrering

Undertillstånd beskrivning
PerformingPreRequisiteSteps Infrastrukturkonfiguration pågår för datamigrering.
Validering pågår Verifiering pågår.
MigreraData Datamigrering pågår.
Slutföra migrering Migreringen är i slutfasen av slutförandet.
Slutförd Migreringen har slutförts.
Misslyckades Migreringen misslyckades.

Undertillstånd för validering

Undertillstånd beskrivning
Misslyckades Verifieringen misslyckades.
Lyckades Valideringen har slutförts.
Varning! Verifieringen är i varningstext.

Snabb

Om det finns både Migrate och Validate och Migrate kräver slutförandet av onlinemigreringen ytterligare ett steg – användaren måste vidta en snabb åtgärd. När kopieringen/klonen av basdata har slutförts flyttas migreringen till WaitingForUserAction tillståndet och undertillståndet WaitingForCutoverTrigger . I det här tillståndet kan användaren utlösa snabbkopplingen från portalen genom att välja migreringen.

Innan du påbörjar cutover är det viktigt att se till att:

  • Skrivningar till källan stoppas – Latency värdet är 0 eller nära 0. Informationen Latency kan hämtas från skärmen för migreringsinformation enligt nedan:

    Skärmbild av snabbmigrering.

  • latency värdet minskar till 0 eller nära 0

  • Värdet latency anger när målet senast synkroniserades med källan. Nu kan du stoppa skrivning till källan och snabbinitiering kan initieras. Om det finns tung trafik vid källan rekommenderar vi att du stoppar skrivningar först så att du Latency kan komma nära 0 och sedan initieras en snabb användning. Snabbåtgärden tillämpar alla väntande ändringar från källan till målet och slutför migreringen. Om du utlöser en "cutover" även med nonzero Latency, stoppas replikeringen till den tidpunkten. Alla data finns på källan tills brytpunkten tillämpas på målet. Anta att svarstiden var 15 minuter vid snabbpunkten, så alla ändrade data under de senaste 15 minuterna tillämpas på målet. Tiden beror på kvarvarande ändringar som inträffar under de senaste 15 minuterna. Därför rekommenderar vi att svarstiden går till noll eller nära noll innan du utlöser snabbheten.

    Skärmbild av Confirmcutovermigration.

  • Migreringen flyttas till tillståndet Succeeded när undertillståndet Migrating Data eller snabbmigreringen (i Onlinemigrering) har slutförts. Om det uppstår ett problem i undertillståndet Migrating Data flyttas migreringen till ett Failed tillstånd.

    Skärmbild av lyckad migrering.

Kontrollera migreringen när den är klar

När du har slutfört databaserna måste du manuellt verifiera data mellan källan och målet och kontrollera att alla objekt i måldatabasen har skapats.

Efter migreringen kan du utföra följande uppgifter:

  • Verifiera data på den flexibla servern och se till att det är en exakt kopia av källinstansen.
  • Efter verifiering aktiverar du alternativet för hög tillgänglighet på den flexibla servern efter behov.
  • Ändra SKU:n för den flexibla servern så att den matchar programbehoven. Den här ändringen kräver en omstart av databasservern.
  • Om du ändrar några serverparametrar från deras standardvärden i källinstansen kopierar du dessa serverparametervärden på den flexibla servern.
  • Kopiera andra serverinställningar, till exempel taggar, aviseringar och brandväggsregler (om tillämpligt), från källinstansen till den flexibla servern.
  • Gör ändringar i ditt program för att peka anslutningssträng till en flexibel server.
  • Övervaka databasens prestanda noggrant för att se om det kräver prestandajustering.

Relaterat innehåll