Migrieren von Datenbankressourcen zu Azure weltweit

Dieser Artikel enthält Informationen dazu, wie Sie Azure-Datenbankressourcen von Azure Deutschland zu Azure weltweit migrieren können.

SQL-Datenbank

Erstellen Sie mit der Exportfunktion eine BACPAC-Datei, um kleinere Azure SQL-Datenbank-Workloads zu migrieren, ohne dass die migrierte Datenbank online bleibt. Eine BACPAC-Datei ist eine komprimierte Datei (ZIP-Datei), die Metadaten und die Daten aus der SQL Server-Datenbank enthält. Nachdem Sie die BACPAC-Datei erstellt haben, können Sie die Datei in die Zielumgebung kopieren (z.B. mit AzCopy) und die Importfunktion verwenden, um die Datenbank erneut zu erstellen. Beachten Sie die folgenden Aspekte:

• Damit ein Export im Hinblick auf Transaktionen konsistent ist, müssen Sie sicherstellen, dass eine der folgenden Bedingungen zutrifft:
  • Während des Exports tritt keine Schreibaktivität auf.
  • Sie exportieren aus einer bezüglich Transaktionen konsistenten Kopie Ihrer Azure SQL-Datenbank.
• Für einen Export in Azure-Blobspeicher ist die Größe der BACPAC-Datei auf 200 GB beschränkt. Führen Sie für größere BACPAC-Datei einen Export in lokalen Speicher aus.
• Falls der Exportvorgang aus der SQL-Datenbank länger als 20 Stunden dauert, wird der Vorgang möglicherweise abgebrochen. Suchen Sie in den folgenden Artikeln nach Tipps, wie die Leistung gesteigert werden kann.

Weitere Informationen finden Sie unter:

• Erfahren Sie, wie Sie eine Datenbank in eine BACPAC-Datei exportieren.
• Erfahren Sie, wie Sie eine BACPAC-Datei in eine neue Datenbank importieren.
• Lesen Sie die Dokumentation zu Azure SQL-Datenbank.

Migrieren einer SQL-Datenbank mithilfe der aktiven Georeplikation

Für Datenbanken, die für BACPAC-Dateien zu groß sind oder von einer Cloud zu einer anderen migriert werden sollen und mit minimalen Ausfallzeiten online bleiben, können Sie die aktive Georeplikation von Azure Deutschland zur globalen Azure-Umgebung konfigurieren.

Ausführliche Informationen zu den Kosten für die aktive Georeplikation finden Sie in Preise für Azure SQL-Datenbank im Abschnitt Aktive Georeplikation.

Zum Migrieren von Datenbanken mit aktiver Georeplikation ist ein logischer Azure SQL-Server in der globalen Azure-Umgebung erforderlich. Sie können den Server im Portal, mit Azure PowerShell, mit der Azure CLI usw. erstellen. Das Konfigurieren der aktiven Georeplikation für die Migration von Azure Deutschland zur globalen Azure-Umgebung wird jedoch nur mithilfe von Transact-SQL (T-SQL) unterstützt.

Mit der ALTER DATABASE-Anweisung können Sie einen Zielserver in der globalen Azure-Umgebung angeben, indem Sie auf der Zielseite den vollqualifizierten DNS-Servernamen verwenden.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]

• sourcedb stellt den Datenbanknamen auf einem Azure SQL-Server in Azure Deutschland dar.
• public-server.database.windows.net stellt den Namen des Azure SQL-Servers dar, der in der globalen Azure-Umgebung vorhanden ist, zu der die Datenbank migriert werden soll. Der Namespace „database.windows.net“ ist erforderlich. Ersetzen Sie public-server durch den Namen des logischen SQL-Servers in der globalen Azure-Umgebung. Der Server in der globalen Azure-Umgebung muss einen anderen Namen aufweisen als der primäre Server in Azure Deutschland.

Der Befehl wird in der Masterdatenbank auf dem Server in Azure Deutschland ausgeführt, der zum Host der zu migrierenden lokalen Datenbank wird.

