Sdílet prostřednictvím


Kurz: Online migrace z Amazon RDS for PostgreSQL do Azure Database for PostgreSQL s využitím služby migration Service Preview

Tento článek popisuje, jak migrovat databázi PostgreSQL z Amazon RDS for PostgreSQL do Azure Database for PostgreSQL online.

Služba migrace ve službě Azure Database for PostgreSQL je plně spravovaná služba integrovaná do webu Azure Portal a Azure CLI. Je navržená tak, aby zjednodušila cestu migrace na server Azure Database for PostgreSQL.

  • Požadavky
  • Provedení migrace
  • Monitorování migrace
  • Přímá migrace
  • Kontrola migrace po dokončení

Požadavky

K dokončení migrace potřebujete následující požadavky:

Před zahájením migrace se službou Azure Database for PostgreSQL migration service je důležité splnit následující požadavky, které jsou speciálně navržené pro scénáře online migrace.

Ověření zdrojové verze

Zdrojová verze serveru PostgreSQL musí být 9.5 nebo novější.

Pokud je zdrojová verze PostgreSQL menší než 9.5, před zahájením migrace ji upgradujte na verzi 9.5 nebo vyšší.

Instalace test_decoding – Instalace zdroje

  • test_decoding obdrží WAL prostřednictvím logického dekódovacího mechanismu a dekóduje ho do textové reprezentace provedených operací.
  • V Amazon RDS for PostgreSQL je modul plug-in test_decoding předinstalovaný a připravený k logické replikaci. To vám umožní snadno nastavit sloty logické replikace a streamovat změny WAL, což usnadňuje případy použití, jako je zachytávání dat změn (CDC) nebo replikace do externích systémů.
  • Další informace o modulu plug-in pro dekódování testů najdete v dokumentaci k PostgreSQL.

Konfigurace nastavení cíle

  • Před migrací je potřeba vytvořit flexibilní server Azure Database for PostgreSQL.
  • Skladová položka zřízená pro flexibilní server Azure Database for PostgreSQL by se měla shodovat se zdrojem.
  • Pokud chcete vytvořit novou službu Azure Database for PostgreSQL, přejděte na stránku Vytvoření služby Azure Database for PostgreSQL.

Povolení CDC jako zdroje

  • test_decoding Modul plug-in logického dekódování zachycuje změněné záznamy ze zdroje.
  • Pokud chcete uživateli migrace povolit přístup k oprávněním replikace, spusťte následující příkaz:
GRANT rds_replication TO <<username>>;
  • Ve zdrojové instanci PostgreSQL upravte následující parametry vytvořením nové skupiny parametrů:

    • Nastavit rds.logical_replication = 1
    • Nastavte max_replication_slots hodnotu větší než jednu. Hodnota by měla být větší než počet databází vybraných pro migraci.
    • Nastavte max_wal_senders hodnotu větší než jednu. Měl by být alespoň stejný jako max_replication_slotspočet odesílatelů, kteří už ve vaší instanci použili.
    • Parametr wal_sender_timeout končí neaktivní připojení replikace delší než zadaný počet milisekund. Výchozí hodnota instance AWS RDS pro PostgreSQL je 30000 milliseconds (30 seconds). Nastavení hodnoty 0 (nula) zakáže mechanismus časového limitu a je platným nastavením pro migraci.
  • Pokud chcete na cílovém flexibilním serveru zabránit tomu, aby online migrace docházet z úložiště, aby se protokoly ukládaly, ujistěte se, že máte dostatek místa v tabulkovém prostoru pomocí zřízeného spravovaného disku. Pokud toho chcete dosáhnout, zakažte parametr azure.enable_temp_tablespaces_on_local_ssd serveru po dobu trvání migrace a po migraci ho obnovte do původního stavu.

Konfigurace nastavení sítě

Nastavení sítě je zásadní pro správné fungování služby migrace. Ujistěte se, že zdrojový server PostgreSQL může komunikovat s cílovým serverem Azure Database for PostgreSQL. Následující konfigurace sítě jsou nezbytné pro úspěšnou migraci.

Informace o nastavení sítě najdete v průvodci sítí pro službu migrace.

Povolení rozšíření

