Esercitazione: eseguire la migrazione da Database di Azure per PostgreSQL - Da server singolo a server flessibile con il servizio di migrazione

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Usando il portale di Azure, è possibile eseguire la migrazione di un'istanza di Database di Azure per PostgreSQL – Server singolo a Database di Azure per PostgreSQL – Server flessibile. In questa esercitazione viene eseguita la migrazione di un database di esempio da un server singolo di Database di Azure per PostgreSQL a un server flessibile di PostgreSQL usando il portale di Azure.

• Configurare il server flessibile di Database di Azure per PostgreSQL
• Configurare l'attività di migrazione
• Monitorare la migrazione
• Annullare la migrazione
• Dopo la migrazione

Portale

È possibile eseguire la migrazione con il portale di Azure.

Offline

Prerequisiti (offline)

Prima di iniziare la migrazione con il servizio di migrazione in Database di Azure per PostgreSQL, è essenziale soddisfare i prerequisiti seguenti, che si applicano agli scenari di migrazione offline.

Verificare la versione di origine

La versione di origine di PostgreSQL deve essere >= 9.5. Se la versione di origine di PostgreSQL è precedente alla versione 9.5, aggiornare la versione di origine di PostgreSQL alla versione 9.5 o a una versione successiva prima della migrazione.

Configurazione della destinazione

• Il server flessibile di Database di Azure per PostgreSQL deve essere distribuito e configurato correttamente in Azure prima di iniziare il processo di migrazione.

• Lo SKU scelto per Database di Azure per PostgreSQL deve corrispondere alle specifiche del database di origine per garantire compatibilità e prestazioni adeguate.

• Per istruzioni dettagliate sulla creazione di un nuovo Database di Azure per PostgreSQL, vedere il collegamento seguente: Avvio rapido: Creare un server.

Configurazione della rete

La configurazione di rete è fondamentale per il corretto funzionamento del servizio di migrazione. Assicurarsi che il server PostgreSQL di origine possa comunicare con il server di Database di Azure per PostgreSQL di destinazione. Le configurazioni di rete seguenti sono essenziali per una corretta migrazione.

Per informazioni sul setup di rete, vedere Guida alla rete per il servizio di migrazione.

Abilitare le estensioni

Per garantire una corretta migrazione con il servizio migrazione in Database di Azure per PostgreSQL, potrebbe essere necessario verificare le estensioni per l'istanza di PostgreSQL di origine. Le estensioni offrono caratteristiche e funzionalità aggiuntive che potrebbero essere necessarie per l'applicazione. Assicurarsi di verificare le estensioni nell'istanza di PostgreSQL di origine prima di avviare il processo di migrazione.

Abilitare le estensioni supportate identificate nell'istanza di PostgreSQL di origine in Database di Azure per PostgreSQL - Server flessibile di destinazione.

Per altre informazioni sulle estensioni, vedere Estensioni in Database di Azure per PostgreSQL.

Nota

Quando vengono apportate modifiche al parametro shared_preload_libraries, è necessario un riavvio.

Controllare i parametri del server

Questi parametri non vengono migrati automaticamente nell'ambiente di destinazione e devono essere configurati manualmente.

• Associare i valori dei parametri del server del database PostgreSQL di origine a Database di Azure per PostgreSQL accedendo alla sezione Parametri del server nel portale di Azure e aggiornando manualmente i valori di conseguenza.

• Salvare le modifiche del parametro e, se necessario, riavviare il server flessibile di Database di Azure per PostgreSQL per applicare la nuova configurazione.

Disabilitare la disponibilità elevata (affidabilità) e le repliche in lettura nella destinazione

• La disabilitazione della disponibilità elevata (affidabilità) e della lettura delle repliche nell'ambiente di destinazione è essenziale. Queste funzionalità devono essere abilitate solo dopo il completamento della migrazione.

• Seguendo queste linee guida, è possibile garantire un processo di migrazione senza problemi senza le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e quando il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente del database in Azure.

Configurare il server flessibile di Database di Azure per PostgreSQL

• Creare il server flessibile di destinazione. Per consultare la procedura guidata, vedere Creare un server flessibile di Database di Azure per PostgreSQL usando il portale.

• Le estensioni nell'elenco elementi consentiti devono essere caricate nelle librerie all'avvio del server. È essenziale che l'estensione si trovi nell'elenco elementi consentiti prima di avviare una migrazione.

• Controllare se la distribuzione dei dati tra le tabelle di un database è asimmetrica, con la maggior parte dei dati presenti in una sola o in poche tabelle. Se è asimmetrica, la velocità di migrazione potrebbe essere più lenta del previsto. In questo caso, la velocità di migrazione può essere aumentata eseguendo la migrazione della tabella di grandi dimensioni in parallelo.

Configurare l'attività di migrazione

Il servizio di migrazione include un'esperienza semplice di procedura guidata nel portale di Azure. Ecco come iniziare:

1. Aprire il Web browser e passare al portale. Per accedere, immettere le credenziali. La visualizzazione predefinita è il dashboard del servizio.

2. Passare alla destinazione del server flessibile di Database di Azure per PostgreSQL.

3. Nel scheda Panoramica del server flessibile, nel menu a sinistra, scorrere fino a Migrazione e selezionare questa opzione.

   

4. Selezionare il pulsante Crea per avviare una migrazione da un singolo server a un server flessibile. Se si usa il servizio di migrazione per la prima volta, viene visualizzata una griglia vuota con un prompt per iniziare la prima migrazione.

   

   Se sono già state create migrazioni verso la destinazione del server flessibile, la griglia contiene informazioni sulle migrazioni che sono state tentate verso questa destinazione dal server singolo.

5. Si passa attraverso una serie di schede di procedura guidata per creare una migrazione in questa destinazione del server flessibile da diverse fonti possibili. Per impostazione predefinita, il tipo di server di origine è impostato su Server singolo di Database di Azure per PostgreSQL, ovvero quello a cui si è interessati in questo scenario.

In alternativa, è possibile iniziare il processo di migrazione dal server singolo di Database di Azure per PostgreSQL.

1. Aprire il Web browser e passare al portale. Per accedere, è necessario immettere le credenziali. La visualizzazione predefinita è il dashboard del servizio.

2. Quando si seleziona il server singolo, è possibile osservare un banner relativo alla migrazione nella scheda Panoramica. Selezionare Eseguire la migrazione ora per iniziare.

   

3. Viene visualizzata una pagina con due opzioni. Se il server flessibile è già stato creato e lo si vuole usare come destinazione, scegliere Seleziona esistente e selezionare i dettagli relativi a Sottoscrizione, Gruppo di risorse e Nome del server corrispondenti. Dopo aver effettuato le selezioni, selezionare Vai alla migrazione guidata e seguire le istruzioni nella sezione Configurazione.

   

4. Se si sceglie di creare un nuovo server flessibile, selezionare Crea nuovo e Vai alla creazione guidata. Questa azione avvia il processo di creazione del server flessibile e distribuisce il server flessibile.

   

Dopo aver distribuito il server flessibile, seguire i passaggi da 3 a 5 in Configurare l'attività di migrazione.

Attrezzaggio

La prima scheda è Configurazione. In caso di mancato recapito, consentire le estensioni necessarie come descritto in Configurare il server flessibile di Database di Azure per PostgreSQL prima di avviare una migrazione.

Nome migrazione è l'identificatore univoco per ogni migrazione verso questa destinazione del server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali tranne il trattino basso (_) e quello alto (-). Il nome deve iniziare con un carattere alfanumerico. Il nome deve anche essere univoco per un server di destinazione, perché nessuna delle due migrazioni alla stessa destinazione server flessibile può avere lo stesso nome.

Tipo del server di origine indica l'origine. In questo caso, si tratta del server singolo di Database di Azure per PostgreSQL

Opzione di migrazione consente di eseguire delle convalide prima di attivare una migrazione. È possibile scegliere una qualsiasi delle opzioni seguenti.

• Convalida: controlla l'idoneità del server e del database per la migrazione alla destinazione.
• Esegui migrazione: ignora le convalide e avvia la migrazione.
• Convalida ed esegui migrazione: esegue la convalida prima di attivare una migrazione. La migrazione viene attivata solo se non ci sono errori di convalida.

È sempre consigliabile scegliere l'opzione Convalida o Convalida ed esegui migrazione per eseguire le convalide preventive prima di eseguire la migrazione.

La modalità di migrazione consente di scegliere tra una migrazione online e una migrazione offline, in questo caso deve essere impostata su Offline.

Selezionare il pulsante Avanti: Selezionare Server di runtime.

Runtime server

