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


Rugalmas skálázású másodlagos replikák

A következőkre vonatkozik:Azure SQL Database

Az Elosztott függvények architektúrájában leírtak szerint az Azure SQL Database Rugalmas skálázás két különböző számítási csomóponttípussal rendelkezik, más néven replikákkal:

A másodlagos replikák mindig írásvédettek, és három különböző típus lehetnek:

  • Magas rendelkezésre állású replika
  • Georeplika
  • Megnevezett replika

Mindegyik típus eltérő architektúrával, funkciókészlettel, céllal és költséggel rendelkezik. A szükséges funkciók alapján egyszerre csak egyet vagy akár mindet használhatja. Másodlagos replikákat kiszolgáló nélküli vagy kiépített számítási szintekkel is használhat.

A Hyperscale névvel ellátott replikák konfigurálásával és kezelésével kapcsolatos oktatóanyagokért lásd a részleteket az oktatóanyagokban:

Magas rendelkezésre állású replika

A magas rendelkezésre állású (HA) replika ugyanazokat a lapkiszolgálókat használja, mint az elsődleges replika, ezért a HA-replika hozzáadásához nincs szükség adatmásolásra. A HA-replikák az adatbázisok rendelkezésre állásának növelésére szolgálnak; feladatátvételi célokra gyakori készenléti replikaként működnek. Ha az elsődleges replika elérhetetlenné válik, az egyik meglévő HA-replikára történő feladatátvétel automatikus és gyors. A csatlakozási sztringet nem kell módosítani; az átállás során az alkalmazások minimális állásidőt tapasztalhatnak az aktív kapcsolatok megszakadása miatt. Ebben a forgatókönyvben szokásos módon ajánlott a megfelelő újrapróbálkozás logikája. Több illesztőprogram már bizonyos fokú automatikus újrapróbálkozás-logikát biztosít. Ha .NET-et használ, a legújabb Microsoft.Data.SqlClient kódtár natív támogatást nyújt a konfigurálható automatikus újrapróbálkozási logikához.

A HA-replikák ugyanazt a kiszolgáló- és adatbázisnevet használják, mint az elsődleges replika. A szolgáltatásiszint-célkitűzés (SLO) is mindig ugyanaz, mint az elsődleges replika esetében. A HA-replikák nem láthatók és nem kezelhetők önálló erőforrásokként, a portálról vagy bármely API-ból. A számlázásuk az elsődleges replikával megegyező számítási sebességgel történik, de a tárolási költségek nem vonatkoznak a másodlagos replikákra.

Nulla és négy közötti HA replika lehet. Az új adatbázis létrehozásakor megadhatja a számreplikákat, vagy frissítheti egy meglévő adatbázis replikáinak számát. A HA-replikák számának megadásához használhatja a gyakori felügyeleti végpontokat és eszközöket (például: Azure PowerShell, Azure CLI, Azure Portal, REST API). A HA-replikák létrehozása és eltávolítása nem befolyásolja az elsődleges replika aktív kapcsolatait.

Csatlakozás HA-replikához

Hyperscale adatbázisokban az ApplicationIntent ügyfél által használt kapcsolati sztring argumentuma határozza meg, hogy a kapcsolat az olvasási és írási műveleteket támogató elsődleges replikához, vagy egy olvasásra optimalizált, nagy rendelkezésre állású replikához van-e irányítva. Ha ApplicationIntent be van állítva ReadOnly , és az adatbázis nem rendelkezik másodlagos replikával, a kapcsolat az elsődleges replikához lesz irányítva, és alapértelmezés szerint a ReadWrite viselkedéshez lesz irányítva.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<password>;Trusted_Connection=False; Encrypt=True;

Minden HA-replika azonos az erőforrás-kapacitásukban. Ha egynél több HA-replika van jelen, az olvasási szándékú számítási feladat tetszőlegesen oszlik el az összes rendelkezésre álló HA-replika között. Ha több HA-replika is létezik, vegye figyelembe, hogy mindegyik adatkésés eltérő lehet az elsődlegesen végrehajtott adatmódosítások tekintetében. Minden HA-replika ugyanazokat az adatokat használja, mint az elsődleges, ugyanazon lapkiszolgálókon. Az egyes HA-replikák helyi adatgyorsítótárai azonban tükrözik az elsődlegesen a tranzakciónapló-szolgáltatáson keresztül végrehajtott módosításokat, amelyek az elsődleges replikából a HA-replikákra továbbítják a naplórekordokat. Ennek eredményeképpen a HA-replikán végrehajtó számítási feladattól függően a naplórekordok alkalmazása különböző sebességgel történhet, így a különböző replikák eltérő adatkésésben lehetnek az elsődleges replikához képest.

