Olvasási replikák az önálló Azure Database for PostgreSQL-kiszolgálón
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?
Az olvasási replika funkcióval adatokat replikálhat egy Azure Database for PostgreSQL-kiszolgálóról egy írásvédett kiszolgálóra. A replikák aszinkron módon frissülnek a PostgreSQL-motor natív fizikai replikációs technológiájával. Az elsődleges kiszolgálóról legfeljebb öt replikára replikálhat.
A replikák új, Ön által kezelt kiszolgálók, amelyek hasonlítanak a hagyományos Azure Database for PostgreSQL-kiszolgálókhoz. Minden olvasási replika esetében a kiosztott számításért a virtuális magokért és a tárterületért kell fizetnie GB/hóban.
Megtudhatja, hogyan hozhat létre és kezelhet replikákat.
Mikor érdemes olvasási replikát használni?
Az olvasási replika funkció javítja az olvasásigényes számítási feladatok teljesítményét és skálázását. Az olvasási számítási feladatok a replikákba izolálhatók, míg az írási feladatok az elsődleges kiszolgálóra irányíthatók. Az olvasási replikák másik régióban is üzembe helyezhetők, és vészhelyreállítás esetén előléptethetők olvasási/írási kiszolgálóként.
Gyakori forgatókönyv, hogy a BI- és elemzési számítási feladatok az olvasási replikát használják adatforrásként a jelentéskészítéshez.
Mivel a replikák írásvédettek, nem csökkentik közvetlenül az elsődleges írási kapacitás terheit az elsődleges kiszolgálón.
Megfontolások
A funkció olyan forgatókönyvekhez készült, ahol a késés elfogadható, és a lekérdezések kiszervezésére szolgál. Nem szinkron replikációs forgatókönyvekhez készült, ahol a replikaadatok várhatóan naprakészek lesznek. Az elsődleges hely és a replika között mérhető késésre lehet számítani. Ez a számítási feladattól és az elsődleges és a replika közötti késéstől függően percekben vagy akár órákban is lehet. A replikán lévő adatok idővel konzisztenssé válnak az elsődleges helyen lévő adatokkal. Ezt a funkciót olyan számítási feladatok esetében érdemes használni, amelyeknél nem jelent problémát a késés.
Feljegyzés
A legtöbb számítási feladat esetén az olvasási replikák közel valós idejű frissítéseket biztosítanak az elsődleges kiszolgálóról. Az állandó, nehéz, nagy írási igényű elsődleges számítási feladatok esetén azonban a replika késése tovább nőhet, és előfordulhat, hogy soha nem éri el az elsődleges kiszolgálót. Ez megnövelheti az elsődleges kiszolgálón a tárterület-használatot is, mivel a rendszer nem törli a WAL-fájlokat, amíg meg nem érkeznek a replikához. Ha ez a helyzet nem szűnik meg, az olvasási replikáknak a nagy írási igényű számítási feladatok befejeződése utáni törlése és újbóli létrehozása jelenti a megoldást, hogy a replika a késés szempontjából ismét megfelelő állapotba kerüljön. Az aszinkron olvasási replikák nem megfelelőek ilyen nagy írási igényű számítási feladatokhoz. Az alkalmazás olvasási replikáinak kiértékelésekor figyelje a replika késését egy teljes alkalmazás-munkaterhelési ciklus esetében a csúcsidőn és a csúcsidőn kívüli időpontokon keresztül, hogy elérhesse a lehetséges késést és a várható RTO/RPO-t a számítási feladat ciklusának különböző pontjain.
Feljegyzés
Az automatikus biztonsági mentések legfeljebb 4 TB-os tárkonfigurációval konfigurált replikakiszolgálókhoz lesznek végrehajtva.
Régiók közötti replikáció
Az elsődleges kiszolgálóétól eltérő régióban is létrehozhat olvasási replikát. A régiók közötti replikáció olyan forgatókönyvek esetén lehet hasznos, mint a vészhelyreállítás megtervezése vagy az adatok közelebb hozása a felhasználókhoz.
Feljegyzés
Az alapszintű kiszolgálók csak az azonos régiós replikációt támogatják.
Elsődleges kiszolgáló bármelyik Azure Database for PostgreSQL-régióban lehet. Az elsődleges kiszolgáló rendelkezhet replikával a párosított régióban vagy az univerzális replikarégiókban. Az alábbi képen látható, hogy mely replikarégiók érhetők el az elsődleges régiótól függően.
Univerzális replikarégiók
Az olvasási replikát az alábbi régiók bármelyikében létrehozhatja, függetlenül attól, hogy hol található az elsődleges kiszolgáló. Ezek az univerzális replikarégiók:
Kelet-Ausztrália, Délkelet-Ausztrália, Dél-Brazília, Kanada középső régiója, Kelet-Kanada, USA középső régiója, USA keleti régiója, USA 2. keleti régiója, Kelet-Japán, Nyugat-Japán, Közép-Korea, Dél-Korea, USA északi középső régiója, Észak-Európa, USA déli középső régiója, Délkelet-Ázsia, Egyesült Királyság déli régiója, Egyesült Királyság nyugati régiója, Nyugat-Európa, USA nyugati régiója, USA 2. nyugati régiója, USA nyugati középső régiója.
Párosított régiók
Az univerzális replikarégiók mellett olvasási replikát is létrehozhat az elsődleges kiszolgáló Azure-párosított régiójában. Ha nem ismeri a régió párját, az Azure Párosított régiók című cikkből tudhat meg többet.
Ha régiók közötti replikákat használ vészhelyreállítás tervezéséhez, javasoljuk, hogy a replikát a párosított régióban hozza létre a többi régió helyett. A párosított régiók elkerülik az egyidejű frissítéseket, és rangsorolják a fizikai elkülönítést és az adattárolást.
A következő korlátozásokat kell figyelembe venni:
- Egyirányú párok: Egyes Azure-régiók csak egy irányban vannak párosítva. Ezek közé a régiók közé tartozik Nyugat-India, Dél-Brazília. Ez azt jelenti, hogy a nyugat-indiai elsődleges kiszolgáló létrehozhat egy replikát Dél-Indiában. A dél-indiai elsődleges kiszolgáló azonban nem tud replikát létrehozni Nyugat-Indiában. Ennek az az oka, hogy Nyugat-India másodlagos régiója Dél-India, de Dél-India másodlagos régiója nem Nyugat-India.
Replika létrehozása
A replikálási munkafolyamat elindításakor létrejön egy üres Azure Database for PostgreSQL-kiszolgáló. Az új kiszolgáló tele van az elsődleges kiszolgálóról származó adatokkal. A létrehozási idő az elsődleges helyen található adatok mennyiségétől és a legutóbbi heti teljes biztonsági mentés óta eltelt időtől függ. Ez néhány percet vagy akár több órát is jelenthet.
A tárterület automatikus növeléséhez minden replika engedélyezve van. Az automatikus növekedés funkció lehetővé teszi, hogy a replika lépést tartson a replikált adatokkal, és megakadályozza a tárterületen kívüli hibák által okozott replikációs szünetet.
Az olvasási replika funkció a PostgreSQL fizikai replikációját használja, nem pedig a logikai replikációt. Az alapértelmezett működési mód a replikálási tárolóhelyek használatával történő folyamatos replikáció. Szükség esetén a rendszer naplóátvitelt használ a felzárkózáshoz.
További információ az olvasási replikák Azure Portalon történő létrehozásáról.
Ha a forrás PostgreSQL-kiszolgáló ügyfél által kezelt kulcsokkal van titkosítva, tekintse meg a dokumentációt a további szempontokért.
Csatlakozás a replikához
Replika létrehozásakor az nem örökli az elsődleges kiszolgáló tűzfalszabályait vagy VNet-szolgáltatásvégpontját. Ezeket a szabályokat külön be kell állítani a replika esetében.
A replika örökli a rendszergazdai fiókot az elsődleges kiszolgálótól. Az elsődleges kiszolgálón lévő összes felhasználói fiók replikálva lesz az olvasási replikákra. Az olvasási replikákhoz csak az elsődleges kiszolgálón elérhető felhasználói fiókok használatával lehet csatlakozni.
A replikához a gazdagépnév és egy érvényes felhasználói fiók használatával csatlakozhat, ahogyan egy normál Azure Database for PostgreSQL-kiszolgálón tenné. A myadmin rendszergazdai felhasználónévvel rendelkező replikám nevű kiszolgáló esetében a psql használatával csatlakozhat a replikához:
psql -h myreplica.postgres.database.azure.com -U myadmin@myreplica -d postgres
Amikor a rendszer kéri, adja meg a felhasználói fiók jelszavát.
Replikálás figyelése
Az Azure Database for PostgreSQL két metrikát biztosít a replikáció monitorozásához. A két metrika a replikák közötti maximális késés és a replika késése. A metrikák megtekintésének módjáról az olvasási replika útmutatójának replikafigyelési szakaszában olvashat.
A Replikák közötti maximális késés metrika az elsődleges és a legelmaradásosabb replika közötti bájtban mért késést mutatja. Ez a metrika csak az elsődleges kiszolgálón alkalmazható és érhető el, és csak akkor lesz elérhető, ha az olvasási replika legalább egy része csatlakozik az elsődlegeshez, és az elsődleges streamelési replikációs módban van. A késési információk nem jelenítik meg a részleteket, ha a replika folyamatban van az elsődlegeshez való felzárkózáshoz az elsődleges archivált naplóinak használatával fájlküldéses replikációs módban.
A Replika késése metrika az utolsó újrajátszott tranzakció óta eltelt időt jeleníti meg. Ha nem történik tranzakció az elsődleges kiszolgálón, a metrika ezt az időelmaradást tükrözi. Ez a metrika csak replikakiszolgálók esetében alkalmazható és érhető el. A replika késésének kiszámítása a pg_stat_wal_receiver nézetből történik:
SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());
Állítson be egy riasztást, amely tájékoztatja, ha a replika késése elér egy olyan értéket, amely nem elfogadható a számítási feladat számára.
További információkért közvetlenül az elsődleges kiszolgáló lekérdezésével kérje le a replikáció késését bájtban az összes replikán.
Feljegyzés
Ha egy elsődleges kiszolgáló vagy olvasási replika újraindul, az újraindításhoz és a felzárkózáshoz szükséges idő a replika késési metrikájában jelenik meg.
Replikáció leállítása / Replika előléptetése
Az elsődleges kiszolgáló és a replika közötti replikációt bármikor leállíthatja. A leállítási művelet hatására a replika újraindul, és előlépteti a replikát egy független, önálló írásvédett kiszolgálóként. A különálló kiszolgálón azok az adatok találhatók, amelyek a replikáció leállításakor rendelkezésre álltak a replikakiszolgálón. Az elsődleges rendszer nem propagálja a későbbi frissítéseket a replikára. Előfordulhat azonban, hogy a replikakiszolgáló még nem alkalmazott naplókat halmozott fel. Az újraindítási folyamat részeként a replika az összes függőben lévő naplót alkalmazza az ügyfélkapcsolatok elfogadása előtt.
Feljegyzés
A rendszergazdai jelszó visszaállítása a replikakiszolgálón jelenleg nem támogatott. Emellett a rendszergazdai jelszó frissítése és az ugyanabban a kérelemben szereplő replikaművelet előléptetése szintén nem támogatott. Ha ezt meg szeretné tenni, először elő kell léptetnie a replikakiszolgálót, majd külön kell frissítenie a jelszót az újonnan előléptetett kiszolgálón.
Megfontolások
- Mielőtt leállítja a replikációt egy olvasási replikán, ellenőrizze a replikáció késését, hogy a replika rendelkezik-e a szükséges adatokkal.
- Mivel az olvasási replikának minden függőben lévő naplót alkalmaznia kell ahhoz, hogy önálló kiszolgálóvá lehessen tenni, az RTO magasabb lehet a nagy számítási feladatok írásához, amikor a replikáció leállítása történik, mivel a replika jelentős késéssel járhat. A replika előléptetésének tervezésekor ügyeljen erre.
- Az előléptetett replikakiszolgáló nem készíthető újra replikává.
- Ha előléptet egy replikát elsődleges kiszolgálóként, nem állíthatja vissza a replikációt a régi elsődleges kiszolgálóra. Ha vissza szeretne lépni a korábbi elsődleges régióba, létrehozhat egy új replikakiszolgálót új néven (vagy) törölheti a régi elsődleges példányt, és létrehozhat egy replikát a régi elsődleges névvel.
- Ha több olvasási replika létezik, és az egyiket elsődleges kiszolgálóként lépteti elő, a többi replikakiszolgáló továbbra is a régi elsődleges kiszolgálóhoz csatlakozik. Előfordulhat, hogy újra létre kell hoznia a replikákat az új, előléptetett kiszolgálóról.
A replikáció leállításakor a replika elveszíti a korábbi elsődleges és egyéb replikákra mutató összes hivatkozást.
Megtudhatja, hogyan állíthatja le a replikára történő replikációt.
Feladatátvétel replikára
Elsődleges kiszolgáló meghibásodása esetén a rendszer nem iktatott át automatikusan az olvasási replikára.
Mivel a replikáció aszinkron, jelentős eltérés lehet az elsődleges és a replika között. A késés mértékét számos tényező befolyásolja, például az elsődleges kiszolgálón futó számítási feladatok típusa, valamint az elsődleges és a replikakiszolgáló közötti késés. A névleges írási számítási feladattal rendelkező tipikus esetekben a replika késése néhány másodperc és néhány perc között várható. Azokban az esetekben azonban, amikor az elsődleges nagy írási igényű számítási feladatot futtat, és a replika nem tud elég gyorsan felzárkózni, a késés sokkal magasabb lehet. Az egyes replikák replikációs késését a metrikareplika késésével követheti nyomon. Ez a metrika a replika utolsó újrajátszott tranzakciója óta eltelt időt mutatja. Javasoljuk, hogy a replika késésének megfigyelésével azonosítsa az átlagos késést. Beállíthatja a replika késésére vonatkozó riasztást, hogy ha az túllépi a várt tartományt, értesítést kap a művelet végrehajtásáról.
Tipp.
Ha feladatátvételt végzett a replikára, a replika elsődlegesről való leválasztásának késése jelzi, hogy mennyi adat veszett el.
Miután eldöntötte, hogy feladatátvételt szeretne végrehajtani egy replikára,
Replikáció leállítása a replikára
Ez a lépés szükséges ahhoz, hogy a replikakiszolgáló önálló kiszolgálóvá váljon, és képes legyen írásokat fogadni. Ennek a folyamatnak a részeként a replikakiszolgáló újraindul, és leválasztja az elsődleges kiszolgálóról. A replikáció leállítása után a háttérfolyamat általában néhány percet vesz igénybe a még nem alkalmazott reziduális naplók alkalmazásához, és az adatbázis írásvédett kiszolgálóként való megnyitásához. A művelet következményeinek megismeréséhez tekintse meg a cikk replikációs leállítása című szakaszát.Az alkalmazás rámutatása a (korábbi) replikára
Minden kiszolgáló egyedi kapcsolati sztring rendelkezik. Frissítse az alkalmazás kapcsolati sztring, hogy az elsődleges helyett a (korábbi) replikára mutasson.
Miután az alkalmazás sikeresen feldolgozta az olvasásokat és írásokat, elvégezte a feladatátvételt. Az alkalmazás által tapasztalt állásidő mértéke attól függ, hogy mikor észleli a problémát, és végrehajtja a fenti 1. és 2. lépést.
Vészhelyreállítás
Ha olyan súlyos katasztrófaesemények lépnek fel, mint a rendelkezésre állási zóna szintje vagy a regionális hibák, az olvasási replika előléptetésével vészhelyreállítási műveletet hajthat végre. A felhasználói felület portálján navigálhat az olvasási replikakiszolgálóhoz. Ezután válassza a replikáció lapot, és leállíthatja a replikát, hogy független kiszolgálóként előléptesse. Másik lehetőségként az Azure CLI használatával leállíthatja és előléptetheti a replikakiszolgálót.
Megfontolások
Ez a szakasz az olvasási replika funkcióval kapcsolatos szempontokat foglalja össze.
Előfeltételek
Az olvasási replikák és a logikai dekódolás is a Postgres előre írási naplójától (WAL) függ. Ez a két funkció különböző naplózási szinteket igényel a Postgrestől. A logikai dekódoláshoz magasabb szintű naplózásra van szükség, mint az olvasási replikák.
A naplózás megfelelő szintjének konfigurálásához használja az Azure replikációs támogatási paraméterét. Az Azure replikációs támogatása három beállítási lehetőséggel rendelkezik:
- Kikapcsolva – A lehető legkevesebb információt helyezi el a WAL-ban. Ez a beállítás a legtöbb Azure Database for PostgreSQL-kiszolgálón nem érhető el.
- Replika – Részletesebb, mint kikapcsolva. Ez az olvasási replikák működéséhez szükséges minimális naplózási szint. Ez a beállítás a legtöbb kiszolgálón az alapértelmezett beállítás.
- Logikai – Részletesebb, mint a replika. Ez a logikai dekódolás működésének minimális naplózási szintje. Ebben a beállításban az olvasási replikák is működnek.
Új replikák
Az olvasási replika új Azure Database for PostgreSQL-kiszolgálóként jön létre. Egy meglévő kiszolgáló nem készíthető replikává. Egy másik olvasási replika replikája nem hozható létre.
Replika konfigurálása
A replika ugyanazokkal a számítási és tárolási beállításokkal jön létre, mint az elsődleges. A replika létrehozása után több beállítás is módosítható, beleértve a tárolási és biztonsági mentési megőrzési időtartamot.
A tűzfalszabályok, a virtuális hálózati szabályok és a paraméterbeállítások nem örökölhetők az elsődleges kiszolgálóról a replikára a replika létrehozásakor vagy után.
Méretezés
Virtuális magok skálázása vagy az általános célú és a memóriaoptimalizált között:
- A PostgreSQL megköveteli, hogy egy másodlagos kiszolgálón a
max_connectionsbeállítás nagyobb vagy egyenlő legyen , mint az elsődleges, ellenkező esetben a másodlagos nem indul el. - Az Azure Database for PostgreSQL-ben az egyes kiszolgálók maximálisan engedélyezett kapcsolatai a számítási termékváltozathoz lesznek rögzítve, mivel a kapcsolatok memóriát foglalnak el. További információ a max_connections és a számítási termékváltozatok közötti leképezésről.
- Vertikális felskálázás: Először skálázza fel a replika számítását, majd skálázza fel az elsődlegeset. Ez a megrendelés megakadályozza, hogy a hibák megsérthessék a követelményt
max_connections. - Leskálázás: Először skálázza le az elsődleges számítást, majd skálázza le a replikát. Ha a replikát az elsődlegesnél alacsonyabbra próbálja méretezni, hiba történik, mivel ez sérti a követelményt
max_connections.
Tároló skálázása:
- Minden replika automatikusan bővíti a tárterületet, hogy megakadályozza a tárterülettel rendelkező replikák replikációs problémáit. Ez a beállítás nem tiltható le.
- Manuálisan is felskálázhatja a tárterületet, ahogyan azt bármely más kiszolgálón tenné.
Alapszint
Az alapszintű kiszolgálók csak az azonos régiós replikációt támogatják.
max_prepared_transactions
A PostgreSQL megköveteli , hogy az max_prepared_transactions olvasási replikán lévő paraméter értéke nagyobb vagy egyenlő legyen az elsődleges értékkel, ellenkező esetben a replika nem indul el. Ha módosítani max_prepared_transactions szeretné az elsődleges példányt, először módosítsa a replikákon.
Leállított replikák
Ha leállítja a replikációt egy elsődleges kiszolgáló és egy olvasási replika között, a replika újraindul a módosítás alkalmazásához. A leállított replika önálló kiszolgálóvá válik, amely olvasási és írási műveleteket is elfogad. Az önálló kiszolgáló nem készíthető újra replikává.
Elsődleges és önálló kiszolgálók törlése
Az elsődleges kiszolgáló törlésekor az összes olvasási replika önálló kiszolgálóvá válik. A replikák újraindulnak, hogy tükrözzék ezt a változást.