Il server di runtime della migrazione è una funzionalità specializzata all'interno del servizio di migrazione di Database di Azure per PostgreSQL, progettata per fungere da server intermedio durante la migrazione. Si tratta di un'istanza separata dall'istanza di Database di Azure per PostgreSQL - Server flessibile, che non rappresenta il server di destinazione, ma viene utilizzata per facilitare la migrazione dei database da un ambiente di origine accessibile solo tramite rete privata.

Per altre informazioni sul runtime server, visitare Runtime server di migrazione.

Selezionare il pulsante Avanti: Connetti all'origine.

Connettersi all’origine

La sezione Origine richiede di specificare i dettagli relativi al server singolo, che è l'origine dei database.

Dopo aver selezionato la sottoscrizione e il gruppo di risorse, l'elenco a discesa per i nomi dei server mostra i server singoli in tale gruppo di risorse tra aree. Selezionare l'origine da cui si desidera eseguire la migrazione. È possibile eseguire la migrazione dei database da un server singolo a un server flessibile di destinazione nella stessa area. Le migrazioni tra aree sono abilitate solo per i server di India, Cina ed Emirati Arabi Uniti.

Dopo aver scelto l'origine server singolo, le caselle Percorso e versione di PostgreSQL vengono popolate automaticamente. Assicurarsi di specificare le credenziali di un ruolo di amministratore, perché è necessario per consentire al servizio di migrazione di eseguire correttamente la migrazione dei database.

Dopo aver compilato tutti i campi, selezionare il collegamento Connetti all'origine. In questo modo viene verificato che i dettagli del server di origine immessi siano corretti e che il server di origine sia raggiungibile.

Selezionare il pulsante Avanti: Selezionare la destinazione di migrazione per continuare.

Selezionare la destinazione di migrazione

La sezione Selezione destinazione della migrazione mostra i metadati della destinazione del server flessibile, ad esempio il nome della sottoscrizione, il gruppo di risorse, il nome del server, la posizione e la versione di PostgreSQL.

Scegliere i valori appropriati per Metodo di autenticazione e tutti i campi correlati all'autenticazione. Assicurarsi che l'identità fornita sia quella dell'utente amministratore nel server di destinazione. Dopo aver compilato tutte le informazioni necessarie, selezionare il collegamento Connetti alla destinazione. In questo modo viene verificato che i dettagli del server di destinazione immessi siano corretti e che il server di destinazione sia raggiungibile.

Selezionare il pulsante Avanti: Selezionare i database per la migrazione per selezionare i database di cui eseguire la migrazione.

Selezionare database per la migrazione

In questa scheda è presente un elenco di database utente all'interno del server singolo. È possibile selezionare fino a otto database ed eseguirne la migrazione in un solo tentativo di migrazione. Se sono presenti più di otto database utente, il processo di migrazione viene ripetuto tra i server di origine e di destinazione per il set di database successivo. I database selezionati presenti nel server di destinazione con gli stessi nomi vengono sovrascritti.

Selezionare il pulsante Avanti: Riepilogo per esaminare i dettagli.

Riepilogo

La scheda Riepilogo riepiloga tutti i dettagli per la creazione della convalida o della migrazione. Esaminare i dettagli e selezionare il pulsante Avvia convalida e migrazione.

Monitorare il portale della migrazione

Dopo aver avviato la migrazione, viene visualizzata una notifica che indica che la convalida o la creazione della migrazione ha esito positivo. Si viene reindirizzati automaticamente alla pagina Migrazione del server flessibile. Qui è disponibile una nuova voce per la convalida o la migrazione creata di recente.

La griglia che mostra le migrazioni include queste colonne: Nome, Stato, Modalità di migrazione, Tipo di migrazione, Server di origine, Tipo del server di origine, Database, Ora inizio e Durata. Le voci vengono visualizzate nell'ordine decrescente dell'ora di inizio con la voce più recente in alto.

È possibile usare il pulsante Aggiorna per aggiornare lo stato della convalida o della migrazione.

È anche possibile selezionare il nome di una particolare migrazione nella griglia per visualizzare i dettagli associati.

Quando viene creata la convalida o la migrazione, questa passa allo stato InProgress e allo stato secondario PerformingPreRequisiteSteps. Il flusso di lavoro richiede 2-3 minuti per configurare l'infrastruttura di migrazione e le connessioni di rete.

Si esaminerà ora come monitorare le migrazioni per ogni opzione di migrazione.

Convalida

Quando lo stato secondario PerformingPreRequisiteSteps viene completato, la convalida passa allo stato secondario Validation in Progress in cui vengono eseguiti i controlli sul server di origine e di destinazione per valutare l'idoneità per la migrazione.

La convalida passa allo stato Succeeded se tutte le convalide hanno lo stato Succeeded o Warning.

La griglia di convalida contiene le informazioni seguenti:

• Le sezioni Dettagli di convalida per istanza e Dettagli di convalida per i database, che rappresentano le regole di convalida usate per controllare l'idoneità della migrazione.
• Nome convalida: nome di ogni regola di convalida specifica.
• Stato di convalida: rappresenta il risultato per ogni regola e può avere uno di questi tre valori:
  • Riuscita: se non sono stati rilevati errori.
  • Non riuscita: se sono presenti errori di convalida.
  • Avviso: se sono presenti avvisi di convalida.
• Durata: tempo impiegato per l'operazione di convalida.
• Ora di inizio (UTC) e Ora di fine (UTC): ora di inizio e fine dell'operazione di convalida in formato UTC.

Lo stato di convalida passa a Failed in caso di errori nella convalida. Selezionare il nome della convalida o il nome del database della convalida non riuscita. Un riquadro di fan-out fornisce i dettagli e l'azione correttiva da eseguire per evitare questo errore.

Migrate

Al termine dello stato secondario PerformingPreRequisiteSteps, la migrazione passa allo stato secondario Migrazione dei dati quando viene eseguita la clonazione/copia dei database. Il tempo necessario per il completamento della migrazione dipende dalle dimensioni e dalla forma dei database di cui si esegue la migrazione. La migrazione è rapida se i dati vengono distribuiti principalmente in modo uniforme in tutte le tabelle. Le tabelle con dimensioni asimmetriche richiedono un tempo relativamente più lungo.

Quando si seleziona uno dei database nella migrazione, viene visualizzato un riquadro di fan-out. Include tutti i conteggi relativi alle tabelle (tabelle copiate, accodate, in copia ed errori) e anche lo stato di migrazione del database.

La migrazione passa allo stato Succeeded quando lo stato Migrating Data viene completato correttamente. Se si verifica un problema nello stato Migrating Data, la migrazione passa a uno stato Failed.

Quando la migrazione passa allo stato Succeeded, la migrazione dello schema e dei dati dal server singolo verso la destinazione del server flessibile è completa. È possibile aggiornare la pagina per controllare lo stato di avanzamento.

Convalida ed esegui migrazione

In questa opzione, le convalide vengono eseguite prima dell'avvio della migrazione. Quando lo stato secondario PerformingPreRequisiteSteps viene completato, il flusso di lavoro passa allo stato secondario Validation in Progress.

• Se la convalida presenta errori, la migrazione passa a uno stato Failed.
• Se la convalida viene completata senza errori, viene avviata la migrazione e il flusso di lavoro passa allo stato secondario Migrating Data.

È possibile visualizzare i risultati di Convalida ed esegui la migrazione al termine dell'operazione.

Online

Prerequisiti (online)

Prima di iniziare la migrazione con il servizio di migrazione in Database di Azure per PostgreSQL, è essenziale soddisfare i prerequisiti seguenti, che si applicano agli scenari di migrazione offline.

Verificare la versione di origine

La versione di origine di PostgreSQL deve essere >= 9.5. Se la versione di origine di PostgreSQL è precedente alla versione 9.5, aggiornare la versione di origine di PostgreSQL alla versione 9.5 o a una versione successiva prima della migrazione.

Configurare i parametri di migrazione online

Per la migrazione online, il supporto della replica deve essere impostato su Logico nelle impostazioni di replica del server PostgreSQL di origine. Inoltre, i valori max_wal_senders e max_replication_slots dei parametri del server devono essere superiori al numero di database di cui è necessario eseguire la migrazione. I parametri possono essere impostati nel portale di Azure in Impostazioni->Parametri del server o configurati nella riga di comando usando i comandi seguenti:

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Assicurarsi che non siano presenti transazioni a esecuzione prolungata. Le transazioni a esecuzione prolungata non consentono la creazione di slot di replica. La creazione di uno slot di replica avrà esito positivo se viene eseguito il commit o il rollback di tutte le transazioni a esecuzione prolungata. È necessario riavviare il server PostgreSQL di origine dopo aver completato tutti i prerequisiti di migrazione online.

Nota

