(Anteprima) Eseguire la migrazione offline da Google AlloyDB per PostgreSQL a Database di Azure per PostgreSQL con il servizio di migrazione

Questo articolo illustra come eseguire la migrazione di un'istanza di Google AlloyDB per PostgreSQL al server flessibile di Database di Azure per PostgreSQL in modalità offline.

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. Semplifica il percorso di migrazione al server flessibile di Database di Azure per PostgreSQL.

• Prerequisiti
• Eseguire la migrazione
• Monitorare la migrazione
• Controllare la migrazione al termine dell'operazione

Prerequisiti

Per completare la migrazione, sono necessari i prerequisiti seguenti:

Prima di avviare la migrazione con il servizio di migrazione di Database di Azure per PostgreSQL, è importante soddisfare i prerequisiti seguenti, appositamente progettati per scenari di migrazione offline.

• Verificare la versione di origine
• Configurare la configurazione di destinazione
• Configurare la configurazione di rete
• Abilitare le estensioni
• Controllare i parametri del server
• Controllare gli utenti e i ruoli
• Disabilitare la disponibilità elevata (affidabilità) e le repliche in lettura nella destinazione

Verificare la versione di origine

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

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

Configurare l'impostazione di destinazione

Prima di iniziare la migrazione, è necessario configurare un database di Azure per PostgreSQL in Azure.

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

Quando si esegue la migrazione tra le versioni di PostgreSQL (principale o secondaria), assicurarsi la compatibilità tra il database e l'applicazione esaminando le note sulla versione per individuare potenziali modifiche di rilievo.

Configurare la configurazione di rete

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

Per informazioni sulla configurazione di rete, vedere Guida alla rete per il servizio di migrazione.

Considerazioni aggiuntive sulla rete

Per facilitare la connettività tra le istanze di PostgreSQL di origine e di destinazione, è essenziale verificare e potenzialmente modificare il file pg_hba.conf del server di origine. 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 del server flessibile di Database di Azure per PostgreSQL abilitare le estensioni supportate identificate nell'istanza di PostgreSQL di origine.

Per altre informazioni, vedere Estensioni e moduli.

Controllare i parametri del server

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

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

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

Controllare gli utenti e i ruoli

Quando si esegue la migrazione a Database di Azure per PostgreSQL, è essenziale affrontare separatamente la migrazione degli utenti e dei ruoli, perché richiedono un intervento manuale:

• Migrazione manuale di utenti e ruoli: gli utenti e i ruoli devono essere migrati manualmente nel Database di Azure per PostgreSQL. Per facilitare questo processo, è possibile usare l'utilità pg_dumpall con il --globals-only flag per esportare oggetti globali, ad esempio ruoli e utenti. Eseguire il comando seguente, sostituendo <<username>> con il nome utente effettivo e <<filename>> con il nome file di output desiderato:

  pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
  

• Restrizione per i ruoli con privilegi avanzati: Database di Azure per PostgreSQL non supporta i ruoli con privilegi avanzati. Pertanto, gli utenti con privilegi con privilegi avanzati devono avere tali privilegi rimossi prima della migrazione. Assicurarsi di modificare le autorizzazioni e i ruoli di conseguenza.

Seguendo questa procedura, è possibile assicurarsi che gli account utente e i ruoli vengano migrati correttamente nel Database di Azure per PostgreSQL senza riscontrare problemi relativi alle restrizioni per l'utente con privilegi avanzati.

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 fluido, senza le variabili aggiuntive introdotte dalla funzionalità di alta disponibilità e dalle repliche di lettura. Una volta completata la migrazione e quando il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente del database in Azure.

Eseguire la migrazione

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

Portal

Questo articolo illustra come usare il portale di Azure per eseguire la migrazione del database PostgreSQL da un server Google AlloyDB per PostgreSQL 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 sfruttare le potenti funzionalità e la scalabilità.

Configurare l'attività di migrazione

Il servizio di migrazione include un'esperienza semplice basata su procedura guidata nel portale di Azure.

Usare il portale di Azure:

1. Seleziona il server flessibile di Azure Database per PostgreSQL.

2. Nel menu della risorsa selezionare Migrazione.

   

3. Selezionare Crea per passare a una serie di schede basate su procedura guidata per eseguire una migrazione a un server flessibile da Google AlloyDB per PostgreSQL.

   Annotazioni

   La prima volta che si usa il servizio di migrazione, viene visualizzata una griglia vuota con un prompt per avviare la prima migrazione.

   Se sono già state create migrazioni alla destinazione del server flessibile, la griglia contiene ora informazioni sui tentativi di migrazione.

   

Configurazione

