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

Horizontális skálázási térképek javítása a RecoveryManager osztállyal

  • Cikk

A következőre vonatkozik: Azure SQL Database

A RecoveryManager osztály lehetővé teszi ADO.NET alkalmazások számára a globális szegmenstérkép (GSM) és a helyi szegmenstérkép (LSM) közötti inkonzisztenciák egyszerű észlelését és kijavítását egy szilánkos adatbázis-környezetben.

A GSM és az LSM skálázott környezetben követi nyomon az egyes adatbázisok leképezését. Időnként szünet következik be a GSM és az LSM között. Ebben az esetben használja a RecoveryManager osztályt a törés észleléséhez és javításához.

A RecoveryManager osztály az Elastic Database ügyfélkódtár része.

Shard map

A kifejezésdefiníciókért lásd az Elastic Database tools szószedetét. Ha szeretné megtudni, hogy a ShardMapManager hogyan kezeli az adatokat egy szegmenses megoldásban, tekintse meg a szegmenstérkép-kezelést.

Miért érdemes a helyreállítási kezelőt használni?

Horizontális adatbázis-környezetben adatbázisonként egy bérlő, kiszolgálónként pedig több adatbázis található. A környezetben számos kiszolgáló is lehet. Minden adatbázis le van képezve a szegmenstérképen, így a hívások a megfelelő kiszolgálóhoz és adatbázishoz irányíthatók. Az adatbázisok skálázási kulcs alapján vannak nyomon követve, és minden szegmenshez kulcsértékek tartománya van hozzárendelve. A skálázási kulcsok például a "D" és az "F" ügyfélneveket jelölhetik. Az összes szegmens (más néven adatbázisok) és leképezési tartományaik leképezése a globális szegmenstérképen (GSM) található. Minden adatbázis tartalmaz egy térképet is a szegmensen található tartományokról, amelyet helyi szegmenstérképnek (LSM) nevezünk. Amikor egy alkalmazás egy szegmenshez csatlakozik, a rendszer gyorsítótárazza a leképezést az alkalmazással a gyors lekérés érdekében. Az LSM a gyorsítótárazott adatok ellenőrzésére szolgál.

A GSM és az LSM a következő okokból válhat szinkronba:

  1. Egy olyan szegmens törlése, amelynek tartományát úgy vélik, hogy már nincs használatban, vagy egy szegmens átnevezése. A szegmensek törlése árva szegmensleképezést eredményez. Hasonlóképpen, az átnevezett adatbázis árva szegmensleképezést is okozhat. A módosítás szándékától függően előfordulhat, hogy el kell távolítani a szegmenst, vagy frissíteni kell a szegmens helyét. Törölt adatbázis helyreállításához lásd : Törölt adatbázis visszaállítása.
  2. Geo feladatátvételi esemény történik. A folytatáshoz frissítenie kell az alkalmazás szegmensleképezési kezelőjének kiszolgálónevét és adatbázisnevét, majd frissítenie kell a szegmensleképezés összes szegmensének szegmensleképezési adatait. Geo-feladatátvétel esetén az ilyen helyreállítási logikát automatizálni kell a feladatátvételi munkafolyamaton belül. A helyreállítási műveletek automatizálása lehetővé teszi a geo-kompatibilis adatbázisok súrlódásmentes kezelhetőségét, és elkerüli a manuális emberi műveleteket. Az adatközpontok kimaradása esetén az adatbázisok helyreállításának lehetőségeiről az Üzletmenet folytonossága és a Vészhelyreállítás című témakörben olvashat.
  3. A rendszer egy szegmenst vagy a ShardMapManager-adatbázist egy korábbi időpontra állítja vissza. A biztonsági másolatok használatával történő időalapú helyreállításról további információt a Biztonsági másolatok használatával történő helyreállítás című témakörben talál.

További információ az Azure SQL Database rugalmas adatbázis-eszközeiről, a georeplikálásról és a visszaállításról:

RecoveryManager lekérése egy ShardMapManagerből

Az első lépés egy RecoveryManager-példány létrehozása. A GetRecoveryManager metódus az aktuális ShardMapManager-példány helyreállítási kezelőjét adja vissza. A szegmenstérképben lévő inkonzisztenciák kezeléséhez először le kell kérnie a RecoveryManagert az adott szegmenstérképhez.

 ShardMapManager smm = ShardMapManagerFactory.GetSqlShardMapManager(smmConnectionString,  
          ShardMapManagerLoadPolicy.Lazy);
          RecoveryManager rm = smm.GetRecoveryManager();

Ebben a példában a RecoveryManager inicializálása a ShardMapManagerből történik. A ShardMap-et tartalmazó ShardMapManager is inicializálva van.