Per la migrazione online con il server singolo di Database di Azure per PostgreSQL, il supporto per la replica di Azure è impostato su logico nelle impostazioni di replica della pagina del server singolo nel portale di Azure.

Configurare la destinazione

• Database di Azure per PostgreSQL deve essere configurato in Azure prima della migrazione.

• Lo SKU scelto per Database di Azure per PostgreSQL deve corrispondere alle specifiche del database di origine per garantire compatibilità e prestazioni adeguate.

• Per istruzioni dettagliate sulla creazione di un nuovo Database di Azure per PostgreSQL, vedere il collegamento seguente: Avvio rapido: Creare un server.

• Il parametro del server max_replication_slots deve essere superiore al numero di database di cui è necessario eseguire la migrazione. Può essere impostato nel portale di Azure in Impostazioni->Parametri del server o configurato nella riga di comando usando il comando seguente:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Configurare la rete

La configurazione di rete è fondamentale per il corretto funzionamento del servizio di migrazione. Assicurarsi che il server PostgreSQL di origine possa comunicare con il server di Database di Azure per PostgreSQL di destinazione. Le configurazioni di rete seguenti sono essenziali per una corretta migrazione.

Per informazioni sul setup di rete, vedere Guida alla rete per il servizio di migrazione.

Abilitare le estensioni

Per garantire una corretta migrazione con il servizio migrazione in Database di Azure per PostgreSQL, potrebbe essere necessario verificare le estensioni per l'istanza di PostgreSQL di origine. Le estensioni offrono caratteristiche e funzionalità aggiuntive che potrebbero essere necessarie per l'applicazione. Assicurarsi di verificare le estensioni nell'istanza di PostgreSQL di origine prima di avviare il processo di migrazione.

Abilitare le estensioni supportate identificate nell'istanza di PostgreSQL di origine in Database di Azure per PostgreSQL - Server flessibile di destinazione.

Per altre informazioni sulle estensioni, vedere Estensioni in Database di Azure per PostgreSQL.

Nota

Quando vengono apportate modifiche al parametro shared_preload_libraries, è necessario un riavvio.

Parametri del server

Questi parametri non vengono migrati automaticamente nell'ambiente di destinazione e devono essere configurati manualmente.

• Associare i valori dei parametri del server del database PostgreSQL di origine a Database di Azure per PostgreSQL accedendo alla sezione "Parametri del server" nel portale di Azure e aggiornando manualmente i valori di conseguenza.

• Salvare le modifiche del parametro e riavviare Database di Azure per PostgreSQL per applicare la nuova configurazione, se necessario.

Disabilitare la disponibilità elevata (affidabilità) e le repliche in lettura nella destinazione

• La disabilitazione della disponibilità elevata (affidabilità) e della lettura delle repliche nell'ambiente di destinazione è essenziale. Queste funzionalità devono essere abilitate solo dopo il completamento della migrazione.

• Seguendo queste linee guida, è possibile garantire un processo di migrazione senza problemi senza le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e quando il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente del database in Azure.

Configurare il server flessibile di Database di Azure per PostgreSQL

• Creare il server flessibile di destinazione. Per consultare la procedura guidata, vedere Creare un server flessibile di Database di Azure per PostgreSQL usando il portale.

• Le estensioni nell'elenco elementi consentiti devono essere caricate nelle librerie all'avvio del server. È essenziale che l'estensione si trovi nell'elenco elementi consentiti prima di avviare una migrazione.

• Controllare se la distribuzione dei dati tra le tabelle di un database è asimmetrica, con la maggior parte dei dati presenti in una sola o in poche tabelle. Se è asimmetrica, la velocità di migrazione potrebbe essere più lenta del previsto. In questo caso, la velocità di migrazione può essere aumentata eseguendo la migrazione della tabella di grandi dimensioni in parallelo.

Configurare l'attività di migrazione

Il servizio di migrazione include un'esperienza semplice di procedura guidata nel portale di Azure. Ecco come iniziare:

1. Aprire il Web browser e passare al portale. Per accedere, immettere le credenziali. La visualizzazione predefinita è il dashboard del servizio.

2. Passare alla destinazione del server flessibile di Database di Azure per PostgreSQL.

3. Nel scheda Panoramica del server flessibile, nel menu a sinistra, scorrere fino a Migrazione e selezionare questa opzione.

   

4. Selezionare il pulsante Crea per avviare una migrazione da un singolo server a un server flessibile. Se si usa il servizio di migrazione per la prima volta, viene visualizzata una griglia vuota con un prompt per iniziare la prima migrazione.

   

   Se sono già state create migrazioni verso la destinazione del server flessibile, la griglia contiene informazioni sulle migrazioni che sono state tentate verso questa destinazione dal server singolo.

5. Si passa attraverso una serie di schede di procedura guidata per creare una migrazione in questa destinazione del server flessibile da diverse fonti possibili. Per impostazione predefinita, il tipo di server di origine è impostato su Server singolo di Database di Azure per PostgreSQL, ovvero quello a cui si è interessati in questo scenario.

In alternativa, è possibile iniziare il processo di migrazione dal server singolo di Database di Azure per PostgreSQL.

1. Aprire il Web browser e passare al portale. Per accedere, è necessario immettere le credenziali. La visualizzazione predefinita è il dashboard del servizio.

2. Quando si seleziona il server singolo, è possibile osservare un banner relativo alla migrazione nella scheda Panoramica. Selezionare Eseguire la migrazione ora per iniziare.

   

3. Viene visualizzata una pagina con due opzioni. Se il server flessibile è già stato creato e lo si vuole usare come destinazione, scegliere Seleziona esistente e selezionare i dettagli relativi a Sottoscrizione, Gruppo di risorse e Nome del server corrispondenti. Dopo aver effettuato le selezioni, selezionare Vai alla migrazione guidata e seguire le istruzioni nella sezione Configurazione.

   

4. Se si sceglie di creare un nuovo server flessibile, selezionare Crea nuovo e Vai alla creazione guidata. Questa azione avvia il processo di creazione del server flessibile e distribuisce il server flessibile.

   

Dopo aver distribuito il server flessibile, seguire i passaggi da 3 a 5 in Configurare l'attività di migrazione.

Attrezzaggio

La prima scheda è Configurazione. In caso di mancato recapito, consentire le estensioni necessarie come descritto in Configurare il server flessibile di Database di Azure per PostgreSQL prima di avviare una migrazione.

Nome migrazione è l'identificatore univoco per ogni migrazione verso questa destinazione del server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali tranne il trattino basso (_) e quello alto (-). Il nome deve iniziare con un carattere alfanumerico. Il nome deve anche essere univoco per un server di destinazione, perché nessuna delle due migrazioni alla stessa destinazione server flessibile può avere lo stesso nome.

Tipo del server di origine indica l'origine. In questo caso, si tratta del server singolo di Database di Azure per PostgreSQL

Opzione di migrazione consente di eseguire delle convalide prima di attivare una migrazione. È possibile scegliere una qualsiasi delle opzioni seguenti.

• Convalida: controlla l'idoneità del server e del database per la migrazione alla destinazione.
• Esegui migrazione: ignora le convalide e avvia la migrazione.
• Convalida ed esegui migrazione: esegue la convalida prima di attivare una migrazione. La migrazione viene attivata solo se non ci sono errori di convalida.

È sempre consigliabile scegliere l'opzione Convalida o Convalida ed esegui migrazione per eseguire le convalide preventive prima di eseguire la migrazione.

La modalità di migrazione consente di scegliere tra una migrazione online e una migrazione offline, in questo caso deve essere impostata su Online.

Se è selezionata la modalità di migrazione Online, la replica logica deve essere attivata nel server singolo di origine. Se non è attivata, il servizio di migrazione attiva automaticamente la replica logica nel server singolo di origine. La replica può essere configurata manualmente selezionando la voce Replica, in Impostazioni, nel menu delle risorse del server singolo e impostando il supporto della replica di Azure su LOGICO. Entrambi gli approcci riavviano il server singolo di origine.

Selezionare il pulsante Avanti: Selezionare Server di runtime.

Runtime server

Il server di runtime della migrazione è una funzionalità specializzata all'interno del servizio di migrazione di Database di Azure per PostgreSQL, progettata per fungere da server intermedio durante la migrazione. Si tratta di un'istanza separata dall'istanza di Database di Azure per PostgreSQL - Server flessibile, che non rappresenta il server di destinazione, ma viene utilizzata per facilitare la migrazione dei database da un ambiente di origine accessibile solo tramite rete privata.

Per altre informazioni sul runtime server, visitare Runtime server di migrazione.

Selezionare il pulsante Avanti: Connetti all'origine.

Connettersi all’origine

La sezione Origine richiede di specificare i dettagli relativi al server singolo, che è l'origine dei database.

