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

Megbízhatóság az Azure SQL Database-ben

Az Azure SQL Database egy teljes körűen felügyelt platform szolgáltatásként (PaaS) adatbázismotor, amely a legtöbb adatbázis-kezelési funkciót kezeli, például a frissítést, a javítást, a biztonsági mentéseket és a monitorozást felhasználói beavatkozás nélkül.

Az Azure használatakor a megbízhatóság közös felelősség. A Microsoft számos lehetőséget kínál a rugalmasság és a helyreállítás támogatására. Ön a felelős azért, hogy megértse, hogyan működnek ezek a képességek az összes használt szolgáltatáson belül, és válassza ki azokat a képességeket, amelyekre szüksége van az üzleti célok és az üzemidő céljainak eléréséhez.

Ez a cikk azt ismerteti, hogyan teheti rugalmassá az Azure SQL Database-t számos lehetséges kimaradással és problémával szemben, beleértve az átmeneti hibákat, a rendelkezésre állási zónák kimaradásait és a régiókimaradásokat. Azt is ismerteti, hogyan használhat biztonsági másolatokat más típusú problémákból való helyreállításhoz, hogyan kezelheti a szolgáltatáskarbantartást, és kiemeli az Azure SQL Database szolgáltatásiszint-szerződéssel (SLA) kapcsolatos legfontosabb információkat.

Termelési üzembe helyezési javaslatok

Ha tudni szeretné, hogyan helyezheti üzembe az Azure SQL Database-t a megoldás megbízhatósági követelményeinek támogatásához, és hogy a megbízhatóság hogyan befolyásolja az architektúra egyéb aspektusait, tekintse meg az Azure SQL Database architektúrával kapcsolatos ajánlott eljárásait az Azure Well-Architected-keretrendszerben.

A megbízhatósági architektúra áttekintése

Az SQL Database a Windows operációs rendszer legújabb stabil SQL Server Database-motorján fut, beleértve az összes vonatkozó javítást is.

Az SQL Database úgy éri el a redundanciát, hogy alapértelmezés szerint három másolatot tárol az adatokról egyetlen adatközpontban az elsődleges régióban. Ez a módszer védi az adatokat, ha honosított hiba történik, például kis léptékű hálózati hiba vagy áramkimaradás esetén, valamint a következő események során:

  • Az ügyfél által kezdeményezett menedzsment műveletek rövid állásidőt eredményeznek

  • Szolgáltatáskarbantartási műveletek

  • Problémák és adatközpont-leállások, ahol az adatközpont az alábbi összetevőkkel rendelkezik:

    • Állványok, ahol a szolgáltatást működtető gépek futnak

    • Az SQL Database-motort futtató virtuális gépet (VM-et) üzemeltető fizikai gépek

  • Az SQL Database-motor egyéb problémái

  • Egyéb lehetséges nem tervezett honosított kimaradások

Az SQL Database az Azure Service Fabric használatával kezeli az adatbázis replikációját.

A redundancia különböző módokon implementálható az SQL Database különböző szolgáltatási szintjeihez. További információ: Rendelkezésre állás redundancián keresztül – SQL Database.

Rugalmasság átmeneti hibákhoz

Az átmeneti hibák rövid, időszakos meghibásodások a komponensekben. Gyakran előfordulnak elosztott környezetben, például a felhőben, és ezek a műveletek szokásos részei. Az átmeneti hibák rövid idő elteltével kijavítják magukat. Fontos, hogy az alkalmazások kezelni tudják az átmeneti hibákat, általában az érintett kérések újrapróbálásával.

Minden felhőalapú alkalmazásnak követnie kell az Azure átmeneti hibakezelési útmutatóját, amikor a felhőben üzemeltetett API-kkal, adatbázisokkal és egyéb összetevőkkel kommunikálnak. További információ: Átmeneti hibák kezelésére vonatkozó javaslatok.

Az SQL Database automatikusan kezeli a kritikus karbantartási feladatokat, például javításokat, biztonsági mentéseket, Windows- és SQL Database-motorfrissítéseket. Emellett automatikusan kezeli a nem tervezett eseményeket, például a mögöttes hardvereket, szoftvereket vagy hálózati hibákat. Az SQL Database-t úgy tervezték, hogy gyorsan helyreálljon a kritikus hibákból, ami biztosítja, hogy az adatok mindig elérhetők legyenek. A felhasználók többsége nem veszi észre, hogy a frissítések végrehajtása folyamatosan történik.

Ha egy adatbázist frissítenek vagy átkapcsolnak, az állásidő nem lesz zavaró, ha újrapróbálkozási logikát alkalmaz az alkalmazásban.

