Esercitazione: Eseguire la migrazione online da una macchina virtuale di Azure o da un server PostgreSQL locale a Database di Azure per PostgreSQL con l'anteprima del servizio di migrazione

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

Questo articolo illustra come eseguire la migrazione di un'istanza di PostgreSQL dalle macchine virtuali locali o di Azure al server flessibile di Database di Azure per PostgreSQL usando il portale di Azure e l'interfaccia della riga di comando di Azure.

Il servizio di migrazione in Database di Azure per PostgreSQL è un servizio completamente gestito, integrato nel portale di Azure e nell'interfaccia della riga di comando di Azure. È progettato per semplificare il percorso di migrazione al server flessibile di Database di Azure per PostgreSQL.

• Configurare il server flessibile di Database di Azure per PostgreSQL
• Configurare l'attività di migrazione
• Monitorare la migrazione
• Controllare la migrazione al termine dell'operazione

Prerequisiti

Per iniziare la migrazione sono necessari i prerequisiti seguenti:

Prima di avviare la migrazione con il servizio migrazione di Database di Azure per PostgreSQL, è importante soddisfare i prerequisiti seguenti, specifici per gli scenari di migrazione online.

• Verificare la versione di origine
• Installare test_decoding - Setup dell'origine
• Configurare il setup della destinazione
• Abilitare Change Data Capture come origine
• Configurare il setup di rete
• Abilitare le estensioni
• Controllare i parametri del server
• Controllare gli utenti e i ruoli

Verificare la versione di origine

La versione del server PostgreSQL di origine deve essere 9.5 o successiva.

Se la versione di origine di PostgreSQL è precedente alla versione 9.5, aggiornarla alla versione 9.5 o successiva prima di avviare la migrazione.

Installare test_decoding - Setup dell'origine

• test_decoding riceve il log write-ahead (WAL) tramite il meccanismo di decodifica logica e lo decodifica in rappresentazioni testuali delle operazioni eseguite.

• Per altre informazioni sul plug-in test-decoding, vedere la documentazione di PostgreSQL

Configurare il setup della destinazione

• Prima della migrazione, è necessario creare un'istanza di Database di Azure per PostgreSQL - Server flessibile.
• Lo SKU di cui è stato effettuato il provisioning per Database di Azure per PostgreSQL - Server flessibile deve corrispondere a quello di origine.
• Per creare un nuovo Database di Azure per PostgreSQL, vedere Creare un database di Azure per PostgreSQL

Abilitare Change Data Capture come origine

• Il plug-in di decodifica logica test_decoding acquisisce i record modificati dall'origine.
• Nell'istanza di PostgreSQL di origine, impostare i parametri e i valori seguenti nel file di configurazione postgresql.conf:
  • Set wal_level = logical
  • Set max_replication_slots su un valore maggiore di 1. Il valore deve essere maggiore del numero di database selezionati per la migrazione.
  • Set max_wal_senders su un valore maggiore di 1, deve essere impostato almeno su uguale a max_replication_slots, più il numero di mittenti già utilizzati dall'istanza.
  • Il parametro wal_sender_timeout termina le connessioni di replica inattive più a lungo del numero specificato di millisecondi. Il valore predefinito per un database PostgreSQL locale è 60000 millisecondi (60 secondi). L'impostazione del valore su 0 (zero) disabilita il meccanismo di timeout ed è valida per la migrazione.

Per evitare che la migrazione online esaurisca lo spazio, verificare di disporre di uno spazio tabella sufficiente usando un disco gestito con provisioning. Per raggiungere questo obiettivo, disabilitare il parametro server azure.enable_temp_tablespaces_on_local_ssd sul Server flessibile per la durata della migrazione e ripristinarlo allo stato originale dopo la migrazione.

Configurare il setup di rete

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

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

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

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.

Abilitare le estensioni

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

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

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

Nota

Quando si apportano modifiche al shared_preload_libraries parametro, è necessario un riavvio.

Controllare i parametri del server

• È necessario configurare manualmente i valori dei parametri del server in Database di Azure per PostgreSQL -Server flessibile in base ai valori dei parametri del server configurati nell'origine.

Controllare gli utenti e i ruoli

