Przenoszenie zasobów do nowego regionu — Azure SQL Database

Dotyczy: Azure SQL Database

• Azure SQL Database
• Wystąpienie zarządzane Azure SQL
• Program SQL Server na maszynach wirtualnych platformy Azure

W tym artykule przedstawiono ogólny przepływ pracy dotyczący przenoszenia bazy danych lub elastycznej puli do nowego regionu.

Uwaga

• Aby przenieść bazy danych i pule elastyczne do innego regionu świadczenia usługi Azure, możesz również użyć zalecanego usługi Azure Resource Mover.
• Ten artykuł dotyczy migracji w chmurze publicznej platformy Azure lub w tej samej suwerennej chmurze.

Omówienie

Istnieją różne scenariusze, w których chcesz przenieść istniejącą bazę danych lub pulę z jednego regionu do innego. Na przykład rozwijasz swoją firmę w nowym regionie i chcesz zoptymalizować ją pod kątem nowej bazy klientów. Możesz też przenieść operacje do innego regionu ze względów zgodności. Lub platforma Azure wydała nowy region, który zapewnia lepszą bliskość i usprawnia środowisko klienta.

Ogólny przepływ pracy przenoszenia zasobów do innego regionu składa się z następujących kroków:

1. Sprawdź wymagania wstępne dotyczące przenoszenia.
2. Przygotuj się do przeniesienia zasobów w zakresie.
3. Monitoruj proces przygotowywania.
4. Przetestuj proces przenoszenia.
5. Zainicjuj rzeczywisty ruch.

Weryfikowanie wymagań wstępnych w celu przeniesienia bazy danych

1. Utwórz serwer docelowy dla każdego serwera źródłowego.
2. Skonfiguruj zaporę z odpowiednimi wyjątkami przy użyciu programu PowerShell.
3. Skonfiguruj oba serwery przy użyciu poprawnych identyfikatorów logowania. Jeśli nie jesteś administratorem subskrypcji lub administratorem programu SQL Server, skontaktuj się z administratorem, aby przypisać potrzebne uprawnienia. Aby uzyskać więcej informacji, zobacz Jak zarządzać zabezpieczeniami usługi Azure SQL Database po odzyskiwaniu po awarii.
4. Jeśli bazy danych są szyfrowane za pomocą funkcji Transparent Data Encryption (TDE) i przynieś własny klucz szyfrowania (BYOK lub klucz zarządzany przez klienta) w usłudze Azure Key Vault, upewnij się, że prawidłowy materiał szyfrowania jest aprowizowany w regionach docelowych.
   • Najprostszym sposobem jest dodanie klucza szyfrowania z istniejącego magazynu kluczy (używanego jako funkcja ochrony TDE na serwerze źródłowym), a następnie ustawienie klucza jako funkcji ochrony TDE na serwerze docelowym, ponieważ serwer w jednym regionie może być teraz połączony z magazynem kluczy w dowolnym innym regionie.
   • Najlepszym rozwiązaniem jest zapewnienie, że serwer docelowy ma dostęp do starszych kluczy szyfrowania (wymaganych do przywracania kopii zapasowych bazy danych), uruchom polecenie cmdlet Get-AzSqlServerKeyVaultKey na serwerze źródłowym, aby zwrócić listę dostępnych kluczy i dodać te klucze do serwera docelowego.
   • Aby uzyskać więcej informacji i najlepszych rozwiązań dotyczących konfigurowania funkcji TDE zarządzanej przez klienta na serwerze docelowym, zobacz Transparent Data Encryption usługi Azure SQL z kluczami zarządzanymi przez klienta w usłudze Azure Key Vault.
   • Aby przenieść magazyn kluczy do nowego regionu, zobacz Przenoszenie magazynu kluczy platformy Azure między regionami.
5. Jeśli inspekcja na poziomie bazy danych jest włączona, wyłącz ją i włącz inspekcję na poziomie serwera. Po przejściu w tryb failover inspekcja na poziomie bazy danych wymaga ruchu między regionami, który nie jest wymagany lub możliwy po przeniesieniu.
6. W przypadku inspekcji na poziomie serwera upewnij się, że:
   • Kontener magazynu, usługa Log Analytics lub centrum zdarzeń z istniejącymi dziennikami inspekcji jest przenoszony do regionu docelowego.
   • Inspekcja jest skonfigurowana na serwerze docelowym. Aby uzyskać więcej informacji, zobacz Wprowadzenie do inspekcji usługi SQL Database.
7. Jeśli serwer ma zasady przechowywania długoterminowego (LTR), istniejące kopie zapasowe LTR pozostają skojarzone z bieżącym serwerem. Ponieważ serwer docelowy jest inny, możesz uzyskać dostęp do starszych kopii zapasowych LTR w regionie źródłowym przy użyciu serwera źródłowego, nawet jeśli serwer zostanie usunięty.