Az alkalmazás átmeneti hibákkal szembeni rugalmasságának teszteléséhez kövesse az alkalmazáshibák rugalmasságának tesztelése című útmutatót.

Rugalmasság a rendelkezésre állási zóna hibáival szemben

A rendelkezésre állási zónák fizikailag különálló adatközpont-csoportok egy Azure-régión belül. Ha egy zóna meghibásodik, a szolgáltatások a fennmaradó zónák egyikére is át tudnak adni feladatokat.

Létrehozhat zónaredundáns önálló adatbázist vagy rugalmas készletet. A zónaredundancia biztosítja, hogy az adatbázis rugalmas legyen a hibák nagy halmazával szemben, beleértve a katasztrofális adatközpont-kimaradásokat is, az alkalmazáslogika módosítása nélkül.

Az általános célú szolgáltatási szint esetében a zónaredundancia biztosítja, hogy az állapot nélküli számítási összetevők és az SQL Database állapotalapú adattárolási összetevői is rugalmasak legyenek a rendelkezésre állási zónák kimaradásával szemben.

A prémium, az üzleti szempontból kritikus és a rugalmas skálázású szolgáltatási szintek esetében a zónaredundancia az SQL-adatbázis replikáit több Azure-rendelkezésre állási zónában helyezi el az elsődleges régióban. Egy meghibásodási pont (SPOF) kiküszöbölése érdekében a vezérlőgyűrű több rendelkezésre állási zónában is duplikálva lesz.

Az egyéb szolgáltatási szintek rendelkezésreállási zónájának támogatásával kapcsolatos információk megtekintéséhez mindenképpen válassza ki a megfelelő szolgáltatási szintet a lap elején.

Requirements

Az alapszintű és a standard szolgáltatási szintek nem támogatják a zónaredundanciát.

A zónaredundancia a virtuális magalapú vásárlási modell üzletileg kritikus, általános célú és rugalmas skálázási szolgáltatási szintjeiben lévő adatbázisok számára érhető el, és csak a DTU-alapú vásárlási modell Prémium szolgáltatási szintje.

Az Általános célú szolgáltatási szint esetében:

Prémium és üzleti szempontból kritikus szolgáltatási szintek esetén:

Rugalmas skálázású szolgáltatási szint esetén:

Az egyéb szolgáltatási szintek rendelkezésreállási zónájának támogatásával kapcsolatos információk megtekintéséhez mindenképpen válassza ki a megfelelő szolgáltatási szintet a lap elején.

Megfontolások

  • Lappangás: A zónaredundáns adatbázisok replikái külön adatközpontokban vannak. A hozzáadott hálózati késés növelheti a tranzakciók véglegesítési idejét, és hatással lehet bizonyos online tranzakciófeldolgozási (OLTP-) számítási feladatok teljesítményére. A legtöbb alkalmazás nem érzékeny erre a plusz késésre.

  • master adatbázis: Ha egy zónaredundáns konfigurációval rendelkező adatbázis jön létre egy logikai kiszolgálón, a master kiszolgálóhoz társított adatbázis is automatikusan zónaredundánssá válik. Az master adatbázis zónaredundanciájának ellenőrzéséről további információt az Adatbázis zónaredundáns rendelkezésre állása című témakörben talál.

Az egyéb szolgáltatási szintek rendelkezésreállási zónájának támogatásával kapcsolatos információk megtekintéséhez mindenképpen válassza ki a megfelelő szolgáltatási szintet a lap elején.

Költség

Az általános célú szolgáltatási szint esetében felár ellenében engedélyezhető a zónaredundancia az SQL Database-ben. További információ: Díjszabás – SQL Database.

A prémium és az üzleti szempontból kritikus szolgáltatási szintek az adatbázis több replikáját is biztosítják. A zónaredundancia engedélyezésekor a replikák el vannak osztva a rendelkezésre állási zónák között. Ez a disztribúció azt jelenti, hogy a zónaredundancia engedélyezése nem jár többletköltséggel az SQL-adatbázison, ha az prémium vagy üzleti szempontból kritikus szolgáltatási szinten van.

Ha több replikát is engedélyez a rugalmas skálázású szolgáltatásiszint-adatbázisból, engedélyezheti a zónaredundanciát. A zónaredundancia engedélyezésekor a replikák el vannak osztva a rendelkezésre állási zónák között. Ez a disztribúció azt jelenti, hogy a zónaredundancia engedélyezése nem jár többletköltséggel az SQL-adatbázison, ha az rugalmas skálázási szolgáltatási szinten van, feltéve, hogy több replikával rendelkezik.

Az egyéb szolgáltatási szintek rendelkezésreállási zónájának támogatásával kapcsolatos információk megtekintéséhez mindenképpen válassza ki a megfelelő szolgáltatási szintet a lap elején.