• Gli utenti e i diversi ruoli devono essere migrati manualmente in Database di Azure per PostgreSQL - Server flessibile. Per la migrazione di utenti e ruoli, è possibile usare pg_dumpall --globals-only -U <<username> -f <<filename>>.sql.
• Database di Azure per PostgreSQL: il server flessibile non supporta alcun utente con privilegi avanzati, gli utenti con ruoli con privilegi avanzati devono essere rimossi prima della migrazione.

Eseguire la migrazione

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

Portale

Questo articolo illustra come usare il portale di Azure per eseguire la migrazione del database PostgreSQL da una macchina virtuale di Azure o da un server PostgreSQL locale a un Database di Azure per PostgreSQL. Il portale di Azure consente di eseguire varie attività, tra cui la migrazione del database. Seguendo i passaggi descritti in questa esercitazione, è possibile trasferire facilmente il database in Azure e sfruttarne le potenti funzionalità e la scalabilità.

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. Immettere le credenziali di accesso. La visualizzazione predefinita è il dashboard del servizio.

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

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

   

4. Selezionare il pulsante Crea per eseguire la migrazione da una macchina virtuale (VM) di Azure o da un server PostgreSQL locale al 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 alla destinazione del server flessibile, la griglia contiene informazioni sui tentativi di migrazione.

5. Selezionare il pulsante Crea. Si passa quindi a una serie di schede basata su procedura guidata per creare una migrazione in questa destinazione server flessibile dal server di origine PostgreSQL.

Attrezzaggio

La prima scheda è quella di configurazione, in cui l'utente avvia le migrazioni fornendo dettagli quali il nome della migrazione e il tipo di origine.

• 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 di server di origine: a seconda dell'origine PostgreSQL, è possibile selezionare Macchina virtuale di Azure o locale.

• 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 sono presenti errori di convalida.

È sempre consigliabile scegliere l'opzione Convalida o Convalida ed esegui migrazione per eseguire le convalide preliminari prima di eseguire la migrazione. Per altre informazioni sulla convalida precedente alla migrazione, vedere questa documentazione.

Modalità di migrazione consente di scegliere la modalità per la migrazione. Offline è l'opzione predefinita.

Selezionare il pulsante Avanti: Connetti all'origine.

Server di runtime

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

Per altre informazioni sul server di runtime, vedere Server di runtime della migrazione.

Connetti all'origine

La scheda Connetti all'origine richiede di specificare i dettagli relativi all'origine selezionata nella scheda Configurazione, che è l'origine dei database.

• Nome server: specificare il nome host o l'indirizzo IP dell'istanza di PostgreSQL di origine
• Porta: numero di porta del server di origine
• Nome di accesso dell'amministratore server: nome utente del server PostgreSQL di origine
• Password: password del server PostgreSQL di origine
• Modalità SSL: i valori supportati sono preferita e obbligatoria. Quando SSL nel server PostgreSQL di origine è disattivato, usare SSLMODE=prefer. Se SSL nel server di origine è attivato, usare SSLMODE=require. I valori di SSL possono essere determinati nel file postgresql.conf.
• Test connessione: esegue il test di connettività tra la destinazione e l'origine. Se la connessione viene stabilita correttamente, gli utenti possono procedere con il passaggio successivo. In caso contrario, è necessario identificare i problemi di rete tra la destinazione e l'origine e verificare il nome utente e la password per l'origine. Il test di connessione richiede alcuni minuti per stabilire una connessione tra la destinazione e l'origine

Quando la connessione di test riesce, selezionare Avanti: Selezionare la destinazione di migrazione

Selezionare la destinazione di migrazione

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

