Eseguire la migrazione delle risorse di database ad Azure globale

2021-03-29

Importante

Dal agosto 2018, non sono stati accettati nuovi clienti né sono stati distribuiti nuovi servizi e funzionalità nelle località originali di Microsoft Cloud Germania.

In base all'evoluzione delle esigenze dei clienti, di recente lanciato due nuove aree data center in Germania, offrendo la residenza dei dati dei clienti, la connettività completa alla rete cloud globale di Microsoft, nonché prezzi competitivi sul mercato.

Inoltre, il 30 settembre 2020 è stato annunciato che Microsoft Cloud Germania chiuderà il 29 ottobre 2021. Altri dettagli sono disponibili qui: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

Sfrutta l'ampiezza delle funzionalità, la sicurezza di livello aziendale e le funzionalità avanzate disponibili nelle nuove aree data center tedesche migrando oggi.

Questo articolo contiene informazioni che consentono di eseguire la migrazione delle risorse di database di Azure da Azure Germania ad Azure globale.

SQL Base di dati

Per eseguire la migrazione di carichi di lavoro di database SQL di Azure più piccoli, senza mantenere online il database migrato, usare la funzione di esportazione per creare un file BACPAC. Un file BACPAC è un file compresso (zippato) che contiene i metadati e i dati del SQL Server database. Dopo aver creato il file BACPAC, è possibile copiare il file nell'ambiente di destinazione , ad esempio usando AzCopy, e usare la funzione di importazione per ricompilare il database. Tenere presenti le considerazioni seguenti:

Affinché un'esportazione sia coerente in modo transazionale, assicurarsi che una delle condizioni seguenti sia vera:
- Durante l'esportazione non si verifica alcuna attività di scrittura.
- L'esportazione viene effettuata da una copia del tuo database SQL, coerente a livello transazionale.
Per esportare nell'archivio BLOB di Azure, le dimensioni del file BACPAC sono limitate a 200 GB. Per un file BACPAC di dimensioni maggiori, esportare nell'archiviazione locale.
Se l'operazione di esportazione dal database SQL richiede più di 20 ore, l'operazione potrebbe essere annullata. Per suggerimenti su come migliorare le prestazioni, vedere gli articoli seguenti.

Nota

La stringa di connessione cambia dopo l'operazione di esportazione perché il nome DNS del server cambia durante l'esportazione.

Per altre informazioni:

Scopri come esportare un database in un file BACPAC.
Scopri come importare un file BACPAC in un database.
Esaminare la documentazione del database SQL di Azure .

Nota

È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Eseguire la migrazione del database SQL usando la replica geografica attiva

Per i database troppo grandi per i file BACPAC o per eseguire la migrazione da un cloud a un altro e rimanere online con tempi di inattività minimi, è possibile configurare la replica geografica attiva da Azure Germania ad Azure globale.

Importante

La configurazione della replica geografica attiva per eseguire la migrazione dei database in Azure globale è supportata solo tramite Transact-SQL (T-SQL) e prima della migrazione è necessario richiedere l'abilitazione della sottoscrizione per supportare la migrazione ad Azure globale. Per inviare una richiesta, è necessario usare questo collegamento alla richiesta di supporto.

Nota

Le aree cloud globali di Azure, Germania centro-occidentale e Germania settentrionale, sono le aree supportate per la replica geografica attiva con il cloud di Azure Germania. Se si vuole un'area di Azure globale alternativa come destinazione finale dei database, è consigliabile dopo il completamento della migrazione ad Azure globale configurare un collegamento di replica geografica aggiuntivo dalla Germania occidentale o dalla Germania settentrionale all'area cloud globale di Azure necessaria.

Per informazioni dettagliate sui costi di replica geografica attiva, vedere la sezione intitolata Replica geografica attiva in prezzi del database SQL di Azure.