Pokud chcete zajistit úspěšnou migraci pomocí služby migrace ve službě Azure Database for PostgreSQL, možná budete muset ověřit rozšíření vaší zdrojové instance PostgreSQL. Rozšíření poskytují funkce a funkce, které můžou být potřeba pro vaši aplikaci. Před zahájením procesu migrace ověřte rozšíření ve zdrojové instanci PostgreSQL.

V cílové instanci flexibilního serveru Azure Database for PostgreSQL povolte podporovaná rozšíření, která jsou identifikována ve zdrojové instanci PostgreSQL.

Další informace najdete v tématu Rozšíření ve službě Azure Database for PostgreSQL.

Poznámka:

Restartování se vyžaduje, když provedete jakékoli změny parametru shared_preload_libraries .

Kontrola parametrů serveru

Tyto parametry se do cílového prostředí nemigrují automaticky a musí být nakonfigurované ručně.

  • Porovná hodnoty parametrů serveru ze zdrojové databáze PostgreSQL se službou Azure Database for PostgreSQL tak, že na webu Azure Portal přistupujete k části Parametry serveru a odpovídajícím způsobem hodnoty aktualizujete ručně.

  • Uložte změny parametrů a restartujte Azure Database for PostgreSQL, aby se v případě potřeby použila nová konfigurace.

Kontrola uživatelů a rolí

Při migraci na Azure Database for PostgreSQL je důležité řešit migraci uživatelů a rolí samostatně, protože vyžadují ruční zásah:

  • Ruční migrace uživatelů a rolí: Uživatelé a jejich přidružené role se musí ručně migrovat do služby Azure Database for PostgreSQL. K usnadnění tohoto procesu můžete použít pg_dumpall nástroj s příznakem --globals-only k exportu globálních objektů, jako jsou role a uživatelské účty. Spusťte následující příkaz a nahraďte <<username>> skutečné uživatelské jméno a <<filename>> požadovaný název výstupního souboru:

    pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
    
  • Omezení rolí superuživatele: Azure Database for PostgreSQL nepodporuje role superuživatele. Uživatelé s oprávněními superuživatele proto musí mít tato oprávnění před migrací odebraná. Ujistěte se, že odpovídajícím způsobem upravíte oprávnění a role.

Pomocí těchto kroků můžete zajistit, aby se uživatelské účty a role správně migrovaly do služby Azure Database for PostgreSQL bez problémů souvisejících s omezeními superuživatele.

Zakázání vysoké dostupnosti (spolehlivosti) a replik pro čtení v cíli

  • Zakázání vysoké dostupnosti (spolehlivosti) a replik pro čtení v cílovém prostředí je nezbytné. Tyto funkce by se měly povolit až po dokončení migrace.

  • Pokud budete postupovat podle těchto pokynů, můžete zajistit hladký proces migrace bez přidaných proměnných zavedených vysokou dostupností a replikami pro čtení. Po dokončení migrace a stabilní databázi můžete tyto funkce povolit, abyste zlepšili dostupnost a škálovatelnost vašeho databázového prostředí v Azure.

Provedení migrace

Migraci můžete provést pomocí webu Azure Portal nebo Azure CLI.

Azure Portal poskytuje jednoduché a intuitivní prostředí na základě průvodce, které vás provede migrací. Podle kroků popsaných v tomto kurzu můžete bez problémů přenést databázi na flexibilní server Azure Database for PostgreSQL a využít výhod jeho výkonných funkcí a škálovatelnosti.

Pokud chcete migrovat pomocí webu Azure Portal, nejprve nakonfigurujete úlohu migrace, připojíte se ke zdroji a cíli a pak provedete migraci.

Konfigurace úlohy migrace