Megnevezett replika

A nevesített replika, akárcsak egy HA-replika, ugyanazokat a lapkiszolgálókat használja, mint az elsődleges replika. A HA-replikákhoz hasonlóan nincs szükség adatmásolásra egy elnevezett replika hozzáadásához.

A HA-replikák és az elnevezett replikák között különbségek vannak:

  • Az elnevezett replikák normál (írásvédett) Azure SQL-adatbázisokként jelennek meg a portálon, valamint az API-hívásokban, például az Azure CLI, Azure PowerShell és T-SQL eszközök használatakor.
  • Az elnevezett replikák adatbázisneve eltérhet az elsődleges replikától, és opcionálisan egy másik logikai kiszolgálón is elhelyezhetők (feltéve, hogy ugyanabban a régióban található, mint az elsődleges replika).
  • Az elnevezett replikák saját szolgáltatásiszint-célkitűzésekkel rendelkeznek, amelyek az elsődleges replikától függetlenül állíthatók be és módosíthatók.
  • Az elnevezett replikák legfeljebb 30 elnevezett replikát támogatnak (minden elsődleges replikához).
  • Az elnevezett replikák különböző hitelesítést támogatnak az egyes elnevezett replikákhoz azáltal, hogy különböző bejelentkezéseket hoznak létre az elnevezett replikákat üzemeltető logikai kiszolgálókon.

Ennek eredményeképpen a nevesített replikák számos előnnyel járnak a HA-replikákkal szemben, ami az írásvédett számítási feladatokat érinti:

  • A névvel ellátott replikához csatlakozó felhasználókat nem választják le, ha az elsődleges replikát fel- vagy le skálázzák.
  • Az elsődleges replikához csatlakozó felhasználókra nem vonatkozik a névvel ellátott replikák vertikális fel- vagy leskálázása.

A megnevezett replikák fő célja az olvasási felskálázási forgatókönyvek széles körének engedélyezése, valamint a hibrid tranzakciós és elemzési feldolgozási (HTAP) számítási feladatok javítása. Az ilyen megoldások létrehozásának módjára itt talál példákat:

Emellett az elnevezett replikák rugalmasságot és elasztikusságot kínálnak, így sok más használati esetnek is eleget tesznek.

  • Hozzáférés-elkülönítés: hozzáférést adhat egy adott nevesített replikához, de az elsődleges replikához vagy más nevesített replikákhoz nem.
  • Számítási feladatoktól függő szolgáltatásiszint-célkitűzés: mivel egy elnevezett replika saját szolgáltatásiszint-célkitűzéssel rendelkezhet, különböző nevesített replikákat használhat különböző számítási feladatokhoz és használati esetekhez. Például egy elnevezett replika használható a Power BI-kérések kiszolgálására, a másik pedig az Apache Spark for Data Science-feladatokhoz való adatok kiszolgálására. Mindegyik rendelkezhet független szolgáltatási szintű célkitűzéssel, és egymástól függetlenül skálázható.
  • Számítási feladattól függő útválasztás: legfeljebb 30 elnevezett replikával csoportokban is használhat nevesített replikákat, hogy egy alkalmazás elkülöníthető legyen egy másiktól. Egy négy elnevezett replikából álló csoport például a mobilalkalmazásokból érkező kérések kiszolgálására használható, míg egy másik két nevű replika a webalkalmazásból érkező kérések kiszolgálására. Ez a megközelítés lehetővé tenné az egyes csoportok teljesítményének és költségeinek finomhangolását.

Megjegyzés:

A Hyperscale elnevezett replikákkal kapcsolatos gyakori kérdésekért tekintse meg az Azure SQL Database Hyperscale elnevezett replikák gyakori kérdéseit.

Zónaredundancia a rugalmas skálázású, elnevezett replikákhoz

A zónaredundanciához konfigurált rugalmas skálázású elnevezett replikák az Azure Rendelkezésre állási zónák használatával terjesztik az elnevezett replikák számítási csomópontjait egy Azure-régió különböző fizikai helyei között. A névvel ellátott replikák zónaredundanciájának kiválasztásával növelheti a rugalmas skálázású adatbázisok minden rétegének rugalmasságát a hibák szélesebb körére, beleértve az adatközpontok leállását is, az alkalmazáslogika módosítása nélkül. További információ: Rugalmas skálázási zónaredundáns rendelkezésre állás.