• Die T-SQL-API zum Starten des Kopiervorgangs authentifiziert den angemeldeten Benutzer auf dem Server in der öffentlichen Cloud. Dies erfolgt durch das Suchen nach einem Benutzer, der in der Masterdatenbank des Servers die gleiche SQL-Anmeldung / den gleichen SQL-Benutzernamen aufweist. Dieser Ansatz ist cloudagnostisch. Daher wird zum Starten cloudübergreifender Kopien die T-SQL-API verwendet. Informationen zu Berechtigungen und weitere Informationen zu diesem Thema finden Sie unter Erstellen und Verwenden der aktiven Georeplikation und ALTER DATABASE (Transact-SQL).

• Mit Ausnahme der anfänglichen T-SQL-Befehlserweiterung zum Angeben eines logischen Azure SQL-Servers in der globalen Azure-Umgebung ist der Rest der aktiven Georeplikation mit der bestehenden Ausführung in der lokalen Cloud identisch. Ausführliche Schritte zum Erstellen einer aktiven Georeplikation finden Sie unter Erstellen und Verwenden der aktiven Georeplikation. Es besteht jedoch der Unterschied, dass die sekundäre Datenbank auf dem sekundären logischen Server erstellt wird, der in der globalen Azure-Umgebung erstellt wurde.

• Sobald die sekundäre Datenbank in der globalen Azure-Umgebung vorhanden ist (als Onlinekopie der Datenbank in Azure Deutschland), kann der Kunde mithilfe des T-SQL-Befehls ALTER DATABASE ein Datenbankfailover von Azure Deutschland zur globalen Azure-Umgebung initiieren (siehe die Tabelle unten).

• Sobald nach dem Failover aus der sekundären Datenbank eine primäre Datenbank in der globalen Azure-Umgebung geworden ist, können Sie die aktive Georeplikation jederzeit beenden und die sekundäre Datenbank in Azure Deutschland entfernen (siehe die folgende Tabelle und die Schritte im Diagramm).

• Nach dem Failover fallen für die sekundäre Datenbank in Azure Deutschland weiterhin Kosten an, bis sie gelöscht wird.

• Die Verwendung des Befehls ALTER DATABASE ist die einzige Möglichkeit, die aktive Georeplikation für die Migration einer Datenbank in Azure Deutschland zur globalen Azure-Umgebung einzurichten.

• Die aktive Georeplikation für diese Migration kann nicht mit dem Azure-Portal, mit Azure Resource Manager, PowerShell oder der CLI konfiguriert werden.

So migrieren Sie eine Datenbank von Azure Deutschland zur globalen Azure-Umgebung:

1. Wählen Sie die Benutzerdatenbank in Azure Deutschland aus, z. B. azuregermanydb

2. Erstellen Sie einen logischen Server in der globalen Azure-Umgebung (in der öffentlichen Cloud), z. B. globalazureserver. Sein vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN) lautet globalazureserver.database.windows.net.

3. Starten Sie die aktive Georeplikation von Azure Deutschland zur globalen Azure-Umgebung, indem Sie auf dem Server in Azure Deutschland diesen T-SQL-Befehl ausführen. Beachten Sie, dass für den öffentlichen Server der vollqualifizierte DNS-Name globalazureserver.database.windows.net verwendet wird. Dadurch wird angegeben, dass sich der Zielserver in der globalen Azure-Umgebung und nicht in Azure Deutschland befindet.

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

4. Um durch die Replikation die Workloads mit Lese-/Schreibzugriff auf den globalen Azure-Server zu verschieben, initiieren Sie ein geplantes Failover zur globalen Azure-Umgebung, indem Sie auf dem globalen Azure-Server den folgenden T-SQL-Befehl ausführen.

   ALTER DATABASE [azuregermanydb] FAILOVER;
   