Služba migrace se dodává s jednoduchým prostředím založeným na průvodci na webu Azure Portal. Tady je postup, jak začít:

  1. Otevřete webový prohlížeč a přejděte na portál. Zadejte svoje přihlašovací údaje pro přihlášení. Výchozím zobrazením je váš řídicí panel služby.

  2. Přejděte do cíle flexibilního serveru Azure Database for PostgreSQL.

  3. Na kartě Přehled flexibilního serveru se v nabídce vlevo posuňte dolů k části Migrace a vyberte ji.

    Snímek obrazovky s výběrem možnosti Migrace

  4. Výběrem tlačítka Vytvořit migrujte z Amazon RDS for PostgreSQL na flexibilní server Azure Database for PostgreSQL. Pokud používáte službu migration service poprvé, zobrazí se prázdná mřížka s výzvou k zahájení první migrace.

    Snímek obrazovky s vytvořením migrace

    Pokud jste už vytvořili migrace do cíle Azure Database for PostgreSQL, obsahuje mřížka informace o pokusech o migraci.

  5. Vyberte tlačítko Vytvořit. Pak si projdete řadu karet založených na průvodci a vytvoříte migraci do tohoto cíle Azure Database for PostgreSQL ze zdrojové instance PostgreSQL.

Nastavení

První kartou je karta Nastavení , kde uživatel musí zadat podrobnosti o migraci, jako je typ zdroje názvu migrace, aby mohli zahájit migrace.

Snímek obrazovky s migrací nastavení na webu Azure Portal

  • Název migrace je jedinečný identifikátor pro každou migraci do tohoto cíle flexibilního serveru. Toto pole přijímá pouze alfanumerické znaky a nepřijímá žádné speciální znaky s výjimkou spojovníku (-). Název nemůže začínat pomlčkou a měl by být jedinečný pro cílový server. Žádné dvě migrace do stejného cíle flexibilního serveru můžou mít stejný název.

  • Typ zdrojového serveru – V závislosti na zdroji PostgreSQL můžete vybrat odpovídající typ zdroje, například cloudovou službu PostgreSQL, místní nastavení nebo virtuální počítač.

  • Možnost migrace umožňuje provádět ověření před aktivací migrace. Můžete vybrat některou z následujících možností:

    • Ověření – Zkontroluje připravenost serveru a databáze na migraci do cíle.
    • Migrace – Přeskočí ověření a spustí migraci.
    • Ověření a migrace – Provádí ověření před aktivací migrace. Migrace se aktivuje jenom v případě, že nedojde k žádným selháním ověření.

Volba možnosti Ověřit nebo Ověřit a migrovat je vždy dobrým postupem při provádění ověření před migrací. Další informace o ověřování předběžné migrace najdete v této dokumentaci.

  • Režim migrace umožňuje vybrat režim migrace. Výchozí možností je offline.

Vyberte tlačítko Další: Připojit se ke zdroji .

Výběr modulu runtime serveru

Server runtime migrace je specializovaná funkce ve službě migrace navržená tak, aby během migrace fungovala jako zprostředkující server. Jedná se o samostatnou instanci flexibilního serveru Azure Database for PostgreSQL, která není cílovým serverem, ale slouží k usnadnění migrace databází ze zdrojového prostředí, které je přístupné pouze prostřednictvím privátní sítě.

Další informace o serveru runtime naleznete v modulu Runtime Server migrace.

Snímek obrazovky se stránkou Serveru modulu runtime migrace

Připojení ke zdroji

Na kartě Připojit ke zdroji se zobrazí výzva k zadání podrobností týkajících se zdroje vybraného na kartě Nastavení, což je zdroj databází.

Snímek obrazovky s connectsourcemigration

  • Název serveru – Zadejte název hostitele nebo IP adresu zdrojové instance PostgreSQL.
  • Port – číslo portu zdrojového serveru
  • Přihlašovací jméno správce serveru – uživatelské jméno zdrojového serveru PostgreSQL
  • Heslo – heslo zdrojového serveru PostgreSQL
  • Režim SSL – Podporované hodnoty jsou upřednostňované a povinné. Pokud je ssl na zdrojovém serveru PostgreSQL vypnuté, použijte SSLMODE=prefer. Pokud je SSL na zdrojovém serveru zapnuté, použijte SSLMODE=require. Hodnoty SSL je možné určit v souboru Postgresql.conf.
  • Test připojení – provede test připojení mezi cílem a zdrojem. Po úspěšném připojení můžou uživatelé pokračovat dalším krokem. V opačném případě musíme identifikovat síťové problémy mezi cílem a zdrojem a ověřit uživatelské jméno a heslo zdroje. Vytvoření testovacího připojení trvá několik minut.

Po úspěšném testovacím připojení vyberte Další : Vyberte cíl migrace.

Výběr cíle migrace

