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

A KÖVETKEZŐKRE VONATKOZIK: Azure SQL Database

A RecoveryManager osztály lehetővé teszi az ADO.NET-alkalmazások számára, hogy könnyedén észlelje és kijavítsa a globális szegmenstérkép (FOGJA) és a helyi szegmenstérkép (LSM) közötti inkonzisztenciákat egy horizontálisan skálázható adatbázis-környezetben.

ATV és az LSM egy horizontálisan 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 MIT és az LSM között. Ebben az esetben használja a RecoveryManager osztályt a törés észlelésére és javítására.

A RecoveryManager osztály a ügyféloldali kódtár rugalmas adatbázis része.

Szilánkleképés

A kifejezésdefiníciókat lásd: rugalmas adatbázis eszközök szószedete. Ha szeretné tudni, hogyan kezeli a ShardMapManager a horizontálisan skálázott megoldásokban található adatokat, tekintse meg a Szilánkleképés-kezelésről való használatát.

Miért érdemes a Recovery Managert használni?

Horizontálisan skáláolt adatbázis-környezetben adatbázisonként egy bérlő és kiszolgálónként sok adatbázis található. A környezetben több kiszolgáló is lehet. Minden adatbázis le van leképezve a szegmenstérképen, így a hívások a megfelelő kiszolgálóhoz és adatbázishoz irányíthatóak. Az adatbázisok nyomon követése egy horizontális skálázású kulcs alapján, és minden szegmenshez kulcsértékek egy tartománya van hozzárendelve. Egy horizontális skálázású kulcs például a "D" és az "F" között szereplő ügyfélneveket ábrázolhatja. Az összes szegmens (más néven adatbázis) és azok leképezési tartományának leképezését a globális szegmenstérkép (FOGA) tartalmazza. Minden adatbázis tartalmaz egy térképet is a szegmensen található tartományokról, amely helyi szegmenstérképnek (LSM) is nevezik. Amikor egy alkalmazás csatlakozik egy szegmenshez, a rendszer gyorsítótárazza a leképezést az alkalmazással a gyors lekéréshez. Az LSM a gyorsítótárazott adatok érvényesítésére használható.

Előfordulhat, hogy a RENDSZER- és LSM-szolgáltatás szinkronizálása a következő okok miatt nem lehetséges:

  1. Egy olyan szegmens törlése, amelynek a tartományát úgy tartják, hogy már nincs használatban, vagy a szegmensek át lesznek mászva. A szegmens törlése árva szegmensleképezést ad eredményül. Az átnevezett adatbázisok hasonlóképpen árva szegmensleképezést okozhatnak. A módosítás céljától függően előfordulhat, hogy a szegmenst el kell távolítani, 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íteni kell a kiszolgáló nevét és a szegmenstérkép-kezelő adatbázisnevét az alkalmazásban, majd frissíteni kell a szegmenstérkép ö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 munkafolyamatban. A helyreállítási műveletek automatizálása zökkenőmentes kezelhetőséget tesz lehetővé a földrajzi alapú adatbázisok számára, és elkerüli a manuális emberi műveleteket. Az adatbázisok adatközpont-kimaradás esetén való helyreállításával kapcsolatos további információkért lásd: Üzletmenet-folytonosság és vészhelyreállítás.
  3. A rendszer egy szegmenst vagy a ShardMapManager adatbázist visszaállítja egy korábbi időpontra. Az időponthoz időben, biztonsági másolatokkal való helyreállításról lásd: Helyreállítás biztonsági másolatokkal.

További információ a Azure SQL Database rugalmas adatbázis, a georeplikációról és a visszaállításról:

RecoveryManager beolvasása ShardMapManagerből

Az első lépés egy RecoveryManager-példány létrehozása. A GetRecoveryManager metódus visszaadja az aktuális ShardMapManager-példány helyreállítási kezelőját. A szegmenstérkép inkonzisztenciáinak kezelése érdekében először le kellkérnie az adott szegmenstérkép RecoveryManager-nevét.

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

Ebben a példában a RecoveryManager inicializálása a ShardMapManagerből származik. A ShardMap-leképezéseket tartalmazó ShardMapManager már 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 smmConnectionStringnek) olyan hitelesítő adatoknak kell lennie, amelyek olvasási-írási engedélyekkel rendelkezik a kapcsolati sztring által hivatkozott LETT ADATBÁZISon. Ezek a hitelesítő adatok általában eltérnek az adatfüggő útválasztás kapcsolatainak 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 location paraméter a leválasztott szegmens szegmensének helye, pontosabban a kiszolgálónév é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 is kezelni fog. Választható.

Fontos

Csak akkor használja ezt a technikát, ha biztos benne, hogy a frissített leképezés tartománya üres. A fenti metódusok nem ellenőrzik az átvitt tartomány adatait, ezért a legjobb, ha a kódba is beveszi az ellenőrzéseket.

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

rm.DetachShard(s.Location, customerMap);

A szegmenstérkép a szegmens törlése előtt tükrözi a szegmens helyét aHARD-ban. Mivel a szegmens törölve lett, feltételezhető, hogy szándékos volt, és a horizontális skálázás kulcstartománya már nincs használatban. Ha nem, akkor végrehajthatja az időponthoz időben való visszaállítást. a szegmens korábbi időpontból való helyreállításához. (Ebben az esetben tekintse át a következő szakaszt a szegmensek inkonzisztenciáinak észleléseként.) A helyreállításhoz lásd: Időponthoz időben való helyreállítás.