5. Der aktive Georeplikationslink kann vor oder nach dem Failoverprozess beendet werden. Durch Ausführen des folgenden T-SQL-Befehls nach dem geplanten Failover wird der Georeplikationslink zur Datenbank, die die Kopie mit Lese-/Schreibzugriff ist, in Azure global entfernt. Sie sollte auf dem logischen Server der aktuellen geo-primären Datenbank (d. h. auf dem globalen Azure-Server) ausgeführt werden. Dadurch wird der Migrationsprozess abgeschlossen.

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

   Der folgende T-SQL-Befehl, wenn er vor dem geplanten Failover ausgeführt wird, beendet auch den Migrationsprozess. In diesem Fall bleibt die Datenbank in Azure Deutschland jedoch die Kopie mit Lese-/Schreibzugriff. Dieser T-SQL-Befehl sollte ebenfalls auf dem logischen Server der aktuellen geo-primären Datenbank, in diesem Fall auf dem Azure Deutschland-Server, ausgeführt werden.

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

Diese Schritte zum Migrieren von Azure SQL-Datenbanken von Azure Deutschland zu einer globalen Azure-Umgebung können auch mithilfe der aktiven Georeplikation durchgeführt werden.

In den folgenden Tabellen sind T-SQL-Befehle zum Verwalten des Failovers aufgeführt. Die folgenden Befehle werden für die cloudübergreifende aktive Georeplikation zwischen Azure Deutschland und der globalen Azure-Umgebung unterstützt:

Ansichten des Überwachungssystems für die aktive Georeplikation

Migrieren von Azure SQL-Datenbanksicherungen zur Langzeitaufbewahrung

Beim Migrieren einer Datenbank mit Georeplikation oder BACPAC-Datei werden die Sicherungen zur langfristigen Aufbewahrung, die die Datenbank möglicherweise in Azure Deutschland hat, nicht kopiert. Sie können das Verfahren „Sicherungen zur langfristigen Aufbewahrung KOPIEREN“ verwenden, um derartige vorhandene Sicherungen in die globale Azure-Zielregion zu migrieren

Voraussetzungen

1. Die Zieldatenbank, in die Sie die LTR-Sicherungen kopieren, muss in Azure weltweit vorhanden sein, bevor Sie mit dem Kopieren der Sicherungen beginnen. Es wird empfohlen, zuerst die Quelldatenbank mithilfe der aktiven Georeplikation zu migrieren und dann die LTR-Sicherungskopie zu initiieren. Dadurch wird sichergestellt, dass die Datenbanksicherungen in die richtige Zieldatenbank kopiert werden. Dieser Schritt ist nicht erforderlich, wenn Sie LTR-Sicherungen einer gelöschten Datenbank kopieren. Beim Kopieren von LTR-Sicherungen einer gelöschten Datenbank wird eine Platzhalterdatenbank-ID in der Zielregion erstellt.
2. Installieren Sie dieses PowerShell Az-Modul
3. Stellen Sie vor dem Beginn sicher, dass die erforderlichen Azure RBAC-Rollen im Bereich Abonnement oder Ressourcengruppe erteilt werden. Hinweis: Für den Zugriff auf LTR-Sicherungen, die zu einem gelöschten Server gehören, muss die Berechtigung jedoch im Bereich Abonnement dieses Servers erteilt werden. .

Einschränkungen

• Failovergruppen werden nicht unterstützt. Dies bedeutet, dass Kunden, die Datenbanken aus Azure Deutschland migrieren, während des Failovers die Verbindungszeichenfolgen selbst verwalten müssen.
• Keine Unterstützung für das Azure-Portal, Azure Resource Manager-APIs, PowerShell oder die CLI. Dies bedeutet, dass bei jeder Migration aus Azure Deutschland das Einrichten der aktiven Georeplikation und das Failover über T-SQL erfolgen müssen.
• Kunden können in der globalen Azure-Umgebung nicht mehrere georeplizierte sekundäre Datenbanken für Datenbanken in Azure Deutschland erstellen.
• Die Erstellung einer georeplizierten sekundären Datenbank muss in der Region „Azure Deutschland“ initiiert werden.
• Kunden können Datenbanken aus Azure Deutschland nur zur globalen Azure-Umgebung migrieren. Zurzeit wird keine andere cloudübergreifende Migration unterstützt.
• Azure AD Benutzer in Azure Deutschland-Benutzerdatenbanken werden migriert, sind jedoch im neuen Azure AD-Mandanten, auf dem sich die migrierte Datenbank befindet, nicht verfügbar. Um diese Benutzer zu aktivieren, müssen sie manuell gelöscht und unter Verwendung der aktuellen Azure AD-Benutzer, die in dem neuen Azure AD-Mandanten verfügbar sind, in dem sich die neu migrierte Datenbank befindet, neu erstellt werden.