Dopo aver selezionato la sottoscrizione e il gruppo di risorse, l'elenco a discesa per i nomi dei server mostra i server singoli in tale gruppo di risorse tra aree. Selezionare l'origine da cui si desidera eseguire la migrazione. È possibile eseguire la migrazione dei database da un server singolo a un server flessibile di destinazione nella stessa area. Le migrazioni tra aree sono abilitate solo per i server di India, Cina ed Emirati Arabi Uniti.

Dopo aver scelto l'origine server singolo, le caselle Percorso e versione di PostgreSQL vengono popolate automaticamente. Assicurarsi di specificare le credenziali di un ruolo di amministratore, perché è necessario per consentire al servizio di migrazione di eseguire correttamente la migrazione dei database.

Dopo aver compilato tutti i campi, selezionare il collegamento Connetti all'origine. In questo modo viene verificato che i dettagli del server di origine immessi siano corretti e che il server di origine sia raggiungibile.

Selezionare il pulsante Avanti: Selezionare la destinazione di migrazione per continuare.

Selezionare la destinazione di migrazione

La sezione Selezione destinazione della migrazione mostra i metadati della destinazione del server flessibile, ad esempio il nome della sottoscrizione, il gruppo di risorse, il nome del server, la posizione e la versione di PostgreSQL.

Scegliere i valori appropriati per Metodo di autenticazione e tutti i campi correlati all'autenticazione. Assicurarsi che l'identità fornita sia quella dell'utente amministratore nel server di destinazione. Dopo aver compilato tutte le informazioni necessarie, selezionare il collegamento Connetti alla destinazione. In questo modo viene verificato che i dettagli del server di destinazione immessi siano corretti e che il server di destinazione sia raggiungibile.

Selezionare il pulsante Avanti: Selezionare i database per la migrazione per selezionare i database di cui eseguire la migrazione.

Selezionare database per la migrazione

In questa scheda è presente un elenco di database utente all'interno del server singolo. È possibile selezionare fino a otto database ed eseguirne la migrazione in un solo tentativo di migrazione. Se sono presenti più di otto database utente, il processo di migrazione viene ripetuto tra i server di origine e di destinazione per il set di database successivo. I database selezionati presenti nel server di destinazione con gli stessi nomi vengono sovrascritti.

Selezionare il pulsante Avanti: Riepilogo per esaminare i dettagli.

Riepilogo

La scheda Riepilogo riepiloga tutti i dettagli per la creazione della convalida o della migrazione. Esaminare i dettagli e selezionare il pulsante Avvia convalida e migrazione.

Monitorare il portale della migrazione

Dopo aver avviato la migrazione, viene visualizzata una notifica che indica che la convalida o la creazione della migrazione ha esito positivo. Si viene reindirizzati automaticamente alla pagina Migrazione del server flessibile. Qui è disponibile una nuova voce per la convalida o la migrazione creata di recente.

La griglia che mostra le migrazioni include queste colonne: Nome, Stato, Modalità di migrazione, Tipo di migrazione, Server di origine, Tipo del server di origine, Database, Ora inizio e Durata. Le voci vengono visualizzate nell'ordine decrescente dell'ora di inizio con la voce più recente in alto.

È possibile usare il pulsante Aggiorna per aggiornare lo stato della convalida o della migrazione.

È anche possibile selezionare il nome di una particolare migrazione nella griglia per visualizzare i dettagli associati.

Quando viene creata la convalida o la migrazione, questa passa allo stato InProgress e allo stato secondario PerformingPreRequisiteSteps. Il flusso di lavoro richiede 2-3 minuti per configurare l'infrastruttura di migrazione e le connessioni di rete.

Si esaminerà ora come monitorare le migrazioni per ogni opzione di migrazione.

Convalida

Quando lo stato secondario PerformingPreRequisiteSteps viene completato, la convalida passa allo stato secondario Validation in Progress in cui vengono eseguiti i controlli sul server di origine e di destinazione per valutare l'idoneità per la migrazione.

La convalida passa allo stato Succeeded se tutte le convalide hanno lo stato Succeeded o Warning.

La griglia di convalida contiene le informazioni seguenti:

• Le sezioni Dettagli di convalida per istanza e Dettagli di convalida per i database, che rappresentano le regole di convalida usate per controllare l'idoneità della migrazione.
• Nome convalida: nome di ogni regola di convalida specifica.
• Stato di convalida: rappresenta il risultato per ogni regola e può avere uno di questi tre valori:
  • Riuscita: se non sono stati rilevati errori.
  • Non riuscita: se sono presenti errori di convalida.
  • Avviso: se sono presenti avvisi di convalida.
• Durata: tempo impiegato per l'operazione di convalida.
• Ora di inizio (UTC) e Ora di fine (UTC): ora di inizio e fine dell'operazione di convalida in formato UTC.

Lo stato di convalida passa a Failed in caso di errori nella convalida. Selezionare il nome della convalida o il nome del database della convalida non riuscita. Un riquadro di fan-out fornisce i dettagli e l'azione correttiva da eseguire per evitare questo errore.

Migrate

Al termine dello stato secondario PerformingPreRequisiteSteps, la migrazione passa allo stato secondario Migrazione dei dati quando viene eseguita la clonazione/copia dei database. Il tempo necessario per il completamento della migrazione dipende dalle dimensioni e dalla forma dei database di cui si esegue la migrazione. La migrazione è rapida se i dati vengono distribuiti principalmente in modo uniforme in tutte le tabelle. Le tabelle con dimensioni asimmetriche richiedono un tempo relativamente più lungo.

Quando si seleziona uno dei database nella migrazione, viene visualizzato un riquadro di fan-out. Include tutti i conteggi relativi alle tabelle (tabelle copiate, accodate, in copia ed errori) e anche lo stato di migrazione del database.

La migrazione passa allo stato Succeeded quando lo stato Migrating Data viene completato correttamente. Se si verifica un problema nello stato Migrating Data, la migrazione passa a uno stato Failed.

Quando la migrazione passa allo stato Succeeded, la migrazione dello schema e dei dati dal server singolo verso la destinazione del server flessibile è completa. È possibile aggiornare la pagina per controllare lo stato di avanzamento.

Convalida ed esegui migrazione

In questa opzione, le convalide vengono eseguite prima dell'avvio della migrazione. Quando lo stato secondario PerformingPreRequisiteSteps viene completato, il flusso di lavoro passa allo stato secondario Validation in Progress.

• Se la convalida presenta errori, la migrazione passa a uno stato Failed.
• Se la convalida viene completata senza errori, viene avviata la migrazione e il flusso di lavoro passa allo stato secondario Migrating Data.

È possibile visualizzare i risultati di Convalida ed esegui la migrazione al termine dell'operazione.

Migrazione cutover

Per le opzioni di migrazione e per Convalida e migrazione, il completamento della migrazione online richiede all'utente di completare un passaggio aggiuntivo, ovvero attivare l'azione Cutover. Al termine della copia/clonazione dei dati di base, la migrazione passa allo stato WaitingForUserAction e allo stato secondario aitingForCutoverTrigger. In questo stato, l'utente può attivare il cutover dal portale selezionando la migrazione e selezionando il pulsante Cutover.

Prima di avviare il cutover, è essenziale assicurarsi che:

• Le scritture nell'origine vengono arrestate: il parametro Latency (minutes) è 0 o vicino a 0. Le informazioni relative a Latency (minutes) possono essere ottenute dalla schermata dei dettagli della migrazione:

Il parametro Latency (minutes) indica quando è avvenuta l'ultima sincronizzazione della destinazione con l'origine. Ad esempio, per il database Ordini precedente, è 0.33333. Ciò significa che le modifiche apportate negli ultimi ~0,3 minuti all'origine devono ancora essere inviate alla destinazione, per il database Ordini. A questo punto, le scritture nell'origine possono essere arrestate e il cutover può essere avviato. Nel caso in cui si verifichi un traffico elevato nell'origine, è consigliabile arrestare prima le scritture in modo che Latency (minutes) possa avvicinarsi a 0 e solo successivamente avviare il cutover. L'operazione di cutover applica tutte le modifiche in sospeso dall'origine alla destinazione e completa la migrazione. Se si attiva un cutover anche con latenza diversa da zero, la replica si arresta fino a quel momento. Tutti i dati nell'origine fino al momento del cutover vengono quindi applicati alla destinazione. Si supponga che la latenza fosse di 15 minuti nel punto di cutover; tutti i dati modificati negli ultimi 15 minuti vengono quindi applicati alla destinazione. Il tempo impiegato dipende dal backlog delle modifiche apportate negli ultimi 15 minuti. Di conseguenza, è consigliabile che la latenza sia zero o si avvicini a zero, prima di attivare il cutover.