A rendelkezésre állási zóna támogatásának konfigurálása

Az általános célú, prémium és üzleti szempontból kritikus szolgáltatási szintek esetében:

Rugalmas skálázású szolgáltatási szint esetén:

Az egyéb szolgáltatási szintek rendelkezésreállási zónájának támogatásával kapcsolatos információk megtekintéséhez mindenképpen válassza ki a megfelelő szolgáltatási szintet a lap elején.

Viselkedés, ha minden zóna kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha az adatbázisok zónaredundanciára vannak konfigurálva, és az összes rendelkezésre állási zóna működőképes.

Az Általános célú szolgáltatási szint esetében:

  • Forgalomirányítás zónák között: A kérelmek egy olyan csomópontra lesznek irányítva, amely az SQL-adatbázis számítási rétegét futtatja. Ha a zónaredundancia engedélyezve van, ez a csomópont bármely rendelkezésre állási zónában található.

  • Adatreplikálás zónák között: Az adatok és naplófájlok szinkron módon replikálódnak a rendelkezésre állási zónák között a ZRS használatával. Az írási műveletek mindaddig nem tekinthetők befejezettnek, amíg az adatok sikeresen nem replikálódnak az összes rendelkezésre állási zónában. Ez a szinkron replikáció erős konzisztenciát és nulla adatvesztést biztosít a zónahibák során. Ez azonban valamivel nagyobb írási késést eredményezhet a helyileg redundáns tároláshoz (LRS) képest.

Prémium és üzleti szempontból kritikus szolgáltatási szintek esetén:

  • Forgalomirányítás zónák között: A replikák a rendelkezésre állási zónák között vannak elosztva, és az egyik replika elsődleges replikaként van kijelölve. A kérések az adatbázis elsődleges replikájához lesznek irányítva.

  • Adatreplikálás zónák között: Az elsődleges replika folyamatosan küld módosításokat a másodlagos replikáknak, hogy az adatok elegendő számú másodlagos replikán legyenek megőrzve az egyes tranzakciók véglegesítése előtt. Ez a folyamat garantálja, hogy ha az elsődleges replika vagy egy olvasható másodlagos replika bármilyen okból elérhetetlenné válik, a feladatátvételhez mindig rendelkezésre áll egy teljesen szinkronizált replika. Ha a zónaredundancia engedélyezve van, ezek a replikák különböző rendelkezésre állási zónákban találhatók. A folyamat azonban valamivel nagyobb írási késést eredményezhet a bejárási zónák hálózati késése miatt.

Rugalmas skálázású szolgáltatási szint esetén:

  • Forgalomirányítás zónák között: Az adatbázis-replikák a rendelkezésre állási zónák között vannak elosztva, és az egyik replika elsődleges replikaként van kijelölve. A kérések az adatbázis elsődleges replikájához lesznek irányítva.

  • Adatreplikálás zónák között: Az elsődleges adatbázisreplika egy zónaredundáns naplószolgáltatáson keresztül küldi le a módosításokat, amely szinkron módon replikálja az összes módosítást a rendelkezésre állási zónák között. A lapkiszolgálók minden rendelkezésre állási zónában találhatók, és tárolják az adatbázis állapotát. Ez a folyamat garantálja, hogy ha az elsődleges replika vagy egy olvasható másodlagos replika bármilyen okból elérhetetlenné válik, a feladatátvételhez mindig rendelkezésre áll egy teljesen szinkronizált replika. A folyamat azonban az LRS-hez képest valamivel nagyobb írási késést eredményezhet.

Az egyéb szolgáltatási szintek rendelkezésreállási zónájának támogatásával kapcsolatos információk megtekintéséhez mindenképpen válassza ki a megfelelő szolgáltatási szintet a lap elején.