La migrazione di database con replica geografica attiva richiede un server logico SQL di Azure in Azure globale. È possibile creare il server usando il portale, Azure PowerShell, l'interfaccia della riga di comando di Azure e così via, ma la configurazione della replica geografica attiva per la migrazione da Azure Germania ad Azure globale è supportata solo tramite Transact-SQL (T-SQL).

Importante

Quando si esegue la migrazione tra cloud, i prefissi dei nomi del server primario (Azure Germania) e secondario (Azure globale) devono essere diversi. Se i nomi dei server sono uguali, l'esecuzione dell'istruzione ALTER DATABASE avrà esito positivo, ma la migrazione avrà esito negativo. Ad esempio, se il prefisso del nome del server primario è myserver (myserver.database.cloudapi.de), il prefisso del nome del server secondario in Azure globale non può essere myserver.

L'istruzione ALTER DATABASE consente di specificare un server di destinazione in Azure globale usando il nome completo del server DNS sul lato di destinazione.

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

sourcedb rappresenta il nome del database in un server SQL di Azure in Azure Germania.
public-server.database.windows.net rappresenta il nome del server SQL di Azure esistente in Azure globale, in cui deve essere eseguita la migrazione del database. Lo spazio dei nomi "database.windows.net" è obbligatorio, sostituire server pubblico con il nome del server SQL logico in Azure Global. Il server in Azure globale deve avere un nome diverso rispetto al server primario in Azure Germania.

Il comando viene eseguito nel database master nel server Di Azure Germania che ospita il database locale di cui eseguire la migrazione.

L'API di avvio-copia T-SQL autentica l'utente connesso nel server cloud pubblico trovando un utente con lo stesso nome utente/account di accesso SQL nel database master di tale server. Questo approccio è indipendente dal cloud; pertanto, l'API T-SQL viene usata per avviare copie tra cloud. Per i permessi e ulteriori informazioni su questo argomento, vedere Creazione e utilizzo della replica geografica attiva e ALTER DATABASE (Transact-SQL).
Ad eccezione dell'estensione del comando T-SQL iniziale che indica un server logico SQL di Azure in Azure globale, il resto del processo di replica geografica attiva è identico all'esecuzione esistente nel cloud locale. Per la procedura dettagliata per creare la replica geografica attiva, vedere Creazione e uso della replica geografica attiva con un'eccezione che il database secondario viene creato nel server logico secondario creato in Azure globale.
Quando il database secondario è presente in Azure globale (come copia online del database di Azure Germania), il cliente può avviare un failover del database da Azure Germania ad Azure globale per questo database usando il comando ALTER DATABASE T-SQL (vedere la tabella seguente).
Dopo il failover, una volta che il database secondario diventa un database primario in Azure globale, è possibile arrestare la replica geografica attiva e rimuovere il database secondario sul lato Azure Germania in qualsiasi momento (vedere la tabella seguente e i passaggi presenti nel diagramma).
Dopo il failover, il database secondario in Azure Germania continuerà a comportare costi fino all'eliminazione.
L'uso del comando ALTER DATABASE è l'unico modo per configurare la replica geografica attiva per eseguire la migrazione di un database di Azure Germania ad Azure globale.
Nessun portale di Azure, Azure Resource Manager, PowerShell o l'interfaccia della riga di comando è disponibile per configurare la replica geografica attiva per questa migrazione.

Per eseguire la migrazione di un database da Azure Germania ad Azure globale:

Scegliere il database utente in Azure Germania, ad esempio azuregermanydb
Creare un server logico in Azure globale (cloud pubblico), ad esempio globalazureserver. Il nome di dominio completo (FQDN) è globalazureserver.database.windows.net.
Avviare la replica geografica attiva da Azure Germania ad Azure globale eseguendo questo comando T-SQL nel server in Azure Germania. Si noti che il nome DNS completo viene usato per il server pubblico globalazureserver.database.windows.net. Ciò significa che il server di destinazione si trova in Azure globale e non in Azure Germania.
```
ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];
```
Quando la replica è pronta per spostare il carico di lavoro di lettura/scrittura nel server di Azure globale, avviare un failover pianificato in Azure globale eseguendo questo comando T-SQL nel server di Azure globale.
```
ALTER DATABASE [azuregermanydb] FAILOVER;
```
Il collegamento di replica geografica attiva può essere terminato prima o dopo il processo di failover. L'esecuzione del comando T-SQL seguente dopo il failover pianificato rimuove il collegamento di replica geografica con il database in Azure globale come copia di lettura/scrittura. Deve essere eseguita nel server logico del database geo-primario corrente ,ad esempio nel server globale di Azure. Verrà completato il processo di migrazione.
```
ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];
```
Il comando T-SQL seguente quando viene eseguito prima del failover pianificato arresta anche il processo di migrazione, ma in questa situazione il database in Azure Germania rimarrà la copia di lettura/scrittura. Questo comando T-SQL deve essere eseguito anche nel server logico del database geo-primario corrente, in questo caso nel server Azure Germania.
```
ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];
```

Questi passaggi per eseguire la migrazione di database SQL di Azure da Azure Germania ad Azure globale possono essere seguiti anche usando la replica geografica attiva.

Per altre informazioni, le tabelle seguenti indicano i comandi T-SQL per la gestione del failover. I comandi seguenti sono supportati per la replica geografica attiva tra cloud tra Azure Germania e Azure globale:

Comando	Descrizione
ALTER DATABASE	Usare l'argomento ADD SECONDARY ON SERVER per creare un database secondario per un database esistente e avviare la replica dei dati
ALTER DATABASE	Usare FAILOVER o FORCE_FAILOVER_ALLOW_DATA_LOSS per cambiare un database secondario come primario per avviare il failover
ALTER DATABASE	Usare REMOVE SECONDARY ON SERVER per terminare una replica di dati tra un database SQL e il database secondario specificato.

Visualizzazioni del sistema di monitoraggio della replica geografica attiva

Comando	Descrizione
sys.geo_replication_links	Restituisce informazioni su tutti i collegamenti di replica esistenti per ogni database nel server di database SQL di Azure.
sys.dm_geo_replication_link_status	Ottiene l'ora dell'ultima replica, l'ultimo ritardo della replica e altre informazioni sul collegamento di replica per un determinato database SQL.
sys.dm_operation_status	Mostra lo stato di tutte le operazioni del database, incluso lo stato dei collegamenti di replica.
sp_wait_for_database_copy_sync	Fa sì che l'applicazione attenda che tutte le transazioni di cui è stato eseguito il commit vengano replicate e riconosciute dal database secondario attivo.

Eseguire la migrazione dei backup di conservazione a lungo termine del database SQL

La migrazione di un database con replica geografica o file BACPAC non include i backup a lungo termine che il database potrebbe avere in Azure Germania. Per eseguire la migrazione dei backup di conservazione a lungo termine esistenti nell'area di Azure globale di destinazione, è possibile usare la procedura di backup di conservazione a lungo termine COPY.

Nota

I metodi di copia di backup documentati qui, relativi alla conservazione a lungo termine (LTR), possono copiare solo i backup con conservazione a lungo termine da Azure Germania ad Azure globale. La copia di backup pitr con questi metodi non è supportata.

Prerequisiti

Il database di destinazione dove si sta copiando i backup con LTR, nel cloud globale di Azure, deve esistere prima di iniziare la copia dei backup. Si consiglia di effettuare innanzitutto la migrazione del database di origine usando la replica geografica attiva e quindi avviare la copia di backup LTR. In questo modo si garantisce che i backup del database vengano copiati nel database di destinazione corretto. Questo passaggio non è obbligatorio, se si copiano backup con conservazione a lungo termine di un database eliminato. Quando si copiano i backup a lungo termine di un database eliminato, verrà creato un ID database fittizio nella regione di destinazione.
Installare il modulo Az di PowerShell
Prima di iniziare, assicurarsi che i ruoli di Azure RBAC necessari siano concessi all'ambito sottoscrizione o gruppo di risorse. Nota: per accedere ai backup con conservazione a lungo termine appartenenti a un server eliminato, è necessario concedere l'autorizzazione nell'ambito della sottoscrizione di tale server. .

