Megosztás a következőn keresztül:

Olvasási replikák az Azure Database for PostgreSQL-kiszolgálón – Rugalmas kiszolgáló

  • Cikk

A következőkre vonatkozik: Azure Database for PostgreSQL – Rugalmas kiszolgáló

Az olvasási replika funkcióval adatokat replikálhat egy rugalmas Azure Database for PostgreSQL-kiszolgálópéldányról egy írásvédett replikára. A replikák aszinkron módon frissülnek a PostgreSQL-motor natív fizikai replikációs technológiájával. 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 fájlalapú naplószállítást használ a felzárkózáshoz. Az elsődleges kiszolgálóról legfeljebb öt replikára replikálhat.

A replikák olyan új kiszolgálók, amelyeket a rugalmas Azure Database for PostgreSQL-példányokhoz hasonlóan kezel. 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 írásvédett kiszolgálóra.

Egy tipikus forgatókönyv az, hogy a BI és az 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

Az olvasási replikákat elsősorban olyan helyzetekhez tervezték, ahol a lekérdezések kiszervezése előnyös, és egy kis késés kezelhető. Úgy vannak optimalizálva, hogy közel valós idejű frissítéseket biztosítsanak az elsődlegestől a legtöbb számítási feladathoz, így kiváló megoldást nyújtanak az írásvédett forgatókönyvekhez. Fontos azonban megjegyezni, hogy ezek nem szinkron replikációs forgatókönyvekhez készültek, amelyek akár percekig is pontos adatokat igényelnek. Bár a replikán lévő adatok végül konzisztenssé válnak az elsődlegessel, előfordulhat, hogy a késés általában néhány másodperctől percig tart, és néhány nagy számítási feladat vagy nagy késés esetén ez a késés órákig is tarthat. Az olvasási replikák általában az elsődleges régióban kisebb késéssel bírnak, mint a georeplikák, mivel az utóbbiak gyakran a földrajzi távolság által okozott késéssel foglalkoznak. A georeplikáció teljesítménykövetkezményeit a georeplikációval kapcsolatos további információkért tekintse meg a georeplikációról szóló cikkben. 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ó, nagy írási igényű elsődleges számítási feladatoknál azonban a replikáció késése tovább nőhet, és előfordulhat, hogy csak az elsődlegessel tud felzárkózni. Ez növelheti a tárterület használatát az elsődleges helyen is, mivel a WAL-fájlok csak a replikában való beérkezés után törlődnek. Ha ez a helyzet továbbra is fennáll, az olvasási replika törlése és újratelepítése az írásigényes számítási feladatok befejezése után, a replikát visszahozhatja egy jó állapotba késésre. 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-számítási feladat ciklusának csúcsidőszakán és nem csúcsidőn keresztül, hogy felmérje 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.

Replika létrehozása

A rugalmas Azure Database for PostgreSQL-kiszolgáló elsődleges kiszolgálója bármely olyan régióban üzembe helyezhető, amely támogatja a szolgáltatást. Az elsődleges kiszolgáló replikáit létrehozhatja ugyanabban a régióban vagy különböző globális Azure-régiókban, ahol rugalmas Azure Database for PostgreSQL-kiszolgáló érhető el. A replikák létrehozásának képessége mostantól néhány speciális Azure-régióra is kiterjed. Tekintse meg a georeplikációs cikket azoknak a speciális régióknak a listájáról, ahol replikákat hozhat létre.

A replika létrehozása munkafolyamat indításakor egy üres, rugalmas Azure Database for PostgreSQL-kiszolgálópéldány jön létre. Az új kiszolgáló tele van az elsődleges kiszolgálón lévő adatokkal. A replikák ugyanabban a régióban történő létrehozásához pillanatkép-megközelítést használunk. Ezért a létrehozás időpontja független az adatok méretétől. A georeplikák az elsődleges példány alapszintű biztonsági mentésével jönnek létre, amelyet aztán a hálózaton keresztül továbbítanak; ezért a létrehozási idő perctől több óráig terjedhet az elsődleges mérettől függően.