È necessario specificare più dettagli correlati alla migrazione, ad esempio il nome della migrazione, il tipo di server di origine, l'opzione e la modalità.

• Il nome della migrazione è l'identificatore univoco per ogni migrazione a questa destinazione 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. Nessuna delle due migrazioni verso la stessa destinazione server flessibile può avere lo stesso nome.

• Tipo di server di origine: a seconda dell'origine PostgreSQL, è possibile selezionare Google AlloyDB per PostgreSQL.

• Opzione di migrazione : consente di eseguire le 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.
  • Convalidare ed eseguire la migrazione : esegue la convalida prima di attivare una migrazione. Se non sono presenti errori di convalida, viene avviata la migrazione.

La scelta dell'opzione Convalida o Convalida e migrazione è sempre una buona pratica per eseguire le convalide preliminari prima di effettuare la migrazione.

Per maggiori informazioni sulla convalida della premigration, vedere premigration.

• La modalità di migrazione consente di scegliere la modalità per la migrazione. Offline è l'opzione predefinita. In questo caso, si userà il valore predefinito.

Selezionare Avanti: server di runtime.

Server di runtime

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

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

Server di origine

La scheda Server di origine richiede di specificare i dettagli relativi all'origine selezionata nella scheda Installazione , che rappresenta l'origine dei database.

• Nome server : specificare il nome dell'host o l'indirizzo IP del server PostgreSQL di origine.
• Porta : numero di porta del server di origine.
• Account di accesso amministratore : nome dell'utente amministratore del server PostgreSQL di origine.
• Password: password dell'account di accesso amministratore fornito per connettersi al server PostgreSQL di origine.
• Modalità SSL : i valori supportati sono preferred e required. Quando SSL nel server PostgreSQL di origine è OFF, usare prefer. Se l'SSL nel server di origine è ON, usare require. I valori SSL possono essere determinati nel file postgresql.conf del server di origine.
• Test della connessione : esegue il test di connettività tra la destinazione e l'origine. Una volta completata la connessione, è possibile passare alla scheda successiva. Questo test mira a identificare eventuali problemi di connettività che potrebbero esistere tra i server di destinazione e di origine, inclusa la verifica dell'autenticazione usando le credenziali fornite. La definizione di una connessione di test richiede alcuni secondi.

Dopo aver completato la connessione di test, selezionare Avanti: Server di destinazione.

Server di destinazione

Nella scheda Server di 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.

• Account di accesso amministratore : nome dell'utente amministratore del server PostgreSQL di destinazione.
• Password: password dell'account di accesso amministratore fornito per connettersi al server PostgreSQL di destinazione.
• FQDN personalizzato o indirizzo IP: il campo FQDN o indirizzo 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, questo potrebbe includere voci come production-flexible-server.example.com, 198.1.0.2, o un FQDN PostgreSQL, ad esempio production-flexible-server.postgres.database.azure.com, se il server DNS personalizzato contiene la zona DNS postgres.database.azure.com o inoltra le query per questa zona a 168.63.129.16, dove il FQDN viene risolto nella zona DNS pubblica o privata di Azure.
• Test della connessione : esegue il test di connettività tra l'origine e la destinazione. Una volta completata la connessione, è possibile passare alla scheda successiva. Questo test mira a identificare eventuali problemi di connettività che potrebbero esistere tra i server di origine e di destinazione, inclusa la verifica dell'autenticazione usando le credenziali fornite. La definizione di una connessione di test richiede alcuni secondi.

Dopo aver completato la connessione di test, selezionare Avanti: Database da convalidare o migrare

Database di cui convalidare o eseguire la migrazione

Nella scheda Database da convalidare o migrare è possibile scegliere un elenco di database utente di cui eseguire la migrazione dal server PostgreSQL di origine.

Dopo aver selezionato i database, selezionare Avanti: Riepilogo.

Riassunto

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

Annullare la convalida o la migrazione

È possibile annullare eventuali convalide o migrazioni in corso. Il flusso di lavoro deve essere nello stato In corso in modo che possa essere annullato. Non è possibile annullare una convalida o una migrazione nello stato Operazione riuscita o Non riuscita .

• L'annullamento di una convalida arresta un'ulteriore 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 . L'azione di annullamento restituisce tutte le modifiche apportate dal servizio di migrazione nel server di destinazione.

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 in questo articolo, è possibile trasferire facilmente il database in Azure e sfruttare le potenti funzionalità e 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 la CLI, aprite il prompt dei comandi e accedete al vostro account Azure utilizzando il comando riportato di seguito.

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-server-hostname-or-IP-address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<source-server-administrator-password>>",
                "TargetServerPassword": "<<target-server-administrator-password>>"
            },
            "targetServerUserName": "<<target-server-administrator-login>>"
        },
        "DBsToMigrate": "<<comma-separated-list-of-databases-in-array-like-["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "AWS_AURORA",
        "sslMode": "Prefer"
    }
}

