Condividi tramite


Esercitazione: Eseguire la migrazione offline da Amazon RDS per PostgreSQL a Database di Azure per PostgreSQL con il servizio di migrazione

Questo articolo illustra come eseguire la migrazione offline del database PostgreSQL da Amazon RDS per PostgreSQL a Database di Azure per PostgreSQL.

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 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 migrazione di Database di Azure per PostgreSQL, è importante soddisfare i prerequisiti seguenti, specifici per gli scenari di migrazione online.

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.

Configurare il setup della 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.

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.

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

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

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

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

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: deve essere eseguita la migrazione manuale degli utenti e dei ruoli associati al Database di Azure per PostgreSQL. Per facilitare questo processo, è possibile usare l'utilità pg_dumpall con il flag --globals-only per esportare gli oggetti globali quali ruoli e account utente. Eseguire il comando seguente, sostituendo <<username>> con il nome utente effettivo e <<filename>> con il nome del file di output desiderato:

    pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
    
  • Restrizione per i ruoli utente con privilegi avanzati: Database di Azure per PostgreSQL non supporta i ruoli utente con privilegi avanzati. Pertanto, occorre rimuovere i privilegi avanzati prima della migrazione. Assicurarsi di modificare le autorizzazioni e i ruoli di conseguenza.

Questa procedura consente di assicurarsi che venga eseguita la migrazione degli account utente e dei ruoli in modo appropriato a Database di Azure per PostgreSQL senza riscontrare problemi relativi alle restrizioni per gli utenti 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 senza problemi senza le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e quando il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente del database in Azure.

Eseguire la migrazione

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

Il portale di Azure offre un'esperienza di migrazione semplice e intuitiva, basata su procedure guidate. Seguendo i passaggi descritti in questa esercitazione, è possibile trasferire facilmente il database nel server flessibile di Database di Azure per PostgreSQL e sfruttarne le potenti funzionalità e la scalabilità.

Per eseguire la migrazione con il portale di Azure, configurare per prima cosa l'attività di migrazione, connettersi all'origine e alla destinazione e quindi eseguire la migrazione.

Configurare l'attività di migrazione

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

  1. Aprire il Web browser e passare al portale. Immettere le credenziali di accesso. La visualizzazione predefinita è il dashboard del servizio.

  2. Passare a Database di Azure per PostgreSQL - Server flessibile.

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

    Screenshot della selezione della migrazione nel portale di Azure.

  4. Selezionare il pulsante Crea per eseguire la migrazione da Amazon RDS per PostgreSQL a un server flessibile.

    Nota

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

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

  5. Selezionare il pulsante Crea per passare a una serie di schede basate su procedura guidata per eseguire una migrazione.

    Screenshot della pagina di creazione della migrazione.

Attrezzaggio

L'utente deve fornire più dettagli relativi alla migrazione, ad esempio il nome della migrazione, il tipo di server di origine, l'opzione e la modalità.

  • 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 Amazon RDS per PostgreSQL.

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

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

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

Per altre informazioni sulla convalida precedente alla migrazione, vedere Pre-migrazione.

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

Selezionare il pulsante Avanti: Connetti all'origine.

Screenshot della pagina delle attività iniziali per la configurazione della migrazione.

Selezionare il server di runtime

Il server di runtime della migrazione è una funzionalità specializzata all'interno del servizio di migrazione, progettata per fungere da server intermedio durante la migrazione. Si tratta di un'istanza separata del server flessibile di Database di Azure per PostgreSQL, 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 della migrazione.

Screenshot della pagina del server di runtime della migrazione.

Connetti all'origine

La scheda Connetti all'origine richiede di fornire i dettagli relativi all'origine selezionata nella scheda Configurazione, che rappresenta 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. Una volta completata la connessione, gli utenti possono procedere al passaggio successivo; devono identificare i problemi di rete tra la destinazione e l'origine e verificare il nome utente e la password per l'origine. Per stabilire una connessione di test sono necessari alcuni minuti.

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

Screenshot della pagina di connessione all'origine.

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

Screenshot della pagina di selezione della destinazione di migrazione.

Selezionare il database per la migrazione

Nella scheda Selezionare database per la migrazione è possibile scegliere un elenco di database utente di cui eseguire la migrazione dal server PostgreSQL di origine.
Dopo aver scelto i database, selezionare Avanti: Riepilogo

Screenshot della pagina di migrazione fetchDB.

Riepilogo

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

Screenshot della pagina di migrazione del riepilogo.

Monitorare la migrazione

Dopo aver selezionato il pulsante Avvia convalida e migrazione, entro pochi secondi viene visualizzata una notifica per indicare che la convalida o la creazione della migrazione è stata eseguita correttamente. Si viene reindirizzati all'istanza della pagina Migrazione del server flessibile. La voce si trova nello stato InProgress e nello stato secondario PerformingPreRequisiteSteps. Il flusso di lavoro richiede 2-3 minuti per configurare l'infrastruttura di migrazione e controllare le connessioni di rete.

Screenshot della pagina di monitoraggio della migrazione.

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 Aggiorna per aggiornare lo stato dell'esecuzione della convalida o della migrazione.

Dettagli della migrazione

Nella griglia, selezionare il nome della migrazione per visualizzare i dettagli associati.

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 Convalida in corso.

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

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

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

  • Convalida a livello di istanza

    • Contiene la convalida correlata al controllo della connettività, alla versione di origine, ovvero alla versione PostgreSQL>= 9.5, al controllo dei parametri del server, se le estensioni sono abilitate nei parametri del server del Database di Azure per PostgreSQL, server flessibile.
  • Convalida a livello di database

    • Contiene la convalida dei singoli database correlati al supporto delle estensioni e delle regole di confronto in Database di Azure per PostgreSQL, un server flessibile.

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

Screenshot dei dettagli che illustrano la convalida e la 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 è nello stato di avviso.

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 migrazione arresta altre attività di migrazione nel server di destinazione e la migrazione passa allo stato di Canceled. L'azione di annullamento esegue il rollback di tutte le modifiche apportate dal servizio di migrazione nel server di destinazione.

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.