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

Ten artykuł zawiera informacje ułatwiające migrowanie zasobów bazy danych platformy Azure z platformy Azure (Niemcy) do globalnej platformy Azure.

Baza Danych SQL

Aby przeprowadzić migrację mniejszych obciążeń usługi Azure SQL Database bez utrzymywania migrowanej bazy danych w trybie online, użyj funkcji eksportu, aby utworzyć plik BACPAC. Plik BACPAC to skompresowany (spakowany) plik zawierający metadane i dane z bazy danych programu SQL Server. Po utworzeniu pliku BACPAC możesz skopiować plik do środowiska docelowego (na przykład za pomocą 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:
  • W trakcie eksportu nie występują żadne operacje 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 pamięci lokalnej.
• Jeśli operacja eksportowania z usługi 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.

Więcej informacji:

• Dowiedz się, jak wyeksportować bazę danych do pliku BACPAC.
• Dowiedz się, jak zaimportować plik BACPAC do bazy danych.
• Zapoznaj się z dokumentacją usługi Azure SQL Database.

Migrowanie bazy danych 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.

Aby uzyskać szczegółowe informacje na temat aktywnych kosztów replikacji geograficznej, zobacz sekcję zatytułowaną Active geo-replication in Azure SQL Database pricing (Cennikaktywnej replikacji geograficznej w usłudze Azure SQL Database).

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

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]

• sourcedb reprezentuje nazwę bazy danych na serwerze Azure SQL Server w Niemczech.
• public-server.database.windows.net reprezentuje 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ą logicznego serwera SQL na globalnej platformie Azure. Serwer na globalnej platformie Azure musi mieć inną nazwę niż serwer podstawowy na platformie Azure (Niemcy).

Polecenie jest wykonywane na bazie danych master na serwerze Azure w Niemczech, który hostuje lokalną bazę danych przeznaczoną do migracji.

• Interfejs API start-copy 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; dlatego interfejs API języka 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 serwer logiczny Usługi Azure SQL na globalnej platformie Azure, reszta 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 sytuacji, gdy baza danych pomocnicza jest tworzona na pomocniczym serwerze logicznym utworzonym w globalnym Azure.

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

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

• Po przejściu w tryb failover, pomocnicza baza danych w Azure Niemczech będzie nadal generować koszty do momentu usunięcia.

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

• Do skonfigurowania aktywnej replikacji geograficznej dla tej migracji nie jest dostępna witryna 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. Jego 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 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 przejście w tryb failover na globalną platformę 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 lub po procesie awaryjnego przełączenia. Wykonanie następującego polecenia T-SQL po zaplanowanym przejściu w tryb failover spowoduje usunięcie linku replikacji geograficznej z bazą danych na globalnej platformie Azure jako kopią odczytu i zapisu. Powinna być uruchamiana na bieżącym serwerze logicznym 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 T-SQL, wykonywane przed zaplanowanym przejściem w tryb failover, również zatrzymuje proces migracji, ale w takiej sytuacji baza danych w 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 baz danych Azure SQL Database 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ższa tabela przedstawia polecenia T-SQL do zarządzania mechanizmem 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:

Aktywne widoki systemu monitorowania replikacji geograficznej

Migrowanie kopii zapasowych do długoterminowego przechowywania bazy danych SQL

Migrowanie bazy danych z replikacją geograficzną lub plikiem BACPAC nie przenosi kopii zapasowych przechowywanych długoterminowo, które baza danych może posiadać na platformie Azure w Niemczech. Aby przeprowadzić migrację istniejących kopii zapasowych przechowywania długoterminowego do docelowego globalnego regionu świadczenia usługi Azure, możesz użyć procedury kopiowania kopii zapasowej przechowywania długoterminowego.

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 przenosisz kopie zapasowe LTR porzuconej bazy danych. Podczas kopiowania kopii zapasowych LTR usuniętej bazy danych w regionie docelowym zostanie utworzony fikcyjny DatabaseID.
2. Zainstaluj ten moduł Az programu PowerShell
3. Przed rozpoczęciem upewnij się, że wymagane role RBAC w Azure są przyznane w zakresie subskrypcji lub grupy zasobów. Uwaga: Aby uzyskać dostęp do kopii zapasowych LTR należących do usuniętego serwera, uprawnienie musi zostać przyznane w zakresie subskrypcji tego serwera. .

Ograniczenia

• Grupy trybu failover nie są obsługiwane. Oznacza to, że klienci migrujący bazy danych platformy Azure w Niemczech będą musieli samodzielnie zarządzać ciągami połączenia podczas przełączania awaryjnego.
• Brak obsługi witryny Azure Portal, interfejsów API usługi Azure Resource Manager, programu PowerShell lub interfejsu wiersza polecenia. Oznacza to, że każda migracja platformy Azure (Niemcy) będzie musiała zarządzać konfiguracją aktywnej replikacji geograficznej i trybem failover za pośrednictwem języka T-SQL.
• Klienci nie mogą tworzyć wielu serwerów geograficznych w globalnej platformie Azure dla baz danych w Niemczech.
• Tworzenie pomocniczego obszaru geograficznego musi zostać zainicjowane z regionu Azure Niemcy.
• Klienci mogą migrować bazy danych z Azure Niemcy wyłącznie do globalnego Azure. Obecnie nie jest obsługiwana żadna inna migracja między chmurami.
• Użytkownicy usługi Azure AD w bazach danych użytkowników Azure Germany są migrowani, ale nie są dostępni w nowej dzierżawie Azure AD, w której znajduje się zmigrowana baza danych. Aby umożliwić tym użytkownikom, należy ich ręcznie usunąć i ponownie utworzyć, wykorzystując aktualnych użytkowników usługi Azure AD dostępnych w nowej dzierżawie usługi Azure AD, gdzie 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 kopii zapasowych przechowywania długoterminowego z platformy Azure (Niemcy) do regionów globalnych platformy Azure.

