Esercitazione: Eseguire la migrazione da Database di Azure per PostgreSQL - Server singolo a Database di Azure per PostgreSQL - Server flessibile usando 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

• 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.

Configurazione della rete

Una corretta configurazione della rete è essenziale per garantire una corretta connettività tra l'origine e la destinazione durante la migrazione. Ecco una guida utile per stabilire la connessione di rete in diversi scenari:

Requisiti di rete per la migrazione:

• ExpressRoute/VPN IPsec/tunneling VPN: quando si connette l'origine locale/AWS ad Azure, potrebbe essere necessario configurare ExpressRoute, VPN IPsec o un tunneling VPN per facilitare il trasferimento sicuro dei dati.

• Peering reti virtuali: stabilire il peering di reti virtuali tra le due reti virtuali distinte per abilitare la connettività di rete diretta, un prerequisito per la migrazione tra la macchina virtuale di Azure e Database di Azure per PostgreSQL.

Scenari di connettività:

La tabella seguente consente di configurare la rete tra l'origine e la destinazione.

Source	Target	Suggerimenti per la connettività
Pubblico	Pubblico	Non sono necessarie altre azioni se l'origine è inclusa nell'elenco elementi consentiti delle regole del firewall della destinazione.
Privata	Pubblico	Questa configurazione non è supportata; usare pg_dump/pg_restore per il trasferimento dei dati.
Pubblico	Privato	Non sono necessarie altre azioni se l'origine è inclusa nell'elenco elementi consentiti delle regole del firewall della destinazione.
Privata	Privata	Stabilire una connessione ExpressRoute, una VPN IPsec, un tunneling VPN o un peering di reti virtuali tra l'origine e la destinazione.
Privata	Endpoint privato	Questa configurazione non è supportata. Contattare il supporto tecnico Microsoft.

Ulteriori considerazioni sulla rete:

• Configurazione di pg_hba.conf: per facilitare la connettività tra le istanze di PostgreSQL di origine e di destinazione, è essenziale verificare e potenzialmente modificare il file pg_hba.conf. Questo file include l'autenticazione del client e deve essere configurato per consentire all'istanza PostgreSQL di destinazione di connettersi all'origine. Per rendere effettive le modifiche apportate al file pg_hba.conf, è in genere necessario riavviare l'istanza di PostgreSQL di origine.

Nota

Il file pg_hba.conf si trova nella directory dei dati dell'installazione di PostgreSQL. Questo file deve essere controllato e configurato se il database di origine è un server PostgreSQL locale o un server PostgreSQL ospitato in una macchina virtuale di Azure. Per le istanze di PostgreSQL in AWS RDS o in servizi gestiti simili, il file pg_hba.conf non è direttamente accessibile o applicabile. L'accesso viene invece controllato tramite le configurazioni di sicurezza e accesso alla rete fornite dal servizio.

Per altre informazioni sulla configurazione della rete, vedere Guida alla rete per il servizio di migrazione in Database di Azure per PostgreSQL - Server flessibile.

Estensioni

Le estensioni sono funzionalità aggiuntive che possono essere aggiunte a PostgreSQL per migliorarne le funzionalità. Le estensioni sono supportate in Database di Azure per PostgreSQL, ma devono essere abilitate manualmente. Per abilitare le estensioni, seguire questa procedura:

• Usare il comando select nell'origine per elencare tutte le estensioni in uso: select extname,extversion from pg_extension;.

• Cercare il parametro del server azure.extensions nella pagina dei parametri del server di Database di Azure per PostgreSQL. Abilitare le estensioni presenti nell'origine all'interno di PostgreSQL.

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

  

• Verificare che l'elenco contenga una delle estensioni seguenti:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

In caso affermativo, cercare il parametro shared_preload_libraries nella pagina dei parametri del server. Questo parametro indica il set di librerie di estensioni precaricate al riavvio del server.

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.

• Aggiungere all'elenco elementi consentiti le estensioni di cui è necessario caricare le 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. Selezionare il pulsante Migra da server singolo. Si passa attraverso una serie di schede di procedura guidata per creare una migrazione in questa destinazione del server flessibile da un qualsiasi server singolo di origine.

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 Selezionare 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 passare alle istruzioni nella sezione Scheda di configurazione di questa pagina.

   

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.

Scheda di configurazione

La prima scheda è Configurazione. Nel caso sia stata saltata, aggiungere all'elenco elementi consentiti le estensioni necessarie come illustrato. È essenziale aggiungere all'elenco elementi consentiti queste estensioni 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 (-). Il nome non può iniziare con un trattino e deve essere univoco per il server di destinazione. Due migrazioni verso la stessa destinazione del server flessibile non possono 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 le migrazioni.
• 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.

Se è selezionata 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. La replica può anche essere configurata manualmente nella scheda Replica del riquadro del server singolo impostando il livello di supporto della replica di Azure su Logica. Entrambi gli approcci riavviano il server singolo di origine.

Selezionare il pulsante Avanti: Connetti all'origine.

Scheda Origine

La scheda 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 del server singolo, le caselle Paese, Versione di PostgreSQL e Nome di accesso dell'amministratore server vengono popolate automaticamente. Il nome di accesso dell'amministratore del server è il nome utente dell'amministratore usato per creare il server singolo. Immettere la password per l'utente amministratore nella casella Password. Il servizio di migrazione esegue la migrazione di database a server singolo come utente amministratore.

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.

Scheda Destinazione

La scheda Destinazione mostra i metadati della destinazione del server flessibile, ad esempio il nome della sottoscrizione, il gruppo di risorse, il nome del server, il paese e la versione di PostgreSQL.

Per Nome di accesso dell'amministratore server, nella scheda viene visualizzato il nome utente dell'amministratore usato durante la creazione della destinazione del server flessibile. Immettere la password corrispondente per l'utente amministratore. Dopo aver inserito la password, 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 per selezionare i database di cui eseguire la migrazione.

Scheda Selezionare i 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. Per impostazione predefinita, i database selezionati con lo stesso nome nella destinazione vengono sovrascritti.

Selezionare il pulsante Avanti 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 sul pulsante di avvio.

Monitorare il portale della migrazione

Dopo aver selezionato il pulsante di avvio, entro pochi secondi viene visualizzata una notifica per indicare che la convalida o la creazione della migrazione è stata eseguita correttamente. 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, Tipo migrazione, Modalità 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 di aggiornamento per aggiornare lo stato della convalida o della migrazione. È anche possibile selezionare il nome della 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 include

• 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.
• 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 e di fine: 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, separatamente rispetto allo 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 usare il pulsante di aggiornamento nella pagina per confermarlo.

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 della 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.

Configurazione della 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;

Configurazione della rete

Una corretta configurazione della rete è essenziale per garantire una corretta connettività tra l'origine e la destinazione durante la migrazione. Ecco una guida utile per stabilire la connessione di rete in diversi scenari:

Requisiti di rete per la migrazione:

• ExpressRoute/VPN IPsec/tunneling VPN: quando si connette l'origine locale/AWS ad Azure, potrebbe essere necessario configurare ExpressRoute, VPN IPsec o un tunneling VPN per facilitare il trasferimento sicuro dei dati.

• Peering reti virtuali: stabilire il peering di reti virtuali tra le due reti virtuali distinte per abilitare la connettività di rete diretta, un prerequisito per la migrazione tra la macchina virtuale di Azure e Database di Azure per PostgreSQL.

Scenari di connettività:

La tabella seguente consente di configurare la rete tra l'origine e la destinazione.

Source	Target	Suggerimenti per la connettività
Pubblico	Pubblico	Non sono necessarie altre azioni se l'origine è inclusa nell'elenco elementi consentiti delle regole del firewall della destinazione.
Privata	Pubblico	Questa configurazione non è supportata; usare pg_dump/pg_restore per il trasferimento dei dati.
Pubblico	Privato	Non sono necessarie altre azioni se l'origine è inclusa nell'elenco elementi consentiti delle regole del firewall della destinazione.
Privata	Privata	Stabilire una connessione ExpressRoute, una VPN IPsec, un tunneling VPN o un peering di reti virtuali tra l'origine e la destinazione.
Privata	Endpoint privato	Questa configurazione non è supportata. Contattare il supporto tecnico Microsoft.

Per altre informazioni sulla configurazione della rete, vedere Guida alla rete per il servizio di migrazione in Database di Azure per PostgreSQL - Server flessibile.

Estensioni

Le estensioni sono funzionalità aggiuntive che possono essere aggiunte a PostgreSQL per migliorarne le funzionalità. Le estensioni sono supportate in Database di Azure per PostgreSQL, ma devono essere abilitate manualmente. Per abilitare le estensioni, seguire questa procedura:

• Usare il comando select nell'origine per elencare tutte le estensioni in uso: select extname,extversion from pg_extension;.

• Cercare il parametro del server azure.extensions nella pagina dei parametri del server di Database di Azure per PostgreSQL. Abilitare le estensioni presenti nell'origine all'interno di PostgreSQL.

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

  

• Verificare che l'elenco contenga una delle estensioni seguenti:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

In caso affermativo, cercare il parametro shared_preload_libraries nella pagina dei parametri del server. Questo parametro indica il set di librerie di estensioni precaricate al riavvio del server.

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.

• Aggiungere all'elenco elementi consentiti le estensioni di cui è necessario caricare le 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. Selezionare il pulsante Migra da server singolo. Si passa attraverso una serie di schede di procedura guidata per creare una migrazione in questa destinazione del server flessibile da un qualsiasi server singolo di origine.

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 Selezionare 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 passare alle istruzioni nella sezione Scheda di configurazione di questa pagina.

   

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.

Scheda di configurazione

La prima scheda è Configurazione. Nel caso sia stata saltata, aggiungere all'elenco elementi consentiti le estensioni necessarie come illustrato. È essenziale aggiungere all'elenco elementi consentiti queste estensioni 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 (-). Il nome non può iniziare con un trattino e deve essere univoco per il server di destinazione. Due migrazioni verso la stessa destinazione del server flessibile non possono 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 le migrazioni.
• 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.

Se è selezionata 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. La replica può anche essere configurata manualmente nella scheda Replica del riquadro del server singolo impostando il livello di supporto della replica di Azure su Logica. Entrambi gli approcci riavviano il server singolo di origine.

Selezionare il pulsante Avanti: Connetti all'origine.

Scheda Origine

La scheda 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 del server singolo, le caselle Paese, Versione di PostgreSQL e Nome di accesso dell'amministratore server vengono popolate automaticamente. Il nome di accesso dell'amministratore del server è il nome utente dell'amministratore usato per creare il server singolo. Immettere la password per l'utente amministratore nella casella Password. Il servizio di migrazione esegue la migrazione di database a server singolo come utente amministratore.

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.

Scheda Destinazione

La scheda Destinazione mostra i metadati della destinazione del server flessibile, ad esempio il nome della sottoscrizione, il gruppo di risorse, il nome del server, il paese e la versione di PostgreSQL.

Per Nome di accesso dell'amministratore server, nella scheda viene visualizzato il nome utente dell'amministratore usato durante la creazione della destinazione del server flessibile. Immettere la password corrispondente per l'utente amministratore. Dopo aver inserito la password, 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 per selezionare i database di cui eseguire la migrazione.

Scheda Selezionare i 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. Per impostazione predefinita, i database selezionati con lo stesso nome nella destinazione vengono sovrascritti.

Selezionare il pulsante Avanti 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 sul pulsante di avvio.

Monitorare la migrazione tramite il portale di Azure

Dopo aver selezionato il pulsante di avvio, entro pochi secondi viene visualizzata una notifica per indicare che la convalida o la creazione della migrazione è stata eseguita correttamente. 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, Tipo migrazione, Modalità 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 di aggiornamento per aggiornare lo stato della convalida o della migrazione. È anche possibile selezionare il nome della 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 include

• 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.
• 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 e di fine: 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, separatamente rispetto allo 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 usare il pulsante di aggiornamento nella pagina per confermarlo.

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

Se sono presenti sia Esegui migrazione che Convalida ed esegui migrazione, il completamento della migrazione online richiede un altro passaggio: è necessaria un'azione di cutover da parte dell'utente. Al termine della copia/clonazione dei dati di base, la migrazione passa allo stato WaitingForUserAction e allo stato secondario WaitingForCutoverTrigger. In questo stato, l'utente può attivare il cutover dal portale selezionando la migrazione.

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, come illustrato di seguito:

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 sincronizzate con la 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 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 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 delle modifiche degli 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 passi a zero o si avvicini a zero, prima di attivare il cutover.

La migrazione passa allo stato Succeeded non appena lo stato secondario Migrating Data o il cutover (nella migrazione online) viene completato correttamente. Se si verifica un problema nello stato secondario Migrating Data, la migrazione passa a uno stato Failed.

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

• 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.

Configurazione della rete

Una corretta configurazione della rete è essenziale per garantire una corretta connettività tra l'origine e la destinazione durante la migrazione. Ecco una guida utile per stabilire la connessione di rete in diversi scenari:

Requisiti di rete per la migrazione:

• ExpressRoute/VPN IPsec/tunneling VPN: quando si connette l'origine locale/AWS ad Azure, potrebbe essere necessario configurare ExpressRoute, VPN IPsec o un tunneling VPN per facilitare il trasferimento sicuro dei dati.

• Peering reti virtuali: stabilire il peering di reti virtuali tra le due reti virtuali distinte per abilitare la connettività di rete diretta, un prerequisito per la migrazione tra la macchina virtuale di Azure e Database di Azure per PostgreSQL.

Scenari di connettività:

La tabella seguente consente di configurare la rete tra l'origine e la destinazione.

Source	Target	Suggerimenti per la connettività
Pubblico	Pubblico	Non sono necessarie altre azioni se l'origine è inclusa nell'elenco elementi consentiti delle regole del firewall della destinazione.
Privata	Pubblico	Questa configurazione non è supportata; usare pg_dump/pg_restore per il trasferimento dei dati.
Pubblico	Privato	Non sono necessarie altre azioni se l'origine è inclusa nell'elenco elementi consentiti delle regole del firewall della destinazione.
Privata	Privata	Stabilire una connessione ExpressRoute, una VPN IPsec, un tunneling VPN o un peering di reti virtuali tra l'origine e la destinazione.
Privata	Endpoint privato	Questa configurazione non è supportata. Contattare il supporto tecnico Microsoft.

Ulteriori considerazioni sulla rete:

• Configurazione di pg_hba.conf: per facilitare la connettività tra le istanze di PostgreSQL di origine e di destinazione, è essenziale verificare e potenzialmente modificare il file pg_hba.conf. Questo file include l'autenticazione del client e deve essere configurato per consentire all'istanza PostgreSQL di destinazione di connettersi all'origine. Per rendere effettive le modifiche apportate al file pg_hba.conf, è in genere necessario riavviare l'istanza di PostgreSQL di origine.

Nota

Il file pg_hba.conf si trova nella directory dei dati dell'installazione di PostgreSQL. Questo file deve essere controllato e configurato se il database di origine è un server PostgreSQL locale o un server PostgreSQL ospitato in una macchina virtuale di Azure. Per le istanze di PostgreSQL in AWS RDS o in servizi gestiti simili, il file pg_hba.conf non è direttamente accessibile o applicabile. L'accesso viene invece controllato tramite le configurazioni di sicurezza e accesso alla rete fornite dal servizio.

Per altre informazioni sulla configurazione della rete, vedere Guida alla rete per il servizio di migrazione in Database di Azure per PostgreSQL - Server flessibile.

Estensioni

Le estensioni sono funzionalità aggiuntive che possono essere aggiunte a PostgreSQL per migliorarne le funzionalità. Le estensioni sono supportate in Database di Azure per PostgreSQL, ma devono essere abilitate manualmente. Per abilitare le estensioni, seguire questa procedura:

• Usare il comando select nell'origine per elencare tutte le estensioni in uso: select extname,extversion from pg_extension;.

• Cercare il parametro del server azure.extensions nella pagina dei parametri del server di Database di Azure per PostgreSQL. Abilitare le estensioni presenti nell'origine all'interno di PostgreSQL.

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

  

• Verificare che l'elenco contenga una delle estensioni seguenti:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

In caso affermativo, cercare il parametro shared_preload_libraries nella pagina dei parametri del server. Questo parametro indica il set di librerie di estensioni precaricate al riavvio del server.

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 (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

Il comando precedente genera 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

Il comando precedente genera il risultato 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 le migrazioni tentate verso il server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali tranne il trattino (-). Il nome non può iniziare con - e due migrazioni verso la stessa destinazione del server flessibile non possono 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 "C:\Users\Administrator\Documents\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/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"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 ed è obbligatorio.
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 creato 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 verranno 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

Se è selezionata 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 in una delle aree precedenti, usare:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\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 precedenti, 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. Questi dettagli includono informazioni sullo stato e sullo 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.

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	È in corso il cutover della migrazione.
Completed	Il cutover ha avuto esito positivo e la migrazione è stata completata.

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 della 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.

Configurazione della 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;

Configurazione della rete

Una corretta configurazione della rete è essenziale per garantire una corretta connettività tra l'origine e la destinazione durante la migrazione. Ecco una guida utile per stabilire la connessione di rete in diversi scenari:

Requisiti di rete per la migrazione:

• ExpressRoute/VPN IPsec/tunneling VPN: quando si connette l'origine locale/AWS ad Azure, potrebbe essere necessario configurare ExpressRoute, VPN IPsec o un tunneling VPN per facilitare il trasferimento sicuro dei dati.

• Peering reti virtuali: stabilire il peering di reti virtuali tra le due reti virtuali distinte per abilitare la connettività di rete diretta, un prerequisito per la migrazione tra la macchina virtuale di Azure e Database di Azure per PostgreSQL.

Scenari di connettività:

La tabella seguente consente di configurare la rete tra l'origine e la destinazione.

Source	Target	Suggerimenti per la connettività
Pubblico	Pubblico	Non sono necessarie altre azioni se l'origine è inclusa nell'elenco elementi consentiti delle regole del firewall della destinazione.
Privata	Pubblico	Questa configurazione non è supportata; usare pg_dump/pg_restore per il trasferimento dei dati.
Pubblico	Privato	Non sono necessarie altre azioni se l'origine è inclusa nell'elenco elementi consentiti delle regole del firewall della destinazione.
Privata	Privata	Stabilire una connessione ExpressRoute, una VPN IPsec, un tunneling VPN o un peering di reti virtuali tra l'origine e la destinazione.
Privata	Endpoint privato	Questa configurazione non è supportata. Contattare il supporto tecnico Microsoft.

Per altre informazioni sulla configurazione della rete, vedere Guida alla rete per il servizio di migrazione in Database di Azure per PostgreSQL - Server flessibile.

Estensioni

Le estensioni sono funzionalità aggiuntive che possono essere aggiunte a PostgreSQL per migliorarne le funzionalità. Le estensioni sono supportate in Database di Azure per PostgreSQL, ma devono essere abilitate manualmente. Per abilitare le estensioni, seguire questa procedura:

• Usare il comando select nell'origine per elencare tutte le estensioni in uso: select extname,extversion from pg_extension;.

• Cercare il parametro del server azure.extensions nella pagina dei parametri del server di Database di Azure per PostgreSQL. Abilitare le estensioni presenti nell'origine all'interno di PostgreSQL.

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

  

• Verificare che l'elenco contenga una delle estensioni seguenti:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

In caso affermativo, cercare il parametro shared_preload_libraries nella pagina dei parametri del server. Questo parametro indica il set di librerie di estensioni precaricate al riavvio del server.

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

Il comando precedente genera 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

Il comando precedente genera il risultato 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 le migrazioni tentate verso il server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali tranne il trattino (-). Il nome non può iniziare con - e due migrazioni verso la stessa destinazione del server flessibile non possono 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 "C:\Users\Administrator\Documents\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/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"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 ed è obbligatorio.
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 creato 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 verranno 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

Se è selezionata 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 in una delle aree precedenti, usare:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\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 precedenti, 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. Questi dettagli includono informazioni sullo stato e sullo 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.

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	È in corso il cutover della migrazione.
Completed	Il cutover ha avuto esito positivo e la migrazione è stata completata.

Eseguire il cutover della migrazione

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, è importante assicurarsi che:

• Le scritture nell'origine siano state arrestate: il parametro latency passa a 0 o si avvicina 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 eliminare 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:

Dopo la migrazione

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