Uwaga

Migrowanie baz danych z istniejącymi kopiami zapasowymi LTR między regionami suwerennymi i publicznymi nie jest obsługiwane, ponieważ wymaga to przeniesienia kopii zapasowych LTR na serwer docelowy, co nie jest obecnie możliwe.

Przygotowywanie zasobów

1. Utwórz grupę trybu failover między serwerem źródłowym a serwerem obiektu docelowego.
2. Dodaj bazy danych, które chcesz przenieść do grupy trybu failover. Replikacja wszystkich dodanych baz danych jest inicjowana automatycznie. Aby uzyskać więcej informacji, zobacz Używanie grup trybu failover z usługą SQL Database.

Monitorowanie procesu przygotowywania

Można okresowo wywoływać metodę Get-AzSqlDatabaseFailoverGroup , aby monitorować replikację baz danych ze źródła do serwera docelowego. Obiekt Get-AzSqlDatabaseFailoverGroup wyjściowy obiektu zawiera właściwość właściwości ReplicationState:

• ReplicationState = 2 (CATCH_UP) wskazuje, że baza danych jest zsynchronizowana i może być bezpiecznie przełączona w tryb failover.
• ReplicationState = 0 (SEEDING) wskazuje, że baza danych nie jest jeszcze rozstawiona, a próba przełączenia w tryb failover zakończy się niepowodzeniem.

Synchronizacja testów

Po wartości ReplicationState 2 nawiąż połączenie z każdą bazą danych lub podzbiorem baz danych przy użyciu pomocniczego punktu końcowego <fog-name>.secondary.database.windows.net i wykonaj dowolne zapytanie względem baz danych, aby zapewnić łączność, odpowiednią konfigurację zabezpieczeń i replikację danych.

Inicjowanie przeniesienia

1. Nawiąż połączenie z serwerem docelowym przy użyciu pomocniczego punktu końcowego <fog-name>.secondary.database.windows.net.
2. Użyj polecenia Switch-AzSqlDatabaseFailoverGroup , aby przełączyć serwer pomocniczy na podstawowy z pełną synchronizacją. Ta operacja się powiedzie lub cofnie.
3. Sprawdź, czy polecenie zostało wykonane pomyślnie, używając polecenia nslook up <fog-name>.secondary.database.windows.net , aby sprawdzić, czy rekord CNAME dns wskazuje adres IP regionu docelowego. Jeśli polecenie przełącznika zakończy się niepowodzeniem, rekord CNAME nie zostanie zaktualizowany.

Usuwanie źródłowych baz danych

Po zakończeniu przenoszenia usuń zasoby w regionie źródłowym, aby uniknąć niepotrzebnych opłat.

1. Usuń grupę trybu failover przy użyciu polecenia Remove-AzSqlDatabaseFailoverGroup.
2. Usuń każdą źródłową bazę danych przy użyciu polecenia Remove-AzSqlDatabase dla każdej bazy danych na serwerze źródłowym. Spowoduje to automatyczne zakończenie linków replikacji geograficznej.
3. Usuń serwer źródłowy przy użyciu polecenia Remove-AzSqlServer.
4. Usuń magazyn kluczy, przeprowadź inspekcję kontenerów magazynu, centrum zdarzeń, dzierżawy firmy Microsoft Entra i innych zasobów zależnych, aby przestać naliczać opłaty za nie.

Weryfikowanie wymagań wstępnych w celu przeniesienia puli

1. Utwórz serwer docelowy dla każdego serwera źródłowego.
2. Skonfiguruj zaporę z odpowiednimi wyjątkami przy użyciu programu PowerShell.
3. Skonfiguruj serwery przy użyciu prawidłowych identyfikatorów logowania. Jeśli nie jesteś administratorem subskrypcji lub administratorem serwera, skontaktuj się z administratorem, aby przypisać potrzebne uprawnienia. Aby uzyskać więcej informacji, zobacz Jak zarządzać zabezpieczeniami usługi Azure SQL Database po odzyskiwaniu po awarii.
4. Jeśli bazy danych są szyfrowane za pomocą przezroczystego szyfrowania danych i używają własnego klucza szyfrowania w usłudze Azure Key Vault, upewnij się, że prawidłowy materiał szyfrowania jest aprowizowany w regionie docelowym.
5. Utwórz docelową elastyczną pulę dla każdej źródłowej elastycznej puli, upewniając się, że pula została utworzona w tej samej warstwie usługi o tej samej nazwie i tym samym rozmiarze.
6. Jeśli inspekcja na poziomie bazy danych jest włączona, wyłącz ją i włącz inspekcję na poziomie serwera. Po przejściu w tryb failover inspekcja na poziomie bazy danych będzie wymagać ruchu między regionami, który nie jest wymagany lub możliwy po przeniesieniu.
7. W przypadku inspekcji na poziomie serwera upewnij się, że:
   • Kontener magazynu, usługa Log Analytics lub centrum zdarzeń z istniejącymi dziennikami inspekcji jest przenoszony do regionu docelowego.
   • Konfiguracja inspekcji jest skonfigurowana na serwerze docelowym. Aby uzyskać więcej informacji, zobacz Inspekcja usługi SQL Database.
