Udostępnij za pośrednictwem

Migrowanie zasobów bazy danych na globalną platformę Azure

  • Artykuł

Ważne

Od sierpnia 2018 r. nie akceptujemy nowych klientów ani nie wdrażamy żadnych nowych funkcji i usług w oryginalnych lokalizacjach usługi Microsoft Cloud Germany.

Na podstawie ewolucji potrzeb klientów niedawno uruchomiliśmy dwa nowe regiony centrum danych w Niemczech, oferując miejsce przechowywania danych klientów, pełną łączność z globalną siecią w chmurze firmy Microsoft, a także konkurencyjne ceny rynkowe.

Ponadto 30 września 2020 r. ogłosiliśmy, że usługa Microsoft Cloud Germany zakończy się 29 października 2021 r. Więcej szczegółów można znaleźć tutaj: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

Skorzystaj z szerokiej gamy funkcji, zabezpieczeń klasy korporacyjnej i kompleksowych funkcji dostępnych w naszych nowych regionach niemieckich centrów danych, migrując już dzisiaj.

Ten artykuł zawiera informacje, które mogą ułatwić migrację zasobów bazy danych platformy Azure z platformy Azure (Niemcy) do globalnej platformy Azure.

SQL Database

Aby przeprowadzić migrację mniejszych obciążeń Azure SQL Database, bez przechowywania zmigrowanej bazy danych w trybie online, użyj funkcji export, aby utworzyć plik BACPAC. Plik BACPAC to skompresowany (zip) plik zawierający metadane i dane z bazy danych SQL Server. Po utworzeniu pliku BACPAC możesz skopiować plik do środowiska docelowego (na przykład przy użyciu narzędzia AzCopy) i użyć funkcji import, aby ponownie skompilować bazę danych. Należy pamiętać o następujących kwestiach:

  • Aby eksport był spójny transakcyjnie, upewnij się, że spełniony jest jeden z następujących warunków:
    • Podczas eksportowania nie występuje żadne działanie zapisu.
    • Eksportujesz z transakcyjnie spójnej kopii bazy danych SQL.
  • Aby wyeksportować do usługi Azure Blob Storage, rozmiar pliku BACPAC jest ograniczony do 200 GB. W przypadku większego pliku BACPAC wyeksportuj do magazynu lokalnego.
  • Jeśli operacja eksportowania z SQL Database trwa dłużej niż 20 godzin, operacja może zostać anulowana. Zapoznaj się z następującymi artykułami, aby uzyskać porady dotyczące zwiększania wydajności.

Uwaga

Parametry połączenia zmienia się po operacji eksportowania, ponieważ nazwa DNS serwera zmienia się podczas eksportowania.

Więcej informacji:

Uwaga

Do interakcji z platformą Azure zalecamy używanie modułu Azure Az w programie PowerShell. Zobacz Instalowanie programu Azure PowerShell, aby rozpocząć. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.

Migrowanie SQL Database przy użyciu aktywnej replikacji geograficznej

W przypadku baz danych, które są zbyt duże dla plików BACPAC, lub migracji z jednej chmury do innej i pozostania w trybie online z minimalnym przestojem, można skonfigurować aktywną replikację geograficzną z platformy Azure (Niemcy) do globalnej platformy Azure.

Ważne

Konfigurowanie aktywnej replikacji geograficznej w celu migrowania baz danych na globalną platformę Azure jest obsługiwane tylko przy użyciu języka Transact-SQL (T-SQL), a przed migracją należy zażądać włączenia subskrypcji w celu obsługi migracji na globalną platformę Azure. Aby przesłać żądanie, musisz użyć tego linku do wniosku o pomoc techniczną.

Uwaga

Regiony chmury globalnej platformy Azure, Niemcy Zachodnio-Środkowe i Niemcy Północne, to obsługiwane regiony aktywnej replikacji geograficznej za pomocą chmury Azure (Niemcy). Jeśli alternatywny globalny region świadczenia usługi Azure jest pożądany jako ostateczne miejsce docelowe baz danych, zaleceniem po zakończeniu migracji do globalnej platformy Azure jest skonfigurowanie dodatkowego linku replikacji geograficznej z Regionu Zachodnio-Środkowe Niemcy lub Niemcy Północne do wymaganego globalnego regionu chmury platformy Azure.