• Eseguire il comando seguente per verificare se sono in esecuzione migrazioni. 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 <subscription_id> --resource-group <resource_group> --name <target_server> --filter all
  

• Nei passaggi precedenti non vengono eseguite migrazioni, quindi si inizia con la nuova migrazione eseguendo il comando seguente.

  az postgres flexible-server migration create --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration> --migration-mode offline --migration-option ValidateAndMigrate --properties "c:/migration-cli/migration_body.json"
  

• Eseguire il comando seguente per visualizzare lo stato della migrazione avviata nel passaggio precedente. È possibile controllare lo stato della migrazione specificando il nome della migrazione.

  az postgres flexible-server migration show --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

• Lo stato di avanzamento e lo stato della migrazione vengono visualizzati in Azure CLI.

• È anche possibile visualizzare i progressi e lo stato nel portale di Azure.

• È possibile annullare qualsiasi tentativo di migrazione in corso usando il cancel comando . Questo comando arresta il tentativo di migrazione specifico ed esegue il rollback di tutte le modifiche che potrebbero essere state apportate nel server di destinazione. Di seguito è riportato il comando dell'interfaccia della riga di comando per annullare la migrazione con stato "In corso".

  az postgres flexible-server migration update cancel --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

Monitorare la migrazione

Dopo aver selezionato il pulsante Avvia convalida e migrazione , 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. La voce mostra Stato come In corso. Il flusso di lavoro richiede da 2 a 3 minuti per configurare l'infrastruttura di migrazione e controllare le connessioni di rete.

La griglia che visualizza le migrazioni include le colonne seguenti: Nome, Stato, Modalità migrazione, Tipo di migrazione, Server di origine, Tipo di server di origine, Database, Durata e Ora di inizio. Le voci vengono visualizzate in base all'ora di inizio in ordine decrescente, con la voce più recente nella parte superiore. È possibile usare il pulsante Aggiorna sulla barra degli strumenti per aggiornare lo stato dell'esecuzione della convalida o della migrazione.

Dettagli della migrazione

Selezionare il nome della migrazione nella griglia per visualizzare i dettagli associati.

Tenere presente che nei passaggi precedenti, quando è stata creata questa migrazione, è stata configurata l'opzione di migrazione come Convalida ed esegui la migrazione. In questo scenario, le convalide vengono eseguite prima dell'avvio della migrazione. Al termine della Esecuzione dei passaggi prerequisiti, il flusso di lavoro passa alla sottofase di convalida in corso.

• Se la convalida presenta errori, la migrazione passa a uno stato Non riuscito .

• Se la convalida viene completata senza errori, viene avviata la migrazione e il flusso di lavoro passa allo stato secondario di Migrazione dei dati.

I dettagli di convalida sono disponibili a livello di istanza e database.

• Dettagli di convalida per l'istanza
  • Contiene la convalida correlata al controllo della connettività, alla versione di origine, ovvero alla versione >postgreSQL = 9.5 e al controllo dei parametri del server, se le estensioni sono abilitate nei parametri del server del server flessibile di Database di Azure per PostgreSQL.
• Dettagli di convalida e migrazione per i database
  • Contiene la convalida dei singoli database correlati al supporto di estensioni e collazioni nel database flessibile di Azure per PostgreSQL.

È possibile visualizzare lo stato di convalida e lo stato della migrazione nella pagina dei dettagli della migrazione.

Alcuni possibili stati di migrazione:

Stati della migrazione

Stato	Description
In elaborazione	È 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.
Riuscito	La migrazione è riuscita ed è stata completata.

Sottostatusi di migrazione

Stato secondario	Description
Esecuzione dei passaggi preliminari	La configurazione dell'infrastruttura è in corso per la migrazione dei dati.
Convalida in corso	La convalida è in corso.
Migrazione dei dati	La migrazione dei dati è in corso.
Completamento della migrazione	La migrazione è nelle fasi finali del completamento.
completato	La migrazione è stata completata.
Non riuscito	La migrazione non è riuscita.

Sottostatusi di convalida

Stato secondario	Description
Non riuscito	Convalida non riuscita.
Riuscito	La convalida ha avuto esito positivo.
Avvertenza	La convalida è nello stato di avviso.

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 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 stringhe di connessione a un server flessibile.

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

Contenuti correlati

• Eseguire la migrazione online da Google AlloyDB per PostgreSQL
• Servizio di migrazione
• Problemi noti e limitazioni