A replika csak akkor tekinthető sikeresnek, ha két feltétel teljesül: az elsődleges példány teljes biztonsági másolatát át kell másolni a replikára, és a tranzakciónaplóknak legfeljebb 1 GB késéssel kell szinkronizálni őket.

A sikeres létrehozási művelet eléréséhez kerülje a replikák létrehozását a nagy tranzakciós terhelés idején. Például ne hozzon létre replikákat más forrásokból rugalmas Azure Database for PostgreSQL-kiszolgálóra vagy nagy terhelésű műveletek során. Ha most migrálja az adatokat, vagy nagy mennyiségű adatot tölt be, a legjobb, ha először befejezi ezt a feladatot. A befejezése után megkezdheti a replikák beállítását. Miután az áttelepítési vagy tömeges betöltési művelet befejeződött, ellenőrizze, hogy a tranzakciónapló mérete visszaállt-e a normál méretre. A tranzakciónapló méretének általában közel kell lennie a példány max_wal_size kiszolgálóparaméterében meghatározott értékhez. A tranzakciónapló tárterület-lábnyomát a tranzakciónapló használt metrikájában követheti nyomon, amely betekintést nyújt a tranzakciónapló által használt tárterület mennyiségébe. A metrika figyelésével biztosíthatja, hogy a tranzakciónapló mérete a várt tartományon belül legyen, és hogy a replikalétrehozási folyamat elindulhasson.

Fontos

Az olvasási replikák jelenleg az általános célú és memóriaoptimalizált kiszolgáló számítási szintjeihez támogatottak. A kipukkasztható kiszolgáló számítási szintje nem támogatott.

Fontos

Replikalétrehozási, törlési és előléptetési műveletek végrehajtásakor az elsődleges kiszolgáló frissítési állapotba kerül. Ez idő alatt a kiszolgálófelügyeleti műveletek, például a kiszolgálóparaméterek módosítása, a magas rendelkezésre állási beállítások módosítása vagy tűzfalak hozzáadása vagy eltávolítása nem lesznek elérhetők. Fontos megjegyezni, hogy a frissítési állapot csak a kiszolgálófelügyeleti műveleteket érinti, és nem befolyásolja az adatsík műveleteit. Ez azt jelenti, hogy az adatbázis-kiszolgáló teljes mértékben működőképes marad, és képes lesz a kapcsolatok elfogadására, valamint az olvasási és írási forgalom kiszolgálására.

További információ az olvasási replikák Azure Portalon történő létrehozásáról.

Konfigurációkezelés

A rugalmas Azure Database for PostgreSQL-kiszolgáló olvasási replikáinak beállításakor fontos megismerni a módosítható kiszolgálókonfigurációkat, az elsődlegestől örökölteket és a kapcsolódó korlátozásokat.

Örökölt konfigurációk

Olvasási replika létrehozásakor az adott kiszolgálókonfigurációkat örökli az elsődleges kiszolgálótól. Ezek a konfigurációk a replika létrehozásakor vagy a beállítás után módosíthatók. Bizonyos beállítások, például a geo-biztonsági mentés azonban nem lesznek replikálva az olvasási replikára.

Konfigurációk replika létrehozásakor

  • Réteg, tárterület mérete: Az "előléptetés elsődleges kiszolgálóra" műveletnél meg kell egyeznie az elsődlegesével. A "független kiszolgálóra való előléptetés és a replikációból való eltávolítás" művelet esetében ez lehet ugyanaz vagy magasabb, mint az elsődleges.
  • Teljesítményszint (IOPS): Állítható.
  • Adattitkosítás: Állítható, például a szolgáltatás által felügyelt kulcsról az ügyfél által felügyelt kulcsra való áttérés.