Aby uzyskać szczegółowe informacje na temat aktywnych kosztów replikacji geograficznej, zobacz sekcję zatytułowaną Active geo-replication (Aktywna replikacja geograficzna) w witrynie Azure SQL Database pricing (Cennik bazy danych).

Migrowanie baz danych z aktywną replikacją geograficzną wymaga Azure SQL serwera logicznego na globalnej platformie Azure. Serwer można utworzyć przy użyciu portalu, Azure PowerShell, interfejsu wiersza polecenia platformy Azure itp., ale konfigurowanie aktywnej replikacji geograficznej w celu migracji z platformy Azure (Niemcy) na globalną platformę Azure jest obsługiwane tylko przy użyciu języka Transact-SQL (T-SQL).

Ważne

Podczas migracji między chmurami prefiksy nazw serwerów podstawowych (Azure (Niemcy) i pomocniczych (globalnych platformy Azure) muszą być inne. Jeśli nazwy serwerów są takie same, uruchomienie instrukcji ALTER DATABASE powiedzie się, ale migracja zakończy się niepowodzeniem. Jeśli na przykład prefiks nazwy serwera podstawowego to myserver (myserver.database.cloudapi.de), prefiks nazwy serwera pomocniczego na globalnej platformie Azure nie może mieć wartości myserver.

Instrukcja ALTER DATABASE umożliwia określenie serwera docelowego na globalnej platformie Azure przy użyciu w pełni kwalifikowanej nazwy serwera DNS po stronie docelowej.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedbreprezentuje nazwę bazy danych na serwerze Azure SQL na platformie Azure (Niemcy).
  • public-server.database.windows.netreprezentuje nazwę serwera Azure SQL, który istnieje na globalnej platformie Azure, gdzie należy migrować bazę danych. Przestrzeń nazw "database.windows.net" jest wymagana, zastąp publiczny serwer nazwą serwera logicznego SQL na globalnej platformie Azure. Serwer na globalnej platformie Azure musi mieć inną nazwę niż serwer podstawowy na platformie Azure w Niemczech.

Polecenie jest wykonywane na bazie danych master na serwerze platformy Azure (Niemcy) hostowanym lokalną bazę danych do zmigrowania.

  • Interfejs API uruchamiania i kopiowania języka T-SQL uwierzytelnia zalogowanego użytkownika na serwerze chmury publicznej, wyszukując użytkownika o tej samej nazwie logowania/użytkownika SQL w bazie danych master tego serwera. Takie podejście jest niezależne od chmury; W związku z tym interfejs API T-SQL jest używany do uruchamiania kopii między chmurami. Aby uzyskać uprawnienia i więcej informacji na ten temat, zobacz Tworzenie i używanie aktywnej replikacji geograficznej i ALTER DATABASE (Transact-SQL).

  • Z wyjątkiem początkowego rozszerzenia polecenia języka T-SQL wskazującego Azure SQL serwera logicznego na globalnej platformie Azure, pozostała część aktywnego procesu replikacji geograficznej jest identyczna z istniejącym wykonaniem w chmurze lokalnej. Aby uzyskać szczegółowe instrukcje tworzenia aktywnej replikacji geograficznej, zobacz Tworzenie i używanie aktywnej replikacji geograficznej z wyjątkiem tworzenia pomocniczej bazy danych w pomocniczym serwerze logicznym utworzonym na globalnej platformie Azure.

  • Gdy pomocnicza baza danych istnieje na globalnej platformie Azure (jako jej kopia online bazy danych Azure Germany), klient może zainicjować przejście bazy danych w tryb failover z platformy Azure (Niemcy) do globalnej platformy Azure dla tej bazy danych przy użyciu polecenia T-SQL ALTER DATABASE (zobacz poniższą tabelę).

  • Po przejściu w tryb failover, gdy pomocnicza baza danych stanie się podstawową bazą danych na globalnej platformie Azure, możesz zatrzymać aktywną replikację geograficzną i usunąć pomocniczą bazę danych po stronie platformy Azure (Niemcy) w dowolnym momencie (zobacz poniższą tabelę i kroki przedstawione na diagramie).

  • Po przejściu w tryb failover pomocnicza baza danych na platformie Azure w Niemczech będzie nadal ponosić koszty do czasu usunięcia.

  • ALTER DATABASE Użycie polecenia to jedyny sposób konfigurowania aktywnej replikacji geograficznej w celu migrowania bazy danych platformy Azure (Niemcy) do globalnej platformy Azure.

  • Do skonfigurowania aktywnej replikacji geograficznej dla tej migracji nie jest dostępna żadna Azure Portal, usługa Azure Resource Manager, program PowerShell lub interfejs wiersza polecenia.

Aby przeprowadzić migrację bazy danych z platformy Azure (Niemcy) do globalnej platformy Azure:

  1. Wybierz bazę danych użytkownika na platformie Azure (Niemcy), na przykład azuregermanydb

  2. Utwórz serwer logiczny na globalnej platformie Azure (w chmurze publicznej), na przykład globalazureserver. Jej w pełni kwalifikowana nazwa domeny (FQDN) to globalazureserver.database.windows.net.

  3. Uruchom aktywną replikację geograficzną z platformy Azure (Niemcy) do globalnej platformy Azure, wykonując to polecenie T-SQL na serwerze na platformie Azure w Niemczech. Należy pamiętać, że w pełni kwalifikowana nazwa DNS jest używana dla serwera globalazureserver.database.windows.netpublicznego . Oznacza to, że serwer docelowy znajduje się na globalnej platformie Azure, a nie na platformie Azure (Niemcy).

    ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];

  4. Gdy replikacja jest gotowa do przeniesienia obciążenia odczytu i zapisu na globalny serwer platformy Azure, zainicjuj planowane przełączanie awaryjne globalnej platformie Azure, wykonując to polecenie T-SQL na globalnym serwerze platformy Azure.

    ALTER DATABASE [azuregermanydb] FAILOVER;

  5. Aktywne łącze replikacji geograficznej można zakończyć przed procesem trybu failover lub po nim. Wykonanie następującego polecenia języka T-SQL po planowane przełączanie awaryjne usuwa link replikacji geograficznej z bazą danych na globalnej platformie Azure jako kopią do odczytu i zapisu. Powinien on być uruchamiany na serwerze logicznym bieżącej podstawowej bazy danych geograficznej (tj. na globalnym serwerze platformy Azure). Spowoduje to ukończenie procesu migracji.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];

    Następujące polecenie języka T-SQL wykonywane przed planowane przełączanie awaryjne również zatrzymuje proces migracji, ale w takiej sytuacji baza danych na platformie Azure w Niemczech pozostanie kopią do odczytu i zapisu. To polecenie języka T-SQL powinno być również uruchamiane na serwerze logicznym bieżącej podstawowej bazy danych geograficznej, w tym przypadku na serwerze azure (Niemcy).

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];