Na kartě Cíl vybrané migrace se zobrazí metadata pro cíl flexibilního serveru, jako je název předplatného, skupina prostředků, název serveru, umístění a verze PostgreSQL.

Snímek obrazovky s obrazovkou pro připojení cílové migrace

  • Uživatelské jméno správce – uživatelské jméno správce cílového serveru PostgreSQL
  • Heslo – heslo cílového serveru PostgreSQL
  • Vlastní plně kvalifikovaný název domény nebo IP adresa (volitelné): Vlastní plně kvalifikovaný název domény nebo pole IP je volitelné a lze ho použít, když je cíl za vlastním serverem DNS nebo má vlastní obory názvů DNS, takže je přístupný jenom přes konkrétní plně kvalifikované názvy domén nebo IP adresy. Může to například zahrnovat položky, jako flexibleserver.example.comje , 198.1.0.2nebo plně kvalifikovaný název domény PostgreSQL, například flexibleserver.postgres.database.azure.com, pokud vlastní server DNS obsahuje zónu postgres.database.azure.com DNS nebo předává dotazy pro tuto zónu do 168.63.129.16, kde se plně kvalifikovaný název domény překládá ve veřejné nebo privátní zóně DNS Azure.
  • Test připojení – provede test připojení mezi cílem a zdrojem. Po úspěšném připojení můžou uživatelé pokračovat dalším krokem. V opačném případě musíme identifikovat síťové problémy mezi cílem a zdrojem a ověřit uživatelské jméno a heslo cíle. Vytvoření připojení mezi cílem a zdrojem trvá několik minut.

Po úspěšném testovacím připojení vyberte další: Vyberte databáze pro migraci.

Výběr databází pro migraci

Na této kartě je seznam uživatelských databází uvnitř zdrojového serveru vybraného na kartě Nastavení. Při jednom pokusu o migraci můžete vybrat a migrovat až osm databází. Pokud existuje více než osm uživatelských databází, proces migrace se opakuje mezi zdrojovými a cílovými servery pro další sadu databází.

Snímek obrazovky s FetchDBmigration

Po výběru databází vyberte Další : Souhrn

Shrnutí

Karta Souhrn shrnuje všechny podrobnosti o zdroji a cíli pro vytvoření ověření nebo migrace. Zkontrolujte podrobnosti a vyberte tlačítko Start.

Snímek obrazovky se souhrnnou migrací

Monitorování migrace

Po výběru tlačítka Start se během několika sekund zobrazí oznámení, že ověření nebo vytvoření migrace proběhlo úspěšně. Pak se automaticky přesměrujete na stránku Migrace flexibilního serveru, která obsahuje novou položku pro nedávno vytvořené ověření nebo migraci.

Snímek obrazovky s migrací monitoru

Mřížka, která zobrazuje migrace, obsahuje tyto sloupce: Název, Stav, Režim migrace, Typ migrace, Zdrojový server, Typ zdrojového serveru, Databáze, Doba trvání a Čas zahájení. Položky se zobrazí v sestupném pořadí počátečního času s nejnovější položkou v horní části. Pomocí tlačítka Aktualizovat můžete aktualizovat stav ověření nebo migrace. Výběrem názvu migrace v mřížce zobrazíte přidružené podrobnosti.

Po vytvoření ověření nebo migrace se přesune do stavu InProgress a podkladu PerformingPreRequisiteSteps . Nastavení infrastruktury migrace a síťových připojení trvá 2 až 3 minuty.

Podrobnosti o migraci

Na kartě Nastavení jsme jako možnost Migrace a ověření vybrali možnost migrace. V tomto scénáři se ověření provádí nejprve před zahájením migrace. Po dokončení dílčího stavu PerformingPreRequisiteSteps se pracovní postup přesune do dílčího stavu probíhajícího ověření.

  • Pokud dojde k chybám, migrace se přesune do stavu selhání .
  • Pokud se ověření dokončí bez chyby, spustí se migrace a pracovní postup se přesune do podstavu Migrace dat.

Výsledky ověření a migrace můžete zobrazit na úrovni instance a databáze.

Snímek obrazovky s migrací Podrobností

Některé možné stavy migrace:

Stavy migrace