Konfigurációk a létrehozás után

  • Tűzfalszabályok: Hozzáadhatók, törölhetők vagy módosíthatók.
  • Réteg, tárterület mérete: Az "előléptetés elsődleges kiszolgálóra" műveletnél meg kell egyeznie az elsődlegesével. A "független kiszolgálóra való előléptetés és a replikációból való eltávolítás" művelet esetében ez lehet ugyanaz vagy magasabb, mint az elsődleges.
  • Teljesítményszint (IOPS): Állítható.
  • Hitelesítési módszer: Állítható, a lehetőségek közé tartozik a PostgreSQL-hitelesítésről a Microsoft Entra-ra váltás.
  • Kiszolgálóparaméterek: A legtöbb állítható. A megosztott memória méretét befolyásolóknak azonban igazodniuk kell az elsődlegeshez, különösen a potenciális "előléptetés az elsődleges kiszolgálóra" forgatókönyvekhez. A "független kiszolgálóra való előléptetés és a replikációból való eltávolítás" művelet esetében ezeknek a paramétereknek meg kell egyezniük, vagy meg kell haladnia az elsődlegesen lévőket.
  • Karbantartási ütemezés: Állítható.

Nem támogatott funkciók olvasási replikákon

Bizonyos funkciók elsődleges kiszolgálókra korlátozódnak, és nem állíthatók be olvasási replikákon. Ezek közé tartoznak:

  • Biztonsági másolatok, beleértve a geo-biztonsági mentéseket is.
  • Magas rendelkezésre állás (HA)

Ha a rugalmas Azure Database for PostgreSQL-kiszolgálópéldány ügyfél által felügyelt kulcsokkal van titkosítva, további szempontokat a dokumentációban talál.

Csatlakozás a replikához

Replika létrehozásakor az örökli az elsődleges kiszolgáló tűzfalszabályait vagy virtuális hálózati szolgáltatásvégpontját. Ezek a szabályok a replika létrehozásakor és bármely későbbi időpontban módosíthatók.

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. Csak az elsődleges kiszolgálón elérhető felhasználói fiókok használatával csatlakozhat olvasási replikához.

A replikához kétféleképpen lehet csatlakozni:

  • Közvetlenül a replikapéldányhoz: A replikához a gazdagépnév és egy érvényes felhasználói fiók használatával csatlakozhat, ahogyan egy rugalmas Azure Database for PostgreSQL-kiszolgálópéldányon tenné. A myreplica nevű kiszolgálóhoz a myadmin rendszergazdai felhasználónévvel csatlakozhat a replikához a következő használatávalpsql:
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

Amikor a rendszer kéri, adja meg a felhasználói fiók jelszavát.

Emellett a kapcsolati folyamat megkönnyítése érdekében az Azure Portal használatra kész kapcsolati sztring biztosít. Ezek a Csatlakozás lapon találhatók. Ezek a bash-konzolokhoz szabott változókat és kapcsolati sztring is libpq magukban foglalják.

  • Virtuális végpontokon keresztül: Létezik egy alternatív kapcsolati módszer, amely virtuális végpontokat használ, a Virtuális végpontok című cikkben leírtak szerint. A virtuális végpontok használatával konfigurálhatja a csak olvasható végpontot úgy, hogy következetesen a replikára mutasson, függetlenül attól, hogy jelenleg melyik kiszolgáló rendelkezik a replikaszerepkörrel.

Replikálás figyelése

A rugalmas Azure Database for PostgreSQL-kiszolgáló olvasási replika funkciója a replikációs pontok mechanizmusára támaszkodik. A replikációs pontok fő előnye, hogy automatikusan módosítják az összes replikakiszolgáló által igényelt tranzakciónaplók (WAL-szegmensek) számát. Ez segít megakadályozni a replikák szinkronizálásának kiesését, mert így elkerülhető a WAL-szegmensek törlése az elsődlegesen, mielőtt elküldené őket a replikáknak. A megközelítés hátránya, hogy fennáll a veszélye annak, hogy a replikációs pont hosszabb ideig inaktív marad az elsődleges helyen. Ilyen esetekben az elsődleges wal-fájlok halmozódnak fel, ami a tárterület használatának növekményes növekedését okozza. Ha a tárterület kihasználtsága eléri a 95%-ot, vagy ha a rendelkezésre álló kapacitás kisebb, mint 5 GiB, a kiszolgáló automatikusan írásvédett üzemmódra vált, hogy elkerülje a lemezes helyzetekhez kapcsolódó hibákat.
Ezért a replikáció késésének és a replikációs pontok állapotának monitorozása kulcsfontosságú az olvasási replikák esetében.

