Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
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.
Migráció előtti érvényesítés
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ás lapján az Ellenőrzés és Ellenőrzés és migrálás lehetőségeket 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 továbbra is a premigrálás érvényesítését, amíg sikeres állapotot nem eredményez. További információ: Premigration validations.
Rugalmas kiszolgálókonfiguráció célhelye
Az adatok kezdeti másolása során a rendszer több beszúrási utasítást hajt végre a célrendszeren, amely előzetes 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') );
Azt javasoljuk, hogy elegendő tárterületet foglaljon le a rugalmas kiszolgálón, ami 1,25-szörös vagy 25% több tárterületet jelent, mint amit az előző parancs kimenete használ. "Storage Autogrow"-t is használhatja.
Important
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.
A rugalmas Azure Database for PostgreSQL-kiszolgáló 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 a rugalmas Azure Database for PostgreSQL-kiszolgáló számítási és tárolási beállításaiban talál.
Important
A rugalmas kiszolgáló létrehozása után a migrálás megkezdése előtt módosítsa a rugalmas kiszolgáló password_encryption kiszolgálóparaméterét SCRAM-SHA-256-ról MD5-re. Ez elengedhetetlen ahhoz, hogy az önálló kiszolgálón meglévő hitelesítő adatok a rugalmas kiszolgálón működjenek
A migráció ütemezése
Minden áttelepítés maximális élettartama hét nap (168 óra) a kezdésétől számítva, és hét nap után lejár. 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őtúllépé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és történne. Offline migrálás esetén az alkalmazásoknak abba kell hagyniuk az adatbázisba történő í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áció gyors. Az éles kiszolgáló áttelepítéséhez tudnia kell, hogy mennyi időbe telik a migrálás, hogy előre megtervezhesse azt.
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 tesztmigrálás végrehajtása a terheléssel.
A gyártási kiszolgáló migrálásának teljes leállási idejének kiszámításához a következő lépéseket kell figyelembe venni:
A PITR migrálása: Úgy lehet a legjobban megbecsülni a termelési adatbázis-kiszolgáló migrálásához szükséges időt, ha a termelési kiszolgálón végrehajt egy időponthoz kötött visszaállítást (PITR), é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 termelési migrálást egy olyan időszakban, amikor az alkalmazási forgalom 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 adatbázis összes objektumának (táblák, szekvenciák, bővítmények, eljárások és indexek) megfelelő számát tartalmazza.
A kulcsalkalmazással kapcsolatos oszlopok maximális vagy minimális azonosítóinak összehasonlítása.
Note
Az adatbázisok összehasonlító mérete nem megfelelő metrika az ellenőrzéshez. Előfordulhat, hogy a forráspéldány puffertartalékokkal vagy elhalt bejegyzésekkel rendelkezik, ami megnövelheti a forráspéldány méretét. 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 sztringek módosítása: Az alkalmazásnak a sikeres ellenőrzés után rugalmas kiszolgálóra kell módosítania a kapcsolati sztringeket. Ez a tevékenység az alkalmazás csapatával van összehangolva annak érdekében, hogy módosítsák a forráspéldányra mutató összes kapcsolati karakterlánc hivatkozását. A rugalmas kiszolgálón a felhasználói paraméter felhasználó =felhasználónév formátumban használható a kapcsolati sztringben.
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ázis mérete | 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 hajtson végre tesztmigrációt a terheléssel annak érdekében, hogy pontos értéket kapjon a kiszolgáló migrálásához.
Important
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. A rugalmas Azure Database for PostgreSQL-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. Egy erőteljes SKU 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. Így ossza szét a nagyméretű táblákat kisebb adatblokkokra, amelyeket ezután párhuzamosan migrál. Ez a funkció a 20 GB-nál nagyobb 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ú
smallintindexel rendelkező oszlopmal kell rendelkeznie,integervagybig int.Note
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 miután megerősítést nyert, hogy egy egyedi indexoszlop hozzáadása nem érinti az alkalmazást, szabad továbblépnie a módosításokkal.
Ha a tábla nem rendelkezik egyszerű elsődleges kulccsal vagy egyedi típusú
smallintindexel,integervagybig 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árat a táblán.create unique index concurrently partkey_idx on <table name> (column name);Ha a táblázat nem rendelkezik
smallintelsődlegesintegerkulccsal,big integyedi 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 egy tábla méretét, hogy ellenőrizze, nagyobb-e 20 GB-nál.
- Ha a méret nagyobb, mint 20 GB, és van egy
smallint,integervagy elsődleges kulcs vagybig integyedi index, a táblázat több részre van felosztva, és az egyes részek 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 típusú
smallintindexel rendelkező oszlopot tartalmaz,integervagybig int. - A táblázat mérete nagyobb, mint 20 GB.
- A használt SKU alapjárati magokkal rendelkezik, amelyek a tábla 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 a VACUUM FULL használatával agresszívebb lehet, de hosszabb futási időt igényel.
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 nélkül hatékonyan visszanyeri a helyet, míg a 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 objektumokat porszívózni
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.
Note
Elsődleges kulcs nélküli táblák online migrálása esetén a célrendszeren csak a insert műveletek lesznek lejátszva. 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 a ALTER TABLE parancsot, amelyben a művelet a REPLICA IDENTITYFULL opcióval van ellátva. 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 (kioldja) a forráspéldányról az idegen adatburkolót.
- 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 kiadási megjegyzései jó kiindulópontok a különböző verziók jelentős 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.