Kopieren von Sicherungen mit langfristiger Aufbewahrung mit PowerShell

Ein neuer PowerShell-Befehl Copy-AzSqlDatabaseLongTermRetentionBackup wurde eingeführt, der zum Kopieren der von Sicherungen mit langfristiger Aufbewahrung aus Azure Deutschland in globale Azure-Regionen verwendet werden kann.

1. Kopieren der LTR-Sicherung mithilfe des Sicherungsnamens Das folgende Beispiel zeigt, wie Sie eine LTR-Sicherung mithilfe des Sicherungsnamens aus Azure Deutschland in die globale Azure-Region kopieren können.

# 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. Kopieren der LTR-Sicherung mithilfe der Sicherungsressourcen-ID Das folgende Beispiel zeigt, wie Sie eine LTR-Sicherung mithilfe der Sicherungsressourcen-ID aus Azure Deutschland in die globale Azure-Region kopieren können. Dieses Beispiel kann auch zum Kopieren von Sicherungen einer gelöschten Datenbank verwendet werden.

$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

Einschränkungen

• PITR-Sicherungen (Point-in-Time Restore) erfolgen nur in der primären Datenbank. Dies ist beabsichtigt. Beim Migrieren von Datenbanken aus Azure Deutschland mithilfe von georedundanter Notfallwiederherstellung werden nach dem Failover die PITR-Sicherungen in der neuen primären Datenbank ausgeführt. Die vorhandenen PITR-Sicherungen (in der vorherigen primären Datenbank in Azure Deutschland) werden jedoch nicht migriert. Wenn Sie zur Unterstützung von Zeitpunktwiederherstellungen PITR-Sicherungen benötigen, müssen Sie die Datenbank aus den PITR-Sicherungen in Azure Deutschland wiederherstellen und dann die wiederhergestellte Datenbank zu einer globalen Azure-Umgebung migrieren.
• Richtlinien für die Langzeitaufbewahrung werden nicht mit der Datenbank migriert. Wenn Sie über eine Richtlinie für die Langzeitaufbewahrung (Long-term retention, LTR) für Ihre Datenbank in Azure Deutschland verfügen, müssen Sie die LTR-Richtlinie nach der Migration manuell kopieren und in der neuen Datenbank neu erstellen.

Anfordern des Zugriffs

Zum Migrieren einer Datenbank von Azure Deutschland zu einer globalen Azure-Umgebung mithilfe von Georeplikation muss Ihr Abonnement in Azure Deutschland aktiviert sein, damit die cloudübergreifenden Migration erfolgreich konfiguriert werden kann.

Zum Aktivieren Ihres Azure Deutschland-Abonnements müssen Sie über den folgenden Link eine Migrationssupportanfrage erstellen:

1. Navigieren Sie zu der folgenden Migrationssupportanfrage.

2. Geben Sie auf der Registerkarte „Grundlagen“ Migration für georedundante Notfallwiederherstellung als Zusammenfassungein, und klicken Sie dann auf Weiter: Lösungen.

   

3. Überprüfen Sie die Empfohlenen Schritte, und klicken Sie dann auf Weiter: Details.

   

4. Geben Sie auf der Seite „Details“ Folgendes an:

   1. Geben Sie im Feld „Beschreibung“ die Abonnement-ID für die globale Azure-Umgebung ein, zu der migriert werden soll. Um Datenbanken zu mehreren Abonnements zu migrieren, fügen Sie eine Liste der IDs der globalen Azure-Umgebungen hinzu, zu denen Sie Datenbanken migrieren möchten.
   2. Geben Sie Kontaktinformationen an: Name, Firmenname, E-Mail-Adresse oder Telefonnummer.
   3. Füllen Sie das Formular aus. Wählen Sie dann Weiter: Überprüfen + erstellen aus.

   