Viselkedés zónahiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha az adatbázisok zónaredundanciára vannak konfigurálva, és a rendelkezésre állási zóna kimarad.

  • Észlelés és válasz: Az SQL Database felelős a rendelkezésre állási zónában fellépő hibák észleléséért és megválaszolásáért. Nem kell semmit tennie a zóna átváltásának kezdeményezéséhez.
  • Értesítés: A Microsoft nem értesíti automatikusan, ha egy zóna le van omlva. Az Azure Service Health használatával azonban megismerheti a szolgáltatás általános állapotát, beleértve a zónahibákat is, és beállíthat Service Health-riasztásokat a problémákról való értesítéshez.
  • Aktív kérések: Ha egy rendelkezésre állási zóna offline állapotba kerül, a hibás rendelkezésre állási zónában feldolgozott kérések leállnak, és újra kell próbálkozni. Ha többet szeretne tudni arról, hogyan teheti rugalmassá az alkalmazásokat az ilyen típusú problémákhoz, tekintse meg az átmeneti hibák rugalmasságával kapcsolatos útmutatót .

  • Forgalom átirányítása: Az általános célú szolgáltatási szint esetében az SQL Database áthelyezi az adatbázismotort egy másik állapot nélküli számítási csomópontra, amely egy másik rendelkezésre állási zónában található, és elegendő szabad kapacitással rendelkezik. A feladatátvétel befejezése után a rendszer automatikusan átirányítja az új kapcsolatokat az új elsődleges számítási csomópontra.

    További információ: Általános célú szolgáltatási szint.

  • Forgalom átirányítása: A prémium és az üzleti szempontból kritikus szolgáltatási szintek esetében az SQL Database kiválaszt egy replikát egy másik rendelkezésre állási zónában, hogy elsődleges replikává váljon. Miután egy másodlagos replika új elsődleges replikává válik, létrehoznak egy másik másodlagos replikát annak biztosítására, hogy a fürt elegendő számú replikával rendelkezzen a kvórum fenntartásához. A feladatátvétel befejezése után a rendszer automatikusan átirányítja az új kapcsolatot az új elsődleges replikára (vagy a kapcsolati karakterlánc alapján olvasható másodlagos replikára).

    További információ: Prémium és Üzleti szempontból kritikus szolgáltatási szintek.

  • Forgalom átirányítása: A rugalmas skálázási szolgáltatási szint esetében, ha az elsődleges replika a zónakimaradás miatt elveszett, az SQL Database előlépteti a másik zónában lévő magas rendelkezésre állású replikák egyikét az új elsődlegesként.

    További információ: rugalmas skálázású szolgáltatási szint.

  • Várható állásidő: A rendelkezésre állási zóna feladatátvétele során előfordulhat, hogy rövid ideig állásidő lesz. Az állásidő általában kevesebb, mint 30 másodperc, amelyet az alkalmazásnak el kell viselnie, ha az átmeneti hibákra vonatkozó rugalmassági útmutatót követi.

  • Várható adatvesztés: A rendelkezésre állási zóna feladatátvétele során nem várható adatvesztés.

Az egyéb szolgáltatási szintek rendelkezésreállási zónájának támogatásával kapcsolatos információk megtekintéséhez mindenképpen válassza ki a megfelelő szolgáltatási szintet a lap elején.

Zóna helyreállítása

A rendelkezésre állási zóna helyreállításakor az Azure Service Fabric automatikusan létrehozza az adatbázis-replikákat a helyreállított rendelkezésre állási zónában, eltávolítja a többi rendelkezésre állási zónában létrehozott ideiglenes replikákat, és folytatja a normál forgalom átirányítását az adatbázisba. A megszakítás elkerülése érdekében az elsődleges replika nem adja vissza automatikusan az eredeti zónát a zóna helyreállítása után.

Zónahibák tesztelése

Az SQL Database platform kezeli a zónaredundáns adatbázisok forgalomirányítási, feladatátvételi és zóna-recovery eljárásait. Mivel ez a szolgáltatás teljes mértékben felügyelt, nem kell kezdeményeznie vagy ellenőriznie a rendelkezésre állási zónák meghibásodási folyamatait. Az alkalmazás hibatűrésének tesztelésével azonban ellenőrizheti, hogy az alkalmazás kezeli-e a hibákat és a feladatátvételeket.

Rugalmasság régiószintű hibákhoz

Ez a szakasz áttekintést nyújt az SQL Database többrégiós georeplikálása során használható két kapcsolódó, de különálló funkcióról:

Aktív georeplikáció

Az aktív georeplika egy folyamatosan szinkronizálható, olvasható másodlagos adatbázist (más néven geo-másodlagos vagy georeplikát) hoz létre egyetlen elsődleges adatbázis bármely régiójában. Az aktív georeplikációs szolgáltatás képes másodlagos adatbázisokat létrehozni ugyanabban a régióban, de ez a konfiguráció nem nyújt védelmet a régiókimaradás ellen. Ha aktív georeplikációs használatával éri el a georedundanciát, a másodlagos adatbázis egy másik régióban található az elsődleges adatbázishoz.

Requirements