Te kroki migracji Azure SQL baz danych z platformy Azure (Niemcy) do globalnej platformy Azure można również wykonać przy użyciu aktywnej replikacji geograficznej.

Aby uzyskać więcej informacji, poniższe tabele wskazują polecenia języka T-SQL do zarządzania trybem failover. Następujące polecenia są obsługiwane w przypadku aktywnej replikacji geograficznej między chmurami między platformą Azure (Niemcy) i globalną platformą Azure:

Polecenie Opis
ALTER DATABASE Użyj argumentu ADD SECONDARY ON SERVER, aby utworzyć pomocniczą bazę danych dla istniejącej bazy danych i uruchomić replikację danych
ALTER DATABASE Przełącz pomocniczą bazę danych w tryb failover lub FORCE_FAILOVER_ALLOW_DATA_LOSS, aby zainicjować tryb failover
ALTER DATABASE Użyj polecenia REMOVE SECONDARY ON SERVER, aby zakończyć replikację danych między SQL Database a określoną pomocniczą bazą danych.

Aktywne widoki systemu monitorowania replikacji geograficznej

Polecenie Opis
sys.geo_replication_links Zwraca informacje o wszystkich istniejących łączach replikacji dla każdej bazy danych na serwerze bazy danych Azure SQL.
sys.dm_geo_replication_link_status Pobiera czas ostatniej replikacji, opóźnienie ostatniej replikacji i inne informacje o linku replikacji dla danej bazy danych SQL.
sys.dm_operation_status Pokazuje stan wszystkich operacji bazy danych, w tym stan łączy replikacji.
sp_wait_for_database_copy_sync Powoduje, że aplikacja czeka, aż wszystkie zatwierdzone transakcje zostaną zreplikowane i potwierdzone przez aktywną pomocniczą bazę danych.