Mivel ez az alkalmazáskód magát a szegmenstérképet módosítja, a gyári metódusban használt hitelesítő adatoknak (az előző példában az smm Csatlakozás ionString) olyan hitelesítő adatoknak kell lenniük, amelyek írás-olvasási engedélyekkel rendelkeznek a kapcsolati sztring által hivatkozott GSM-adatbázisban. Ezek a hitelesítő adatok általában eltérnek az adatfüggő útválasztási kapcsolatok megnyitásához használt hitelesítő adatoktól. További információ: Hitelesítő adatok használata a rugalmas adatbázis-ügyfélben.

Szegmens eltávolítása a szegmenstérképről a szegmens törlése után

A DetachShard metódus leválasztja az adott szegmenst a szegmenstérképről, és törli a szegmenshez társított leképezéseket.

  • A helyparaméter a leválasztott szegmens szegmensének helye, pontosabban a kiszolgáló neve és az adatbázis neve.
  • A shardMapName paraméter a szegmenstérkép neve. Erre csak akkor van szükség, ha ugyanazon szegmenstérkép-kezelő több szegmenstérképet kezel. Opcionális.

Fontos

Ezt a technikát csak akkor használja, ha biztos abban, hogy a frissített leképezés tartománya üres. A fenti metódusok nem ellenőrzik az áthelyezett tartomány adatait, ezért érdemes az ellenőrzéseket belefoglalni a kódba.

Ez a példa eltávolítja a szegmenseket a szegmenstérképről.

rm.DetachShard(s.Location, customerMap);

A szegmenstérkép tükrözi a szegmens helyét a GSM-ben a szegmens törlése előtt. Mivel a szegmens törölve lett, a rendszer feltételezi, hogy szándékos volt, és a skálázási kulcstartomány már nincs használatban. Ha nem, akkor végrehajthatja a pont-idő visszaállítást. a szegmens egy korábbi időpontból való helyreállításához. (Ebben az esetben tekintse át a következő szakaszt a szegmensek inkonzisztenciák észleléséhez.) A helyreállításhoz lásd a pont az idő helyreállítását.

Mivel feltételezzük, hogy az adatbázis törlése szándékos volt, a végleges felügyeleti törlési művelet a szegmensbe való bejegyzés törlése a szegmenstérkép-kezelőben. Ez megakadályozza, hogy az alkalmazás véletlenül olyan tartományba írjon információt, amely nem várt.

Leképezési különbségek észlelése

A DetectMappingDifferences metódus kiválasztja és visszaadja az egyik szegmenstérképet (helyi vagy globális) az igazság forrásaként, és egyezteti a leképezéseket mindkét szegmenstérképen (GSM és LSM).

rm.DetectMappingDifferences(location, shardMapName);
  • A hely megadja a kiszolgáló nevét és az adatbázis nevét.
  • A shardMapName paraméter a szegmenstérkép neve. Erre csak akkor van szükség, ha ugyanazon szegmenstérkép-kezelő több szegmenstérképet kezel. Opcionális.

Leképezési különbségek feloldása

A ResolveMappingDifferences metódus kiválasztja az egyik szegmenstérképet (helyi vagy globális) az igazság forrásaként, és egyezteti a leképezéseket mindkét szegmenstérképen (GSM és LSM).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);
  • A RecoveryToken paraméter felsorolja a GSM és az LSM közötti leképezések különbségeit az adott szegmenshez.
  • A MappingDifferenceResolution enumerálás a szegmensleképezések közötti különbség feloldásának módszerét jelzi.
  • A MappingDifferenceResolution.KeepShardMapping használata ajánlott, ha az LSM tartalmazza a pontos leképezést, és ezért a szegmensben lévő leképezést kell használni. Ez általában akkor fordul elő, ha feladatátvétel történik: a szegmens most egy új kiszolgálón található. Mivel a szegmenst először el kell távolítani a GSM-ből (a RecoveryManager.DetachShard metódus használatával), a leképezés már nem létezik a GSM-en. Ezért az LSM-et kell használni a szegmensleképezés újbóli létrehozásához.

Szegmens csatolása a szegmenstérképhez a szegmens visszaállítása után

Az AttachShard metódus az adott szegmenst a szegmenstérképhez csatolja. Ezután észleli a szegmenstérképek inkonzisztenciáit, és frissíti a leképezéseket, hogy azok megfeleljenek a szegmens helyreállításának helyén lévő szegmensnek. Feltételezzük, hogy az adatbázist is átnevezik az eredeti adatbázis nevére (a szegmens visszaállítása előtt), mivel az időponthoz kötött visszaállítás alapértelmezés szerint egy új, időbélyeggel kiegészített adatbázisra vonatkozik.

rm.AttachShard(location, shardMapName)
  • A helyparaméter a csatolt szegmens kiszolgálóneve és adatbázisneve.
  • A shardMapName paraméter a szegmenstérkép neve. Erre csak akkor van szükség, ha ugyanazon szegmenstérkép-kezelő több szegmenstérképet kezel. Opcionális.