Limitazioni

I gruppi di failover non sono supportati. Ciò significa che i clienti che eseguono la migrazione di database di Azure Germania dovranno gestire autonomamente le stringhe di connessione durante il failover.
Nessun supporto per il portale di Azure, le API di Azure Resource Manager, PowerShell o l'interfaccia della riga di comando. Ciò significa che ogni migrazione di Azure Germania dovrà gestire la configurazione e il failover della replica geografica attiva tramite T-SQL.
I clienti non possono creare più repliche secondarie geografiche in Azure globale per i database in Azure Germania.
La creazione di un database secondario geografico deve essere avviata dall'area di Azure Germania.
I clienti possono eseguire la migrazione di database da Azure Germania solo ad Azure globale. Attualmente non è supportata alcuna altra migrazione tra cloud.
Gli utenti di Azure AD nei database utente di Azure Germania vengono migrati ma non sono disponibili nel nuovo tenant di Azure AD in cui risiede il database migrato. Per abilitare questi utenti, è necessario eliminarli e ricrearli manualmente usando gli utenti di Azure AD correnti disponibili nel nuovo tenant di Azure AD in cui risiede il database appena migrato.

Copiare i backup di conservazione a lungo termine con PowerShell

È stato introdotto un nuovo comando di PowerShell Copy-AzSqlDatabaseLongTermRetentionBackup, che può essere usato per copiare i backup di conservazione a lungo termine da Azure Germania alle aree globali di Azure.

copiare il backup con conservazione a lungo termine usando il nome del backup L'esempio seguente illustra come copiare un backup con conservazione a lungo termine da Azure Germania all'area globale di Azure utilizzando il nome del backup.

# 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

Copie del backup a lungo termine usando l'ID risorsa di backup L'esempio seguente mostra come copiare un backup a lungo termine da Azure Germania a un'area globale di Azure usando un ID risorsa di backup. Questo esempio può essere usato anche per copiare i backup di un database eliminato.

$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

Limitazioni

I backup di ripristino point-in-time (PITR) vengono eseguiti solo sul database primario, come previsto dal progetto. Quando si esegue la migrazione dei database da Azure Germania usando Geo-DR, i backup PITR inizieranno sul nuovo primario dopo il failover. Tuttavia, i backup PITR esistenti (nel precedente database primario in Azure Germania) non verranno migrati. Se sono necessari backup pitr per supportare gli scenari di ripristino temporizzato, è necessario ripristinare il database dai backup pitr in Azure Germania e quindi eseguire la migrazione del database ripristinato in Azure globale.
I criteri di conservazione a lungo termine non vengono migrati con il database. Se si dispone di un criterio di conservazione a lungo termine (LTR) nel database in Azure Germania, è necessario copiare e ricreare manualmente i criteri di conservazione a lungo termine nel nuovo database dopo la migrazione.

Richiesta di accesso

Per eseguire la migrazione di un database da Azure Germania ad Azure globale usando la replica geografica, è necessario abilitare la sottoscrizione in Azure Germania per configurare correttamente la migrazione tra cloud.

Per abilitare la sottoscrizione di Azure Germania, è necessario usare il collegamento seguente per creare una richiesta di supporto per la migrazione:

Accedere alla seguente richiesta di supporto per la migrazione .
Nella scheda Informazioni di base immettere Geo-DR migrazione come Riepilogoe quindi selezionare Avanti: Soluzioni
Esaminare i passaggi consigliati , quindi selezionare Avanti: Dettagli.
Nella pagina dei dettagli specificare quanto segue:
1. Nella casella Descrizione immettere l'ID sottoscrizione di Azure globale a cui eseguire la migrazione. Per eseguire la migrazione dei database a più sottoscrizioni, aggiungere un elenco degli ID di Azure globali a cui si vuole eseguire la migrazione dei database.
2. Specificare le informazioni di contatto: nome, nome della società, indirizzo di posta elettronica o numero di telefono.
3. Completare il modulo, quindi selezionare Avanti: Rivedi e crea.
Esaminare la richiesta di supporto e quindi selezionare Crea.