5. Überprüfen Sie die Supportanfrage, und wählen Sie dann Erstellen aus.

Sie werden benachrichtigt, sobald die Anfrage verarbeitet wurde.

Azure Cosmos DB

Sie können das Azure Cosmos DB-Datenmigrationstool verwenden, um Daten zu Azure Cosmos DB zu migrieren. Das Azure Cosmos DB-Datenmigrationstool ist eine Open-Source-Lösung, mit der Daten aus verschiedenen Quellen in Azure Cosmos DB importiert werden können. Folgende Quellen können verwendet werden: JSON-Dateien, MongoDB, SQL Server, CSV-Dateien, Azure-Tabellenspeicher, Amazon DynamoDB, HBase und Azure Cosmos-Container.

Das Azure Cosmos DB-Datenmigrationstool steht als GUI-Tool oder als Befehlszeilentool zur Verfügung. Der Quellcode ist im GitHub-Repository Azure Cosmos DB Data Migration Tool verfügbar. Eine kompilierte Version des Tools ist im Microsoft Download Center verfügbar.

Um Azure Cosmos DB-Ressourcen zu migrieren, sollten Sie die folgenden Schritte ausführen:

1. Überprüfen Sie die Anforderungen an die Anwendungsbetriebszeit und die Kontokonfigurationen, um den besten Aktionsplan zu bestimmen.
2. Klonen Sie die Kontokonfigurationen aus Azure Deutschland in die neue Region, indem Sie das Datenmigrationstool ausführen.
3. Kann ein Wartungsfenster verwendet werden, kopieren Sie die Daten aus der Quelle in das Ziel, indem Sie das Datenmigrationstool ausführen.
4. Ist es nicht möglich, ein Wartungsfenster zu verwenden, kopieren Sie die Daten aus der Quelle in das Ziel, indem Sie das Tool und dann die folgenden Schritte ausführen:
   1. Verwenden Sie einen konfigurationsgesteuerten Ansatz, um Änderungen an den Lese-/Schreibvorgängen in einer Anwendung vorzunehmen.
   2. Führen Sie eine erstmalige Synchronisierung aus.
   3. Richten Sie eine inkrementelle Synchronisierung ein, und binden Sie den Änderungsfeed ein.
   4. Verknüpfen Sie Lesevorgänge mit dem neuen Konto, und überprüfen Sie die Anwendung.
   5. Beenden Sie Schreibvorgänge in das alte Konto, überprüfen Sie, ob der Änderungsfeed berücksichtigt wird, und verknüpfen Sie dann Schreibvorgänge mit dem neuen Konto.
   6. Beenden Sie das Tool, und löschen Sie das alte Konto.
5. Führen Sie das Tool aus, um zu überprüfen, ob die Daten im alten und im neuen Konto konsistent sind.

Weitere Informationen finden Sie unter:

• Informationen zur Verwendung des Datenmigrationstools finden Sie im Tutorial: Migrieren Ihrer Daten zu Azure Cosmos DB mithilfe des Datenmigrationstools.
• Informationen zu Cosmos DB finden Sie unter Willkommen bei Azure Cosmos DB.

Azure Cache for Redis

Sie haben einige Optionen, wenn Sie eine Azure Cache für Redis-Instanz von Azure Deutschland zu Azure weltweit migrieren möchten. Welche Option Sie auswählen, hängt von Ihren Anforderungen ab.

Option 1: Akzeptieren von Datenverlust, Erstellen einer neuen Instanz

Dieser Ansatz ist am sinnvollsten, wenn die beiden folgenden Bedingungen zutreffen:

• Sie verwenden Azure Cache for Redis als transienten Datencache.
• Ihre Anwendung füllt die Cachedaten in der neuen Region automatisch erneut auf.

So migrieren Sie mit Datenverlust und erstellen Sie eine neue Instanz:

1. Erstellen Sie eine neue Azure Cache for Redis-Instanz in der neuen Zielregion.
2. Ändern Sie Ihre Anwendung so, dass sie die neue Instanz in der neuen Region verwendet.
3. Löschen Sie die alte Azure-Cache für Redis-Instanz in der Quellregion.