• Nome utente amministratore: nome utente dell'amministratore del server PostgreSQL di destinazione
• Password: password del server PostgreSQL di destinazione
• FQDN/IP personalizzato (facoltativo): il campo FQDN/IP personalizzato è facoltativo e può essere usato quando la destinazione si trova dietro un server DNS personalizzato o dispone di spazi dei nomi DNS personalizzati, rendendolo accessibile solo tramite FQDN o indirizzi IP specifici. Ad esempio, può includere voci come flexibleserver.example.com, 198.1.0.2o un FQDN PostgreSQL, flexibleserver.postgres.database.azure.comad esempio , se il server DNS personalizzato contiene la zona postgres.database.azure.com DNS o inoltra le query per questa zona a 168.63.129.16, dove il nome di dominio completo viene risolto nella zona DNS pubblica o privata di Azure.
• Test connessione: esegue il test di connettività tra la destinazione e l'origine. Se la connessione viene stabilita correttamente, gli utenti possono procedere con il passaggio successivo. In caso contrario, è necessario identificare i problemi di rete tra la destinazione e l'origine e verificare il nome utente e la password per la destinazione. Il test di connessione richiede alcuni minuti per stabilire una connessione tra la destinazione e l'origine.

Quando la connessione di test riesce, selezionare Avanti: Selezionare i database per la migrazione

Selezionare i database per la migrazione

In questa scheda, un elenco di database utente si trova all'interno del server di origine selezionato nella scheda di configurazione. È possibile selezionare fino a otto database ed eseguirne la migrazione in un unico 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.

Dopo aver scelto i database, selezionare Avanti: Riepilogo

Riepilogo

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

Monitorare la 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 al pannello Migrazione del server flessibile, che include una nuova voce per la convalida o la migrazione creata di recente.

La griglia che mostra le migrazioni include queste colonne: Nome, Stato, Modalità di migrazione, Tipo di migrazione, Server di origine, Tipo del server di origine, Database, **Durata e Ora inizio. Le voci vengono visualizzate in ordine decrescente rispetto all'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. Nella griglia, selezionare il nome della migrazione 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 da 2 a 3 minuti per configurare l'infrastruttura di migrazione e le connessioni di rete.

Dettagli della migrazione

Nella scheda Configurazione è stata selezionata l'opzione di migrazione Convalida ed esegui migrazione. In questo scenario, 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, la migrazione viene avviata e il flusso di lavoro passa allo stato secondario MigratingData.

I risultati della convalida vengono visualizzati nella scheda Convalida e la migrazione viene monitorata nella scheda Migrazione.

I possibili stati della migrazione includono:

Stati della migrazione

Stato	Descrizione
InProgress	È in corso la configurazione dell'infrastruttura di migrazione oppure è in corso la migrazione effettiva dei dati.
Annullata	La migrazione viene annullata o eliminata.
Non riuscito	La migrazione non è riuscita.
Convalida non riuscita	La convalida non è riuscita.
Completato	La migrazione è riuscita ed è stata completata.
WaitingForUserAction	Applicabile solo per la migrazione online. In attesa dell'azione di cutover da parte dell'utente.

Stati secondari della migrazione

Sottostato	Descrizione
PerformingPreRequisiteSteps	La configurazione dell'infrastruttura è in corso per la migrazione dei dati.
Convalida in corso	La convalida è in esecuzione.
MigratingData	La migrazione dei dati è in corso.
CompletingMigration	La migrazione è nelle fasi finali del completamento.
Completato	La migrazione è stata completata.
Non riuscito	La migrazione non è riuscita.

Stati secondari della convalida

Sottostato	Descrizione
Non riuscito	Convalida non riuscita.
Completato	La convalida ha avuto esito positivo.
Avvertenza	La convalida è in stato di avviso.

Cutover

Se sono presenti sia Esegui migrazione che Convalida ed esegui migrazione, il completamento della migrazione online richiede un ulteriore passaggio: l'utente deve eseguire un'azione di cutover. 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, è importante assicurarsi che:

• Le scritture nell'origine sono arrestate: il valore Latency è 0 o vicino allo 0. Le informazioni Latency possono essere ottenute dalla schermata dei dettagli della migrazione, come illustrato di seguito:
• Il valore latency diminuisce fino a 0 o vicino allo 0
• Il valore latency indica quando è avvenuta l'ultima sincronizzazione della destinazione con l'origine. A questo punto è possibile arrestare la scrittura nell'origine e avviare un cutover. 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. Se si verifica una latenza di 15 minuti al punto di cutover, tutti i dati modificati in quell'arco di tempo vengono applicati alla destinazione. Il tempo dipende dal backlog delle modifiche apportate negli ultimi 15 minuti. Di conseguenza, è consigliabile che la latenza passi a zero o si avvicini allo 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.