Migrowanie SQL Database kopii zapasowych przechowywania długoterminowego

Migrowanie bazy danych z replikacją geograficzną lub plikiem BACPAC nie powoduje skopiowania kopii zapasowych długoterminowego przechowywania, które baza danych może mieć na platformie Azure w Niemczech. Aby przeprowadzić migrację istniejących kopii zapasowych przechowywania długoterminowego do docelowego regionu globalnego platformy Azure, możesz użyć procedury tworzenia kopii zapasowej z długoterminowego przechowywania kopii zapasowej.

Uwaga

Metody kopiowania kopii zapasowych LTR opisane tutaj mogą kopiować tylko kopie zapasowe LTR z platformy Azure (Niemcy) do globalnej platformy Azure. Kopiowanie kopii zapasowych pitr przy użyciu tych metod nie jest obsługiwane.

Wymagania wstępne

  1. Docelowa baza danych, w której kopiujesz kopie zapasowe LTR, na globalnej platformie Azure musi istnieć przed rozpoczęciem kopiowania kopii zapasowych. Zaleca się najpierw przeprowadzenie migracji źródłowej bazy danych przy użyciu aktywnej replikacji geograficznej , a następnie zainicjowanie kopii zapasowej LTR. Zapewni to skopiowanie kopii zapasowych bazy danych do właściwej docelowej bazy danych. Ten krok nie jest wymagany, jeśli kopiujesz kopie zapasowe LTR usuniętej bazy danych. Podczas kopiowania kopii zapasowych LTR usuniętej bazy danych w regionie docelowym zostanie utworzony fikcyjny identyfikator DatabaseID.
  2. Zainstaluj ten moduł Az programu PowerShell
  3. Przed rozpoczęciem upewnij się, że wymagane role RBAC platformy Azure są przyznawane w zakresie subskrypcji lub grupy zasobów . Uwaga: aby uzyskać dostęp do kopii zapasowych LTR należących do usuniętego serwera, należy przyznać uprawnienie w zakresie subskrypcji tego serwera. .

Ograniczenia

  • Grupy trybu failover nie są obsługiwane. Oznacza to, że klienci migrujący bazy danych platformy Azure (Niemcy) będą musieli samodzielnie zarządzać parametrami połączenia podczas pracy w trybie failover.
  • Brak obsługi Azure Portal, interfejsów API usługi Azure Resource Manager, programu PowerShell lub interfejsu wiersza polecenia. Oznacza to, że każda migracja na platformę Azure (Niemcy) będzie musiała zarządzać aktywną konfiguracją replikacji geograficznej i trybem failover za pośrednictwem języka T-SQL.
  • Klienci nie mogą tworzyć wielu serwerów geograficznych na globalnej platformie Azure dla baz danych na platformie Azure w Niemczech.
  • Tworzenie pomocniczego obszaru geograficznego musi zostać zainicjowane z regionu platformy Azure (Niemcy).
  • Klienci mogą migrować bazy danych z platformy Azure (Niemcy) tylko do globalnej platformy Azure. Obecnie nie jest obsługiwana żadna inna migracja między chmurami.
  • Azure AD migrowane bazy danych użytkowników platformy Azure (Niemcy), ale nie są dostępne w nowej dzierżawie Azure AD, w której znajduje się migrowana baza danych. Aby umożliwić tym użytkownikom, muszą zostać ręcznie porzuceni i odtworzeni przy użyciu bieżących użytkowników Azure AD dostępnych w nowej dzierżawie Azure AD, w której znajduje się nowo zmigrowana baza danych.

