Używanie klasy RecoveryManager do rozwiązywanie problemów z mapą fragmentów

Dotyczy: Azure SQL Database

Klasa RecoveryManager zapewnia ADO.NET aplikacjom możliwość łatwego wykrywania i poprawiania wszelkich niespójności między globalną mapą fragmentów (GSM) a lokalną mapą fragmentów (LSM) w środowisku bazy danych podzielonej na fragmenty.

GSM i LSM śledzą mapowanie każdej bazy danych w środowisku podzielonym na fragmenty. Od czasu do czasu następuje przerwa między GSM a LSM. W takim przypadku użyj klasy RecoveryManager, aby wykryć i naprawić przerwę.

Klasa RecoveryManager jest częścią biblioteki klienta elastic database.

Aby zapoznać się z definicjami terminów, zobacz Słownik narzędzi elastycznych baz danych. Aby dowiedzieć się, jak narzędzie ShardMapManager służy do zarządzania danymi w rozwiązaniu podzielonym na fragmenty, zobacz Zarządzanie mapami fragmentów.

Dlaczego warto używać menedżera odzyskiwania

W środowisku bazy danych podzielonej na fragmenty istnieje jedna dzierżawa na bazę danych i wiele baz danych na serwer. W środowisku może być również wiele serwerów. Każda baza danych jest mapowana na mapie fragmentów, więc wywołania mogą być kierowane do poprawnego serwera i bazy danych. Bazy danych są śledzone zgodnie z kluczem fragmentowania, a każdy fragment ma przypisany zakres wartości klucza. Na przykład klucz fragmentowania może reprezentować nazwy klientów z "D" do "F". Mapowanie wszystkich fragmentów (znanych również jako bazy danych) i ich zakresów mapowania znajduje się w globalnej mapie fragmentów (GSM). Każda baza danych zawiera również mapę zakresów zawartych na fragmentach nazywanych lokalną mapą fragmentów (LSM). Gdy aplikacja łączy się z fragmentem, mapowanie jest buforowane za pomocą aplikacji w celu szybkiego pobierania. LSM służy do sprawdzania poprawności danych w pamięci podręcznej.

Urządzenia GSM i LSM mogą nie być zsynchronizowane z następujących powodów:

1. Usunięcie fragmentu, którego zakres nie jest już używany, ani zmiana nazwy fragmentu. Usunięcie fragmentu powoduje mapowanie oddzielonych fragmentów. Podobnie zmieniona baza danych może spowodować mapowanie oddzielonych fragmentów. W zależności od intencji zmiany może być konieczne usunięcie fragmentu lub zaktualizowanie lokalizacji fragmentu. Aby odzyskać usuniętą bazę danych, zobacz Przywracanie usuniętej bazy danych.
2. Odbywa się zdarzenie geograficznego trybu failover. Aby kontynuować, należy zaktualizować nazwę serwera i nazwę bazy danych menedżera map fragmentów w aplikacji, a następnie zaktualizować szczegóły mapowania fragmentów dla wszystkich fragmentów na mapie fragmentów. Jeśli istnieje tryb geo-failover, taka logika odzyskiwania powinna zostać zautomatyzowana w przepływie pracy trybu failover. Automatyzacja akcji odzyskiwania umożliwia bezproblemowe zarządzanie bazami danych z włączoną obsługą geograficzną i pozwala uniknąć ręcznych akcji ludzkich. Aby dowiedzieć się więcej o opcjach odzyskiwania bazy danych w przypadku awarii centrum danych, zobacz Business Continuity and Disaster Recovery (Ciągłość działania i odzyskiwanie po awarii).
3. Fragment lub baza danych ShardMapManager jest przywracana do wcześniejszego punktu w czasie. Aby dowiedzieć się więcej o odzyskiwaniu do punktu w czasie przy użyciu kopii zapasowych, zobacz Odzyskiwanie przy użyciu kopii zapasowych.

Aby uzyskać więcej informacji na temat narzędzi elastycznej bazy danych Azure SQL Database, replikacji geograficznej i przywracania, zobacz następujące tematy:

• Omówienie: ciągłość działania w chmurze i odzyskiwanie po awarii bazy danych za pomocą usługi SQL Database
• Wprowadzenie do narzędzi elastycznej bazy danych
• Zarządzanie mapami fragmentów

Pobieranie elementu RecoveryManager z elementu ShardMapManager

Pierwszym krokiem jest utworzenie wystąpienia programu RecoveryManager. Metoda GetRecoveryManager zwraca menedżera odzyskiwania dla bieżącego wystąpienia ShardMapManager. Aby rozwiązać wszelkie niespójności na mapie fragmentów, należy najpierw pobrać menedżera odzyskiwania dla określonej mapy fragmentów.

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