Annullare la migrazione

È 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. Non elimina né esegue il rollback delle modifiche nel server di destinazione. Assicurarsi di eliminare i database nel server di destinazione che sono coinvolti in una migrazione annullata.

CLI

Questo articolo illustra l'uso dell'interfaccia della riga di comando di Azure per eseguire la migrazione del database PostgreSQL da una macchina virtuale di Azure o da un'istanza di PostgreSQL locale a un Database di Azure per PostgreSQL. L'interfaccia della riga di comando di Azure offre uno strumento potente e flessibile che consente di eseguire varie attività, tra cui la migrazione del database. Seguendo i passaggi descritti nel presente articolo, è possibile trasferire facilmente il database in Azure e sfruttarne le potenti funzionalità, nonché la scalabilità.

Per altre informazioni sull'interfaccia della riga di comando di Azure con il servizio di migrazione, vedere Come configurare l'interfaccia della riga di comando di Azure per il servizio di migrazione.

Dopo aver installato l'interfaccia della riga di comando, aprire il prompt dei comandi e accedere all'account Azure usando il comando seguente.

az login

Configurare l'attività di migrazione

Per iniziare la migrazione, creare un file JSON con i dettagli della migrazione. Il file JSON contiene le informazioni seguenti:

• Modificare i segnaposto seguenti << >> nelle righe del file JSON e archiviarli come <<filename>>.json nel computer locale, in cui viene richiamata l'interfaccia della riga di comando. In questa esercitazione, il file è stato salvato in C:\migration-CLI\migration_body.json

{
"properties": {
"SourceDBServerResourceId": "<<source hostname or IP address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<Source Password>>",
                "TargetServerPassword": "<<Target Password>>"
            },
			"targetServerUserName": "<<Target username>>"
        },
        "DBsToMigrate": "<<comma separated list of databases in a array like - ["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "OnPremises",
        "sslMode": "Prefer"
    }
}

Nota

Quando si configurano le proprietà JSON per la migrazione al server flessibile di Database di Azure per PostgreSQL, se l'ambiente di origine è una macchina virtuale di Azure, è possibile specificare il tipo di origine usando la proprietà "sourceType":"AzureVM". Ciò consente al servizio di migrazione di comprendere l'ambiente da cui viene eseguita la migrazione dei dati.

• Per verificare se vi sono migrazioni in esecuzione, eseguire il comando seguente. Il nome della migrazione è univoco tra le migrazioni all'interno della destinazione Database di Azure per PostgreSQL - Server flessibile.

  az postgres flexible-server migration list --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --filter All
  

• Nei passaggi precedenti non sono state effettuate migrazioni, quindi si inizia con la nuova migrazione eseguendo il comando seguente

  az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-mode online --migration-option ValidateAndMigrate --properties "C:\migration-cli\migration_body.json"
  

• Per avviare lo stato della migrazione nel passaggio precedente, eseguire il comando seguente. È possibile controllare lo stato della migrazione specificando il nome della migrazione

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

• Lo stato del processo di migrazione viene visualizzato nell'interfaccia della riga di comando di Azure.

• È anche possibile visualizzare lo stato di Database di Azure per PostgreSQL - Server flessibile nel portale di Azure.

• È possibile annullare eventuali tentativi di migrazione in corso mediante 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 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

Cutover

• 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 mediante il comando seguente. Il cutover può anche essere attivato dal portale selezionando il nome della migrazione nella griglia di migrazione.

• È anche possibile avviare il cutover dal portale di Azure.

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

Controllare la migrazione al termine dell'operazione

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

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

• Verificare i dati nel server flessibile e assicurarsi che si tratti di una copia esatta dell'istanza di origine.
• Dopo la verifica, abilitare l'opzione di disponibilità elevata nel server flessibile in base alle esigenze.
• Modificare lo SKU del server flessibile in modo che corrisponda alle esigenze dell'applicazione. Questa modifica richiede un riavvio del server di database.
• Se si modificano i parametri del server dai relativi valori predefiniti nell'istanza di origine, copiare questi valori nel server flessibile. Copiare le altre impostazioni del server dall'istanza di origine al server flessibile, ad esempio tag, avvisi e regole del firewall (se applicabile).
• 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