Pianificazione della migrazione da MongoDB a Cosmos DB

Completato

Dopo aver esaminato i vantaggi di Cosmos DB, il CIO ha dato il vantaggio di eseguire un modello di verifica. La prima fase del progetto consiste nel pianificare la migrazione dei dati. Ciò includerà la configurazione di un cosmos DB vuoto per ospitare i dati migrati.

In questa unità verranno illustrati i passaggi per creare un database Cosmos DB e selezionare un metodo di migrazione offline o online.

Verificare la compatibilità di MongoDB

La prima attività prima della migrazione consiste nel verificare di eseguire la migrazione da una versione supportata di MongoDB. È possibile verificare il supporto della versione più recente nel sito seguente:

API di Azure Cosmos DB per MongoDB: funzionalità e sintassi supportate

Per iniziare a usare cosmos DB in Azure, creare un account Cosmos DB con l'API MongoDB. Creare quindi un database nell'account. È possibile separare i carichi di lavoro del database in database diversi, un vantaggio di questo approccio è la granularità a cui è possibile impostare la velocità effettiva.

L'accesso ai dati è controllato usando reti virtuali di Azure. Si configurerà il gruppo di sicurezza di rete della rete virtuale per aprire le porte 53, 443, 445, 9354 e 10000-20000. Ovviamente è anche necessario configurare i firewall locali per consentire l'accesso tramite queste porte al server MongoDB locale.

In genere, una migrazione comporta una grande quantità di trasferimento dei dati ed è possibile aumentare temporaneamente la velocità effettiva durante la migrazione. Se si specifica la velocità effettiva a livello di database, è necessario considerare che ogni raccolta richiede almeno 100 UR/sec. Di conseguenza, il numero minimo di UR/sec per il database è il numero di raccolte moltiplicate per 100. La velocità effettiva a livello di database sembra spesso più appropriata rispetto alla velocità effettiva a livello di raccolta per gli scenari di migrazione, ma è consigliabile considerare che questa impostazione non può essere modificata dopo la creazione e, di conseguenza, è consigliabile scegliere l'impostazione più appropriata per l'uso previsto del database dopo la migrazione.

Migrazione offline o online

In una migrazione offline si arrestano le connessioni al database, si esegue la migrazione e quindi si stabiliscono connessioni al nuovo database migrato. Viene importato per impedire le connessioni durante la migrazione, perché queste transazioni andranno perse.

Una migrazione online applica tutte le transazioni che si verificano durante la migrazione al nuovo database migrato. Nessuna transazione viene persa.

Una migrazione offline è più veloce, ma una migrazione online ha meno tempi di inattività. Il tempo di inattività inizia quando la migrazione viene avviata per la modalità offline, ma il tempo di inattività inizia solo alla fine della migrazione quando si verifica il cutover al nuovo database online. È consigliabile eseguire una migrazione offline di test in una copia del sistema attivo per verificare se il tempo di inattività è accettabile. Potrebbe essere possibile eseguire la migrazione in un momento in cui l'attività è in genere bassa. Se il tempo di inattività per la migrazione offline non è accettabile, scegliere migrazione online.

Per altre informazioni sulle migrazioni online, vedere Eseguire la migrazione online di MongoDB all'API Mongo di Azure Cosmos DB

Per altre informazioni sulle migrazioni offline, vedere Eseguire la migrazione offline di MongoDB all'API Mongo di Azure Cosmos DB