W tym przykładzie menedżer odzyskiwania jest inicjowany z narzędzia ShardMapManager. Element ShardMapManager zawierający element ShardMap jest również już zainicjowany.

Ponieważ ten kod aplikacji manipuluje samą mapą fragmentów, poświadczenia używane w metodzie fabryki (w poprzednim przykładzie smmConnectionString) powinny być poświadczeniami, które mają uprawnienia do odczytu i zapisu w bazie danych GSM, do których odwołuje się parametry połączenia. Te poświadczenia zazwyczaj różnią się od poświadczeń używanych do otwierania połączeń na potrzeby routingu zależnego od danych. Aby uzyskać więcej informacji, zobacz Używanie poświadczeń w kliencie elastycznej bazy danych.

Usuwanie fragmentu z elementu ShardMap po usunięciu fragmentu

Metoda DetachShard odłącza dany fragment od mapy fragmentu i usuwa mapowania skojarzone z fragmentem.

• Parametr lokalizacji to lokalizacja fragmentu, w szczególności nazwa serwera i nazwa bazy danych, odłączony fragment.
• Parametr shardMapName jest nazwą mapy fragmentu. Jest to wymagane tylko wtedy, gdy wiele map fragmentów jest zarządzanych przez tego samego menedżera mapy fragmentów. Opcjonalny.

Ważne

Ta technika jest używana tylko wtedy, gdy masz pewność, że zakres zaktualizowanego mapowania jest pusty. Powyższe metody nie sprawdzają danych dla przenoszonego zakresu, dlatego najlepiej uwzględnić kontrole w kodzie.

W tym przykładzie usunięto fragmenty z mapy fragmentów.

rm.DetachShard(s.Location, customerMap);

Mapa fragmentów odzwierciedla lokalizację fragmentu w GSM przed usunięciem fragmentu. Ponieważ fragment został usunięty, zakłada się, że jest to zamierzone, a zakres kluczy fragmentowania nie jest już używany. Jeśli nie, możesz wykonać przywracanie do punktu w czasie. w celu odzyskania fragmentu z wcześniejszego punktu w czasie. (W takim przypadku przejrzyj następującą sekcję, aby wykryć niespójności fragmentów). Aby odzyskać, zobacz Odzyskiwanie do punktu w czasie.

Ponieważ zakłada się, że usunięcie bazy danych było zamierzone, ostateczną akcją oczyszczania administracyjnego jest usunięcie wpisu do fragmentu w menedżerze mapy fragmentów. Dzięki temu aplikacja nieumyślnie zapisuje informacje w zakresie, który nie jest oczekiwany.

Aby wykryć różnice mapowania

Metoda DetectMappingDifferences wybiera i zwraca jedną z map fragmentów (lokalną lub globalną) jako źródło prawdy i uzgadnia mapowania na obu mapach fragmentów (GSM i LSM).

rm.DetectMappingDifferences(location, shardMapName);

• Lokalizacja określa nazwę serwera i nazwę bazy danych.
• Parametr shardMapName jest nazwą mapy fragmentu. Jest to wymagane tylko wtedy, gdy wiele map fragmentów jest zarządzanych przez tego samego menedżera mapy fragmentów. Opcjonalny.

Aby rozwiązać problemy z różnicami mapowania

Metoda ResolveMappingDifferences wybiera jedną z map fragmentów (lokalną lub globalną) jako źródło prawdy i uzgadnia mapowania na obu mapach fragmentów (GSM i LSM).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);

• Parametr RecoveryToken wylicza różnice w mapowaniach między gsm i LSM dla określonego fragmentu.
• Wyliczenie MappingDifferenceResolution służy do wskazywania metody rozpoznawania różnicy między mapowaniami fragmentów.
• MappingDifferenceResolution.KeepShardMapping zaleca się, aby w przypadku, gdy LSM zawiera dokładne mapowanie i dlatego należy użyć mapowania w fragmentach. Dzieje się tak zwykle w przypadku przejścia w tryb failover: fragment znajduje się teraz na nowym serwerze. Ponieważ fragment musi zostać najpierw usunięty z systemu GSM (przy użyciu metody RecoveryManager.DetachShard), mapowanie nie istnieje już na serwerze GSM. W związku z tym LSM musi służyć do ponownego ustanowienia mapowania fragmentów.

Dołączanie fragmentu do obiektu ShardMap po przywróceniu fragmentu

Metoda AttachShard dołącza dany fragment do mapy fragmentu. Następnie wykrywa wszelkie niespójności mapowania fragmentów i aktualizuje mapowania, aby pasować do fragmentu w momencie przywracania fragmentu. Przyjmuje się, że nazwa bazy danych została również zmieniona tak, aby odzwierciedlała oryginalną nazwę bazy danych (przed przywróceniem fragmentu), ponieważ przywracanie do punktu w czasie jest domyślnie przywracane do nowej bazy danych dołączonej przy użyciu znacznika czasu.