Aktív georeplikációs műveletek használatakor vegye figyelembe a következő követelményeket:

  • Régiótámogatás:Az aktív georeplikálás minden Azure-régióban engedélyezhető, és nem igényel Azure-régiópárok használatát.

    Jótanács

    Az SQL Database egy biztonságos üzembehelyezési gyakorlatot követ, amelyben az Azure arra törekszik, hogy ne helyezzen üzembe frissítéseket a párosított régiókban egyszerre. Ha az aktív georeplikálást úgy konfigurálja, hogy a nem használt régiókat használja, állítsa be az egyes régiók kiszolgálóinak különböző karbantartási időszakait. Ez a megközelítés segít csökkenteni annak az esélyét, hogy mindkét régióban egyidejűleg a karbantartás okozta csatlakozási problémák jelentkeznek.

  • Konfigurációs: Az elsődlegesnek és a geo-másodlagosnak is ugyanazzal a szolgáltatási szinttel kell rendelkeznie, és azonos számítási szinttel, számítási mérettel és biztonsági mentési tárterület-redundanciával kell rendelkeznie.

  • Tűzfal: Az elsődleges és a geo-másodlagos ip-cím tűzfalszabályainak is azonosnak kell lennie.

  • Azure-előfizetések: Az aktív georeplikálás különböző Azure-előfizetések adatbázisai esetében támogatott.

Megfontolások

  • Az aktív georeplikációs funkció egyetlen adatbázis feladatátvételét biztosítja. Ha több adatbázis feladatátvételére van szüksége, fontolja meg inkább a feladatátvételi csoportok használatát.

  • Mivel a georeplikálás aszinkron, feladatátvétel esetén adatvesztés lehetséges. Ha meg kell szüntetnie az adatvesztést az aszinkron replikációból a feladatátvétel során, konfigurálja az alkalmazást úgy, hogy blokkolja a hívó szálat, amíg az utolsó véglegesített tranzakciót nem továbbítja és meg nem erősíti a másodlagos adatbázis tranzakciónaplójában. Ez a megközelítés egyéni fejlesztést igényel, és csökkenti az alkalmazás teljesítményét. További információ: A kritikus adatok elvesztésének megakadályozása.

  • További információ a korlátozásokról és szempontokról: Aktív georeplikációs szolgáltatás.

Költség

A másodlagos adatbázisokat külön adatbázisként számlázzák.

Ha nem használ másodlagos adatbázist olvasási vagy írási számítási feladatokhoz, fontolja meg, hogy ki tudja-e jelölni készenléti replikaként a költségek csökkentése érdekében.

Többrégiós támogatás konfigurálása

Viselkedés, ha minden régió kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy adatbázis aktív georeplikációs használatára van konfigurálva, és minden régió működőképes.

  • Forgalomirányítás régiók között: Az alkalmazást úgy kell konfigurálni, hogy olvasási-írási kéréseket küldjön az elsődleges adatbázisnak. Igény szerint csak olvasható kéréseket küldhet egy másodlagos adatbázisba, ami segít csökkenteni a csak olvasható terhelések elsődleges adatbázisra gyakorolt hatását.

  • Régiók közötti adatreplikálás: Az elsődleges és a másodlagos adatbázisok közötti replikáció aszinkron módon történik, ami azt jelenti, hogy a módosítás az elsődleges adatbázisra való alkalmazása és a másodlagos adatbázisba történő replikálása közötti késleltetés lehet.

    Feladatátvételkor ön dönti el, hogyan kezelheti az adatvesztés lehetőségét.

Viselkedés régióhiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy adatbázis aktív georeplikációs használatára van konfigurálva, és kimaradás történik az elsődleges régióban:

  • Észlelés és válasz: Ön felelős az adatbázis vagy régió leállásának észleléséért és a feladatátvétel aktiválásáért.
  • Értesítés: A Microsoft nem értesíti automatikusan, ha egy régió le van állítva. Az Azure Service Health használatával azonban megismerheti a szolgáltatás általános állapotát, beleértve a régióhibákat is, és beállíthat Service Health-riasztásokat a problémákról való értesítéshez.

  • Aktív kérések: A feladatátvétel során az aktív kérések leállnak, és újra kell próbálkozni.

  • Várható adatvesztés: Ha az elsődleges adatbázis elérhető, igény szerint adatvesztés nélkül is elvégezhet feladatátvételt. A feladatátvételi folyamat a szerepkörök váltása előtt szinkronizálja az adatokat az elsődleges és a másodlagos adatbázisok között.

    Ha az elsődleges adatbázis nem érhető el, előfordulhat, hogy kényszerített feladatátvételt kell végrehajtania, ami adatvesztést eredményez. Az adatvesztés mértékét a replikáció késésének figyelésével becsülheti meg. További információ: SQL Database monitorozása metrikákkal és riasztásokkal.

  • Várható állásidő: A feladatátvétel során általában legfeljebb 60 másodpercnyi állásidő áll rendelkezésre. Győződjön meg arról, hogy az alkalmazás kezeli az átmeneti hibákat, hogy képes legyen helyreállni rövid állásidő után. Az, hogy milyen gyorsan konfigurálja újra az alkalmazását a csatlakozáshoz az új fő adatbázishoz, befolyásolja a tapasztalt állásidőt.

  • Forgalom átirányítása: Ön felel azért, hogy újrakonfigurálja az alkalmazást, hogy kéréseket küldjön az új elsődleges adatbázisnak. Ha transzparens feladatátvételre van szüksége, fontolja meg feladatátvételi csoportok használatát.