La migrazione passa allo stato Completato non appena lo stato secondario Migrazione dei dati o il cutover (in modalità di migrazione online) viene completato correttamente. Se si verifica un problema nello stato secondario Migrazione dati, la migrazione passa a uno stato Non riuscito.

I possibili stati della migrazione includono:

• InProgress: è in corso la configurazione dell'infrastruttura di migrazione oppure è in corso la migrazione effettiva dei dati.
• Canceled: la migrazione viene annullata o eliminata.
• Failed: la migrazione non è riuscita.
• Validation Failed: la convalida non è riuscita.
• Succeeded: la migrazione è riuscita ed è stata completata.

I possibili stati secondari della migrazione includono:

• PerformingPreRequisiteSteps: è in corso la configurazione dell'infrastruttura per la migrazione dei dati.
• Validation in Progress: la convalida è in corso.
• MigratingData: è in corso la migrazione dei dati.
• CompletingMigration: la migrazione è quasi completata.
• Completed: la migrazione è stata completata correttamente.

Annullare la migrazione tramite il portale

È possibile annullare eventuali convalide o migrazioni in corso. Il flusso di lavoro deve trovarsi nello stato InProgress per essere annullato. Non è possibile annullare una convalida o una migrazione che si trova nello stato Succeeded o Failed.

L'annullamento di una convalida arresta qualsiasi altra attività di convalida e la convalida passa allo stato Canceled.

L'annullamento di una migrazione arresta altre attività di migrazione nel server di destinazione e la migrazione passa allo stato di Canceled. L'azione di annullamento eseguirà il rollback di tutte le modifiche apportate dal servizio di migrazione nel server di destinazione.

CLI

È possibile eseguire la migrazione usando l'interfaccia della riga di comando di Azure.

Offline

Prerequisiti (offline)

Prima di iniziare la migrazione con il servizio di migrazione in Database di Azure per PostgreSQL, è essenziale soddisfare i prerequisiti seguenti, che si applicano agli scenari di migrazione offline.

Verificare la versione di origine

La versione di origine di PostgreSQL deve essere >= 9.5. Se la versione di origine di PostgreSQL è precedente alla versione 9.5, aggiornare la versione di origine di PostgreSQL alla versione 9.5 o a una versione successiva prima della migrazione.

Configurazione della destinazione

• Il server flessibile di Database di Azure per PostgreSQL deve essere distribuito e configurato correttamente in Azure prima di iniziare il processo di migrazione.

• Lo SKU scelto per Database di Azure per PostgreSQL deve corrispondere alle specifiche del database di origine per garantire compatibilità e prestazioni adeguate.

• Per istruzioni dettagliate sulla creazione di un nuovo Database di Azure per PostgreSQL, vedere il collegamento seguente: Avvio rapido: Creare un server.

Configurazione della rete

La configurazione di rete è fondamentale per il corretto funzionamento del servizio di migrazione. Assicurarsi che il server PostgreSQL di origine possa comunicare con il server di Database di Azure per PostgreSQL di destinazione. Le configurazioni di rete seguenti sono essenziali per una corretta migrazione.

Per informazioni sul setup di rete, vedere Guida alla rete per il servizio di migrazione.

Abilitare le estensioni

Per garantire una corretta migrazione con il servizio migrazione in Database di Azure per PostgreSQL, potrebbe essere necessario verificare le estensioni per l'istanza di PostgreSQL di origine. Le estensioni offrono caratteristiche e funzionalità aggiuntive che potrebbero essere necessarie per l'applicazione. Assicurarsi di verificare le estensioni nell'istanza di PostgreSQL di origine prima di avviare il processo di migrazione.

Abilitare le estensioni supportate identificate nell'istanza di PostgreSQL di origine in Database di Azure per PostgreSQL - Server flessibile di destinazione.

Per altre informazioni sulle estensioni, vedere Estensioni in Database di Azure per PostgreSQL.

Nota

Quando vengono apportate modifiche al parametro shared_preload_libraries, è necessario un riavvio.

Controllare i parametri del server

Questi parametri non vengono migrati automaticamente nell'ambiente di destinazione e devono essere configurati manualmente.

• Associare i valori dei parametri del server del database PostgreSQL di origine a Database di Azure per PostgreSQL accedendo alla sezione Parametri del server nel portale di Azure e aggiornando manualmente i valori di conseguenza.

• Salvare le modifiche del parametro e, se necessario, riavviare il server flessibile di Database di Azure per PostgreSQL per applicare la nuova configurazione.

Disabilitare la disponibilità elevata (affidabilità) e le repliche in lettura nella destinazione

• La disabilitazione della disponibilità elevata (affidabilità) e della lettura delle repliche nell'ambiente di destinazione è essenziale. Queste funzionalità devono essere abilitate solo dopo il completamento della migrazione.

• Seguendo queste linee guida, è possibile garantire un processo di migrazione senza problemi senza le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e quando il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente del database in Azure.

Operazioni preliminari

1. Se non si ha familiarità con Microsoft Azure, creare un account per valutare le offerte.

2. Installare l'interfaccia della riga di comando di Azure più recente per il sistema operativo in uso dalla pagina di installazione dell'interfaccia della riga di comando di Azure.

   Se l'interfaccia della riga di comando di Azure è già installata, controllare la versione usando il comando az version. La versione deve essere 2.50.0 o una versione successiva per usare i comandi dell'interfaccia della riga di comando della migrazione. Se si ha una versione diversa, aggiornare la versione dell'interfaccia della riga di comando di Azure.

3. Eseguire il comando az login:

   az login
   

   Viene visualizzata una finestra del browser con la pagina di accesso di Azure. Specificare le credenziali di Azure per eseguire correttamente l'autenticazione. Per altre modalità di accesso con l'interfaccia della riga di comando di Azure, vedere questo articolo.

Comandi dell'interfaccia della riga di comando per la migrazione (offline)

Il servizio di migrazione include comandi dell'interfaccia della riga di comando facili da usare per eseguire attività correlate alla migrazione. Tutti i comandi dell'interfaccia della riga di comando iniziano con az postgres flexible-server migration. È importante aggiungere all'elenco elementi consentiti le estensioni prima di avviare una migrazione.

Per informazioni sulle opzioni associate a un comando e al frame della sintassi corretta, è possibile usare il parametro --help:

az postgres flexible-server migration --help

L'esecuzione del comando precedente restituisce l'output seguente:

L'output elenca i comandi di migrazione supportati, insieme alle relative azioni. Questi comandi verranno ora esaminati in dettaglio.

Creare una migrazione usando l'interfaccia della riga di comando di Azure

Il comando create consente di creare una migrazione da un server di origine a un server di destinazione:

az postgres flexible-server migration create --help

L'esecuzione del comando precedente restituisce l'output seguente:

Elenca gli argomenti previsti e presenta una sintassi di esempio per creare correttamente una migrazione dal server di origine al server di destinazione. Ecco il comando dell'interfaccia della riga di comando per creare una nuova migrazione:

az postgres flexible-server migration create [--subscription]
                                             [--resource-group]
                                             [--name]
                                             [--migration-name]
                                             [--migration-mode]
                                             [--properties]

Parametro	Descrizione
subscription	ID sottoscrizione della destinazione del server flessibile.
resource-group	Gruppo di risorse della destinazione del server flessibile.
name	Nome della destinazione del server flessibile.
migration-name	Identificatore univoco per ogni migrazione a questa destinazione del server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali tranne il trattino basso (_) e quello alto (-). Il nome deve iniziare e terminare con un carattere alfanumerico. Il nome deve anche essere univoco per un server di destinazione, perché nessuna delle due migrazioni alla stessa destinazione server flessibile può avere lo stesso nome.
migration-mode	Questo è un parametro opzionale. Valore predefinito: Offline. La migrazione offline comporta la copia dei database di origine in un momento specifico nel server di destinazione.
properties	Percorso assoluto di un file JSON con le informazioni sull'origine del server singolo.

Ad esempio:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./migrationBody.json" --migration-mode offline

L'argomento migration-name usato nel comando create viene usato in altri comandi dell'interfaccia della riga di comando, ad esempio update, delete e show.. Identifica in modo univoco il tentativo di migrazione nelle azioni corrispondenti in tutti questi comandi.

Infine, per il comando create è necessario passare un file JSON come parte dell'argomento properties.

La struttura del file JSON è:

{
  "properties": {
    "sourceDbServerResourceId": "/subscriptions/<subscriptionid>/resourceGroups/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
    "secretParameters": {
      "adminCredentials": {
        "sourceServerPassword": "<password>",
        "targetServerPassword": "<password>"
      }
    },
    "sourceServerUserName": "<username>@<servername>",
    "targetServerUserName": "<username>",
    "dbsToMigrate": ["<db1>", "<db2>"],
    "overwriteDbsInTarget": "true"
  }
}