Kopiowanie kopii zapasowych przechowywania długoterminowego przy użyciu programu PowerShell

Wprowadzono nowe polecenie programu PowerShell Copy-AzSqlDatabaseLongTermRetentionBackup , które może służyć do kopiowania długoterminowych kopii zapasowych przechowywania z platformy Azure (Niemcy) do regionów globalnych platformy Azure.

  1. Kopiowanie kopii zapasowej LTR przy użyciu nazwy kopii zapasowej Poniższy przykład pokazuje, jak skopiować kopię zapasową LTR z platformy Azure (Niemcy) do regionu globalnego platformy Azure przy użyciu nazwy kopii zapasowej.
# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -Location $location 
    -ResourceGroupName $sourceRGName 
    -ServerName $sourceServerName 
    -DatabaseName $sourceDatabaseName
    -BackupName $backupName
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN
  1. Kopiowanie kopii zapasowej LTR przy użyciu identyfikatora resourceID kopii zapasowej Poniższy przykład pokazuje, jak skopiować kopię zapasową LTR z platformy Azure (Niemcy) do regionu globalnego platformy Azure przy użyciu identyfikatora resourceID kopii zapasowej. Ten przykład może służyć do kopiowania kopii zapasowych usuniętej bazy danych.
$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All

# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId

# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -ResourceId $resourceID 
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN

Ograniczenia

  • Tworzenie kopii zapasowych przywracania do punktu w czasie (PITR) odbywa się tylko w podstawowej bazie danych. Jest to zgodnie z założeniami. Podczas migrowania baz danych z platformy Azure (Niemcy) przy użyciu funkcji Geo-DR kopie zapasowe pitr zostaną uruchomione na nowym podstawowym serwerze po przejściu w tryb failover. Jednak istniejące kopie zapasowe pitr (w poprzedniej podstawowej wersji platformy Azure w Niemczech) nie zostaną zmigrowane. Jeśli potrzebujesz kopii zapasowych przywracania do punktu w czasie w celu obsługi scenariuszy przywracania do punktu w czasie, musisz przywrócić bazę danych z kopii zapasowych pitR na platformie Azure w Niemczech, a następnie przeprowadzić migrację odzyskanej bazy danych na globalną platformę Azure.
  • Zasady przechowywania długoterminowego nie są migrowane z bazą danych. Jeśli masz zasady przechowywania długoterminowego (LTR) w bazie danych na platformie Azure (Niemcy), należy ręcznie skopiować i ponownie utworzyć zasady przechowywania długoterminowego dla nowej bazy danych po migracji.

Żądanie dostępu

Aby przeprowadzić migrację bazy danych z platformy Azure (Niemcy) do globalnej platformy Azure przy użyciu replikacji geograficznej, twoja subskrypcja na platformie Azure (Niemcy ) musi zostać włączona, aby pomyślnie skonfigurować migrację między chmurami.