Option 2: Kopieren von Daten aus der Quellinstanz in die Zielinstanz

Ein Mitglied des Azure Cache for Redis-Teams hat ein Open-Source-Tool geschrieben, das Daten aus einer Azure Cache for Redis-Instanz in eine andere kopiert, ohne Import- oder Exportfunktionalität zu erfordern. Informationen zu dem Tool finden Sie in Schritt 4 in den folgenden Schritten.

So kopieren Sie Daten aus der Quellinstanz in die Zielinstanz:

1. Erstellen Sie einen virtuellen Computer in der Quellregion. Wenn Ihr Dataset in Azure Cache for Redis groß ist, stellen Sie sicher, dass Sie eine relativ leistungsfähige VM-Größe auswählen, um die für den Kopiervorgang benötigte Zeit zu minimieren.
2. Erstellen Sie eine neue Azure Cache for Redis-Instanz in der Zielregion.
3. Leeren Sie die Daten aus der Ziel-Instanz. (Stellen Sie sicher, dass Sie nicht aus dem Quell-instance leeren. Das Leeren ist erforderlich, da das Kopiertool vorhandene Schlüssel am Zielspeicherort nicht überschreibt.)
4. Verwenden Sie das folgende Tool, um Daten automatisch aus der Azure Cache for Redis-Quellinstanz in die Azure Cache for Redis-Zielinstanz zu kopieren: Quelle des Tools und Tool herunterladen.

Option 3: Exportieren aus der Quellinstanz, Importieren in die Zielinstanz

Bei diesem Ansatz werden die Vorteile von Features genutzt, die nur im Premium-Tarif verfügbar sind.

So exportieren Sie aus der Quellinstanz und importieren Sie in die Zielinstanz:

1. Erstellen Sie im Premium-Tarif eine neue Azure Cache for Redis-Instanz in der Zielregion. Verwenden Sie dieselbe Größe wie für die Azure Cache for Redis-Quellinstanz.

2. Exportieren Sie Daten aus dem Quellcache, oder verwenden Sie das PowerShell-Cmdlet „Export-AzRedisCache“.

   Hinweis

   Das Azure Storage-Exportkonto muss sich in derselben Region wie die Cacheinstanz befinden.

3. Kopieren Sie die exportierten Blobs in ein Speicherkonto in der Zielregion (z. B. mit AzCopy).

4. Importieren Sie Daten in den Zielcache, oder verwenden Sie das PowerShell-Cmdlet „Import-AzRedisCache“.

5. Konfigurieren Sie Ihre Anwendung so, dass sie die Azure Cache for Redis-Zielinstanz verwendet.

Option 4: Schreiben von Daten in zwei Azure Cache for Redis-Instanzen, Lesen aus einer Instanz

Bei diesem Ansatz müssen Sie Ihre Anwendung ändern. Die Anwendung muss Daten in mehrere Cacheinstanzen schreiben, während sie aus einer der Cacheinstanzen liest. Dieser Ansatz ist sinnvoll, wenn die in Azure-Cache für Redis gespeicherten Daten die folgenden Kriterien erfüllen:

• Die Daten werden regelmäßig aktualisiert.
• Alle Daten werden in die Azure Cache for Redis-Zielinstanz geschrieben.
• Es ist genügend Zeit für die Aktualisierung aller Daten verfügbar.

Weitere Informationen finden Sie unter:

• Lesen Sie die Übersicht über Azure-Cache für Redis.

PostgreSQL und MySQL

Weitere Informationen finden Sie in den Artikeln im Abschnitt „Sichern und Migrieren von Daten“ in PostgreSQL und MySQL.

Nächste Schritte

Erfahren Sie mehr über Tools, Techniken und Empfehlungen zum Migrieren von Ressourcen in den folgenden Dienstkategorien:

• Compute
• Netzwerk
• Storage
• Web
• Analyse
• IoT
• Integration
• Identität
• Security
• Verwaltungstools
• Medien