Régió helyreállítása

Az elsődleges régió helyreállítása után manuálisan végezhet feladat-visszavételt az elsődleges régióba egy másik feladatátvétel végrehajtásával.

Régióhibák tesztelése

Egy régió kimaradását bármikor szimulálhatja manuális átváltás aktiválásával. Feladatátvételt (adatvesztés nélkül) vagy kényszerített feladatátvételt is aktiválhat.

Átállás csoportok

A feladatátvételi csoportok az aktív georeplikációs adatokra épülnek. Feladatátvételi csoportokkal a következő műveleteket hajthatja végre:

  • Adatbáziskészlet replikálása egyetlen logikai kiszolgálóról az Azure-régiók tetszőleges kombinációjára.

  • Hajtsa végre az adatbázisok átváltását csoportban.

  • Olyan kapcsolati végpontokat használjon, amelyek automatikusan irányítják a kapcsolatokat az elsődleges felé.

Requirements

  • Régiótámogatás: A feladatátvételi csoportok az összes Azure-régióban létrehozhatóak, és nem igényelnek Azure-régiópárokat.

    Jótanács

    Ha nem párosított régiókkal konfigurál egy feladatátvételi csoportot, érdemes különböző karbantartási időszakokat beállítani az egyes régiókban lévő kiszolgálókhoz. Ez a megközelítés segít csökkenteni annak az esélyét, hogy mindkét régióban egyidejűleg a karbantartás okozta csatlakozási problémák jelentkeznek.

  • Konfigurációs: A feladatátvételi csoport másodlagos adatbázisainak ugyanazzal a szolgáltatási szinttel, számítási szinttel, számítási mérettel, IP-cím tűzfalszabályokkal és biztonsági mentési tárterület-redundanciával kell rendelkezniük, mint az elsődleges adatbázisnak.

Megfontolások

  • Zónaredundancia: A rugalmas skálázási szolgáltatási szint esetében, ha az elsődleges adatbázis zónaredundanciával rendelkezik, akkor a másodlagos adatbázisok zónaredundanciái automatikusan engedélyezve vannak.
  • Zónaredundancia: A másodlagos adatbázisokban alapértelmezés szerint nincs engedélyezve a zónaredundancia, de később engedélyezheti.

  • Lehetséges adatvesztés: Mivel a georeplikálás aszinkron, feladatátvétel esetén adatvesztés is lehetséges. Ha meg kell szüntetnie az adatvesztést az aszinkron replikációból a feladatátvételek során, konfigurálhatja az alkalmazást úgy, hogy blokkolja a hívó szálat, amíg az utolsó véglegesített tranzakciót nem továbbítja és meg nem erősíti a másodlagos adatbázis tranzakciónaplójában. Ez a megközelítés egyéni fejlesztést igényel, és csökkenti az alkalmazás teljesítményét. További információ: A kritikus adatok elvesztésének megakadályozása.

  • A korlátozásokról és szempontokról bővebben a feladatátvételi csoportok című részben találhat információt.

Költség

A másodlagos adatbázisokat külön adatbázisként számlázzák.

Ha nem használ másodlagos adatbázist olvasási vagy írási számítási feladatokhoz, fontolja meg, hogy ki tudja-e jelölni készenléti replikaként a költségek csökkentése érdekében.

Többrégiós támogatás konfigurálása

  • Feladatátvételi csoportok engedélyezése: Feladatátvételi csoportot konfigurálhat egy logikai kiszolgálón. Hozzáadhatja a logikai kiszolgáló összes adatbázisát a feladatátvételi csoporthoz, vagy kiválaszthatja a hozzáadni kívánt adatbázisok egy részhalmazát.

    Feladatátvételi csoport létrehozásakor kiválasztja a feladatátvételi szabályzatot, amely meghatározza, hogy ki felelős a kimaradás észleléséért és a feladatátvétel végrehajtásáért. Konfigurálhatja az ajánlott ügyfél által felügyelt feladatátvételt, vagy a Microsoft által felügyelt feladatátvételt.

    Fontos

    A Microsoft által kezdeményezett átállás valószínűleg jelentős késés után következik be, és legjobb erőfeszítés alapon történik. Előfordulhat, hogy az adatbázisok feladatátvétele más időpontban történik, mint más Azure-szolgáltatások feladatátvétele. További információ: Feladatátvételi csoport konfigurálása az SQL Database-hez.

    A feladatátvételi csoport konfigurálása után a kezdeti üzembe helyezési lépés eltarthat egy ideig.

  • Feladatátvételi csoportok letiltása: Eltávolíthat egy önálló adatbázist egy feladatátvételi csoportból, eltávolíthat egy teljes feladatátvételi csoportot, vagy áthelyezhet egy adatbázist egy másik feladatátvételi csoportba.

Viselkedés, ha minden régió kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy adatbázis egy feladatátvevő csoportban van konfigurálva, és minden régió működőképes.

  • Forgalomirányítás a régiók között: Olvasási és írási, valamint csak olvasási számítási feladatok esetén a feladatátvételi csoportok két végpontot biztosítanak, amelyeken keresztül csatlakoztathatja alkalmazásait. A feladatátvételi csoport figyelő végpontjainak használatával minimalizálhatja az állásidőt a feladatátvételek során. Normál műveletek során a következő útválasztási viselkedés következik be:

    • Az olvasási-írási figyelő végpont az összes kérést az elsődleges adatbázisokhoz irányítja.

    • Az írásvédett élőhallgató végpont az összes kérést egy olvasható másodlagos adatbázisba irányítja.

  • Régiók közötti adatreplikálás: Az elsődleges és a másodlagos adatbázisok közötti georeplikálás aszinkron módon történik. Ez a késés azt jelenti, hogy késés lehet az elsődleges adatbázisra alkalmazott módosítás és a másodlagos adatbázisba való replikálás között.

    Feladatátvételkor ön dönti el, hogyan kezelheti az adatvesztés lehetőségét.

Viselkedés régióhiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy adatbázis egy feladatátvételi csoportban van konfigurálva, és az elsődleges régióban kimaradás történik:

  • Az észlelés és a válasz a használt feladatátvételi szabályzattól függ.

    • Ügyfél által kezdeményezett feladatátvétel: Ön felelős az adatbázis vagy régió leállásának észleléséért és a feladatátvétel aktiválásáért.

    • Microsoft által kezdeményezett feladatátvétel: A Microsoft a feladatátvételt az érintett régióban lévő összes feladatátvételi csoport esetében aktiválja. A Microsoft várhatóan csak kivételes helyzetekben hajtja végre ezt a feladatátvételi típust. A legtöbb megoldás esetében ne támaszkodhat a Microsoft által felügyelt feladatátvételre. További információ: Feladatátvételi szabályzat – Microsoft által felügyelt.

  • Értesítés: A Microsoft nem értesíti automatikusan, ha egy régió le van állítva. Az Azure Service Health használatával azonban megismerheti a szolgáltatás általános állapotát, beleértve a régióhibákat is, és beállíthat Service Health-riasztásokat a problémákról való értesítéshez.

  • Aktív kérések: A feladatátvétel során az aktív kérések leállnak, és újra kell próbálkozni.

  • Várható adatvesztés: Az adatvesztés a használt feladatátvételi szabályzattól függ.

    • Ügyfél által kezdeményezett feladatátvétel: Ha az elsődleges adatbázis elérhető, igény szerint adatvesztés nélkül is elvégezhet feladatátvételt. A feladatátvételi folyamat a szerepkörök váltása előtt szinkronizálja az adatokat az elsődleges és a másodlagos adatbázisok között.

      Ha az elsődleges adatbázis nem érhető el, előfordulhat, hogy kényszerített feladatátvételt kell végrehajtania, ami adatvesztést eredményez. Az adatvesztés mértékét a replikáció késésének figyelésével becsülheti meg. További információ: SQL Database monitorozása metrikákkal és riasztásokkal.

    • Microsoft által kezdeményezett feladatátvétel: A Microsoft által felügyelt feladatátvétel csak kivételes esetekben aktiválódik. A Microsoft által felügyelt feladatátvételek kényszerített feladatátvételek, ami azt jelenti, hogy némi adatvesztés várható. Nem szabályozhatja, hogy mekkora adatvesztést tapasztalhat.

  • Várható állásidő: Az állásidő a használt feladatátvételi szabályzattól függ.

    • Ügyfél által kezdeményezett feladatátvétel: A feladatátvétel során általában legfeljebb 60 másodpercnyi állásidő áll rendelkezésre. Győződjön meg arról, hogy az alkalmazás kezeli az átmeneti hibákat, hogy képes legyen helyreállni rövid állásidő után.

    • Microsoft által kezdeményezett feladatátvétel: Megadhat egy türelmi időszakot , amely meghatározza, hogy a Microsoft mennyi ideig várjon a feladatátvétel megkezdése előtt. A minimális türelmi időszak egy óra. A Microsoft válaszideje azonban valószínűleg legalább több óra lesz.

  • Forgalom átirányítása: A feladatátvétel során az SQL Database frissíti az írás és írásvédett kiszolgáló végpontjait, hogy szükség szerint az új elsődleges és másodlagos adatbázisokhoz irányítsa a forgalmat.

    Ha az új másodlagos adatbázis (korábban az elsődleges adatbázis) nem érhető el, az írásvédett figyelővégpont nem tud csatlakozni, amíg az új másodlagos elérhetővé nem válik.