Javasoljuk, hogy állítsa be a riasztási szabályokat a felhasznált tárterületre vagy a tárterület százalékos arányára, valamint a replikációs késésekre, ha túllépnek bizonyos küszöbértékeket, hogy proaktív módon cselekedhessen, növelje a tárterület méretét, és törölje a lemaradásban lévő olvasási replikákat. Beállíthat például egy riasztást, ha a tárterület százalékos kihasználtsága meghaladja a 80%-ot, és ha a replika késése meghaladja az 5 percet. A tranzakciónapló-tároló használt metrikája megmutatja, hogy a WAL-fájlok felhalmozódása a túlzott tárterület-használat fő oka-e.

A rugalmas Azure Database for PostgreSQL-kiszolgáló két metrikát biztosít a replikáció monitorozásához. A két metrika a maximális fizikai replikációs késés és az olvasási 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 maximális fizikai replikációs késés metrika az elsődleges és a legelmaradásban lévő 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 replikák közül legalább egy csatlakozik az elsődlegeshez. A késési információ akkor is jelen van, ha a replika éppen az elsődleges, a replika létrehozása vagy inaktívvá válása során van folyamatban.

Az Olvasási replika késése metrika az utolsó újrajátszott tranzakció óta eltelt időt jeleníti meg. Ha például nem történik tranzakció az elsődleges kiszolgálón, és az utolsó tranzakciót 5 másodperccel ezelőtt játszották vissza, akkor az olvasási replika késése 5 másodperces késést mutat. Ez a metrika alkalmazható, és csak replikákon érhető el.

Á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ót kérdezheti le, hogy lekérje az összes replika replikációs késését.

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ó állapota

A replikáció előrehaladásának és állapotának figyeléséhez és a művelet előléptetéséhez tekintse meg az Azure Portal Replikációs állapot oszlopát. Ez az oszlop a replikációs lapon található, és különböző állapotokat jelenít meg, amelyek betekintést nyújtanak az olvasási replikák aktuális állapotába és az elsődlegesre mutató hivatkozásukba. Az Azure Resource Manager API-ra támaszkodó felhasználók esetében az API meghívásakor az GetReplica állapot replikációs állapotként jelenik meg a replica tulajdonságcsomagban.

A lehetséges értékek a következők:

Replikáció állapota Leírás Előléptetési sorrend Replika létrehozási sorrendjének olvasása
Átkonfigurálását A replika elsődleges kapcsolatának kezdetére vár. Hosszabb ideig is eltarthat, ha a replika vagy régiója nem érhető el, például katasztrófa miatt. 0 n/a
Kiépítés Az olvasási replika ki van építve, és a két kiszolgáló közötti replikáció még nem kezdődött el. Amíg a kiépítés befejeződik, nem tud csatlakozni az olvasási replikához. n/a 0
Frissítése A kiszolgálókonfiguráció előkészítése folyamatban van egy aktivált művelet, például az előléptetés vagy az olvasási replika létrehozása után. 2 2
Felzárkózás WAL-fájlokat alkalmazunk a replikára. A fázis időtartama az előléptetés során a választott adatszinkronizálási lehetőségtől függ – tervezett vagy kényszerített. 3 3
Aktív Kifogástalan állapot, amely azt jelzi, hogy az olvasási replika sikeresen csatlakozott az elsődlegeshez. Ha a kiszolgálók le vannak állítva, de korábban sikeresen csatlakoztak, az állapot aktív marad. 4 4
Törött Nem kifogástalan állapot, amely azt jelzi, hogy az előléptetési művelet meghiúsult, vagy a replika valamilyen okból nem tud csatlakozni az elsődlegeshez. A probléma megoldásához vesse el a replikát, és hozza létre újra a replikát." N.A. N.A.