Si verrà contattati dopo l'elaborazione della richiesta.

Azure Cosmos DB

È possibile usare lo strumento di migrazione dei dati di Azure Cosmos DB per eseguire la migrazione dei dati ad Azure Cosmos DB. Lo strumento di migrazione dei dati di Azure Cosmos DB è una soluzione open source che importa i dati in Azure Cosmos DB da origini diverse, tra cui file JSON, MongoDB, SQL Server, file CSV, archiviazione tabelle di Azure, Amazon DynamoDB, HBase e contenitori di Azure Cosmos.

Lo strumento di migrazione dei dati di Azure Cosmos DB è disponibile come strumento di interfaccia grafica o come strumento da riga di comando. Il codice sorgente è disponibile nell'Azure Cosmos DB Data Migration Tool repository GitHub. Una versione compilata di dello strumento è disponibile nel Centro download di Microsoft.

Per eseguire la migrazione delle risorse di Azure Cosmos DB, è consigliabile completare la procedura seguente:

Esaminare i requisiti di disponibilità dell'applicazione e le configurazioni dell'account per determinare il piano d'azione migliore.
Clonare le configurazioni dell'account da Azure Germania alla nuova area eseguendo lo strumento di migrazione dei dati.
Se è possibile usare una finestra di manutenzione, copiare i dati dall'origine alla destinazione eseguendo lo strumento di migrazione dei dati.
Se non è possibile utilizzare una finestra di manutenzione, copiate i dati dall'origine alla destinazione eseguendo lo strumento, e quindi completate questi passaggi:
1. Usare un approccio basato su configurazione per apportare modifiche alla lettura/scrittura in un'applicazione.
2. Completare una sincronizzazione per la prima volta.
3. Configurare una sincronizzazione incrementale e aggiornarsi con il feed delle modifiche.
4. Punta al nuovo account e convalida l'applicazione.
5. Ferma le scritture nell'account precedente, verifica che il feed delle modifiche sia aggiornato, e quindi indirizza le scritture al nuovo account.
6. Interrompere lo strumento ed eliminare il vecchio account.
Eseguire lo strumento per verificare che i dati siano coerenti tra gli account precedenti e nuovi.

Per altre informazioni:

Per informazioni su come usare lo strumento di migrazione dei dati, vedere Esercitazione: Usare lo strumento di migrazione dei dati per eseguire la migrazione dei dati ad Azure Cosmos DB.
Per informazioni su Cosmos DB, vedere benvenuto in Azure Cosmos DB.

Cache di Azure per Redis

Sono disponibili alcune opzioni se si vuole eseguire la migrazione di un'istanza di Cache Redis di Azure da Azure Germania ad Azure globale. L'opzione scelta dipende dai requisiti.

Opzione 1: Accettare la perdita di dati, creare una nuova istanza

Questo approccio ha più senso quando entrambe le condizioni seguenti sono vere:

Stai usando Azure Cache per Redis come una cache dei dati temporanei.
L'applicazione ripopolerà automaticamente i dati della cache nella nuova area.

Per eseguire la migrazione con perdita di dati e creare una nuova istanza:

Creare una nuova istanza di Cache Redis di Azure nella nuova area di destinazione.
Aggiornare l'applicazione per usare la nuova istanza nella nuova area.
Eliminare la vecchia istanza di Azure Cache per Redis nella regione di origine.

Opzione 2: Copiare dati dall'istanza di origine all'istanza di destinazione

Un membro del team di Cache Redis di Azure ha scritto uno strumento open source che copia i dati da un'istanza di Cache Redis di Azure a un'altra senza richiedere funzionalità di importazione o esportazione. Per informazioni sullo strumento, vedere il passaggio 4 nei passaggi seguenti.