8. Jeśli serwer ma zasady przechowywania długoterminowego (LTR), istniejące kopie zapasowe LTR pozostają skojarzone z bieżącym serwerem. Ponieważ serwer docelowy jest inny, możesz uzyskać dostęp do starszych kopii zapasowych LTR w regionie źródłowym przy użyciu serwera źródłowego, nawet jeśli serwer zostanie usunięty.

Uwaga

Migrowanie baz danych z istniejącymi kopiami zapasowymi LTR między regionami suwerennymi i publicznymi nie jest obsługiwane, ponieważ wymaga to przeniesienia kopii zapasowych LTR na serwer docelowy, co nie jest obecnie możliwe.

Przygotowanie do przeniesienia

1. Utwórz oddzielną grupę trybu failover między każdą elastyczną pulą na serwerze źródłowym a jego odpowiednikiem elastyczną pulą na serwerze docelowym.

2. Dodaj wszystkie bazy danych w puli do grupy trybu failover. Replikacja dodanych baz danych jest inicjowana automatycznie. Aby uzyskać więcej informacji, zobacz Używanie grup trybu failover z usługą SQL Database.

   Uwaga

   Chociaż istnieje możliwość utworzenia grupy trybu failover obejmującej wiele elastycznych pul, zdecydowanie zalecamy utworzenie oddzielnej grupy trybu failover dla każdej puli. Jeśli masz dużą liczbę baz danych w wielu elastycznych pulach, które należy przenieść, możesz uruchomić kroki przygotowania równolegle, a następnie zainicjować krok przenoszenia równolegle. Ten proces jest skalowany lepiej i zajmuje mniej czasu w porównaniu z wieloma elastycznymi pulami w tej samej grupie trybu failover.

Monitorowanie procesu przygotowywania

Można okresowo wywoływać metodę Get-AzSqlDatabaseFailoverGroup , aby monitorować replikację baz danych ze źródła do miejsca docelowego. Obiekt Get-AzSqlDatabaseFailoverGroup wyjściowy obiektu zawiera właściwość właściwości ReplicationState:

• ReplicationState = 2 (CATCH_UP) wskazuje, że baza danych jest zsynchronizowana i może być bezpiecznie przełączona w tryb failover.
• ReplicationState = 0 (SEEDING) wskazuje, że baza danych nie jest jeszcze rozstawiona, a próba przełączenia w tryb failover zakończy się niepowodzeniem.

Synchronizacja testów

Gdy parametr ReplicationState to 2, połącz się z każdą bazą danych lub podzbiorem baz danych przy użyciu pomocniczego punktu końcowego <fog-name>.secondary.database.windows.net i wykonaj dowolne zapytanie względem baz danych, aby zapewnić łączność, odpowiednią konfigurację zabezpieczeń i replikację danych.

Inicjowanie przeniesienia

1. Nawiąż połączenie z serwerem docelowym przy użyciu pomocniczego punktu końcowego <fog-name>.secondary.database.windows.net.
2. Użyj polecenia Switch-AzSqlDatabaseFailoverGroup , aby przełączyć serwer pomocniczy na podstawowy z pełną synchronizacją. Ta operacja zakończy się powodzeniem lub wycofana.
3. Sprawdź, czy polecenie zostało wykonane pomyślnie, używając polecenia nslook up <fog-name>.secondary.database.windows.net , aby sprawdzić, czy rekord CNAME dns wskazuje adres IP regionu docelowego. Jeśli polecenie przełącznika zakończy się niepowodzeniem, rekord CNAME nie zostanie zaktualizowany.

Usuwanie źródłowych elastycznych pul

Po zakończeniu przenoszenia usuń zasoby w regionie źródłowym, aby uniknąć niepotrzebnych opłat.

1. Usuń grupę trybu failover przy użyciu polecenia Remove-AzSqlDatabaseFailoverGroup.
2. Usuń każdą źródłową pulę elastyczną na serwerze źródłowym przy użyciu polecenia Remove-AzSqlElasticPool.
3. Usuń serwer źródłowy przy użyciu polecenia Remove-AzSqlServer.
4. Usuń magazyn kluczy, przeprowadź inspekcję kontenerów magazynu, centrum zdarzeń, dzierżawy firmy Microsoft Entra i innych zasobów zależnych, aby przestać naliczać opłaty za nie.

Następne kroki

Zarządzaj bazą danych po migracji.