Stát Popis
InProgress Nastavení infrastruktury migrace probíhá nebo probíhá skutečná migrace dat.
Zrušeno Migrace se zruší nebo odstraní.
Neúspěch Migrace se nezdařila.
Ověření se nezdařilo. Ověření se nezdařilo.
Uspěl Migrace byla úspěšná a je dokončená.
WaitingForUserAction Platí jenom pro online migraci. Čeká se na provedení přímé akce uživatele.

Podstavy migrace

Podstate Popis
ProvedeníPreRequisiteSteps Nastavení infrastruktury probíhá pro migraci dat.
Probíhá ověření Probíhá ověřování.
Migrace dat Probíhá migrace dat.
Dokončení migrace Migrace je v posledních fázích dokončení.
Dokončeno Migrace byla dokončena.
Neúspěch Migrace se nezdařila.

Podstate ověření

Podstate Popis
Neúspěch Ověření se nezdařilo.
Uspěl Ověření je úspěšné.
Upozorňující Ověření je v upozornění.

Přímá migrace

Pokud existují migrace migrovat i ověřit a migrovat, dokončení online migrace vyžaduje další krok – uživatel musí provést přímou akci. Po dokončení kopírování/klonování základních dat se migrace přesune do WaitingForUserAction stavu a podstavu WaitingForCutoverTrigger . V tomto stavu může uživatel spustit přímou migraci z portálu výběrem migrace.

Před zahájením přímé migrace je důležité zajistit, aby:

  • Zápisy do zdroje jsou zastaveny – Latency hodnota je 0 nebo se blíží 0. Informace Latency lze získat z obrazovky s podrobnostmi o migraci, jak je znázorněno níže:

    Snímek obrazovky s přímou migrací

  • latency hodnota se zmenší na 0 nebo se blíží 0.

  • Hodnota latency označuje, kdy se cíl naposledy synchronizoval se zdrojem. V tomto okamžiku je možné zápis do zdroje zastavit a zahájit přímou migraci. V případě velkého provozu ve zdroji se doporučuje nejprve zastavit zápisy, aby Latency se mohlo blížit 0, a pak se zahájí přímá migrace. Operace přímé migrace použije všechny čekající změny ze zdroje na cíl a dokončí migraci. Pokud aktivujete přímou akci i s nenulovým stavem Latency, , replikace se zastaví až do tohoto bodu v čase. Všechna data jsou ve zdroji, dokud se bod přímé migrace nepoužije na cíl. Řekněme, že latence v přímé bodě byla 15 minut, takže se všechna změněná data za posledních 15 minut použijí na cíl. Čas závisí na backlogu změn, ke kterým dochází za posledních 15 minut. Proto se doporučuje, aby latence před aktivací přímé migrace přešla na nulu nebo téměř nulu.

    Snímek obrazovky s confirmcutovermigration

  • Migrace se přesune do Succeeded stavu, kdy Migrating Data se podstav nebo přímá migrace (v online migraci) úspěšně dokončí. Pokud dojde k problému v podstavu Migrating Data , migrace se přesune do Failed stavu.

    Snímek obrazovky s úspěšnou migrací

Kontrola migrace po dokončení

Po dokončení databází je potřeba ručně ověřit data mezi zdrojem a cílem a ověřit, že se všechny objekty v cílové databázi úspěšně vytvořily.

Po migraci můžete provádět následující úlohy:

  • Ověřte data na flexibilním serveru a ujistěte se, že se jedná o přesnou kopii zdrojové instance.
  • Po ověření povolte možnost vysoké dostupnosti na flexibilním serveru podle potřeby.
  • Změňte skladovou položku flexibilního serveru tak, aby odpovídala potřebám aplikace. Tato změna vyžaduje restartování databázového serveru.
  • Pokud změníte parametry serveru z jejich výchozích hodnot ve zdrojové instanci, zkopírujte tyto hodnoty parametrů serveru na flexibilním serveru.
  • Zkopírujte další nastavení serveru, jako jsou značky, výstrahy a pravidla brány firewall (pokud je to možné), ze zdrojové instance na flexibilní server.
  • Proveďte změny aplikace tak, aby odkazy připojovací řetězec na flexibilní server.
  • Pečlivě monitorujte výkon databáze a zjistěte, jestli vyžaduje ladění výkonu.