Mivel feltételezzük, hogy az adatbázis törlése szándékos volt, a végső rendszergazdai törlési művelet a szegmens bejegyzésének törlése a szegmenstérkép-kezelőben. Ez megakadályozza, hogy az alkalmazás véletlenül olyan tartományba írjon adatokat, amely nem várt.

A 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 (A MIT és az LSM).

rm.DetectMappingDifferences(location, shardMapName);
  • A hely adja meg a kiszolgáló é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 is kezelni fog. Választható.

Leképezési különbségek megoldá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 (a VALAMINT és az LSM-et).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);
  • A RecoveryToken paraméter számba veszi az adott szegmensRE vonatkozó, a MIT és az LSM közötti leképezések közötti különbségeket.
  • A MappingDifferenceResolution enumerálás a szegmensleképezések közötti különbség feloldásának metódusát jelzi.
  • MappingDifferenceResolution.KeepShardMapping ajánlott, ha az LSM tartalmazza a pontos leképezést, ezért a szegmensben található leképezést kell használni. Feladatátvétel esetén általában ez történik: a szegmens most már egy új kiszolgálón található. Mivel a szegmenst először el kell távolítani a MIT-ről (a RecoveryManager.DetachShard metódussal), a leképezés már nem létezik a MIT-re. Ezért az LSM-et kell használni a szegmensleképezés újralétrehozására.

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

Az AttachShard metódus a megadott szegmenst csatolja a szegmenstérképhez. Ezután észleli az esetleges szegmenstérkép-inkonzisztenciákat, és frissíti a leképezéseket, hogy megegyeznek a szegmens visszaállítási pontján található szegmenssel. Feltételezzük, hogy az adatbázist is átnevezték, hogy tükrözze az eredeti adatbázisnevet (a szegmens visszaállítása előtt), mivel az időponthoz való visszaállítás alapértelmezett beállítása egy új adatbázis, amely az időbélyegzővel van hozzáfűzve.

rm.AttachShard(location, shardMapName)
  • A location paramé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 is kezelni fog. Választható.

Ez a példa egy szegmenst ad hozzá a szegmenstérképhez, amely nemrég lett visszaállítva egy korábbi időpontból. Mivel a szegmens (azaz az LSM-szegmens leképezése) vissza lett állva, lehetséges, hogy inkonzisztens aHARD bejegyzéssel. A példakódon kívül a szegmenst visszaállították, és átnevezték az adatbázis eredeti nevére. A visszaállítás óta feltételezzük, hogy az LSM-hez 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 elérhetővé válik, és az lesz az új elsődleges adatbázis. A kiszolgáló neve és lehetséges, hogy az adatbázis (a konfigurációtól függően) eltér az eredeti elsődlegestől. Ezért aHARD és az LSM szegmensének leképezési bejegyzései rögzítettek. Hasonlóképpen, ha az adatbázist egy másik névre vagy helyre, vagy egy korábbi időpontra visszaállítják, az inkonzisztenciát okozhat a szegmenstérképek között. A szegmenstérkép-kezelő kezeli a nyitott kapcsolatok elosztását a megfelelő adatbázissal. Az elosztás a szegmenstérképen található adatokon és az alkalmazáskérés céljaként megadott horizontális skálázáskulcs értékén alapul. A geo-feladatátvétel után ezt az információt frissíteni kell a helyreállított adatbázis pontos kiszolgálónevének, adatbázisnevének és szegmensleképezésének megfelelően.

Ajánlott eljárások

A geo-feladatátvételt és helyreállítást általában az alkalmazás felhőalapú rendszergazdája kezeli, és szándékosan használja Azure SQL Database folytonossági funkciókat. Az üzletmenet folytonosságának tervezéséhez folyamatokra, eljárásokra és intézkedésekre van szükség annak érdekében, hogy az üzleti műveletek megszakítás nélkül folytatódni tudjanak. A RecoveryManager osztály részeként elérhető metódusokat ebben a folyamatban kell használni annak érdekében, hogy a GSM és az LSM a helyreállítási művelet alapján naprakész legyen. Öt alapvető lépéssel gondoskodhat arról, hogy a GSM és az LSM megfelelően tükrözze a feladatátvételi események 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 munkafolyamatba.

  1. A RecoveryManager lekérése 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ák észlelése a GSM és az LSM közötti leképezésben.
  5. A GSM és az LSM közötti különbségek megoldása az LSM megbízhatóságának megbékvő megoldásához.

Ez a példa a következő lépéseket végzi el:

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

  2. Szegmenseket csatol a szegmenstérképhez, amelyek az új szegmenshelyeket tükrözik (a "Configuration.SecondaryServer" paraméter az új kiszolgálónév, de ugyanaz az adatbázisnév).

  3. Lekéri a helyreállítási jogkivonatokat úgy, hogy észleli az egyes szegmensek a GSM és az LSM közötti leképezési különbségeket.

  4. Úgy oldja fel az inkonzisztenciákat, hogy megbízik az egyes szegmensek LSM-ének leképezésében.

    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 források

Még nem használ rugalmas adatbázis-eszközöket? Tekintse meg a első lépések útmutatót. Ha kérdése van, kérjük, lépjen kapcsolatba velünk a Microsoft Q&a SQL Database és a szolgáltatások iránti kérések kérdéseit tartalmazó oldalon , adja hozzá őket a SQL Database visszajelzési fórumhoz.