Régió helyreállítása

Ha szükséges, ön felel az elsődleges régióba való visszalépésért. Az ügyféltámogatású átkapcsolás végrehajtásával manuálisan is elvégezheti a visszaállást az elsődleges régióba.

Még ha a Microsoft kezdeményezte is az eredeti átkapcsolást, akkor is Ön a felelős az előző régióba való visszakapcsolásért, ha ezt választja.

Régióhibák tesztelése

Egy régió kimaradását bármikor szimulálhatja manuális átváltás aktiválásával. Feladatátvételt (adatvesztés nélkül) vagy kényszerített feladatátvételt is aktiválhat.

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

Készítsen biztonsági másolatot az adatbázisokról a különböző kockázatok, köztük az adatvesztés elleni védelem érdekében. A biztonsági másolatok visszaállíthatók a véletlen adatvesztés, sérülés vagy egyéb problémák helyreállítása érdekében. A biztonsági mentések eltérnek a zónaredundanciától, az aktív georeplikálástól vagy a feladatátvételi csoportoktól, és különböző céljuk van. További információ: Redundancia, replikáció és biztonsági mentés.

Az SQL Database automatikus biztonsági mentést biztosít az adatbázisokról. A biztonsági mentés gyakoriságáról, amely befolyásolhatja az adatvesztés mértékét, ha biztonsági másolatból kell visszaállítania, tekintse meg az SQL Database automatikus biztonsági mentéseit.

Biztonsági mentési tár

Dönthet úgy, hogy LRS-ben vagy ZRS-ben tárolja az automatikus biztonsági mentéseket. Ha párosított régiót használ, úgy is dönthet, hogy georedundáns tárolással replikálja az automatikus biztonsági másolatokat a párosított régióba. Ez a funkció lehetővé teszi a biztonsági másolatok földrajzi helyreállítását a párosított régióba. További információ: Automatizált biztonsági mentések az SQL Database-ben.

Ha nem támogatott régiót használ, vagy ha a párosított régiótól eltérő régióba kell replikálnia a biztonsági másolatokat, fontolja meg az adatbázis exportálását és az exportált fájl tárolását egy olyan tárfiókban, amely blobobjektum-replikációt használ egy másik régióban lévő tárfiókba való replikáláshoz. További információ: Adatbázis exportálása.

A szolgáltatás karbantartásával szembeni rugalmasság

Ha az SQL Database karbantartást hajt végre az adatbázisokon és a rugalmas készleteken, előfordulhat, hogy az adatbázis automatikusan átvált egy másodlagos replikára. Az ügyfélalkalmazások rövid kapcsolati fennakadásokat tapasztalhatnak feladatátvétel esetén. Az ügyfélalkalmazásoknak követniük kell az átmeneti hibákkal szembeni rugalmasság útmutatását a hatások minimalizálása érdekében.

Az SQL Database lehetővé teszi egy karbantartási időszak megadását, amelyet általában a szolgáltatásfrissítésekhez és más karbantartási műveletekhez használnak. A karbantartási időszak konfigurálása segíthet minimalizálni az esetleges mellékhatásokat, például az automatikus feladatátvételt a munkaidőben. A tervezett karbantartásról előzetes értesítést is kaphat.

A platform automatikusan fenntartja az SQL Database-kapcsolatok feldolgozásához használt átjárókat. A frissítési vagy karbantartási műveletek rövid kapcsolati fennakadásokat is okozhatnak, amelyeket az ügyfelek újrapróbálkozhatnak.

További információ: Karbantartás ablak az SQL Database-ben.

Szolgáltatásiszint-szerződés

Az Azure-szolgáltatások szolgáltatásiszint-szerződése (SLA) leírja az egyes szolgáltatások várható elérhetőségét, valamint azokat a feltételeket, amelyeket a megoldásnak teljesítenie kell a rendelkezésre állási elvárás eléréséhez. További információ: SLA-k az online szolgáltatásokhoz.

Az SQL Database szolgáltatásszintű szerződése (SLA) leírja a szolgáltatás várható rendelkezésre állását, valamint az aktív georeplikáció várható helyreállítási pontját és helyreállítási idejét.

Ha zónaredundáns adatbázist vagy rugalmas készletet helyez üzembe, és támogatott szolgáltatási szintet használ, az üzemidejű SLA magasabb.

Kapcsolódó tartalom

  • Last updated on