Aby włączyć subskrypcję platformy Azure w Niemczech, musisz użyć następującego linku, aby utworzyć żądanie obsługi migracji:

  1. Przejdź do następującego żądania obsługi migracji.

  2. Na karcie Podstawy wprowadź pozycję Geo-DR migration jako podsumowanie, a następnie wybierz pozycję Dalej: Rozwiązania

    formularz nowego wniosku o pomoc techniczną

  3. Przejrzyj zalecane kroki, a następnie wybierz pozycję Dalej: Szczegóły.

    wymagane informacje o żądaniu pomocy technicznej

  4. Na stronie szczegółów podaj następujące informacje:

    1. W polu Opis wprowadź globalny identyfikator subskrypcji platformy Azure, do których chcesz przeprowadzić migrację. Aby przeprowadzić migrację baz danych do więcej niż jednej subskrypcji, dodaj listę globalnych identyfikatorów platformy Azure, do których chcesz migrować bazy danych.
    2. Podaj informacje kontaktowe: imię i nazwisko, nazwę firmy, adres e-mail lub numer telefonu.
    3. Wypełnij formularz, a następnie wybierz pozycję Dalej: Przeglądanie i tworzenie.

    szczegóły żądania pomocy technicznej

  5. Przejrzyj wniosek o pomoc techniczną, a następnie wybierz pozycję Utwórz.

Skontaktujesz się z tobą po przetworzeniu żądania.

Azure Cosmos DB

Do migrowania danych do usługi Azure Cosmos DB można użyć narzędzia do migracji danych do usługi Azure Cosmos DB. Narzędzie do migracji danych usługi Azure Cosmos DB to rozwiązanie typu open source, które importuje dane do usługi Azure Cosmos DB z różnych źródeł, w tym: pliki JSON, MongoDB, SQL Server, pliki CSV, Azure Table Storage, Amazon DynamoDB, HBase i kontenery usługi Azure Cosmos.

Narzędzie do migracji danych usługi Azure Cosmos DB jest dostępne jako narzędzie interfejsu graficznego lub jako narzędzie wiersza polecenia. Kod źródłowy jest dostępny w repozytorium GitHub narzędzia do migracji danych usługi Azure Cosmos DB . Skompilowana wersja narzędzia jest dostępna w Centrum pobierania Microsoft.

Aby przeprowadzić migrację zasobów usługi Azure Cosmos DB, zalecamy wykonanie następujących kroków:

  1. Przejrzyj wymagania dotyczące czasu pracy aplikacji i konfiguracje kont, aby określić najlepszy plan działania.
  2. Sklonuj konfiguracje kont z platformy Azure (Niemcy) do nowego regionu, uruchamiając narzędzie do migracji danych.
  3. Jeśli jest możliwe użycie okna obsługi, skopiuj dane ze źródła do miejsca docelowego, uruchamiając narzędzie do migracji danych.
  4. Jeśli użycie okna obsługi nie jest opcją, skopiuj dane ze źródła do miejsca docelowego, uruchamiając narzędzie, a następnie wykonaj następujące kroki:
    1. Użyj podejścia opartego na konfiguracji, aby wprowadzić zmiany w celu odczytu/zapisu w aplikacji.
    2. Ukończ synchronizację po raz pierwszy.
    3. Skonfiguruj synchronizację przyrostową i nadrobij zaległości w kanale zmian.
    4. Punkt odczytuje nowe konto i weryfikuje aplikację.
    5. Zatrzymaj zapisy na starym koncie, sprawdź, czy źródło zmian zostało przechwycone, a następnie wskaż zapis na nowym koncie.
    6. Zatrzymaj narzędzie i usuń stare konto.
  5. Uruchom narzędzie, aby sprawdzić, czy dane są spójne na starych i nowych kontach.

Więcej informacji:

Azure Cache for Redis

Istnieje kilka opcji migracji wystąpienia Azure Cache for Redis z platformy Azure (Niemcy) do globalnej platformy Azure. Wybrana opcja zależy od wymagań.

Opcja 1. Akceptowanie utraty danych, tworzenie nowego wystąpienia

Takie podejście ma największy sens, gdy spełnione są oba następujące warunki:

  • Używasz Azure Cache for Redis jako przejściowej pamięci podręcznej danych.
  • Aplikacja będzie ponownie wypełniać dane pamięci podręcznej automatycznie w nowym regionie.

Aby przeprowadzić migrację z powodu utraty danych i utworzyć nowe wystąpienie:

  1. Utwórz nowe wystąpienie Azure Cache for Redis w nowym regionie docelowym.
  2. Zaktualizuj aplikację, aby korzystała z nowego wystąpienia w nowym regionie.
  3. Usuń stare wystąpienie Azure Cache for Redis w regionie źródłowym.