1. Kopiowanie kopii zapasowej LTR przy użyciu nazwy kopii zapasowej W poniższym przykładzie pokazano, 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 

2. Kopiowanie kopii zapasowej LTR przy użyciu identyfikatora resourceID kopii zapasowej W poniższym przykładzie pokazano, 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

• Kopie zapasowe do przywracania w punkcie czasu (PITR) są wykonywane tylko w podstawowej bazie danych. Jest to celowe działanie. Podczas migrowania baz danych z platformy Azure Germany przy użyciu funkcji Geo-DR, kopie zapasowe PITR zostaną uruchomione na nowym serwerze podstawowym po failover. Jednak istniejące kopie zapasowe PITR (na poprzednim serwerze głównym w Azure w Niemczech) nie zostaną zmigrowane. Jeśli potrzebujesz kopii zapasowych PITR do obsługi jakichkolwiek scenariuszy przywracania do punktu w czasie, musisz przywrócić bazę danych z kopii zapasowych PITR w regionie Niemcy na platformie Azure, 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 długoterminowego przechowywania (LTR) w bazie danych na platformie Azure (Niemcy), musisz ręcznie skopiować i ponownie utworzyć zasady LTR w nowej bazie 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 (Niemcy), musisz użyć następującego linku, aby utworzyć żądanie obsługi migracji:

1. Przejdź do następującego wniosku o wsparcie dotyczące migracji.

2. Na karcie Podstawowe wprowadź Geo-DR migracja jako Podsumowanie, a następnie wybierz pozycję Dalej: Rozwiązania

   

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

   

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

   1. W polu Opis wprowadź identyfikator globalnej subskrypcji platformy Azure, do której chcemy migrować. 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: Przejrzyj i utwórz.

   

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

Po przetworzeniu żądania skontaktujemy się z tobą.

Azure Cosmos DB (Usługa bazodanowa firmy Microsoft)

Narzędzie do migracji danych usługi Azure Cosmos DB umożliwia migrowanie 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 zsynchronizuj się ze strumieniem zmian.
   4. Skieruj odczyty do nowego konta i zatwierdź aplikację.
   5. Zatrzymaj zapisy na starym koncie, potwierdź, że kanał zmian jest zaktualizowany, a następnie przekieruj zapisy na nowe konto.
   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:

• Aby dowiedzieć się, jak używać narzędzia do migracji danych, zobacz Samouczek: migrowanie danych do usługi Azure Cosmos DB przy użyciu narzędzia do migracji danych.
• Aby dowiedzieć się więcej o usłudze Cosmos DB, zobacz Witamy w usłudze Azure Cosmos DB.

Usługa Azure Cache dla Redis

Istnieje kilka opcji migracji wystąpienia usługi 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ększe znaczenie, gdy oba następujące warunki są spełnione:

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

Aby przeprowadzić migrację ze stratą danych i utworzyć nowe wystąpienie:

1. Stwórz nowe wystąpienie usługi Azure Cache for Redis w nowym regionie docelowym.
2. Zaktualizuj aplikację, aby używała nowej instancji w nowym regionie.
3. Usuń stare wystąpienie usługi 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 usługi Azure Cache for Redis napisał narzędzie typu open source, które kopiuje dane z jednego wystąpienia usługi 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 usłudze 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 usługi Azure Cache for Redis dla regionu docelowego.
3. Opróżnij dane z wystąpienia docelowego . (Pamiętaj, aby nie wyczyścić źródłowego przykładu. Wyczyśczenie 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 usługi Azure Cache for Redis do docelowego wystąpienia usługi Azure Cache for Redis: źródło narzędzia i pobieranie narzędzi.

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ć do wystąpienia docelowego:

1. Utwórz nowe wystąpienie usługi Azure Cache for Redis w warstwie Premium w regionie docelowym. Użyj tego samego rozmiaru co źródłowe wystąpienie usługi Azure Cache for Redis.

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

   Uwaga / Notatka

   Konto eksportowania usługi Azure Storage musi znajdować się w tym samym regionie co instancja pamięci podręcznej.

3. Skopiuj wyeksportowane kontenery do konta magazynu w regionie docelowym (na przykład za pomocą narzędzia AzCopy).

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

5. Skonfiguruj ponownie aplikację tak, aby korzystała z docelowego wystąpienia usługi Azure Cache for Redis.

Opcja 4: Zapisywanie danych w dwóch wystąpieniach usługi Azure Cache for Redis, a odczytywanie z jednego wystąpienia.

W tym podejściu 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 usłudze Azure Cache for Redis spełniają następujące kryteria:

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

Więcej informacji:

• Zapoznaj się z omówieniem usługi Azure Cache for Redis.

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.

Dalsze kroki

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

• Liczyć
• Sieci komputerowe
• Przechowywanie
• Sieć Web
• Analytics
• Iot
• Integracja
• Tożsamość
• Bezpieczeństwo
• Narzędzia zarządzania
• Media