Másodlagos replikák rugalmas skálázása

A következőre 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ípusból állnak:

  • Magas rendelkezésre állású replika
  • Georeplika
  • Elnevezett 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 csak egyet vagy akár mind a hármat használhatja együtt. A másodlagos replikákat kiszolgáló nélküli és kiépített számítási szintek is támogatják.

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ákat főként az adatbázisok rendelkezésre állásának növelésére használják; feladatátvételi célokra gyakori készenlétben 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 kapcsolati sztring nem kell módosítani; a feladatátvételi alkalmazások során előfordulhat, hogy az aktív kapcsolatok megszakadása miatt minimális állásidőt tapasztalnak. 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ási szint célkitűzése 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ásként a portálról vagy bármely API-ból.

Nulla vagy négy HA replika is lehet. A számuk az adatbázis létrehozásakor vagy az adatbázis létrehozása után módosítható a közös felügyeleti végpontokon és eszközökön keresztül (például: PowerShell, AZ CLI, 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.

HA-replikára Csatlakozás

Rugalmas skálázású adatbázisokban az ApplicationIntent ügyfél által használt kapcsolati sztring argumentuma határozza meg, hogy a kapcsolat az írásvédett elsődleges replikához vagy egy írásvédett HA-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=<myPassword>;Trusted_Connection=False; Encrypt=True;

Minden HA-replika azonos az erőforrás-kapacitásban. 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, amely a naplórekordokat az elsődleges replikából továbbítja a HA-replikáknak. Ennek eredményeképpen a HA-replika által feldolgozott számítási feladattól függően a naplórekordok alkalmazása eltérő sebességgel történhet, így a különböző replikák eltérő adatkéséssel rendelkezhetnek az elsődleges replikához képest.

Elnevezett 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 és AZ API-hívásokban (AZ CLI, PowerShell, T-SQL).
  • 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ók nem fognak megszakadni, ha az elsődleges replika fel- vagy leskálázva van; Ugyanakkor az elsődleges replikához csatlakozó felhasználókat nem érintik a felfelé vagy lefelé skálázó nevesített replikák.
  • A más replikákon futó, hosszú ideig futó lekérdezések nem érintik a replikán futó számítási feladatokat.

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:

A fent felsorolt fő forgatókönyveken kívül a nevesített replikák rugalmasságot és rugalmasságot kínálnak számos más használati eset kielégítése érdekében:

  • 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 feladattól függő szolgáltatásszint-célkitűzés: mivel egy megnevezett replika saját szolgáltatásiszint-célkitűzéssel rendelkezhet, különböző elnevezett 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 Sparknak való adatok kiszolgálására Adattudomány feladatokhoz. 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 használható az elnevezett replikák, 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.

Az alábbi példa létrehoz egy elnevezett replikát WideWorldImporters_NamedReplica az adatbázishoz WideWorldImporters. Az elsődleges replika szolgáltatásszint-célkitűzést HS_Gen5_4, míg a névvel ellátott replika HS_Gen5_2 használ. Mindkettő ugyanazt a logikai kiszolgálót contosoeasthasználja. Ha közvetlenül szeretné használni a REST API-t, ez a lehetőség a következő lehetőségeket is lehetővé teszi: Adatbázisok – Adatbázis létrehozása elnevezett replikaként másodlagosként.

  1. Az Azure Portalon keresse meg azt az adatbázist, amelyhez létre szeretné hozni a nevesített replikát.

  2. Az SQL Database lapon jelölje ki az adatbázist, görgessen az adatkezeléshez, válassza a Replikák lehetőséget, majd válassza a Replika létrehozása lehetőséget.

    Screenshot that shows create named replica step.

  3. Válassza az Elnevezett replika lehetőséget a Replika konfigurációja területen, válassza ki vagy hozza létre a kiszolgálót a megnevezett replikához, adja meg a nevesített replika-adatbázis nevét, és szükség esetén konfigurálja a Számítási és tárolási beállításokat.

    Screenshot that shows configuration of named replica.

  4. Válassza a Véleményezés + létrehozás lehetőséget, tekintse át az információkat, majd válassza a Létrehozás lehetőséget.

  5. Megkezdődik a nevesített replika üzembe helyezési folyamata.

    Screenshot that shows named replica deployment status.

  6. Amikor az üzembe helyezés befejeződött, az elnevezett replika megjeleníti annak állapotát.

    Screenshot that shows named replica status after deployment.

  7. Térjen vissza az elsődleges adatbázis lapjára, majd válassza a Replikák lehetőséget. A nevesített replika a Nevesített replikák listában található.

    Screenshot that shows the SQL database primary and named replica.

Mivel nincs adatáthelyezés, a legtöbb esetben egy elnevezett replika jön létre körülbelül egy perc múlva. Miután a névvel ellátott replika elérhetővé válik, látható lesz a portálon vagy bármely parancssori eszközben, például az AZ CLI-ben vagy a PowerShellben. A névvel ellátott replika használható normál írásvédett adatbázisként.

Megjegyzés:

A rugalmas skálázású, elnevezett replikákkal kapcsolatos gyakori kérdésekért tekintse meg az Azure SQL Database rugalmas skálázású replikákkal kapcsolatos gyakori kérdéseket.

Csatlakozás nevesített replikára

A névvel ellátott replikához való csatlakozáshoz a névvel ellátott replika kapcsolati sztring kell használnia, hivatkozva a kiszolgáló és az adatbázis nevére. Nincs szükség az "ApplicationIntent=ReadOnly" beállítás megadására, mivel a nevesített replikák mindig írásvédettek.

A HA-replikákhoz hasonlóan az elsődleges, a HA és az elnevezett replikák is ugyanazokon az adatokon osztoznak ugyanazon lapkiszolgálókon, az egyes elnevezett replikák adatgyorsítótárai szinkronban maradnak az elsődlegessel a tranzakciónapló-szolgáltatáson keresztül, amely az elsődleges replikák naplórekordjait továbbítja. Ennek eredményeképpen attól függően, hogy egy nevesített replika milyen számítási feladatot dolgoz fel, a naplórekordok alkalmazása eltérő 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.

Névvel ellátott replika módosítása

Egy elnevezett replika szolgáltatásiszint-célkitűzését a parancson vagy ALTER DATABASE bármely más támogatott módon (Portal, AZ CLI, PowerShell, REST API) határozhatja meg. Ha a névvel ellátott replika létrehozása után módosítania kell a szolgáltatásiszint-célkitűzést, akkor ezt a nevesített replika parancsával teheti meg ALTER DATABASE ... MODIFY . Ha például WideWorldImporters_NamedReplica az adatbázis nevesített replikája WideWorldImporters , az alábbi módon teheti meg.

Nyissa meg a nevesített replikaadatbázis oldalát, majd válassza a Compute + Storage lehetőséget. Frissítse a virtuális magokat.

Screenshot that shows named replica service level objective update.

Elnevezett replika eltávolítása

Ha el szeretne távolítani egy elnevezett replikát, ugyanúgy elveti, mint egy normál adatbázist.

Nyissa meg a nevesített replikaadatbázis oldalát, és válassza a Delete lehetőséget.

Screenshot that shows deletion of named replica.

Fontos

Az elnevezett replikák automatikusan törlődnek, ha az elsődleges replika, amelyből létrehozták őket, törlődik.

Ismert problémák

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

Az elnevezett replikákból sys.databasesvisszaadott sorértékek az és database_idkívüli name oszlopokban inkonzisztensek és helytelenek lehetnek. Egy elnevezett replika oszlopa például compatibility_level 140-ként jelenthető, még akkor is, ha az elsődleges adatbázis, amelyből a nevesített replikát létrehozták, 150-re 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.

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 geo 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ásra használható az elsődleges régióban bekövetkezett katasztrófa vagy kimaradás esetén. A földrajzi replikák földrajzi olvasási felskálázási forgatókönyvekhez is használhatók. 2022 októberétől a rugalmas skálázású 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őponthoz kötött visszaállítása nem támogatott.
  • A georeplika georeplika létrehozása (más néven "georeplika-láncolás") nem támogatott.

További lépések