Megtudhatja, hogyan figyelheti a replikációt.

Megfontolások

Ez a szakasz az olvasási replika funkcióval kapcsolatos szempontokat foglalja össze. A következő szempontok érvényesek.

  • Energiaműveletek: Az energiaműveletek, beleértve az indítási és leállítási műveleteket is, az elsődleges és a replikakiszolgálóra egyaránt alkalmazhatók. A rendszer integritásának megőrzése érdekében azonban egy adott sorrendet kell követni. Az olvasási replikák leállítása előtt győződjön meg arról, hogy az elsődleges kiszolgáló le van állítva. A műveletek megkezdésekor indítsa el a műveletet a replikakiszolgálókon az elsődleges kiszolgáló elindítása előtt.
  • Ha a kiszolgáló olvasási replikákkal rendelkezik, akkor az elsődleges kiszolgáló törlése előtt törölni kell az olvasási replikákat.
  • A rugalmas Azure Database for PostgreSQL-kiszolgálón a főverzió helyben történő frissítéséhez el kell távolítania a kiszolgálón jelenleg engedélyezett olvasási replikákat. A replikák törlése után az elsődleges kiszolgáló frissíthető a kívánt főverzióra. A frissítés befejezése után újra létrehozhatja a replikákat a replikációs folyamat folytatásához.
  • Prémium SSD v2: Az aktuális kiadástól számítva, ha az elsődleges kiszolgáló Prémium SSD v2-t használ a tároláshoz, az olvasási replikák létrehozása nem támogatott.
  • Rendszergazdai jelszó alaphelyzetbe állítása: A rendszergazdai jelszó visszaállítása a replikakiszolgálón jelenleg nem támogatott. Emellett a rendszergazdai jelszó frissítése és a replikaművelet előmozdítása ugyanabban a kérésben 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.

Új replikák

Az olvasási replika új rugalmas Azure Database for PostgreSQL-kiszolgálópéldányké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, vagyis a kaszkádolt replikáció nem támogatott.

Erőforrás áthelyezése

A felhasználók az elsődleges erőforráscsoporttól eltérő erőforráscsoportban hozhatnak létre olvasási replikákat. Az olvasási replikák áthelyezése azonban egy másik erőforráscsoportba a létrehozásuk után nem támogatott. Ezenkívül a replikák áthelyezése egy másik előfizetésbe, és az olvasási replikákat tartalmazó elsődleges példány áthelyezése egy másik erőforráscsoportba vagy előfizetésbe nem támogatott.

Automatikus tárolás

Ha olvasási replikákat konfigurál egy rugalmas Azure Database for PostgreSQL-kiszolgálópéldányhoz, elengedhetetlen annak biztosítása, hogy a replikákon a tárterület automatikus feltöltési beállítása megegyezik az elsődleges kiszolgálóéval. A tárolási automatikus kapacitás funkció lehetővé teszi az adatbázis-tároló automatikus növelését, hogy megakadályozza a szabad terület elfogyását, ami adatbáziskimaradásokhoz vezethet. Az alábbiakban bemutatjuk, hogyan kezelheti hatékonyan a tárolási automatikus kapacitás beállításait:

  • Az elsődleges kiszolgáló beállításától függetlenül bármely replikán engedélyezhető a tárterület automatikus kapacitása.
  • Ha a tárterület automatikus feltöltése engedélyezve van az elsődleges kiszolgálón, akkor azt a replikákon is engedélyezni kell a tárolóméretezési viselkedés konzisztenciájának biztosításához.
  • Ha engedélyezni szeretné a tárterület automatikus használatát az elsődlegesen, először engedélyeznie kell azt a replikákon. Ez a műveleti sorrend elengedhetetlen a replikáció integritásának fenntartásához.
  • Ezzel szemben, ha le szeretné tiltani a tárterület automatikus elszaporodását, először tiltsa le az elsődleges kiszolgálón a replikák előtt, hogy elkerülje a replikációs bonyodalmakat.

Biztonsági mentés és visszaállítás

A rugalmas Azure Database for PostgreSQL-kiszolgálópéldány biztonsági mentéseinek és visszaállításának kezelésekor fontos szem előtt tartani a kiszolgáló jelenlegi és korábbi szerepét a különböző előléptetési forgatókönyvekben. Az alábbiakban a legfontosabb tudnivalókat kell megjegyezni:

Előléptetés elsődleges kiszolgálóra

  1. A rendszer nem készít biztonsági másolatot az olvasási replikákról: A biztonsági másolatokat a rendszer soha nem készíti el az olvasási replikakiszolgálókról, függetlenül a korábbi szerepkörüktől.

  2. A korábbi biztonsági másolatok megőrzése: Ha egy kiszolgáló egykor elsődleges volt, és az adott időszakban biztonsági másolatokat készített, a biztonsági másolatok megmaradnak. A rendszer a felhasználó által meghatározott megőrzési időszakig megőrzi őket.

  3. Visszaállítási műveletek korlátozásai: Még ha korábbi biztonsági másolatok is léteznek egy olvasási replikára áttért kiszolgálóhoz, a visszaállítási műveletek korlátozottak. Visszaállítási műveletet csak akkor kezdeményezhet, ha a kiszolgáló előléptetett az elsődleges szerepkörre.

Az egyértelműség kedvéért íme egy táblázat, amely az alábbi pontokat szemlélteti:

Kiszolgálói szerepkör Biztonsági mentés készült Visszaállítás engedélyezett
Elsődleges Igen Igen
Replika olvasása Nem Nem
Elsődlegesre előléptetett olvasási replika Igen Igen

Előléptetés független kiszolgálóra, és eltávolítás a replikációból

Bár a kiszolgáló olvasási replika, a rendszer nem készít biztonsági másolatot. Ha azonban előléptetik egy független kiszolgálóra, az előléptetett kiszolgáló és az elsődleges kiszolgáló is készít biztonsági másolatot, és mindkét kiszolgálón engedélyezve van a visszaállítás.

Hálózat

Az olvasási replikák támogatják a rugalmas Azure Database for PostgreSQL-kiszolgáló által támogatott összes hálózati lehetőséget.

Fontos

Az elsődleges kiszolgáló és az olvasási replikák közötti kétirányú kommunikáció elengedhetetlen az Azure Database for PostgreSQL rugalmas kiszolgálóbeállításához. Rendelkeznie kell egy olyan kiépítéssel, amely forgalmat küld és fogad az 5432-s célporton az Azure-beli virtuális hálózati alhálózaton belül.

A fenti követelmény nemcsak a szinkronizálási folyamatot segíti elő, hanem biztosítja az előléptetési mechanizmus megfelelő működését is, ahol a replikáknak fordított sorrendben kell kommunikálniuk – replikáról elsődlegesre – különösen az elsődleges műveletekre való előléptetés során. Ezenkívül engedélyezni kell a Write-Ahead Logging (WAL) archívumokat tároló Azure Storage-fiókhoz való csatlakozást az adatok tartósságának megőrzéséhez és a hatékony helyreállítási folyamatok engedélyezéséhez.

A privát hozzáférés (virtuális hálózati integráció) olvasási replikákhoz való konfigurálásáról és a magánhálózati környezeten belüli Azure-régiók és virtuális hálózatok közötti replikáció következményeinek megismeréséről az Azure-régiók közötti replikációról és a privát hálózatkezeléssel rendelkező virtuális hálózatokról szóló oldalon talál további információt.

Replikációs ponttal kapcsolatos problémák elhárítása

Ritkán a replikációs pontok által okozott nagy késés az elsődleges kiszolgálón a felhalmozott WAL-fájlok miatt megnövekedett tárterület-használathoz vezethet. Ha a tárterület kihasználtsága eléri a 95%-ot, vagy a rendelkezésre álló kapacitás 5 GiB alá csökken, a kiszolgáló automatikusan írásvédett üzemmódra vált a lemez teljes hibáinak elkerülése érdekében.

Mivel az elsődleges kiszolgáló állapotának és működésének fenntartása prioritást élvez, ilyen peremhálózati esetekben a replikációs pont elvethető, hogy az elsődleges kiszolgáló továbbra is működőképes maradjon az olvasási és írási forgalom számára. A replikáció tehát fájlalapú naplószállítási módra vált, ami nagyobb replikációs késést eredményezhet.

Elengedhetetlen, hogy a tárterület kihasználtsága és a replikáció késése szorosan monitorozható legyen, és az eszkalálás előtt meg kell tenni a szükséges lépéseket a lehetséges problémák megoldásához.

Kiszolgálóparaméterek

Olvasási replika létrehozásakor örökli a kiszolgáló paramétereit az elsődleges kiszolgálótól. Ennek célja, hogy egységes és megbízható kiindulópontot biztosítson. Az olvasási replika létrehozása után végrehajtott kiszolgálóparaméterek azonban nem replikálódnak automatikusan. Ez a viselkedés az olvasási replika egyéni finomhangolásának előnyeit kínálja, például növeli az olvasásigényes műveletek teljesítményét az elsődleges kiszolgáló paramétereinek módosítása nélkül. Bár ez rugalmasságot és testreszabási lehetőségeket biztosít, gondos és manuális felügyeletet is igényel az elsődleges és a replika közötti konzisztencia fenntartásához, ha a kiszolgálóparaméterek egységessége szükséges.

Rendszergazda istratorok módosíthatják az olvasási replikakiszolgáló kiszolgálóparamétereit, és más értékeket állíthatnak be, mint az elsődleges kiszolgálón. Az egyetlen kivétel azok a paraméterek, amelyek hatással lehetnek a replika helyreállítására, amelyeket az alábbi "Méretezés" szakaszban is megemlítünk: , , , , max_worker_processesmax_wal_senders. max_locks_per_transactionmax_prepared_transactionsmax_connections Annak érdekében, hogy az olvasási replika helyreállítása zökkenőmentes legyen, és ne ütközhessen megosztott memóriakorlátozásokkal, ezeket a paramétereket mindig olyan értékekre kell beállítani, amelyek egyenértékűek vagy nagyobbak az elsődleges kiszolgálón konfigurált értékekkel.

Hangsor

Ingyenesen fel- és leskálázhatja a számításokat (virtuális magokat), módosíthatja a szolgáltatási szintet általános célúról memóriaoptimalizáltra (vagy fordítva), és felskálázhatja a tárterületet, de az alábbi kikötések érvényesek.

Számítási skálázáshoz:

  • A rugalmas Azure Database for PostgreSQL-kiszolgálóhoz a replikák több paraméterének nagyobbnak vagy egyenlőnek kell lennie az elsődleges beállításnál, hogy a replika ne fogyjon ki a megosztott memóriából a helyreállítás során. Az érintett paraméterek a következők: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders. max_worker_processes

  • 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.

  • 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.

  • Az elsődleges számításnak mindig egyenlőnek vagy kisebbnek kell lennie, mint a legkisebb replika számítása.

Tárolóméretezéshez:

  • Vertikális felskálázás: Először skálázza fel a replika tárterületét, majd skálázza fel az elsődlegest.

  • Az elsődleges tárterület méretének mindig egyenlőnek vagy kisebbnek kell lennie, mint a legkisebb replika tárhelymérete.

Kapcsolódó tartalom