Per copiare dati dall'istanza di origine all'istanza di destinazione:

Creare una macchina virtuale nell'area di origine. Se il set di dati in Cache Redis di Azure è di grandi dimensioni, assicurarsi di selezionare una dimensione di macchina virtuale relativamente potente per ridurre al minimo il tempo di copia.
Creare una nuova istanza di Cache Redis di Azure nell'area di destinazione.
Purgare i dati dall'istanza del target. Assicurarsi che non svuotare dall'istanza di origine . Lo svuotamento è necessario perché lo strumento di copia non sovrascrive le chiavi esistenti nel percorso di destinazione.
Usare il seguente strumento per copiare automaticamente i dati dall'istanza di origine di Azure Cache per Redis all'istanza di destinazione di Azure Cache per Redis: strumenti sorgente e strumenti di download.

Nota

Questo processo può richiedere molto tempo a seconda delle dimensioni del set di dati.

Opzione 3: Esportare dall'istanza di origine, importare nell'istanza di destinazione

Questo approccio sfrutta le funzionalità disponibili solo nel livello Premium.

Per esportare dall'istanza di origine e importare nell'istanza di destinazione:

Creare una nuova istanza di Cache Redis di Azure di livello Premium nell'area di destinazione. Usare la stessa dimensione dell'istanza di Cache Redis di Azure di origine.
Esportare i dati dalla cache di origine o usare il cmdlet di PowerShell Export-AzRedisCache.

Nota

L'account di esportazione di Azure Storage deve trovarsi nella stessa area dell'istanza della cache.
Copiare i BLOB esportati in un account di archiviazione nell'area di destinazione, ad esempio usando AzCopy.
Importare dati nella cache di destinazione o usare il cmdlet di PowerShell Import-AzRedisCAche.
Riconfigura l'applicazione per usare l'istanza di Cache Redis di Azure di destinazione.

Opzione 4: Scrivere dati in due istanze di Cache Redis di Azure, leggere da un'istanza

Per questo approccio, è necessario modificare l'applicazione. L'applicazione deve scrivere dati in più di un'istanza della cache durante la lettura da una delle istanze della cache. Questo approccio ha senso se i dati archiviati in Cache Redis di Azure soddisfano i criteri seguenti:

I dati vengono aggiornati regolarmente.
Tutti i dati vengono scritti nell'istanza della Cache Redis di Azure di destinazione.
Tempo sufficiente per l'aggiornamento di tutti i dati.

Per altre informazioni:

Esaminare la panoramica di Azure Cache per Redis.

PostgreSQL e MySQL

Per altre informazioni, vedere gli articoli nella sezione "Eseguire il backup e la migrazione dei dati" di PostgreSQL e MySQL.

PostgreSQL e mySQL

Passaggi successivi

Informazioni su strumenti, tecniche e consigli per la migrazione delle risorse nelle categorie di servizio seguenti:

Condividi tramite

Eseguire la migrazione delle risorse di database ad Azure globale

SQL Base di dati

Eseguire la migrazione del database SQL usando la replica geografica attiva

Visualizzazioni del sistema di monitoraggio della replica geografica attiva

Eseguire la migrazione dei backup di conservazione a lungo termine del database SQL

Prerequisiti

Limitazioni

Copiare i backup di conservazione a lungo termine con PowerShell

Limitazioni

Richiesta di accesso

Azure Cosmos DB

Cache di Azure per Redis

Opzione 1: Accettare la perdita di dati, creare una nuova istanza

Opzione 2: Copiare dati dall'istanza di origine all'istanza di destinazione

Opzione 3: Esportare dall'istanza di origine, importare nell'istanza di destinazione

Opzione 4: Scrivere dati in due istanze di Cache Redis di Azure, leggere da un'istanza

PostgreSQL e MySQL

Passaggi successivi

Risorse aggiuntive