rm.AttachShard(location, shardMapName)

• Parametr lokalizacji to nazwa serwera i nazwa bazy danych, dołączanego fragmentu.
• Parametr shardMapName jest nazwą mapy fragmentu. Jest to wymagane tylko wtedy, gdy wiele map fragmentów jest zarządzanych przez tego samego menedżera mapy fragmentów. Opcjonalny.

W tym przykładzie dodano fragment do mapy fragmentów, która została niedawno przywrócona z wcześniejszego punktu w czasie. Ponieważ fragment (a mianowicie mapowanie fragmentu w LSM) został przywrócony, jest potencjalnie niespójny z wpisem fragmentu w GSM. Poza tym przykładowym kodem fragment został przywrócony i zmieniono nazwę na oryginalną nazwę bazy danych. Ponieważ został przywrócony, przyjmuje się, że mapowanie w maszynie LSM jest zaufanym mapowaniem.

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

Aktualizowanie lokalizacji fragmentów po przełączeniu geograficznego w tryb failover (przywracanie) fragmentów

Jeśli istnieje tryb failover geograficznie, pomocnicza baza danych zostanie udostępniona do zapisu i stanie się nową podstawową bazą danych. Nazwa serwera i potencjalnie baza danych (w zależności od konfiguracji) może być inna niż oryginalna podstawowa. W związku z tym należy naprawić wpisy mapowania fragmentu w dyskach GSM i LSM. Podobnie, jeśli baza danych zostanie przywrócona do innej nazwy lub lokalizacji lub do wcześniejszego punktu w czasie, może to spowodować niespójności w mapach fragmentów. Menedżer map fragmentów obsługuje dystrybucję otwartych połączeń z poprawną bazą danych. Dystrybucja jest oparta na danych na mapie fragmentów i wartości klucza fragmentowania, który jest elementem docelowym żądania aplikacji. Po przejściu w tryb failover geograficznego te informacje muszą zostać zaktualizowane przy użyciu dokładnej nazwy serwera, nazwy bazy danych i mapowania fragmentów odzyskanej bazy danych.

Najlepsze rozwiązania

Tryb failover i odzyskiwanie geograficzne są operacjami zwykle zarządzanymi przez administratora chmury aplikacji celowo korzystającej z funkcji ciągłości działania usługi Azure SQL Database. Planowanie ciągłości działania wymaga procesów, procedur i miar w celu zapewnienia, że operacje biznesowe mogą być kontynuowane bez przerw. Metody dostępne w ramach klasy RecoveryManager powinny być używane w tym przepływie pracy, aby upewnić się, że gsm i LSM są aktualne na podstawie podjętej akcji odzyskiwania. Istnieje pięć podstawowych kroków właściwego zapewnienia GSM i LSM odzwierciedla dokładne informacje po zdarzeniu trybu failover. Kod aplikacji do wykonania tych kroków można zintegrować z istniejącymi narzędziami i przepływem pracy.

1. Pobierz menedżera odzyskiwania z menedżera ShardMapManager.
2. Odłącz stary fragment od mapy fragmentu.
3. Dołącz nowy fragment do mapy fragmentu, w tym nową lokalizację fragmentu.
4. Wykrywaj niespójności w mapowaniu między systemem GSM i LSM.
5. Rozwiąż różnice między GSM i LSM, ufając LSM.

W tym przykładzie są wykonywane następujące kroki:

1. Usuwa fragmenty z mapy fragmentów, która odzwierciedla lokalizacje fragmentów przed zdarzeniem trybu failover.

2. Dołącza fragmenty do mapy fragmentów odzwierciedlające nowe lokalizacje fragmentów (parametr "Configuration.SecondaryServer" to nowa nazwa serwera, ale ta sama nazwa bazy danych).

3. Pobiera tokeny odzyskiwania, wykrywając różnice mapowania między serwerem GSM a maszyną LSM dla każdego fragmentu.

4. Rozwiązuje niespójności, ufając mapowaniu z maszyny LSM każdego fragmentu.

   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);
            }
        }
    }
   

Powiązana zawartość

Jeszcze nie korzystasz z narzędzi elastycznych baz danych? Zapoznaj się z naszym przewodnikiem Wprowadzenie. W przypadku pytań skontaktuj się z nami na stronie pytań i odpowiedzi dotyczących usługi SQL Database oraz w przypadku żądań funkcji, dodaj nowe pomysły lub zagłosuj na istniejące pomysły na forum opinii usługi SQL Database.