I parametri create che passano al formato di file JSON sono indicati di seguito:

Parametro	Tipo	Descrizione
sourceDbServerResourceId	Richiesto	Questo parametro è l'ID della risorsa dell'origine del server singolo.
adminCredentials	Richiesto	Questo parametro elenca le password per gli utenti amministratori sia per l'origine del server singolo che per la destinazione del server flessibile. Queste password consentono di eseguire l'autenticazione nei server di origine e di destinazione.
sourceServerUserName	Richiesto	Il valore predefinito è l'utente amministratore specificato durante la creazione di un server singolo e la password specificata viene usata per l'autenticazione di questo utente. Se non si usa l'utente predefinito, questo parametro è l'utente o il ruolo nel server di origine usato per eseguire la migrazione. L'utente deve disporre dei privilegi e della proprietà necessari degli oggetti di database coinvolti nella migrazione e deve essere membro del ruolo azure_pg_admin.
targetServerUserName	Richiesto	Il valore predefinito è l'utente amministratore creato durante la creazione di un server flessibile e la password specificata viene usata per l'autenticazione di questo utente. Se non si usa l'utente predefinito, questo parametro è l'utente o il ruolo nel server di destinazione usato per eseguire la migrazione. Questo utente deve essere membro dei ruoli azure_pg_admin, pg_read_all_settings, pg_read_all_stats, pg_stat_scan_tables e deve avere il ruolo gli attributi Crea ruolo, Crea DB.
dbsToMigrate	Richiesto	Specificare l'elenco di database di cui si vuole eseguire la migrazione al server flessibile. Viene eseguita la migrazione solo dei database utente. I database di sistema o i database di modello, ad esempio template0 e template1, non vengono migrati.
overwriteDbsInTarget	Richiesto	Quando impostato su true, se nel server di destinazione esiste già un database con lo stesso nome di quello di cui si sta tentando di eseguire la migrazione, il servizio di migrazione sovrascrive automaticamente il database.
setupLogicalReplicationOnSourceDBIfNeeded	Facoltativo	È possibile abilitare automaticamente la replica logica nel server di origine impostando questa proprietà su true. Questa modifica nelle impostazioni del server richiede un riavvio del server con due-tre minuti di tempo di inattività.
sourceDBServerFullyQualifiedDomainName	Facoltativo	È consigliabile usarlo quando viene usato un server DNS personalizzato per la risoluzione dei nomi di una rete virtuale. Specificare il nome di dominio completo dell'origine del server singolo in base al server DNS personalizzato per questa proprietà.
targetDBServerFullyQualifiedDomainName	Facoltativo	È consigliabile usarlo quando viene usato un server DNS personalizzato per la risoluzione dei nomi all'interno di una rete virtuale. Specificare il nome di dominio completo della destinazione del server flessibile in base al server DNS personalizzato. sourceDBServerFullyQualifiedDomainName e targetDBServerFullyQualifiedDomainName sono inclusi come parte del formato JSON solo nel raro caso in cui venga usato un server DNS personalizzato per la risoluzione dei nomi anziché il DNS fornito da Azure. Altrimenti, è consigliabile non includere questi parametri nel file JSON.

Si notino questi punti essenziali per la risposta del comando:

• Quando viene attivato il comando create, la migrazione passa allo stato InProgress e allo stato secondario PerformingPreRequisiteSteps. Il flusso di lavoro di migrazione richiede alcuni minuti per distribuire l'infrastruttura della migrazione e configurare le connessioni tra l'origine e la destinazione.
• Quando lo stato secondario PerformingPreRequisiteSteps viene completato, la migrazione passa allo stato secondario Migrating Data, quando viene eseguita la clonazione/copia dei database.
• Ogni database migrato ha una propria sezione con tutti i dettagli della migrazione, ad esempio numero di tabelle, inserimenti incrementali, eliminazioni e byte in sospeso.
• Il tempo necessario per completare lo stato secondario Migrating Data dipende dalle dimensioni dei database di cui viene eseguita la migrazione.
• La migrazione passa allo stato Succeeded non appena lo stato secondario Migrating Data viene completato correttamente. Se si verifica un problema nello stato secondario Migrating Data, la migrazione passa a uno stato Failed.

Elencare le migrazioni

Il comando list elenca tutti i tentativi di migrazione eseguiti verso una destinazione del server flessibile:

az postgres flexible-server migration list [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--filter]

Il parametro filter include due opzioni:

• Active: elenca i tentativi di migrazione attivi correnti (in corso) nel server di destinazione. Non include le migrazioni non riuscite, annullate o riuscite.
• All: elenca tutti i tentativi di migrazione nel server di destinazione. Sono incluse sia le migrazioni attive che concluse, indipendentemente dallo stato.

Per altre informazioni su questo comando, usare il parametro --help:

az postgres flexible-server migration list --help

Monitorare la migrazione

Il comando --show consente di monitorare le migrazioni in corso e fornisce lo stato e lo stato secondario attuali della migrazione.

az postgres flexible-server migration show [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--migration-name]

Il parametro migration_name è il nome assegnato alla migrazione durante l'esecuzione dell comando create. Ecco uno snapshot della risposta di esempio del comando dell'interfaccia della riga di comando per visualizzare i dettagli:

Per altre informazioni su questo comando, usare il parametro --help:

 az postgres flexible-server migration show --help

Le tabelle seguenti descrivono gli stati e gli stati secondari della migrazione.

Stato di migrazione	Descrizione
InProgress	L'infrastruttura di migrazione è configurata oppure è in corso la migrazione effettiva dei dati.
Canceled	La migrazione viene annullata o eliminata.
Failed	La migrazione non è riuscita.
Succeeded	La migrazione è riuscita ed è stata completata.
ValidationFailed	La migrazione non è riuscita durante la convalida preliminare della migrazione.

Stato secondario della migrazione	Descrizione
PerformingPreRequisiteSteps	L'infrastruttura viene configurata e viene preparata per la migrazione dei dati.
MigratingData	La migrazione dei dati è in corso.
CompletingMigration	Completamento del processo di migrazione.
Completed	La migrazione è completa, indipendentemente dal fatto che lo stato abbia esito positivo o negativo.
CancelingRequestedDBMigrations	Annullamento della migrazione.
ValidationInProgress	La convalida è in esecuzione.

Online

Prerequisiti (online)

Prima di iniziare la migrazione con il servizio di migrazione in Database di Azure per PostgreSQL, è essenziale soddisfare i prerequisiti seguenti, che si applicano agli scenari di migrazione offline.

Verificare la versione di origine

La versione di origine di PostgreSQL deve essere >= 9.5. Se la versione di origine di PostgreSQL è precedente alla versione 9.5, aggiornare la versione di origine di PostgreSQL alla versione 9.5 o a una versione successiva prima della migrazione.

Configurare i parametri di migrazione online

Per la migrazione online, il supporto della replica deve essere impostato su Logico nelle impostazioni di replica del server PostgreSQL di origine. Inoltre, i valori max_wal_senders e max_replication_slots dei parametri del server devono essere superiori al numero di database di cui è necessario eseguire la migrazione. I parametri possono essere impostati nel portale di Azure in Impostazioni->Parametri del server o configurati nella riga di comando usando i comandi seguenti:

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Assicurarsi che non siano presenti transazioni a esecuzione prolungata. Le transazioni a esecuzione prolungata non consentono la creazione di slot di replica. La creazione di uno slot di replica avrà esito positivo se viene eseguito il commit o il rollback di tutte le transazioni a esecuzione prolungata. È necessario riavviare il server PostgreSQL di origine dopo aver completato tutti i prerequisiti di migrazione online.

Nota

Per la migrazione online con il server singolo di Database di Azure per PostgreSQL, il supporto per la replica di Azure è impostato su logico nelle impostazioni di replica della pagina del server singolo nel portale di Azure.

Configurare la destinazione

• Database di Azure per PostgreSQL deve essere configurato in Azure prima della migrazione.

• Lo SKU scelto per Database di Azure per PostgreSQL deve corrispondere alle specifiche del database di origine per garantire compatibilità e prestazioni adeguate.

• Per istruzioni dettagliate sulla creazione di un nuovo Database di Azure per PostgreSQL, vedere il collegamento seguente: Avvio rapido: Creare un server.

• Il parametro del server max_replication_slots deve essere superiore al numero di database di cui è necessario eseguire la migrazione. Può essere impostato nel portale di Azure in Impostazioni->Parametri del server o configurato nella riga di comando usando il comando seguente:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Configurare la rete

La configurazione di rete è fondamentale per il corretto funzionamento del servizio di migrazione. Assicurarsi che il server PostgreSQL di origine possa comunicare con il server di Database di Azure per PostgreSQL di destinazione. Le configurazioni di rete seguenti sono essenziali per una corretta migrazione.

Per informazioni sul setup di rete, vedere Guida alla rete per il servizio di migrazione.

Abilitare le estensioni

Per garantire una corretta migrazione con il servizio migrazione in Database di Azure per PostgreSQL, potrebbe essere necessario verificare le estensioni per l'istanza di PostgreSQL di origine. Le estensioni offrono caratteristiche e funzionalità aggiuntive che potrebbero essere necessarie per l'applicazione. Assicurarsi di verificare le estensioni nell'istanza di PostgreSQL di origine prima di avviare il processo di migrazione.

Abilitare le estensioni supportate identificate nell'istanza di PostgreSQL di origine in Database di Azure per PostgreSQL - Server flessibile di destinazione.

Per altre informazioni sulle estensioni, vedere Estensioni in Database di Azure per PostgreSQL.

Nota

Quando vengono apportate modifiche al parametro shared_preload_libraries, è necessario un riavvio.

Parametri del server

Questi parametri non vengono migrati automaticamente nell'ambiente di destinazione e devono essere configurati manualmente.

• Associare i valori dei parametri del server del database PostgreSQL di origine a Database di Azure per PostgreSQL accedendo alla sezione "Parametri del server" nel portale di Azure e aggiornando manualmente i valori di conseguenza.

• Salvare le modifiche del parametro e riavviare Database di Azure per PostgreSQL per applicare la nuova configurazione, se necessario.

Disabilitare la disponibilità elevata (affidabilità) e le repliche in lettura nella destinazione

• La disabilitazione della disponibilità elevata (affidabilità) e della lettura delle repliche nell'ambiente di destinazione è essenziale. Queste funzionalità devono essere abilitate solo dopo il completamento della migrazione.

• Seguendo queste linee guida, è possibile garantire un processo di migrazione senza problemi senza le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e quando il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente del database in Azure.

Operazioni preliminari

1. Se non si ha familiarità con Microsoft Azure, creare un account per valutare le offerte.

2. Installare l'interfaccia della riga di comando di Azure più recente per il sistema operativo in uso dalla pagina di installazione dell'interfaccia della riga di comando di Azure.

   Se l'interfaccia della riga di comando di Azure è già installata, controllare la versione usando il comando az version. La versione deve essere 2.50.0 o una versione successiva per usare i comandi dell'interfaccia della riga di comando della migrazione. Se si ha una versione diversa, aggiornare la versione dell'interfaccia della riga di comando di Azure.

3. Eseguire il comando az login:

   az login
   

   Viene visualizzata una finestra del browser con la pagina di accesso di Azure. Specificare le credenziali di Azure per eseguire correttamente l'autenticazione. Per altre modalità di accesso con l'interfaccia della riga di comando di Azure, vedere questo articolo.

Comandi dell'interfaccia della riga di comando per la migrazione (online)

Il servizio di migrazione include comandi dell'interfaccia della riga di comando facili da usare per eseguire attività correlate alla migrazione. Tutti i comandi dell'interfaccia della riga di comando iniziano con az postgres flexible-server migration. È importante aggiungere all'elenco elementi consentiti le estensioni prima di avviare una migrazione.

Per informazioni sulle opzioni associate a un comando e al frame della sintassi corretta, è possibile usare il parametro --help:

az postgres flexible-server migration --help

L'esecuzione del comando precedente restituisce l'output seguente:

L'output elenca i comandi di migrazione supportati, insieme alle relative azioni. Questi comandi verranno ora esaminati in dettaglio.

Creare una migrazione usando l'interfaccia della riga di comando di Azure

Il comando create consente di creare una migrazione da un server di origine a un server di destinazione:

az postgres flexible-server migration create --help

L'esecuzione del comando precedente restituisce l'output seguente:

Elenca gli argomenti previsti e presenta una sintassi di esempio per creare correttamente una migrazione dal server di origine al server di destinazione. Ecco il comando dell'interfaccia della riga di comando per creare una nuova migrazione:

az postgres flexible-server migration create [--subscription]
                                             [--resource-group]
                                             [--name]
                                             [--migration-name]
                                             [--migration-mode]
                                             [--properties]

Parametro	Descrizione
subscription	ID sottoscrizione della destinazione del server flessibile.
resource-group	Gruppo di risorse della destinazione del server flessibile.
name	Nome della destinazione del server flessibile.
migration-name	Identificatore univoco per ogni migrazione a questa destinazione del server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali tranne il trattino basso (_) e quello alto (-). Il nome deve iniziare e terminare con un carattere alfanumerico. Il nome deve anche essere univoco per un server di destinazione, perché nessuna delle due migrazioni alla stessa destinazione server flessibile può avere lo stesso nome.
migration-mode	Questo è un parametro opzionale. Il valore predefinito è Offline. Per le migrazioni online è necessario passare Online.
properties	Percorso assoluto di un file JSON con le informazioni sull'origine del server singolo.

Ad esempio:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./migrationBody.json" --migration-mode online

L'argomento migration-name usato nel comando create viene usato in altri comandi dell'interfaccia della riga di comando, ad esempio update, delete e show.. Identifica in modo univoco il tentativo di migrazione nelle azioni corrispondenti in tutti questi comandi.

Infine, per il comando create è necessario passare un file JSON come parte dell'argomento properties.

La struttura del file JSON è:

{
  "properties": {
    "sourceDbServerResourceId": "/subscriptions/<subscriptionid>/resourceGroups/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
    "secretParameters": {
      "adminCredentials": {
        "sourceServerPassword": "<password>",
        "targetServerPassword": "<password>"
      }
    },
    "sourceServerUserName": "<username>@<servername>",
    "targetServerUserName": "<username>",
    "dbsToMigrate": ["<db1>", "<db2>"],
    "overwriteDbsInTarget": "true"
  }
}

I parametri create che passano al formato di file JSON sono indicati di seguito:

Parametro	Tipo	Descrizione
sourceDbServerResourceId	Richiesto	Questo parametro è l'ID della risorsa dell'origine del server singolo.
adminCredentials	Richiesto	Questo parametro elenca le password per gli utenti amministratori sia per l'origine del server singolo che per la destinazione del server flessibile. Queste password consentono di eseguire l'autenticazione nei server di origine e di destinazione.
sourceServerUserName	Richiesto	Il valore predefinito è l'utente amministratore specificato durante la creazione di un server singolo e la password specificata viene usata per l'autenticazione di questo utente. Se non si usa l'utente predefinito, questo parametro è l'utente o il ruolo nel server di origine usato per eseguire la migrazione. L'utente deve disporre dei privilegi e della proprietà necessari degli oggetti di database coinvolti nella migrazione e deve essere membro del ruolo azure_pg_admin.
targetServerUserName	Richiesto	Il valore predefinito è l'utente amministratore creato durante la creazione di un server flessibile e la password specificata viene usata per l'autenticazione di questo utente. Se non si usa l'utente predefinito, questo parametro è l'utente o il ruolo nel server di destinazione usato per eseguire la migrazione. Questo utente deve essere membro dei ruoli azure_pg_admin, pg_read_all_settings, pg_read_all_stats, pg_stat_scan_tables e deve avere il ruolo gli attributi Crea ruolo, Crea DB.
dbsToMigrate	Richiesto	Specificare l'elenco di database di cui si vuole eseguire la migrazione al server flessibile. Viene eseguita la migrazione solo dei database utente. I database di sistema o i database di modello, ad esempio template0 e template1, non vengono migrati.
overwriteDbsInTarget	Richiesto	Quando impostato su true, se nel server di destinazione esiste già un database con lo stesso nome di quello di cui si sta tentando di eseguire la migrazione, il servizio di migrazione sovrascrive automaticamente il database.
setupLogicalReplicationOnSourceDBIfNeeded	Facoltativo	È possibile abilitare automaticamente la replica logica nel server di origine impostando questa proprietà su true. Questa modifica nelle impostazioni del server richiede un riavvio del server con due-tre minuti di tempo di inattività.
sourceDBServerFullyQualifiedDomainName	Facoltativo	È consigliabile usarlo quando viene usato un server DNS personalizzato per la risoluzione dei nomi di una rete virtuale. Specificare il nome di dominio completo dell'origine del server singolo in base al server DNS personalizzato per questa proprietà.
targetDBServerFullyQualifiedDomainName	Facoltativo	È consigliabile usarlo quando viene usato un server DNS personalizzato per la risoluzione dei nomi all'interno di una rete virtuale. Specificare il nome di dominio completo della destinazione del server flessibile in base al server DNS personalizzato. sourceDBServerFullyQualifiedDomainName e targetDBServerFullyQualifiedDomainName sono inclusi come parte del formato JSON solo nel raro caso in cui venga usato un server DNS personalizzato per la risoluzione dei nomi anziché il DNS fornito da Azure. Altrimenti, è consigliabile non includere questi parametri nel file JSON.

