Ajánlott eljárások az Azure Database for PostgreSQL-be való zökkenőmentes migráláshoz
A következőkre vonatkozik: 
Azure Database for PostgreSQL – Rugalmas kiszolgáló
Ez a cikk az Azure Database for PostgreSQL-be történő zökkenőmentes és sikeres migrálást biztosító gyakori buktatókat és ajánlott eljárásokat ismerteti.
Premigráció ellenőrzése
Az áttelepítés első lépéseként futtassa az áttelepítés előtti ellenőrzést, mielőtt végrehajtja az áttelepítést. Az áttelepítés beállítási lapján az Ellenőrzés és ellenőrzés és migrálás lehetőséget használhatja. A premigráció ellenőrzése alapos ellenőrzéseket végez egy előre meghatározott szabálykészleten. A cél a lehetséges problémák azonosítása és a helyreállítható műveletekhez használható elemzések biztosítása. Futtassa a premigráció érvényesítését, amíg az sikeres állapotot nem eredményez. További információ: Premigration validations.
Cél rugalmas kiszolgálókonfiguráció
Az adatok kezdeti alappéldánya során a rendszer több beszúrási utasítást hajt végre a célon, amely írási naplókat (WAL-okat) hoz létre. A WAL-ek archiválásáig a naplók a célhelyen lévő tárolót és az adatbázis által igényelt tárterületet használnak fel.
A szám kiszámításához jelentkezzen be a forráspéldányba, és futtassa ezt a parancsot az összes migrálandó adatbázishoz:
SELECT pg_size_pretty( pg_database_size('dbname') );
Javasoljuk, hogy elegendő tárterületet foglaljon le a rugalmas kiszolgálón, ami 1,25-szörös vagy 25%-kal több tárterületet jelent, mint amennyit az előző parancs kimenete használ. A Storage Autogrow-t is használhatja.
Fontos
A tárterület mérete manuális konfigurációban vagy a Storage Autogrow-ban nem csökkenthető. A tárkonfigurációs spektrum minden lépése megduplázza a méretet, ezért körültekintő előre megbecsülni a szükséges tárterületet.
Az Azure Database for PostgreSQL – Rugalmas kiszolgálópéldány portál használatával történő létrehozásának rövid útmutatója kiváló kiindulópont. Az egyes kiszolgálókonfigurációkról további információt az Azure Database for PostgreSQL rugalmas kiszolgáló számítási és tárolási lehetőségei című témakörben talál.
Migrálási ütemterv
Minden áttelepítés maximális élettartama hét nap (168 óra) a kezdés után, és hét nap után időtúllépés. Az adatérvényesítés után elvégezheti az áttelepítést és az alkalmazás átállását, és minden ellenőrzés befejeződött, hogy elkerülje az áttelepítés időzítését. Online migrálás esetén a kezdeti alappéldány elkészülte után az átállási időszak három napig (72 óráig) tart, mielőtt időtúllépést végez. Offline migrálás esetén az alkalmazásoknak abba kell hagyniuk az adatbázisba való írást az adatvesztés megakadályozása érdekében. Az online migráláshoz hasonlóan a migrálás során is alacsonyan tarthatja a forgalmat.
A legtöbb nem gyártási kiszolgáló (dev, UAT, test és átmeneti) offline migrálással lesz migrálva. Mivel ezek a kiszolgálók kevesebb adatot tartalmaznak, mint az éles kiszolgálók, a migrálás gyors. Az éles kiszolgáló áttelepítéséhez tudnia kell, hogy mennyi időbe telne a migrálás előre megtervezése.
A migrálás befejezéséhez szükséges idő több tényezőtől függ. Tartalmazza az adatbázisok számát, méretét, az egyes adatbázisokon belüli táblák számát, az indexek számát és a táblák közötti adateloszlást. A célkiszolgáló termékváltozatától, valamint a forráspéldányon és a célkiszolgálón elérhető IOPS-tól is függ. A migrálási időt befolyásoló számos tényező miatt nehéz megbecsülni a migrálás teljes időtartamát. A legjobb módszer a tesztelési migrálás végrehajtása a számítási feladattal.
Az éles kiszolgáló migrálásának teljes állásidejének kiszámításához a következő fázisokat kell figyelembe venni:
A PITR migrálása: Az éles adatbázis-kiszolgáló migrálásához szükséges idő alapján a legjobban úgy lehet megbecsülni, ha az éles kiszolgáló egy időponthoz kötött visszaállítást (PITR) hajt végre, és az offline migrálást ezen az újonnan visszaállított kiszolgálón futtatja.
Puffer migrálása: Az előző lépés befejezése után megtervezheti a tényleges éles migrálást egy olyan időszakban, amikor az alkalmazásforgalom alacsony. Ez a migrálás ugyanazon a napon vagy valószínűleg egy hétre is tervezhető. Ekkorra a forráskiszolgáló mérete növekedhetett. Frissítse az éles kiszolgáló becsült migrálási idejét a növekedés mértéke alapján. Ha a növekedés jelentős, fontolja meg egy másik teszt elvégzését a PITR-kiszolgáló használatával. A legtöbb kiszolgáló esetében azonban a méretnövekedés nem lehet elég jelentős.
Adatérvényesítés: Miután az éles kiszolgáló áttelepítése befejeződött, ellenőriznie kell, hogy a rugalmas kiszolgálón lévő adatok a forráspéldány pontos másolatai-e. Használhat nyílt forráskódú vagy külső eszközöket, vagy manuálisan is elvégezheti az ellenőrzést. Készítse elő a tényleges migrálás előtt elvégezni kívánt érvényesítési lépéseket. Az ellenőrzés a következőket tartalmazhatja:
A sorok száma megegyezik az áttelepítésben érintett összes táblával.
Az összes adatbázis-objektum (táblák, sorozatok, bővítmények, eljárások és indexek) egyező száma.
A kulcsalkalmazással kapcsolatos oszlopok maximális vagy minimális azonosítóinak összehasonlítása.
Feljegyzés
Az adatbázisok összehasonlító mérete nem megfelelő metrika az ellenőrzéshez. Előfordulhat, hogy a forráspéldány blobokkal vagy elhalt üstökösökkel rendelkezik, ami a forráspéldány méretét is felütheti. A forráspéldányok és a célkiszolgálók közötti méretkülönbségek normálisak. Az ellenőrzés előző három lépésében szereplő probléma az áttelepítéssel kapcsolatos problémát jelez.
Kiszolgálóbeállítások áttelepítése: Az egyéni kiszolgálóparamétereket, tűzfalszabályokat (ha vannak), a címkéket és a riasztásokat manuálisan kell átmásolni a forráspéldányból a célba.
Kapcsolati sztring módosítása: Az alkalmazásnak a sikeres ellenőrzés után rugalmas kiszolgálóra kell módosítania a kapcsolati sztring. Ez a tevékenység az alkalmazás csapatával van összehangolva a forráspéldányra mutató kapcsolati sztring összes hivatkozásának módosításához. A rugalmas kiszolgálón a felhasználói paraméter a user=felhasználónév formátumban használható a kapcsolati sztring.
Például: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1
Bár a migrálás gyakran problémamentesen fut, célszerű vészhelyzeteket tervezni, ha több időre van szükség a hibakereséshez, vagy ha újra kell indítani az áttelepítést.
Migrálási sebesség teljesítménymérése
Az alábbi táblázat azt mutatja be, hogy mennyi időbe telik a különböző méretű adatbázisok áttelepítése a migrálási szolgáltatás használatával. A migrálás egy rugalmas kiszolgáló és a termékváltozat Standard_D4ds_v4 (4 mag, 16 GB memória) használatával történt.
| Adatbázisméret | Hozzávetőlegesen eltelt idő (Óó: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 |
Az előző számok a migrálás befejezéséhez szükséges idő közelítését adják meg. Határozottan javasoljuk, hogy futtasson tesztmigrálást a számítási feladattal, hogy pontos értéket kapjon a kiszolgáló migrálásához.
Fontos
Bár a Burstable termékváltozat nem korlátozás, javasoljuk, hogy válasszon egy magasabb termékváltozatot a rugalmas kiszolgáló számára a gyorsabb migráláshoz. Azure Database for PostgreSQL – A rugalmas kiszolgáló támogatja a közel nulla állásidős számítást és az IOPS-skálázást, így a termékváltozat minimális állásidővel frissíthető. Az SKU-t bármikor módosíthatja úgy, hogy megfeleljen az alkalmazás áttelepítés utáni igényeinek.
A migrálás sebességének javítása: Táblák párhuzamos migrálása
A célhoz hatékony termékváltozatot ajánlunk, mert a PostgreSQL migrálási szolgáltatás elfogy egy tárolóból a rugalmas kiszolgálón. A hatékony termékváltozat lehetővé teszi több tábla párhuzamos migrálását. A termékváltozatot visszaskálázhatja az előnyben részesített konfigurációra a migrálás után. Ez a szakasz az áttelepítési sebesség javítására szolgáló lépéseket tartalmazza, ha a táblák közötti adateloszlásnak kiegyensúlyozottabbnak kell lennie, vagy ha egy hatékonyabb termékváltozat nem befolyásolja jelentősen az áttelepítési sebességet.
Ha a forrás adateloszlása erősen ferde, és az adatok nagy része egy táblában található, a migráláshoz lefoglalt számítást teljes mértékben ki kell használni, ami szűk keresztmetszetet okoz. Ezért ossza fel a nagy táblákat kisebb adattömbökre, amelyeket aztán párhuzamosan migrál. Ez a funkció az 1 000 000-nél (1 m)-nél több üstökű táblákra vonatkozik. A táblázat kisebb adattömbökre való felosztása akkor lehetséges, ha az alábbi feltételek valamelyike teljesül:
A táblának egy egyszerű (nem összetett) elsődleges kulccsal vagy egyedi típusú vagy típusú
intsignificant intindexel rendelkező oszlopmal kell rendelkeznie.Feljegyzés
Az első vagy a második megközelítés esetében gondosan ki kell értékelnie, hogy milyen következményekkel jár, ha egyedi indexoszlopot ad hozzá a forrássémában. Csak azután, hogy megerősítést nyert, hogy egy egyedi indexoszlop hozzáadása nem érinti az alkalmazást, ha továbblép a módosításokra.
Ha a tábla nem rendelkezik egyszerű elsődleges kulccsal vagy egyedi típusú
intindexel, vagysignificant intaz adattípus feltételeinek megfelelő oszloptal rendelkezik, az oszlop az alábbi paranccsal konvertálható egyedi indexgé. Ez a parancs nem igényel zárolást a táblán.create unique index concurrently partkey_idx on <table name> (column name);Ha a tábla nem rendelkezik
simple int/big intelsődleges kulccsal, egyedi indexkel vagy az adattípus feltételeinek megfelelő oszloptal, az ALTER használatával hozzáadhat egy ilyen oszlopot, és elvetheti az áttelepítés után. AALTERparancs futtatásához zárolni kell a táblát.alter table <table name> add column <column name> big serial unique;
Ha az előző feltételek bármelyike teljesül, a rendszer több partícióban, párhuzamosan migrálja a táblát, ami növeli az áttelepítési sebességet.
Hogyan működik?
- A migrálási szolgáltatás megkeresi a tábla elsődleges kulcsának/egyedi indexének maximális és minimális egész értékét, amelyet párhuzamosan kell felosztani és migrálni.
- Ha a minimális és a maximális érték közötti különbség meghaladja az 1 000 000 (1 m) értéket, a táblázat több részre van felosztva, és minden rész párhuzamos migrálása történik.
Összefoglalva, a PostgreSQL migrálási szolgáltatás párhuzamos szálakban migrál egy táblát, és csökkenti az áttelepítési időt, ha:
- A táblázat egy egyszerű elsődleges kulccsal vagy egyedi, int vagy jelentős int típusú indexkel rendelkező oszlopot tartalmaz.
- A táblázat legalább 1 000 000 (1 m) sorból áll, így az elsődleges kulcs minimális és maximális értéke közötti különbség több mint 1 000 000 (1 m).
- A használt termékváltozat alapjárati magokkal rendelkezik, amelyek a táblázat párhuzamos migrálásához használhatók.
Vákuumblob a PostgreSQL-adatbázisban
Az adatok hozzáadása, frissítése és törlése során a PostgreSQL idővel halmozhatja fel a holt sorokat és a felesleges tárterületet. Ez a bloat megnövelheti a tárolási követelményeket és csökkentheti a lekérdezési teljesítményt. A porszívózás kulcsfontosságú karbantartási feladat, amely segít visszanyerni ezt a felesleges helyet, és biztosítja az adatbázis hatékony működését. A vákuumozás olyan problémákat old meg, mint a holt sorok és a táblablob a tárolás hatékony használata érdekében. Emellett segít a gyorsabb migrálásban is, mivel az áttelepítési idő az adatbázis méretének függvénye.
A PostgreSQL biztosítja a parancsot a VACUUM holt sorok által elfoglalt tárterület visszaszerzéséhez. A ANALYZE lehetőség statisztikákat is gyűjt a lekérdezéstervezés további optimalizálásához. A nagy írási tevékenységgel rendelkező táblák esetében a VACUUM folyamat agresszívebb lehet a használatával VACUUM FULL, de több időt igényel a futtatás.
Standard vákuum
VACUUM your_table;Vákuum elemzéssel
VACUUM ANALYZE your_table;Agresszív vákuum nehéz írási táblákhoz
VACUUM FULL your_table;
Ebben a példában cserélje le a your_table a tényleges táblanévre. A VACUUM parancs FULL hatékonyan visszanyeri a helyet, míg VACUUM ANALYZE optimalizálja a lekérdezéstervezést. Ezt VACUUM FULL a lehetőséget megfontoltan kell használni a nagyobb teljesítményre gyakorolt hatása miatt.
Egyes adatbázisok olyan nagyméretű objektumokat, például képeket vagy dokumentumokat tárolnak, amelyek idővel hozzájárulhatnak az adatbázis-bloathoz. A VACUUMLO parancsot a PostgreSQL-ben lévő nagy objektumokhoz tervezték.
Nagy objektumok vákuuma
VACUUMLO;
Ezeknek a porszívózási stratégiáknak a rendszeres beépítése biztosítja a jól karbantartott PostgreSQL-adatbázist.
Különleges szempont
Vannak speciális feltételek, amelyek általában egyedi körülményekre, konfigurációkra vagy előfeltételekre vonatkoznak, amelyeket az oktatóanyag vagy a modul elvégzése előtt figyelembe kell vennie. Ezek a feltételek tartalmazhatnak konkrét szoftververziókat, hardverkövetelményeket vagy egyéb eszközöket, amelyek a tanulási tartalom sikeres elvégzéséhez szükségesek.
Online migrálás
Az online migrálás a pgcopydb használatát követi, és néhány logikai dekódolási korlátozás érvényes. Azt is javasoljuk, hogy az online migrálás alatt álló adatbázis összes táblájában legyen egy elsődleges kulcs. Ha az elsődleges kulcs hiányzik, a hiba azt eredményezi, hogy a migrálás során csak insert a műveletek jelennek meg, kivéve a frissítéseket vagy a törléseket. Az online migrálás folytatása előtt adjon hozzá egy ideiglenes elsődleges kulcsot a megfelelő táblákhoz.
Feljegyzés
Az elsődleges kulcs nélküli táblák online migrálása esetén csak insert a műveletek lesznek lejátszva a célon. Ez inkonzisztenciát okozhat az adatbázisban, ha a forráson frissített vagy törölt rekordok nem tükrözik a célt.
Másik lehetőségként használhatja azt a ALTER TABLE parancsot, amelyben a művelet a REPLICA IDENTIYFULL. A FULL beállítás rögzíti a sor összes oszlopának régi értékeit, így az online migrálás során az összes CRUD-művelet az elsődleges kulcs hiányában is megjelenik a célon. Ha egyik lehetőség sem működik, végezzen offline migrálást alternatívaként.
Adatbázis postgres_fdw kiterjesztéssel
A postgres_fdw modul biztosítja a külső adatburkoló postgres_fdw, amely a külső PostgreSQL-kiszolgálókon tárolt adatok eléréséhez használható. Ha az adatbázis ezt a bővítményt használja, a sikeres migrálás biztosításához a következő lépéseket kell végrehajtani.
- Ideiglenesen távolítsa el (leválasztja) az idegen adatburkolót a forráspéldányról.
- Végezze el a többi adatmigrálását a migrálási szolgáltatás használatával.
- A migrálás után állítsa vissza a külső adatburkoló szerepköröket, a felhasználót és a célra mutató hivatkozásokat.
Adatbázis postGIS-kiterjesztéssel
A postGIS bővítmény kompatibilitástörő változásokat/tömörítési problémákat tapasztal a különböző verziók között. Ha rugalmas kiszolgálóra migrál, az alkalmazást ellenőrizni kell az újabb postGIS-verzióval, hogy az alkalmazás ne legyen érintett, vagy hogy a szükséges módosításokat végre kell hajtani. A postGIS hírei és kibocsátási megjegyzései jó kiindulópontok a verziók kompatibilitástörő változásainak megértéséhez.
Adatbázis-kapcsolat törlése
Előfordulhat, hogy a migrálás indításakor ez a hiba jelenik meg:
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.
Ebben a forgatókönyvben engedélyt adhat az migration user adatbázis összes aktív kapcsolatának bezárására vagy a kapcsolatok manuális bezárására, mielőtt újra megkísérlené az áttelepítést.