Opcja 2. Kopiowanie danych z wystąpienia źródłowego do wystąpienia docelowego

Członek zespołu Azure Cache for Redis napisał narzędzie open source, które kopiuje dane z jednego wystąpienia Azure Cache for Redis do innego bez konieczności importowania lub eksportowania funkcji. Aby uzyskać informacje o narzędziu, zobacz krok 4 w poniższych krokach.

Aby skopiować dane z wystąpienia źródłowego do wystąpienia docelowego:

  1. Utwórz maszynę wirtualną w regionie źródłowym. Jeśli zestaw danych w Azure Cache for Redis jest duży, upewnij się, że wybrano stosunkowo zaawansowany rozmiar maszyny wirtualnej, aby zminimalizować czas kopiowania.
  2. Utwórz nowe wystąpienie Azure Cache for Redis w regionie docelowym.
  3. Opróżnij dane z wystąpienia docelowego . (Pamiętaj, aby nie opróżnić wystąpienia źródłowego . Opróżnianie jest wymagane, ponieważ narzędzie do kopiowania nie zastępuje istniejących kluczy w lokalizacji docelowej).
  4. Użyj następującego narzędzia, aby automatycznie skopiować dane ze źródłowego wystąpienia Azure Cache for Redis do wystąpienia docelowego Azure Cache for Redis: Źródło narzędzia i pobieranie narzędzi.

Uwaga

Ten proces może zająć dużo czasu w zależności od rozmiaru zestawu danych.

Opcja 3. Eksportowanie z wystąpienia źródłowego, importowanie do wystąpienia docelowego

Takie podejście korzysta z funkcji, które są dostępne tylko w warstwie Premium.

Aby wyeksportować z wystąpienia źródłowego i zaimportować je do wystąpienia docelowego:

  1. Utwórz nową warstwę Premium Azure Cache for Redis wystąpienie w regionie docelowym. Użyj tego samego rozmiaru co wystąpienie Azure Cache for Redis źródłowego.

  2. Wyeksportuj dane z źródłowej pamięci podręcznej lub użyj polecenia cmdlet programu PowerShell Export-AzRedisCache.

    Uwaga

    Konto usługi Azure Storage eksportu musi znajdować się w tym samym regionie co wystąpienie pamięci podręcznej.

  3. Skopiuj wyeksportowane obiekty blob do konta magazynu w regionie docelowym (na przykład przy użyciu narzędzia AzCopy).

  4. Zaimportuj dane do docelowej pamięci podręcznej lub użyj polecenia cmdlet Import-AzRedisCAche programu PowerShell.

  5. Skonfiguruj ponownie aplikację, aby używała docelowego wystąpienia Azure Cache for Redis.

Opcja 4. Zapisywanie danych w dwóch wystąpieniach Azure Cache for Redis odczytanych z jednego wystąpienia

W przypadku tego podejścia należy zmodyfikować aplikację. Aplikacja musi zapisywać dane w więcej niż jednym wystąpieniu pamięci podręcznej podczas odczytywania z jednego z wystąpień pamięci podręcznej. Takie podejście ma sens, jeśli dane przechowywane w Azure Cache for Redis spełniają następujące kryteria:

  • Dane są regularnie odświeżane.
  • Wszystkie dane są zapisywane w wystąpieniu Azure Cache for Redis docelowym.
  • Masz wystarczająco dużo czasu na odświeżenie wszystkich danych.

Więcej informacji:

Bazy danych PostgreSQL i MySQL

Aby uzyskać więcej informacji, zobacz artykuły w sekcji "Tworzenie kopii zapasowych i migrowanie danych" w usługach PostgreSQL i MySQL.

Bazy danych PostgreSQL i MySQL

Następne kroki

Dowiedz się więcej o narzędziach, technikach i zaleceniach dotyczących migrowania zasobów w następujących kategoriach usług: