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 Database di Azure per PostgreSQL a un server flessibile PostgreSQL usando il portale di Azure.

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

Portale

È possibile eseguire la migrazione usando il portale di Azure.

Offline

Prerequisiti (offline)

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

Verificare la versione di origine

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

Configurazione di destinazione

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

• Lo SKU scelto per il Database di Azure per PostgreSQL deve corrispondere alle specifiche del database di origine per garantire la compatibilità e le 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 di rete è essenziale per garantire una corretta connettività tra l'origine e la destinazione durante la migrazione. Ecco una guida che consente di stabilire la connessione di rete per diversi scenari:

Requisiti di rete per la migrazione:

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

• Peering reti virtuali: stabilire il peering di rete virtuale 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 il Database di Azure per PostgreSQL.

scenari di Connessione ivity:

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

Source	Target	Connessione ivity Suggerimenti
Pubblico	Pubblico	Non è necessaria alcuna altra azione se l'origine è inclusa nell'elenco elementi consentiti nelle regole del firewall della destinazione.
Privata	Pubblico	Questa configurazione non è supportata; usare pg_dump/pg_restore per il trasferimento dei dati.
Pubblico	Privato	Non è necessaria alcuna altra azione se l'origine è inclusa nell'elenco elementi consentiti nelle regole del firewall della destinazione.
Privata	Privata	Stabilire un peering di rete virtuale, VPN ExpressRoute, IPsec, tunneling VPN o rete virtuale tra l'origine e la destinazione.
Privata	Endpoint privato	Questa configurazione non è supportata; contattare il supporto tecnico Microsoft.

Considerazioni aggiuntive sulla rete:

• pg_hba.conf Configurazione: 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 client e deve essere configurato per consentire a 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 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 di 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 Parametro server del Database di Azure per PostgreSQL. Abilitare le estensioni disponibili nell'origine all'interno di PostgreSQL.

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

  

• Controllare se l'elenco contiene 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 precaricati al riavvio del server.

Parametri del server

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

• Trovare la corrispondenza dei valori dei parametri del server dal database PostgreSQL di origine al Database di Azure per PostgreSQL accedendo alla sezione "Parametri server" nella portale di Azure e aggiornando manualmente i valori di conseguenza.

• Salvare le modifiche del parametro e riavviare il 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 le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente di database in Azure.

Configurare il server flessibile Database di Azure per PostgreSQL

• Creare il server flessibile di destinazione. Per i passaggi guidati, vedere l'argomento di avvio rapido Creare un server flessibile Database di Azure per PostgreSQL usando il portale.

• Estensioni allowlist le cui librerie devono essere caricate all'avvio del server. È essenziale che l'estensione si trovi nell'elenco di 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 singola (o 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 basata su procedura guidata sul 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 server flessibile Database di Azure per PostgreSQL.

3. Nella scheda Panoramica del server flessibile, nel menu a sinistra scorrere verso il basso fino a Migrazione e selezionarlo.

   

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

   

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

5. Selezionare il pulsante Esegui migrazione da server singolo. Si passa attraverso una serie di schede basate su procedura guidata per creare una migrazione in questa destinazione server flessibile da qualsiasi server singolo di origine.

In alternativa, è possibile avviare il processo di migrazione dal server singolo 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 correlato alla migrazione nella scheda Panoramica. Selezionare Esegui migrazione ora per iniziare.

   

3. Si viene visualizzati in una pagina con due opzioni. Se è già stato creato un server flessibile e si vuole usarlo come destinazione, scegliere Seleziona esistente e selezionare i dettagli di Sottoscrizione, Gruppo di risorse e Nome server corrispondenti. Dopo aver effettuato le selezioni, selezionare Vai alla migrazione guidata e passare alle istruzioni nella sezione Configurazione della pagina.

   

4. Se si sceglie crea un nuovo server flessibile, selezionare Crea nuovo e selezionare Vai a Creazione guidata. Questa azione illustra 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 Setup

La prima scheda è Setup. In caso di mancato recapito, consentire l'elenco delle estensioni necessarie, come illustrato in È essenziale consentire queste estensioni prima di avviare una migrazione.

Il nome della migrazione è l'identificatore univoco per ogni migrazione a questa destinazione del server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali tranne un trattino (-). Il nome non può iniziare con un trattino e deve essere univoco per un server di destinazione. Due migrazioni alla stessa destinazione del server flessibile possono avere lo stesso nome.

Il tipo di server di origine indica l'origine. In questo caso, è Database di Azure per PostgreSQL server singolo

L'opzione di migrazione consente di eseguire convalide prima di attivare una migrazione. È possibile scegliere una delle opzioni seguenti.

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

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

Se è selezionata l'anteprima della migrazione online , la replica logica deve essere attivata nel server singolo di origine. Se non è attivato, il servizio di migrazione attiva automaticamente la replica logica nel server singolo di origine. La replica può essere configurata manualmente anche nella scheda Replica nel riquadro Lato server singolo impostando il livello di supporto della replica di Azure su Logico. Entrambi gli approcci riavviano il server singolo di origine.

Selezionare il pulsante Avanti : Connessione a Origine.

Scheda Origine

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

Dopo aver eseguito le selezioni sottoscrizione e 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 vuole eseguire la migrazione dei database. È possibile eseguire la migrazione di database da un server singolo a un server flessibile di destinazione nella stessa area. Le migrazioni tra aree sono abilitate solo per i server India, Cina ed Emirati Arabi Uniti.

Dopo aver scelto l'origine server singolo, le caselle Percorso, Versione PostgreSQL e Nome account di accesso amministratore server vengono popolate automaticamente. Il nome di accesso dell'amministratore del server è il nome utente amministratore usato per creare il server singolo. Nella casella Password immettere la password per l'utente amministratore. Il servizio di migrazione esegue la migrazione di database a server singolo come utente amministratore.

Dopo aver compilato tutti i campi, selezionare il collegamento Connessione all'origine. Ciò verifica 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 della migrazione per continuare.

Scheda Destinazione

Nella scheda Destinazione vengono visualizzati i metadati per la destinazione del server flessibile, ad esempio il nome della sottoscrizione, il gruppo di risorse, il nome del server, il percorso e la versione di PostgreSQL.

Per Nome account di accesso amministratore server, nella scheda viene visualizzato il nome utente amministratore usato durante la creazione della destinazione server flessibile. Immettere la password corrispondente per l'utente amministratore. Dopo aver compilato la password, selezionare il collegamento Connessione di destinazione. Ciò verifica 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.

Selezionare Database per la scheda di migrazione

In questa scheda è presente un elenco di database utente all'interno del server singolo. È possibile selezionare ed eseguire la migrazione fino a otto database in un singolo 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 successivo di database. 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 Start.

Monitorare il portale di migrazione

Dopo aver selezionato il pulsante start, viene visualizzata una notifica in pochi secondi per indicare che la convalida o la creazione della migrazione ha esito positivo. Si viene reindirizzati automaticamente alla pagina Migrazione del server flessibile. È disponibile una nuova voce per la convalida o la migrazione creata di recente.

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

È possibile usare il pulsante aggiorna 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, passa allo stato InProgress e alla sottostate 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

Al termine dell'istruzione PerformingPreRequisiteSteps , la convalida passa allo stato secondario Convalida in corso in cui i controlli vengono eseguiti sul server di origine e di destinazione per valutare l'idoneità per la migrazione.

La convalida passa allo stato Succeeded se tutte le convalide sono in stato Succeeded o Warning .

La griglia di convalida ha

• Dettagli di convalida per le sezioni Dettagli di convalida e istanza per i database, che rappresentano le regole di convalida usate per controllare l'idoneità della migrazione.
• Stato convalida: rappresenta il risultato per ogni regola e può avere uno dei tre valori
  • Operazione riuscita : se non sono stati trovati errori.
  • Non riuscito : 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 fine: ora di inizio e di fine dell'operazione di convalida in formato UTC.

Lo stato convalida passa allo stato Non riuscito se sono presenti errori nella convalida. Selezionare il nome di convalida o la convalida del nome del database non riuscita e un riquadro di fanout fornisce i dettagli e l'azione correttiva da eseguire per evitare questo errore.

Migrate

Al termine del supporto PerformingPreRequisiteSteps , la migrazione passa al supporto di 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 dimensioni delle tabelle asimmetriche richiedono un tempo relativamente più lungo.

Quando si seleziona uno dei database nella migrazione, viene visualizzato un riquadro fan-out. Include tutto il numero di tabelle, copiato, accodato, copiato ed errori, a parte lo stato della migrazione del database.

La migrazione passa allo stato Succeeded al termine dell'operazione di migrazione dei dati . Se si verifica un problema nello stato Migrazione dei dati , la migrazione passa a uno stato Non riuscito .

Dopo che la migrazione passa allo stato Succeeded , schema e migrazione dei dati dal server singolo alla destinazione del server flessibile è stata completata. È possibile usare il pulsante di aggiornamento nella pagina per confermare lo stesso.

Convalidare ed eseguire la migrazione

In questa opzione, le convalide vengono eseguite prima dell'avvio della migrazione. Al termine dell'istruzione PerformingPreRequisiteSteps , il flusso di lavoro passa allo stato secondario Convalida in corso.

• Se la convalida presenta errori, la migrazione passa a uno stato Non riuscito .
• Se la convalida è stata completata senza errori, viene avviata la migrazione e il flusso di lavoro passa allo stato secondario di Migrazione dei dati.

Dopo il completamento dell'operazione, è possibile visualizzare i risultati di Convalida e migrazione .

Online (anteprima)

Prerequisiti (online)

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

Verificare la versione di origine

La versione di PostgreSQL di origine deve essere >= 9.5. Se la versione postgreSQL di origine è minore di 9.5, aggiornare la versione postgreSQL di origine a 9.5 o 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 parametri e max_replication_slots i max_wal_senders valori del server devono essere maggiori del numero di database di cui è necessario eseguire la migrazione. I parametri possono essere impostati nella portale di Azure in parametri Impostazioni-server> o configurati nella riga di comando usando i comandi seguenti:

• ALTER SYSTEM edizione Standard T wal_level = logico;
• ALTER SYSTEM edizione Standard T max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM edizione Standard T max_replication_slots = number of databases to migrate + 1;

Assicurarsi che non siano presenti transazioni a esecuzione prolungata. Le transazioni con 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 Database di Azure per PostgreSQL server singolo, il supporto della replica di Azure è impostato su logico nelle impostazioni di replica della pagina del server singolo nel portale di Azure.

Configurazione di destinazione

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

• Lo SKU scelto per il Database di Azure per PostgreSQL deve corrispondere alle specifiche del database di origine per garantire la compatibilità e le 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 max_replication_slots del server deve essere maggiore del numero di database di cui è necessario eseguire la migrazione. Può essere impostato nella portale di Azure in parametri Impostazioni-server> o configurato nella riga di comando usando il comando seguente:

• ALTER SYSTEM edizione Standard T max_replication_slots = number of databases to migrate + 1;

Configurazione della rete

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

Requisiti di rete per la migrazione:

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

• Peering reti virtuali: stabilire il peering di rete virtuale 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 il Database di Azure per PostgreSQL.

scenari di Connessione ivity:

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

Source	Target	Connessione ivity Suggerimenti
Pubblico	Pubblico	Non è necessaria alcuna altra azione se l'origine è inclusa nell'elenco consentito nelle regole del firewall di destinazione.
Privata	Pubblico	Questa configurazione non è supportata; usare pg_dump/pg_restore per il trasferimento dei dati.
Pubblico	Privato	Non è necessaria alcuna altra azione se l'origine è inclusa nell'elenco consentito nelle regole del firewall di destinazione.
Privata	Privata	Stabilire un peering di rete virtuale, VPN ExpressRoute, IPsec, tunneling VPN o rete virtuale tra l'origine e la destinazione.
Privata	Endpoint privato	Questa configurazione non è supportata; contattare il supporto tecnico Microsoft.

Per altre informazioni sulla configurazione di 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 Parametro server del Database di Azure per PostgreSQL. Abilitare le estensioni disponibili nell'origine all'interno di PostgreSQL.

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

  

• Controllare se l'elenco contiene 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 precaricati al riavvio del server.

Parametri del server

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

• Trovare la corrispondenza dei valori dei parametri del server dal database PostgreSQL di origine al Database di Azure per PostgreSQL accedendo alla sezione "Parametri server" nella portale di Azure e aggiornando manualmente i valori di conseguenza.

• Salvare le modifiche del parametro e riavviare il 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 le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente di database in Azure.

Configurare il server flessibile Database di Azure per PostgreSQL

• Creare il server flessibile di destinazione. Per i passaggi guidati, vedere l'argomento di avvio rapido Creare un server flessibile Database di Azure per PostgreSQL usando il portale.

• Estensioni allowlist le cui librerie devono essere caricate all'avvio del server. È essenziale che l'estensione si trovi nell'elenco di 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 singola (o 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 basata su procedura guidata sul 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 server flessibile Database di Azure per PostgreSQL.

3. Nella scheda Panoramica del server flessibile, nel menu a sinistra scorrere verso il basso fino a Migrazione e selezionarlo.

   

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

   

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

5. Selezionare il pulsante Esegui migrazione da server singolo. Si passa attraverso una serie di schede basate su procedura guidata per creare una migrazione in questa destinazione server flessibile da qualsiasi server singolo di origine.

In alternativa, è possibile avviare il processo di migrazione dal server singolo 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 correlato alla migrazione nella scheda Panoramica. Selezionare Esegui migrazione ora per iniziare.

   

3. Si viene visualizzati in una pagina con due opzioni. Se è già stato creato un server flessibile e si vuole usarlo come destinazione, scegliere Seleziona esistente e selezionare i dettagli di Sottoscrizione, Gruppo di risorse e Nome server corrispondenti. Dopo aver effettuato le selezioni, selezionare Vai alla migrazione guidata e passare alle istruzioni nella sezione Configurazione della pagina.

   

4. Se si sceglie crea un nuovo server flessibile, selezionare Crea nuovo e selezionare Vai a Creazione guidata. Questa azione illustra 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 Setup

La prima scheda è Setup. In caso di mancato recapito, consentire l'elenco delle estensioni necessarie, come illustrato in È essenziale consentire queste estensioni prima di avviare una migrazione.

Il nome della migrazione è l'identificatore univoco per ogni migrazione a questa destinazione del server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali tranne un trattino (-). Il nome non può iniziare con un trattino e deve essere univoco per un server di destinazione. Due migrazioni alla stessa destinazione del server flessibile possono avere lo stesso nome.

Il tipo di server di origine indica l'origine. In questo caso, è Database di Azure per PostgreSQL server singolo

L'opzione di migrazione consente di eseguire convalide prima di attivare una migrazione. È possibile scegliere una delle opzioni seguenti.

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

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

Se è selezionata l'anteprima della migrazione online , la replica logica deve essere attivata nel server singolo di origine. Se non è attivato, il servizio di migrazione attiva automaticamente la replica logica nel server singolo di origine. La replica può essere configurata manualmente anche nella scheda Replica nel riquadro Lato server singolo impostando il livello di supporto della replica di Azure su Logico. Entrambi gli approcci riavviano il server singolo di origine.

Selezionare il pulsante Avanti : Connessione a Origine.

Scheda Origine

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

Dopo aver eseguito le selezioni sottoscrizione e 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 vuole eseguire la migrazione dei database. È possibile eseguire la migrazione di database da un server singolo a un server flessibile di destinazione nella stessa area. Le migrazioni tra aree sono abilitate solo per i server India, Cina ed Emirati Arabi Uniti.

Dopo aver scelto l'origine server singolo, le caselle Percorso, Versione PostgreSQL e Nome account di accesso amministratore server vengono popolate automaticamente. Il nome di accesso dell'amministratore del server è il nome utente amministratore usato per creare il server singolo. Nella casella Password immettere la password per l'utente amministratore. Il servizio di migrazione esegue la migrazione di database a server singolo come utente amministratore.

Dopo aver compilato tutti i campi, selezionare il collegamento Connessione all'origine. Ciò verifica 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 della migrazione per continuare.

Scheda Destinazione

Nella scheda Destinazione vengono visualizzati i metadati per la destinazione del server flessibile, ad esempio il nome della sottoscrizione, il gruppo di risorse, il nome del server, il percorso e la versione di PostgreSQL.

Per Nome account di accesso amministratore server, nella scheda viene visualizzato il nome utente amministratore usato durante la creazione della destinazione server flessibile. Immettere la password corrispondente per l'utente amministratore. Dopo aver compilato la password, selezionare il collegamento Connessione di destinazione. Ciò verifica 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.

Selezionare Database per la scheda di migrazione

In questa scheda è presente un elenco di database utente all'interno del server singolo. È possibile selezionare ed eseguire la migrazione fino a otto database in un singolo 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 successivo di database. 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 Start.

Monitorare la migrazione usando portale di Azure

Dopo aver selezionato il pulsante start, viene visualizzata una notifica in pochi secondi per indicare che la convalida o la creazione della migrazione ha esito positivo. Si viene reindirizzati automaticamente alla pagina Migrazione del server flessibile. È disponibile una nuova voce per la convalida o la migrazione creata di recente.

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

È possibile usare il pulsante aggiorna 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, passa allo stato InProgress e alla sottostate 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

Al termine dell'istruzione PerformingPreRequisiteSteps , la convalida passa allo stato secondario Convalida in corso in cui i controlli vengono eseguiti sul server di origine e di destinazione per valutare l'idoneità per la migrazione.

La convalida passa allo stato Succeeded se tutte le convalide sono in stato Succeeded o Warning .

La griglia di convalida ha

• Dettagli di convalida per le sezioni Dettagli di convalida e istanza per i database, che rappresentano le regole di convalida usate per controllare l'idoneità della migrazione.
• Stato convalida: rappresenta il risultato per ogni regola e può avere uno dei tre valori
  • Operazione riuscita : se non sono stati trovati errori.
  • Non riuscito : 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 fine: ora di inizio e di fine dell'operazione di convalida in formato UTC.

Lo stato convalida passa allo stato Non riuscito se sono presenti errori nella convalida. Selezionare il nome di convalida o la convalida del nome del database non riuscita e un riquadro di fanout fornisce i dettagli e l'azione correttiva da eseguire per evitare questo errore.

Migrate

Al termine del supporto PerformingPreRequisiteSteps , la migrazione passa al supporto di 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 dimensioni delle tabelle asimmetriche richiedono un tempo relativamente più lungo.

Quando si seleziona uno dei database nella migrazione, viene visualizzato un riquadro fan-out. Include tutto il numero di tabelle, copiato, accodato, copiato ed errori, a parte lo stato della migrazione del database.

La migrazione passa allo stato Succeeded al termine dell'operazione di migrazione dei dati . Se si verifica un problema nello stato Migrazione dei dati , la migrazione passa a uno stato Non riuscito .

Dopo che la migrazione passa allo stato Succeeded , schema e migrazione dei dati dal server singolo alla destinazione del server flessibile è stata completata. È possibile usare il pulsante di aggiornamento nella pagina per confermare lo stesso.

Convalidare ed eseguire la migrazione

In questa opzione, le convalide vengono eseguite prima dell'avvio della migrazione. Al termine dell'istruzione PerformingPreRequisiteSteps , il flusso di lavoro passa allo stato secondario Convalida in corso.

• Se la convalida presenta errori, la migrazione passa a uno stato Non riuscito .
• Se la convalida è stata completata senza errori, viene avviata la migrazione e il flusso di lavoro passa allo stato secondario di Migrazione dei dati.

Dopo il completamento dell'operazione, è possibile visualizzare i risultati di Convalida e migrazione .

Migrazione completa

Se è presente sia La migrazione che la migrazione, il completamento della migrazione online richiede un altro passaggio: è necessaria un'azione Cutover da parte dell'utente. Al termine della copia/clonazione dei dati di base, la migrazione passa allo WaitingForUserAction stato e al WaitingForCutoverTrigger supporto. 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:Latency (minutes) il parametro è 0 o vicino a 0 Le Latency (minutes) informazioni possono essere ottenute dalla schermata dei dettagli della migrazione, come illustrato di seguito:

Latency (minutes) parametro indica quando l'ultima destinazione è sincronizzata con l'origine. Ad esempio, per il database Orders 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 orders. A questo punto, le scritture nell'origine possono essere arrestate e avviate da cutover. Nel caso in cui si verifichi un traffico elevato all'origine, è consigliabile arrestare prima le scritture in modo che Latency (minutes) possano avvicinarsi a 0 e quindi venga avviato un cutover. L'operazione 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 punto nel tempo. Tutti i dati nell'origine fino a quando il punto di cutover non viene quindi applicato alla destinazione. Si supponga che una latenza sia stata di 15 minuti al punto di cutover, quindi tutti i dati delle modifiche negli ultimi 15 minuti vengono applicati alla destinazione. Il tempo impiegato dipende dal backlog delle modifiche apportate negli ultimi 15 minuti. Di conseguenza, è consigliabile che la latenza vada a zero o quasi zero, prima di attivare il cutover.

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

I possibili stati di migrazione includono:

• InProgress: la configurazione dell'infrastruttura di migrazione è in corso o la migrazione effettiva dei dati è in corso.
• Annullata: la migrazione viene annullata o eliminata.
• Operazione non riuscita: la migrazione non è riuscita.
• Convalida non riuscita : la convalida non è riuscita.
• Operazione completata: la migrazione è stata completata e completata.

Le possibili sottostate di migrazione includono:

• Esecuzione diPreRequisiteSteps: è in corso la configurazione dell'infrastruttura per la migrazione dei dati.
• Convalida in corso: la convalida è in corso.
• Migrazione diData: la migrazione dei dati è in corso.
• CompletionMigration: la migrazione è in fasi finali del completamento.
• Completata: 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 da annullare. Non è possibile annullare una convalida o una migrazione nello stato Operazione riuscita o Non riuscita.

L'annullamento di una convalida arresta qualsiasi altra attività di convalida e la convalida passa a uno stato Annullato . L'annullamento di una migrazione arresta altre attività di migrazione nel server di destinazione e passa a uno stato Annullato . Non rilascia o esegue il rollback delle modifiche nel server di destinazione. Assicurarsi di eliminare i database nel server di destinazione coinvolti in una migrazione annullata.

CLI

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

Offline

Prerequisiti (offline)

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

Verificare la versione di origine

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

Configurazione di destinazione

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

• Lo SKU scelto per il Database di Azure per PostgreSQL deve corrispondere alle specifiche del database di origine per garantire la compatibilità e le 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 di rete è essenziale per garantire una corretta connettività tra l'origine e la destinazione durante la migrazione. Ecco una guida che consente di stabilire la connessione di rete per diversi scenari:

Requisiti di rete per la migrazione:

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

• Peering reti virtuali: stabilire il peering di rete virtuale 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 il Database di Azure per PostgreSQL.

scenari di Connessione ivity:

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

Source	Target	Connessione ivity Suggerimenti
Pubblico	Pubblico	Non è necessaria alcuna altra azione se l'origine è inclusa nell'elenco elementi consentiti nelle regole del firewall della destinazione.
Privata	Pubblico	Questa configurazione non è supportata; usare pg_dump/pg_restore per il trasferimento dei dati.
Pubblico	Privato	Non è necessaria alcuna altra azione se l'origine è inclusa nell'elenco elementi consentiti nelle regole del firewall della destinazione.
Privata	Privata	Stabilire un peering di rete virtuale, VPN ExpressRoute, IPsec, tunneling VPN o rete virtuale tra l'origine e la destinazione.
Privata	Endpoint privato	Questa configurazione non è supportata; contattare il supporto tecnico Microsoft.

Considerazioni aggiuntive sulla rete:

• pg_hba.conf Configurazione: 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 client e deve essere configurato per consentire a 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 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 di 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 Parametro server del Database di Azure per PostgreSQL. Abilitare le estensioni disponibili nell'origine all'interno di PostgreSQL.

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

  

• Controllare se l'elenco contiene 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 precaricati al riavvio del server.

Parametri del server

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

• Trovare la corrispondenza dei valori dei parametri del server dal database PostgreSQL di origine al Database di Azure per PostgreSQL accedendo alla sezione "Parametri server" nella portale di Azure e aggiornando manualmente i valori di conseguenza.

• Salvare le modifiche del parametro e riavviare il 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 le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente di database in Azure.

Operazioni preliminari

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

2. Installare la versione più recente dell'interfaccia della riga di comando di Azure per il sistema operativo 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 az version comando . La versione deve essere 2.50.0 o successiva per usare i comandi dell'interfaccia della riga di comando di migrazione. In caso contrario, 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 di 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 consentire l'elenco delle estensioni prima di avviare una migrazione.

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

az postgres flexible-server migration --help

Il comando precedente offre l'output seguente:

L'output elenca i comandi di migrazione supportati, insieme alle relative azioni. Esaminiamo in dettaglio questi comandi.

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

Il create comando 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 offre 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 server flessibile.
name	Nome della destinazione del server flessibile.
migration-name	Identificatore univoco per le migrazioni tentate di eseguire il server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali, ad eccezione di un trattino (-). Il nome non può iniziare con -e non due migrazioni a una destinazione server flessibile 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 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 viene usato in altri comandi dell'interfaccia della create riga di comando, ad esempio update, deletee show. identifica in modo univoco il tentativo di migrazione nelle azioni corrispondenti in tutti questi comandi.

Infine, il create comando deve passare un file JSON come parte del relativo properties argomento.

La struttura del codice 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 create parametri che passano al formato di file JSON sono indicati di seguito:

Parametro	Tipo	Descrizione
sourceDbServerResourceId	Richiesto	Questo parametro è l'ID risorsa dell'origine server singolo ed è obbligatorio.
adminCredentials	Richiesto	Questo parametro elenca le password per gli utenti amministratori sia per l'origine server singolo che per la destinazione 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 singolo server e la password specificata viene usata per l'autenticazione per l'utente. Se non si usa l'utente predefinito, questo parametro è l'utente o il ruolo nel server di origine 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 per l'utente. Se non si usa l'utente predefinito, questo parametro è l'utente o il ruolo nel server di destinazione usato per eseguire la migrazione. L'utente deve essere membro dei ruoli di azure_pg_admin, pg_read_all_settings, pg_read_all_stats pg_stat_scan_tables e deve avere il ruolo Crea database.
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 modello, ad esempio template0 e template1, non verranno migrati.
overwriteDbsInTarget	Richiesto	Se impostato su true, se il server di destinazione ha un database esistente 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 inattività.
SourceDBServerFullyQualifiedDomainName	Facoltativo	Usarlo quando viene usato un server DNS personalizzato per la risoluzione dei nomi per una rete virtuale. Specificare il nome di dominio completo dell'origine server singolo in base al server DNS personalizzato per questa proprietà.
TargetDBServerFullyQualifiedDomainName	Facoltativo	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 codice JSON solo nello scenario raro in cui viene usato un server DNS personalizzato per la risoluzione dei nomi anziché per il DNS fornito da Azure. In caso contrario, non includere questi parametri nel file JSON.

Si notino questi punti essenziali per la risposta del comando:

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

Configurare la replica

Se è selezionata l'anteprima della 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 SetupLogicalReplicationOnSourceDBIfNeeded parametro 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 avanzare la migrazione quando il server flessibile è in attesa nello WaitingForLogicalReplicationSetupRequestOnSourceDB stato.

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 list comando elenca tutti i tentativi di migrazione eseguiti su una destinazione server flessibile:

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

Il filter parametro ha 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 help parametro :

az postgres flexible-server migration list -- help

Monitorare la migrazione

Il show comando consente di monitorare le migrazioni in corso e fornisce lo stato corrente e lo stato secondario della migrazione. Questi dettagli includono informazioni sullo stato corrente e sullo stato secondario della migrazione.

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

Il migration_name parametro è il nome assegnato alla migrazione durante il create comando . 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 help parametro :

 az postgres flexible-server migration show -- help

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

Stato di migrazione	Descrizione
InProgress	L'infrastruttura di migrazione è configurata o la migrazione effettiva dei dati è in corso.
Canceled	La migrazione viene annullata o eliminata.
Failed	La migrazione non è riuscita.
Succeeded	La migrazione è stata completata e completata.

Sottostato della migrazione	Descrizione
PerformingPreRequisiteSteps	L'infrastruttura viene configurata e viene preparata per la migrazione dei dati.
MigratingData	La migrazione dei dati è in corso.
CompletingMigration	Il cutover della migrazione è in corso.
Completed	cutover ha avuto esito positivo e la migrazione è stata completata.

Online (anteprima)

Prerequisiti (online)

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

Verificare la versione di origine

La versione di PostgreSQL di origine deve essere >= 9.5. Se la versione postgreSQL di origine è minore di 9.5, aggiornare la versione postgreSQL di origine a 9.5 o 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 parametri e max_replication_slots i max_wal_senders valori del server devono essere maggiori del numero di database di cui è necessario eseguire la migrazione. I parametri possono essere impostati nella portale di Azure in parametri Impostazioni-server> o configurati nella riga di comando usando i comandi seguenti:

• ALTER SYSTEM edizione Standard T wal_level = logico;
• ALTER SYSTEM edizione Standard T max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM edizione Standard T max_replication_slots = number of databases to migrate + 1;

Assicurarsi che non siano presenti transazioni a esecuzione prolungata. Le transazioni con 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 Database di Azure per PostgreSQL server singolo, il supporto della replica di Azure è impostato su logico nelle impostazioni di replica della pagina del server singolo nel portale di Azure.

Configurazione di destinazione

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

• Lo SKU scelto per il Database di Azure per PostgreSQL deve corrispondere alle specifiche del database di origine per garantire la compatibilità e le 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 max_replication_slots del server deve essere maggiore del numero di database di cui è necessario eseguire la migrazione. Può essere impostato nella portale di Azure in parametri Impostazioni-server> o configurato nella riga di comando usando il comando seguente:

• ALTER SYSTEM edizione Standard T max_replication_slots = number of databases to migrate + 1;

Configurazione della rete

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

Requisiti di rete per la migrazione:

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

• Peering reti virtuali: stabilire il peering di rete virtuale 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 il Database di Azure per PostgreSQL.

scenari di Connessione ivity:

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

Source	Target	Connessione ivity Suggerimenti
Pubblico	Pubblico	Non è necessaria alcuna altra azione se l'origine è inclusa nell'elenco consentito nelle regole del firewall di destinazione.
Privata	Pubblico	Questa configurazione non è supportata; usare pg_dump/pg_restore per il trasferimento dei dati.
Pubblico	Privato	Non è necessaria alcuna altra azione se l'origine è inclusa nell'elenco consentito nelle regole del firewall di destinazione.
Privata	Privata	Stabilire un peering di rete virtuale, VPN ExpressRoute, IPsec, tunneling VPN o rete virtuale tra l'origine e la destinazione.
Privata	Endpoint privato	Questa configurazione non è supportata; contattare il supporto tecnico Microsoft.

Per altre informazioni sulla configurazione di 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 Parametro server del Database di Azure per PostgreSQL. Abilitare le estensioni disponibili nell'origine all'interno di PostgreSQL.

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

  

• Controllare se l'elenco contiene 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 precaricati al riavvio del server.

Parametri del server

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

• Trovare la corrispondenza dei valori dei parametri del server dal database PostgreSQL di origine al Database di Azure per PostgreSQL accedendo alla sezione "Parametri server" nella portale di Azure e aggiornando manualmente i valori di conseguenza.

• Salvare le modifiche del parametro e riavviare il 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 le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente di database in Azure.

Operazioni preliminari

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

2. Installare la versione più recente dell'interfaccia della riga di comando di Azure per il sistema operativo 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 az version comando . La versione deve essere 2.50.0 o successiva per usare i comandi dell'interfaccia della riga di comando di migrazione. In caso contrario, 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 di 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 consentire l'elenco delle estensioni prima di avviare una migrazione.

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

az postgres flexible-server migration --help

Il comando precedente offre l'output seguente:

L'output elenca i comandi di migrazione supportati, insieme alle relative azioni. Esaminiamo in dettaglio questi comandi.

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

Il create comando 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 offre 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 server flessibile.
name	Nome della destinazione del server flessibile.
migration-name	Identificatore univoco per le migrazioni tentate di eseguire il server flessibile. Questo campo accetta solo caratteri alfanumerici e non accetta caratteri speciali, ad eccezione di un trattino (-). Il nome non può iniziare con -e non due migrazioni a una destinazione server flessibile 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 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 viene usato in altri comandi dell'interfaccia della create riga di comando, ad esempio update, deletee show. identifica in modo univoco il tentativo di migrazione nelle azioni corrispondenti in tutti questi comandi.

Infine, il create comando deve passare un file JSON come parte del relativo properties argomento.

La struttura del codice 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 create parametri che passano al formato di file JSON sono indicati di seguito:

Parametro	Tipo	Descrizione
sourceDbServerResourceId	Richiesto	Questo parametro è l'ID risorsa dell'origine server singolo ed è obbligatorio.
adminCredentials	Richiesto	Questo parametro elenca le password per gli utenti amministratori sia per l'origine server singolo che per la destinazione 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 singolo server e la password specificata viene usata per l'autenticazione per l'utente. Se non si usa l'utente predefinito, questo parametro è l'utente o il ruolo nel server di origine 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 per l'utente. Se non si usa l'utente predefinito, questo parametro è l'utente o il ruolo nel server di destinazione usato per eseguire la migrazione. L'utente deve essere membro dei ruoli di azure_pg_admin, pg_read_all_settings, pg_read_all_stats pg_stat_scan_tables e deve avere il ruolo Crea database.
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 modello, ad esempio template0 e template1, non verranno migrati.
overwriteDbsInTarget	Richiesto	Se impostato su true, se il server di destinazione ha un database esistente 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 inattività.
SourceDBServerFullyQualifiedDomainName	Facoltativo	Usarlo quando viene usato un server DNS personalizzato per la risoluzione dei nomi per una rete virtuale. Specificare il nome di dominio completo dell'origine server singolo in base al server DNS personalizzato per questa proprietà.
TargetDBServerFullyQualifiedDomainName	Facoltativo	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 codice JSON solo nello scenario raro in cui viene usato un server DNS personalizzato per la risoluzione dei nomi anziché per il DNS fornito da Azure. In caso contrario, non includere questi parametri nel file JSON.

Si notino questi punti essenziali per la risposta del comando:

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

Configurare la replica

Se è selezionata l'anteprima della 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 SetupLogicalReplicationOnSourceDBIfNeeded parametro 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 avanzare la migrazione quando il server flessibile è in attesa nello WaitingForLogicalReplicationSetupRequestOnSourceDB stato.

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 list comando elenca tutti i tentativi di migrazione eseguiti su una destinazione server flessibile:

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

Il filter parametro ha 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 help parametro :

az postgres flexible-server migration list -- help

Monitorare la migrazione

Il show comando consente di monitorare le migrazioni in corso e fornisce lo stato corrente e lo stato secondario della migrazione. Questi dettagli includono informazioni sullo stato corrente e sullo stato secondario della migrazione.

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

Il migration_name parametro è il nome assegnato alla migrazione durante il create comando . 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 help parametro :

 az postgres flexible-server migration show -- help

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

Stato di migrazione	Descrizione
InProgress	L'infrastruttura di migrazione è configurata o la migrazione effettiva dei dati è in corso.
Canceled	La migrazione viene annullata o eliminata.
Failed	La migrazione non è riuscita.
Succeeded	La migrazione è stata completata e completata.

Sottostato della migrazione	Descrizione
PerformingPreRequisiteSteps	L'infrastruttura viene configurata e viene preparata per la migrazione dei dati.
MigratingData	La migrazione dei dati è in corso.
CompletingMigration	Il cutover della migrazione è in corso.
Completed	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 WaitingForCutoverTrigger stato secondario. 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 vengono arrestate:latency il parametro diminuisce a 0 o vicino a 0

latency parametro indica quando l'ultima destinazione è sincronizzata con l'origine. Ad esempio, ecco il 201 e il 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 avviate da cutover. Nel caso in cui si verifichi un traffico elevato all'origine, è consigliabile arrestare prima le scritture in modo che Latency possano avvicinarsi a 0 e quindi venga avviato il cutover. L'operazione Cutover applica tutte le modifiche in sospeso dall'origine alla destinazione e completa la migrazione. Se si attiva un "Cutover" anche con diverso da zero Latency, la replica si arresta fino a quel punto nel tempo. Tutti i dati nell'origine fino a quando il punto di cutover non viene quindi applicato alla destinazione. Si supponga che una latenza sia stata di 15 minuti al punto di cutover, quindi tutti i dati delle modifiche negli ultimi 15 minuti si applicano alla destinazione. Il tempo impiegato dipende dal backlog delle modifiche apportate negli ultimi 15 minuti. Di conseguenza, è consigliabile che la latenza vada a zero o quasi zero, prima di attivare il cutover. Le latency informazioni 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 riesce, la migrazione passa allo Failed stato .

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

 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 cancel comando . Questo comando arresta il tentativo di migrazione specifico, ma non rilascia o esegue il rollback delle 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 help parametro :

 az postgres flexible-server migration update cancel -- help

Il comando fornisce 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 eseguire 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 a 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 i valori dei parametri del server 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 stringa di connessione a un server flessibile.

• Monitorare attentamente le prestazioni del database per verificare se richiede l'ottimizzazione delle prestazioni.

Contenuto correlato

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