Ez a példa egy szegmenst ad hozzá a szegmenstérképhez, amelyet nemrég állítottak vissza egy korábbi időpontból. Mivel a szegmens (azaz az LSM-ben lévő szegmens leképezése) visszaállítva, lehetséges, hogy inkonzisztens a GSM szegmensbejegyzésével. A példakódon kívül a szegmens visszaállítva és átnevezve lett az adatbázis eredeti nevére. A visszaállítás óta feltételezzük, hogy az LSM-ben a leképezés a megbízható leképezés.

rm.AttachShard(s.Location, customerMap);
var gs = rm.DetectMappingDifferences(s.Location);
   foreach (RecoveryToken g in gs)
    {
    rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
    }

Szegmenshelyek frissítése a szegmensek geo feladatátvétele (visszaállítása) után

Geo-feladatátvétel esetén a másodlagos adatbázis írási akadálymentessé válik, és az új elsődleges adatbázissá válik. A kiszolgáló neve és az adatbázis (a konfigurációtól függően) eltérhet az eredeti elsődlegestől. Ezért a GSM-ben és az LSM-ben lévő szegmens leképezési bejegyzéseit rögzíteni kell. Hasonlóképpen, ha az adatbázist egy másik névre vagy helyre vagy egy korábbi időpontra állítja vissza, az inkonzisztenciákat okozhat a szegmenstérképekben. A Shard Map Manager kezeli a nyitott kapcsolatok megfelelő adatbázishoz való elosztását. A terjesztés a szegmenstérkép adatain és az alkalmazáskérelmek célként szolgáló szilánkkulcsán alapul. A geo feladatátvételt követően ezeket az adatokat frissíteni kell a helyreállított adatbázis pontos kiszolgálónevével, adatbázisnevével és szegmensleképezésével.

Best practices

A geo feladatátvétel és helyreállítás általában az alkalmazás felhő rendszergazdája által felügyelt műveletek, amelyek szándékosan használják az Azure SQL Database üzletmenet-folytonossági funkcióit. Az üzletmenet-folytonossági tervezés folyamatokat, eljárásokat és intézkedéseket igényel annak érdekében, hogy az üzleti műveletek megszakítás nélkül folytatódhassanak. A RecoveryManager osztály részeként elérhető módszereket ebben a munkafolyamatban kell használni annak érdekében, hogy a GSM és az LSM naprakész maradjon a végrehajtott helyreállítási művelet alapján. Öt alapvető lépéssel biztosíthatja, hogy a GSM és az LSM megfelelően tükrözze a feladatátvételi esemény utáni pontos információkat. A lépések végrehajtásához szükséges alkalmazáskód integrálható a meglévő eszközökbe és munkafolyamatokba.

  1. Kérje le a RecoveryManagert a ShardMapManagerből.
  2. Válassza le a régi szegmenst a szegmenstérképről.
  3. Csatolja az új szegmenst a szegmenstérképhez, beleértve az új szegmens helyét is.
  4. Inkonzisztenciákat észlel a GSM és az LSM közötti leképezésben.
  5. Oldja meg a GSM és az LSM közötti különbségeket, bízva az LSM-ben.

Ez a példa a következő lépéseket hajtja végre:

  1. Eltávolítja azokat a szegmenseket a szegmenstérképről, amelyek a feladatátvételi esemény előtti szegmenshelyeket tükrözik.

  2. A szegmenseket az új szegmenshelyeket tükröző szegmenstérképhez csatolja (a "Configuration.SecondaryServer" paraméter az új kiszolgáló neve, de ugyanaz az adatbázisnév).

  3. Lekéri a helyreállítási jogkivonatokat a GSM és az LSM közötti leképezési különbségek észlelésével az egyes szegmensekhez.

  4. Az inkonzisztenciákat úgy oldja meg, hogy megbízik az egyes szegmensek LSM-éből származó leképezésben.

    var shards = smm.GetShards();
foreach (shard s in shards)
{
  if (s.Location.Server == Configuration.PrimaryServer)
      {
       ShardLocation slNew = new ShardLocation(Configuration.SecondaryServer, s.Location.Database);
       rm.DetachShard(s.Location);
       rm.AttachShard(slNew);
       var gs = rm.DetectMappingDifferences(slNew);
       foreach (RecoveryToken g in gs)
         {
            rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
         }
     }
 }

További információforrások

Még nem használ rugalmas adatbázis-eszközöket? Tekintse meg az első lépések útmutatót. Ha kérdése van, lépjen kapcsolatba velünk az SQL Database-hez készült Microsoft Q&A kérdésoldalon, és a funkciókérésekért, adjon hozzá új ötleteket, vagy szavazzon a meglévő ötletekre az SQL Database visszajelzési fórumában.