Ha egy zónaredundáns, rugalmas skálázású replikát szeretne létrehozni, tekintse meg a rugalmas skálázású, elnevezett replika létrehozását ismertető oktatóanyagot.

Az alkalmazáshibák rugalmasságának hibaelhárításával és tesztelésével kapcsolatban lásd: Alkalmazáshibák rugalmasságának tesztelése.

Georeplika

Az aktív georeplikálással létrehozhatja az elsődleges rugalmas skálázású adatbázis olvasható másodlagos replikáját ugyanabban vagy egy másik Azure-régióban. A georeplikákat egy másik logikai kiszolgálón kell létrehozni. A georeplika adatbázisneve mindig megegyezik az elsődleges adatbázis nevével.

Georeplika létrehozásakor a rendszer minden adatot átmásol az elsődleges kiszolgálóról egy másik lapkiszolgálóra. A georeplika nem oszt meg lapkiszolgálókat az elsődlegessel, még akkor sem, ha ugyanabban a régióban vannak. Ez az architektúra biztosítja a földrajzi feladatátvételekhez szükséges redundanciát.

A georeplikák az adatbázis tranzakciósan konzisztens másolatának aszinkron replikáción keresztüli fenntartására szolgálnak. Ha egy georeplika egy másik Azure-régióban található, akkor vészhelyreállításhoz használható, ha az elsődleges régióban katasztrófa vagy kimaradás van. A földrajzi replikák földrajzi olvasási felskálázási forgatókönyvekhez is használhatók. 2022. október hónaptól a Hyperscale geo másodlagos replikából származó adatbázis-másolás támogatott.

A rugalmas skálázású adatbázisok georeplikálása a következő jelenlegi korlátozásokkal rendelkezik:

  • Csak egy georeplika hozható létre (ugyanabban vagy más régióban).
  • A georeplika időpont szerinti visszaállítása nem támogatott.
  • A georeplika georeplika létrehozása (más néven "georeplika-láncolás") nem támogatott.

Hibaelhárítás

Zónaredundáns rugalmas skálázású, elnevezett replikák hibaelhárítása

  • Az alkalmazáshibák rugalmasságának hibaelhárításával és tesztelésével kapcsolatban lásd: Alkalmazáshibák rugalmasságának tesztelése.

  • Győződjön meg arról, hogy legalább egy magas rendelkezésre állású replika van megadva egy zónaredundáns, elnevezett replika létrehozásakor a PowerShellben és a parancssori felületen. Például: Hyperscale nevű replika létrehozása.

    • Az Azure CLI-ben meg kell adnia mindkét paramétert: ha-replicas és redundant.
    • A PowerShellben meg kell adnia a paramétert HighAvailabilityReplicaCount és ZoneRedundanta .
    • Ha nincs megadva, a következő hibaüzenet jelenik meg: (ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.
  • A rugalmas skálázású adatbázisnak rendelkeznie kell már engedélyezett zónaredundanciával, ami előfeltétele annak, hogy ezt a funkciót elnevezett replikákhoz engedélyezze.

    • Az elnevezett replikák zónaredundanciája akkor is engedélyezhető, ha az elsődleges adatbázis zónaredundanciája engedélyezve van.
    • Ha nincs engedélyezve, a következő hibaüzenet jelenik meg: (DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.

Ismert problémák

Részben helytelenül visszaadott adatok a sys.database-ből

A sys.databases által visszaadott sorértékek a névvel ellátott replikák esetében a name és database_id oszlopokon kívüli oszlopokban következetlenek és helytelenek lehetnek. Egy elnevezett replika oszlopa például compatibility_level 140-esként is jelenthető, még akkor is, ha a névvel ellátott replikának megfelelő elsődleges adatbázis 150-es kompatibilitási szintre van állítva. Ha lehetséges, kerülő megoldásként ugyanazokat az adatokat kell lekérni a DATABASEPROPERTYEX() függvény használatával, amely helyes adatokat ad vissza.

A Hyperscale névvel ellátott replikák konfigurálásával és kezelésével kapcsolatos oktatóanyagokért lásd a részleteket az oktatóanyagokban:

További információkért lásd: