A PostgreSQL-adatbázis frissítése memóriakép és visszaállítás használatával
A KÖVETKEZŐKRE VONATKOZIK:
Azure Database for PostgreSQL – Önálló kiszolgáló
Fontos
Azure Database for PostgreSQL – Az önálló kiszolgáló a kivezetési útvonalon van. Határozottan javasoljuk, hogy frissítsen az Azure Database for PostgreSQL rugalmas kiszolgálóra. A rugalmas Azure Database for PostgreSQL-kiszolgálóra való migrálással kapcsolatos további információkért lásd: Mi történik az önálló Azure Database for PostgreSQL-kiszolgálóval?
Feljegyzés
A jelen dokumentációban ismertetett fogalmak mind az Önálló Azure Database for PostgreSQL-re, mind az Azure Database for PostgreSQL rugalmas kiszolgálóra vonatkoznak.
Az Azure Database for PostgreSQL-ben üzembe helyezett PostgreSQL-kiszolgálót úgy frissítheti, hogy az adatbázisokat egy magasabb szintű verziókiszolgálóra migrálja az alábbi módszerekkel.
- Offline metódus a PostgreSQL pg_dump és pg_restore használatával, amely állásidőt von maga után az adatok áttelepítéséhez. Ez a dokumentum a frissítés/migrálás ezen módszerével foglalkozik.
- Online metódus a Database Migration Service (DMS) használatával. Ez a módszer csökkenti az állásidő-migrálást, és szinkronizálja a céladatbázist a forrással, és kiválaszthatja, hogy mikor kell megszakítani a műveletet. A DMS használatához azonban figyelembe kell venni néhány előfeltételt és korlátozást. További részleteket a DMS dokumentációjában talál.
- Helyszíni főverzió-frissítési módszer az Azure Database for PostgreSQL rugalmas kiszolgálóval. A helyi főverzió-frissítési funkció egyetlen kattintással végrehajtja a kiszolgáló főverzió-frissítését. Ez leegyszerűsíti a frissítési folyamatot, amely minimalizálja a kiszolgálóhoz hozzáférő felhasználók és alkalmazások fennakadásait. A helyszíni frissítések egyszerűbben frissíthetik a példány főverzióját, mivel a frissítés után megőrzik az aktuális kiszolgáló nevét és egyéb beállításait, és nem igényelnek adatmigrálást vagy az alkalmazás kapcsolati sztring módosításait. A helyi verziófrissítés gyorsabb, és rövidebb állásidőt igényel, mint az adatmigrálás.
Az alábbi táblázat az adatbázis méretei és forgatókönyvei alapján nyújt néhány javaslatot.
| Adatbázis/forgatókönyv | Memóriakép/visszaállítás (offline) | DMS (Online) |
|---|---|---|
| Van egy kis adatbázisa, és engedheti meg magának a frissítés állásidejét | X | |
| Kis adatbázisok (< 10 GB) | X | X |
| Kis közepes méretű (10 GB – 100 GB) | X | X |
| Nagyméretű adatbázisok (> 100 GB) | X | |
| A frissítés állásideje (az adatbázis méretétől függetlenül) | X | |
| Meg tudja kezelni a DMS előfeltételeit, beleértve az újraindítást is? | X | |
| Elkerülheti a DLL-eket és a nem megjelölt táblákat a frissítési folyamat során? | X |
Ez az útmutató néhány offline migrálási módszert és példát tartalmaz, amelyek bemutatják, hogyan migrálhat a forráskiszolgálóról a PostgreSQL magasabb verzióját futtató célkiszolgálóra.
Feljegyzés
A PostgreSQL-memóriakép és -visszaállítás többféleképpen is elvégezhető. Dönthet úgy, hogy az útmutatóban megadott módszerek valamelyikével migrál, vagy az igényeinek megfelelő alternatív módszereket választ. További paraméterekkel rendelkező részletes memóriakép- és visszaállítási szintaxist a pg_dump és pg_restore című cikkben talál.
A memóriakép és a visszaállítás az Azure Database for PostgreSQL-lel való használatának előfeltételei
Az útmutató végigvezetéséhez a következőkre van szüksége:
- A frissíteni kívánt motor alacsonyabb verzióját futtató forrás PostgreSQL-adatbázis-kiszolgáló.
- Célként szolgáló PostgreSQL-adatbáziskiszolgáló a kívánt főverziójú Azure Database for PostgreSQL-kiszolgálóval – önálló kiszolgálóval vagy Rugalmas Azure Database for PostgreSQL-kiszolgálóval.
- Egy PostgreSQL-ügyfélrendszer a memóriakép futtatásához és a parancsok visszaállításához. Javasoljuk, hogy a magasabb adatbázis-verziót használja. Ha például a PostgreSQL 9.6-os verziójáról 11-es verzióra frissít, használja a PostgreSQL 11-es verzióját.
- Lehet olyan Linux- vagy Windows-ügyfél, amely telepítette a PostgreSQL-t, és telepítette a pg_dump és pg_restore parancssori segédprogramokat.
- Másik lehetőségként használhatja az Azure Cloud Shellt, vagy az Azure Cloud Shellt az Azure Portal jobb felső részén található menüsávon. A memóriakép- és visszaállítási parancsok futtatása előtt be kell jelentkeznie a fiókjába
az login.
- A PostgreSQL-ügyfél lehetőleg ugyanabban a régióban fut, mint a forrás- és célkiszolgálók.
További részletek és szempontok
- A forrás- és céladatbázisok kapcsolati sztring a portál "Csatlakozás ion strings" elemének kiválasztásával találhatja meg.
- Előfordulhat, hogy több adatbázist is futtat a kiszolgálón. Az adatbázisok listáját a forráskiszolgálóhoz való csatlakozással és a futtatással
\ltalálja meg. - Hozzon létre megfelelő adatbázisokat a céladatbázis-kiszolgálón, vagy adja hozzá
-Cazpg_dumpadatbázisokat létrehozó parancsot. - Nem frissíthet
azure_maintenancevagy sablonalapú adatbázisokat. Ha módosította a sablonadatbázisokat, áttelepítheti a módosításokat, vagy elvégezheti ezeket a módosításokat a céladatbázisban. - Tekintse meg a fenti táblázatokat, és állapítsa meg, hogy az adatbázis alkalmas-e erre a migrálási módra.
- Ha az Azure Cloud Shellt szeretné használni, vegye figyelembe, hogy a munkamenet 20 perc után időtúllépést jelez. Ha az adatbázis mérete < 10 GB, a munkamenet túllépése nélkül is végrehajthatja a frissítést. Ellenkező esetben előfordulhat, hogy más módon is nyitva kell tartania a munkamenetet, például 10–15 perc alatt egyszer kell lenyomnia egy billentyűt.
Az útmutatóban használt példaadatbázis
Ebben az útmutatóban az alábbi forrás- és célkiszolgálók és adatbázisnevek szemléltetik példákkal.
| Leírás | Érték |
|---|---|
| Forráskiszolgáló (9.5-ös verzió) | pg-95.postgres.database.azure.com |
| Forrásadatbázis | pad5gb |
| Forrásadatbázis mérete | 5 GB |
| Forrás felhasználóneve | pg@pg-95 |
| Célkiszolgáló (v11) | pg-11.postgres.database.azure.com |
| Céladatbázis | pad5gb |
| Cél felhasználóneve | pg@pg-11 |
Feljegyzés
A rugalmas kiszolgáló támogatja a PostgreSQL 11-es verzióját. Emellett a rugalmas kiszolgáló felhasználóneve nem igényel @dbservername.
Adatbázisok frissítése offline migrálási módszerekkel
A frissítésekhez használhatja az ebben a szakaszban ismertetett módszerek egyikét. A feladatok végrehajtása során az alábbi tippeket használhatja.
Ha ugyanazt a jelszót használja a forráshoz és a céladatbázishoz, beállíthatja a környezeti változót
PGPASSWORD=yourPassword. Ezután nem kell minden alkalommal jelszót megadnia, amikor olyan parancsokat futtat, mint a psql, a pg_dump és a pg_restore. Hasonlóképpen további változókat is beállíthat,PGSSLMODEpéldáulPGUSERa PostgreSQL környezeti változóit.Ha a PostgreSQL-kiszolgáló TLS-/SSL-kapcsolatokat igényel (alapértelmezés szerint az Azure Database for PostgreSQL-kiszolgálókon), állítson be egy környezeti változót
PGSSLMODE=require, hogy az pg_restore eszköz csatlakozzon a TLS-hez. TLS nélkül a hiba beolvashatóFATAL: SSL connection is required. Please specify SSL options and retry.A Windows parancssorban futtassa a parancsot
SET PGSSLMODE=requirea pg_restore parancs futtatása előtt. Linux vagy Bash rendszeren futtassa a parancsotexport PGSSLMODE=requirea pg_restore parancs futtatása előtt.
Fontos
A dokumentumban ismertetett lépések és módszerek néhány példát mutatnak a pg_dump/pg_restore parancsokra, és nem jelölik a frissítések végrehajtásának összes lehetséges módját. Javasoljuk, hogy tesztelje és ellenőrizze a parancsokat egy tesztkörnyezetben, mielőtt éles környezetben használja őket.
Szerepkörök migrálása
A szerepkörök (felhasználók) globális objektumok, amelyeket az adatbázis(ok) visszaállítása előtt külön kell áttelepíteni az új fürtre. A bináris fájlokat -r (--roles-only) beállítással is használhatja pg_dumpall a memóriaképek kiírásához.
Az összes szerepkör kiírása jelszóval a forráskiszolgálóról:
pg_dumpall -r --host=mySourceServer --port=5432 --username=myUser@mySourceServer --database=mySourceDB > roles.sql
Az összes szerepkörnév kiírása jelszó nélkül a rugalmas forráskiszolgálóról:
pg_dumpall -r --no-role-passwords --host=mySourceServer --port=5432 --username=myUser --database=mySourceDB > roles.sql
Fontos
Az Azure Database for PostgreSQL-ben – A rugalmas kiszolgáló felhasználói nem férhetnek hozzá pg_authid táblához, amely az adatbázis-engedélyezési azonosítókkal és a felhasználó jelszavával kapcsolatos információkat tartalmaz. Ezért a felhasználók jelszavainak beolvasása nem lehetséges. Fontolja meg az Azure Key Vault használatát a titkos kulcsok biztonságos tárolásához.
Szerkessze és távolítsa el a roles.sql tartalom hivatkozásait NOSUPERUSERNOBYPASSRLS a psql használatával a célkiszolgálón:
psql -f roles.sql --host=myTargetServer --port=5432 --username=myUser --dbname=postgres
A memóriakép szkriptjének nem szabad teljesen hiba nélkül futnia. Különösen azért, mert a szkript a forrásfürtben meglévő összes szerepkörhöz létrehozza a CREATE SZEREPKÖRt, a rendszerindítási szuperfelhasználónál (például azure_pg_admin vagy azure_superuser) biztosan "már létezik szerepkör" hibaüzenet jelenik meg. Ez a hiba ártalmatlan, és figyelmen kívül hagyható. --clean A beállítás használata valószínűleg további ártalmatlan hibaüzeneteket eredményez a nem létező objektumokról, bár ezeket a hozzáadással --if-existsminimalizálhatja.
1. módszer: A pg_dump és a psql használata
Ez a módszer két lépésből áll. Először is a forráskiszolgálóról származó SQL-fájl kiírása a következő használatával pg_dump: . A második lépés a fájl importálása a célkiszolgálóra a használatával psql. Részletekért tekintse meg az Áttelepítés exportálási és importálási dokumentációt.
2. módszer: Pg_dump és pg_restore használata
Ebben a frissítési módszerben először létrehoz egy memóriaképet a forráskiszolgálóról a használatával pg_dump. Ezután visszaállítja a memóriaképfájlt a célkiszolgálóra pg_restorea . A részletekért tekintse meg a migrálási dokumentációt a memóriakép és a visszaállítás dokumentációjának használatával.
3. módszer: A memóriaképadatok továbbítása a céladatbázisba
Ha nem rendelkezik PostgreSQL-ügyfélrel, vagy az Azure Cloud Shellt szeretné használni, akkor ezt a módszert használhatja. Az adatbázis-memóriakép közvetlenül a céladatbázis-kiszolgálóra kerül, és nem tárolja a memóriaképet az ügyfélben. Ezért ez korlátozott tárterülettel rendelkező ügyféllel is használható, és akár az Azure Cloud Shellből is futtatható.
Győződjön meg arról, hogy az adatbázis létezik a célkiszolgálón a parancs használatával
\l. Ha az adatbázis nem létezik, hozza létre az adatbázist.psql "host=myTargetServer port=5432 dbname=postgres user=myUser password=###### sslmode=mySSLmode"postgres> \l postgres> create database myTargetDB;Futtassa a memóriaképet, és állítsa vissza egyetlen parancssorként egy cső használatával.
pg_dump -Fc --host=mySourceServer --port=5432 --username=myUser --dbname=mySourceDB | pg_restore --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDBPéldául:
pg_dump -Fc --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb | pg_restore --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gbA frissítési (migrálási) folyamat befejeződése után tesztelheti az alkalmazást a célkiszolgálón.
Ismételje meg ezt a folyamatot a kiszolgálón belüli összes adatbázis esetében.
Az alábbi táblázat például azt mutatja be, hogy mennyi időbe telt a streamelési memóriakép használatával történő migrálás. A mintaadatok feltöltése a pgbench használatával történik. Mivel az adatbázis különböző méretű objektumokkal rendelkezhet, mint a pgbench által létrehozott táblák és indexek, erősen ajánlott tesztelni az adatbázis memóriaképét és visszaállítását, hogy megértse az adatbázis frissítéséhez szükséges tényleges időt.
| Adatbázis mérete | Kb. a szükséges idő |
|---|---|
| 1 GB | 1-2 perc |
| 5 GB | 8-10 perc |
| 10 GB | 15-20 perc |
| 50 GB | 1-1,5 óra |
| 100 GB | 2,5-3 óra |
4. módszer: Párhuzamos memóriakép és visszaállítás használata
Ezt a módszert akkor érdemes megfontolni, ha kevés nagyobb táblával rendelkezik az adatbázisban, és párhuzamosítani szeretné az adatbázis memóriaképének és visszaállításának folyamatát. Az ügyfélrendszerben elegendő tárhelyre is szüksége van a biztonsági mentési memóriaképek elhelyezéséhez. Ez a párhuzamos memóriakép- és visszaállítási folyamat csökkenti a teljes migrálás befejezéséhez szükséges időt. Az 1–1,5 órát igénybe vett 50 GB-os pgbench-adatbázis például az 1. és a 2. módszerrel fejeződött be, és ez a módszer kevesebb mint 30 percet vett igénybe.
A forráskiszolgáló minden adatbázisához hozzon létre egy megfelelő adatbázist a célkiszolgálón.
psql "host=myTargetServer port=5432 dbname=postgres user=myuser password=###### sslmode=mySSLmode"postgres> create database myDB;Például:
psql "host=pg-11.postgres.database.azure.com port=5432 dbname=postgres user=pg@pg-11 password=###### sslmode=require" psql (12.3 (Ubuntu 12.3-1.pgdg18.04+1), server 13.3) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off) Type "help" for help. postgres> create database bench5gb; postgres> \qFuttassa a pg_dump parancsot címtárformátumban, amelyben a feladatok száma = 4 (az adatbázisban lévő táblák száma). Nagyobb számítási szinttel és több táblával magasabb számra növelheti azt. Ez a pg_dump létrehoz egy könyvtárat, amely minden feladathoz tömörített fájlokat tárol.
pg_dump -Fd -v --host=sourceServer --port=5432 --username=myUser --dbname=mySourceDB -j 4 -f myDumpDirectoryPéldául:
pg_dump -Fd -v --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb -j 4 -f dump.dirEzután állítsa vissza a biztonsági mentést a célkiszolgálón.
$ pg_restore -v --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB -j 4 myDumpDirPéldául:
$ pg_restore -v --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb -j 4 dump.dir
Tipp.
A dokumentumban említett folyamat az Azure Database for PostgreSQL rugalmas kiszolgálójának frissítésére is használható. A fő különbség az, hogy a rugalmas kiszolgáló célkiszolgálójának kapcsolati sztring a @dbName. Ha például a felhasználónév pgaz, akkor az egyetlen kiszolgáló felhasználóneve a kapcsolati sztringben pg@pg-95lesz, míg rugalmas kiszolgáló esetén egyszerűen használható pg.
Frissítés/migrálás utáni
A főverzió frissítése után javasoljuk, hogy futtassa a parancsot az ANALYZE egyes adatbázisokban a pg_statistic tábla frissítéséhez. Ellenkező esetben teljesítményproblémák léphetnek fel.
postgres=> analyze;
ANALYZE
Következő lépések
- Miután elégedett a céladatbázis-függvénnyel, elvetheti a régi adatbázis-kiszolgálót.
- Azure Database for PostgreSQL esetén – csak egykiszolgálós. Ha ugyanazt az adatbázisvégpontot szeretné használni, mint a forráskiszolgáló, akkor a régi forrásadatbázis-kiszolgáló törlése után létrehozhat egy olvasási replikát a régi adatbázis-kiszolgáló nevével. Az állandó replikációs állapot létrehozása után leállíthatja a replikát, amely előlépteti a replikakiszolgálót független kiszolgálóként. További részletekért lásd a replikációt .
Fontos
Erősen ajánlott tesztelni az új PostgreSQL frissített verzióját, mielőtt közvetlenül éles környezetben használnám. Ez magában foglalja a kiszolgálóparaméterek összehasonlítását a régebbi forrásverzióforrás és az újabb verziócél között. Győződjön meg arról, hogy azonosak, és ellenőrizze az új verzióban hozzáadott új paramétereket. A verziók közötti különbségek itt találhatók.