Si notino questi punti essenziali per la risposta del comando:

• Quando viene attivato il comando create, la migrazione passa allo stato InProgress e allo stato secondario PerformingPreRequisiteSteps. Il flusso di lavoro di migrazione richiede alcuni minuti per distribuire l'infrastruttura della migrazione e configurare le connessioni tra l'origine e la destinazione.
• Quando lo stato secondario PerformingPreRequisiteSteps viene completato, la migrazione passa allo stato secondario Migrating Data, quando viene eseguita la clonazione/copia dei database.
• Ogni database migrato ha una propria sezione con tutti i dettagli della migrazione, ad esempio numero di tabelle, inserimenti incrementali, eliminazioni e byte in sospeso.
• Il tempo necessario per completare lo stato secondario Migrating Data dipende dalle dimensioni dei database di cui viene eseguita la migrazione.
• La migrazione passa allo stato Succeeded non appena lo stato secondario Migrating Data viene completato correttamente. Se si verifica un problema nello stato secondario Migrating Data, la migrazione passa a uno stato Failed.

Configurare la replica

Per la migrazione online, la replica logica deve essere attivata nel server singolo di origine. Se non è attivata, il servizio di migrazione attiva automaticamente la replica logica nel server singolo di origine quando il parametro setupLogicalReplicationOnSourceDBIfNeeded viene passato con un valore di true nel file JSON associato. La replica può anche essere configurata manualmente nell'origine dopo l'avvio della migrazione usando il comando seguente. Entrambi gli approcci di attivazione della replica logica riavviano il server singolo di origine.

Ad esempio:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

Questo comando è necessario per far proseguire la migrazione quando il server flessibile è in attesa nello stato WaitingForLogicalReplicationSetupRequestOnSourceDB.

Per eseguire la migrazione online, usare:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./migrationBody.json" --migration-mode online

Elencare le migrazioni

Il comando list elenca tutti i tentativi di migrazione eseguiti verso una destinazione del server flessibile:

az postgres flexible-server migration list [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--filter]

Il parametro filter include due opzioni:

• Active: elenca i tentativi di migrazione attivi correnti (in corso) nel server di destinazione. Non include le migrazioni non riuscite, annullate o riuscite.
• All: elenca tutti i tentativi di migrazione nel server di destinazione. Sono incluse sia le migrazioni attive che concluse, indipendentemente dallo stato.

Per altre informazioni su questo comando, usare il parametro --help:

az postgres flexible-server migration list --help

Monitorare le migrazioni

Il comando show consente di monitorare le migrazioni in corso e fornisce lo stato e lo stato secondario attuali della migrazione.

az postgres flexible-server migration show [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--migration-name]

Il parametro migration_name è il nome assegnato alla migrazione durante l'esecuzione dell comando create. Ecco uno snapshot della risposta di esempio del comando dell'interfaccia della riga di comando per visualizzare i dettagli:

Per altre informazioni su questo comando, usare il parametro --help:

 az postgres flexible-server migration show --help

Le tabelle seguenti descrivono gli stati e gli stati secondari della migrazione.

Stato di migrazione	Descrizione
InProgress	L'infrastruttura di migrazione è configurata oppure è in corso la migrazione effettiva dei dati.
Canceled	La migrazione viene annullata o eliminata.
Failed	La migrazione non è riuscita.
Succeeded	La migrazione è riuscita ed è stata completata.
ValidationFailed	La migrazione non è riuscita durante la convalida preliminare della migrazione.

Stato secondario della migrazione	Descrizione
PerformingPreRequisiteSteps	L'infrastruttura viene configurata e viene preparata per la migrazione dei dati.
MigratingData	La migrazione dei dati è in corso.
WaitingForCutoverTrigger	Attività di migrazione dei dati completata e in attesa che l'utente attivi il cutover.
CompletingMigration	Completamento del processo di migrazione.
Completed	La migrazione è completa, indipendentemente dal fatto che lo stato abbia esito positivo o negativo.
CancelingRequestedDBMigrations	Annullamento della migrazione.
ValidationInProgress	La convalida è in esecuzione.

Eseguire il cutover delle migrazioni

Nelle migrazioni online, al termine della migrazione dei dati di base, l'attività di migrazione passa allo stato secondario WaitingForCutoverTrigger. In questo stato, l'utente può attivare il cutover tramite l'interfaccia della riga di comando usando il comando seguente. Il cutover può anche essere attivato dal portale selezionando il nome della migrazione nella griglia di migrazione.

Ad esempio:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --cutover

Prima di avviare il cutover, è essenziale assicurarsi che:

• Le scritture nell'origine vengono arrestate: il parametro latency è 0 o vicino a 0

Il parametro latency indica quando è avvenuta l'ultima sincronizzazione della destinazione con l'origine. Ad esempio, qui è 201 e 202 per i due database, come illustrato nell'immagine seguente. Ciò significa che le modifiche apportate negli ultimi ~200 secondi all'origine devono ancora essere sincronizzate con la destinazione. A questo punto, le scritture nell'origine possono essere arrestate e il cutover può essere avviato. Nel caso in cui si verifichi un traffico elevato nell'origine, è consigliabile arrestare prima le scritture in modo che Latency possa avvicinarsi a 0 e successivamente il cutover possa essere avviato. L'operazione di cutover applica tutte le modifiche in sospeso dall'origine alla destinazione e completa la migrazione. Se si attiva un "Cutover" anche con il valore Latency diverso da zero, la replica si arresta fino a quel momento. Tutti i dati nell'origine fino al momento del cutover vengono quindi applicati alla destinazione. Si supponga che la latenza fosse di 15 minuti nel punto di cutover; tutti i dati delle modifiche degli ultimi 15 minuti si applicano quindi alla destinazione. Il tempo impiegato dipende dal backlog delle modifiche apportate negli ultimi 15 minuti. Di conseguenza, è consigliabile che la latenza passi a zero o si avvicini a zero, prima di attivare il cutover. Le informazioni relative a latency possono essere ottenute usando il comando migration show.

Di seguito è riportato uno snapshot della migrazione prima di avviare il cutover:

Dopo l'avvio del cutover, tutte le transazioni eseguite durante la copia di base vengono copiate in sequenza nella destinazione e la migrazione viene completata.

Se il cutover non viene eseguito correttamente, la migrazione passa allo stato Failed.

Per altre informazioni su questo comando, usare il parametro --help:

 az postgres flexible-server migration update --help

Annullare la migrazione tramite l'interfaccia della riga di comando

È possibile annullare qualsiasi tentativo di migrazione in corso usando il comando cancel. Questo comando arresta il tentativo di migrazione specifico ed esegue il rollback di tutte le modifiche nel server di destinazione. Ecco il comando dell'interfaccia della riga di comando per annullare una migrazione:

az postgres flexible-server migration update cancel [--subscription]
                                                    [--resource-group]
                                                    [--name]
                                                    [--migration-name]

Ad esempio:

az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1

Per altre informazioni su questo comando, usare il parametro --help:

 az postgres flexible-server migration update cancel --help

Il comando genera l'output seguente:

Controllare la migrazione al termine dell’operazione

Dopo aver completato i database, è necessario convalidare manualmente i dati tra origine e destinazione e verificare che tutti gli oggetti nel database di destinazione siano stati creati correttamente.

Dopo la migrazione, è possibile effettuare le attività seguenti:

• Verificare i dati nel server flessibile e assicurarsi che si tratti di una copia esatta dell'istanza di origine.

• Dopo la verifica, abilitare l'opzione di disponibilità elevata nel server flessibile in base alle esigenze.

• Modificare lo SKU del server flessibile in modo che corrisponda alle esigenze dell'applicazione. Questa modifica richiede un riavvio del server di database.

• Se si modificano i parametri del server dai relativi valori predefiniti nell'istanza di origine, copiare questi valori nel server flessibile.

• Copiare altre impostazioni del server, ad esempio tag, avvisi e regole del firewall (se applicabile) dall'istanza di origine al server flessibile.

• Apportare modifiche all'applicazione per puntare le stringhe di connessione a un server flessibile.

• Monitorare attentamente le prestazioni del database per assicurarsi che non sia necessaria l'ottimizzazione delle prestazioni.

Contenuto correlato

• Servizio di migrazione
• Eseguire la migrazione da AWS RDS
• Procedure consigliate
• Problemi noti e limitazioni
• Configurazione della rete
• Convalide premigrazione