Eseguire la migrazione online da un server Amazon Aurora PostgreSQL a Database di Azure per PostgreSQL, con il servizio di migrazione

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 in modalità online.

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.

• Prerequisiti
• Eseguire la migrazione
• Monitorare la migrazione
• Avvia il cutover
• Controllare la migrazione al termine

Prerequisiti

Per iniziare la migrazione, sono necessari i prerequisiti seguenti:

Prima di avviare una migrazione usando il servizio di migrazione in Database di Azure per PostgreSQL, è importante completare i prerequisiti seguenti. Questi prerequisiti sono progettati specificamente per gli scenari di migrazione online.

• Verificare la versione di origine
• Installare test_decoding per l'installazione dell'origine
• Configurare l'installazione di destinazione
• Abilitare Change Data Capture come origine
• Configurare la configurazione 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 postgreSQL di origine è precedente alla 9.5, aggiornare la versione alla versione 9.5 o successiva prima di avviare la migrazione.

Installare test_decoding per l'installazione dell'origine

• Il plug-in test_decoding riceve la registrazione write-ahead (WAL) tramite il meccanismo di decodifica logica. Il plug-in decodifica WAL in rappresentazioni di testo delle operazioni eseguite.
• In Amazon RDS per PostgreSQL il plug-in test_decoding è preinstallato e pronto per la replica logica. È possibile configurare facilmente slot di replica logica e trasmettere modifiche WAL, ad esempio per Change Data Capture (CDC) o per la replica in sistemi esterni.

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

Configurare l'installazione di destinazione

Prima di iniziare la migrazione, è necessario creare un'istanza di Database di Azure per PostgreSQL in Azure. Lo SKU provisionato per il server flessibile di Database di Azure per PostgreSQL deve corrispondere alla sorgente.

Per altre informazioni, vedere Creare un server flessibile di 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.

• Per consentire all'utente di migrazione di accedere alle autorizzazioni di replica, eseguire il comando seguente:

  GRANT rds_replication TO <username>;
  

• Nell'istanza di PostgreSQL di origine modificare i parametri seguenti nel gruppo di parametri cluster di database creando un nuovo gruppo di parametri:

  • Impostare rds.logical_replication su 1.
  • Impostare max_replication_slots su un valore maggiore di 1. Il valore deve essere maggiore del numero di database selezionati per la migrazione.
  • Impostare max_wal_senders su un valore maggiore di 1. Deve essere almeno lo stesso valore del valore per max_replication_slots, più il numero di mittenti già usati nell'istanza.
  • Il parametro wal_sender_timeout termina le connessioni di replica inattive più lunghe del numero specificato di millisecondi. Il valore predefinito per un'istanza di Amazon Aurora PostgreSQL è 30000 milliseconds (30 seconds). L'impostazione del valore su 0 (zero) disabilita il meccanismo di timeout ed è un'impostazione valida per la migrazione.

• Nell’obiettivo Server flessibile, per evitare che la migrazione online non disponga di spazio sufficiente per memorizzare i log, verificare di disporre di un archivio dello spazio tabella sufficiente usando un disco gestito con provisioning. Disabilitare il parametro azure.enable_temp_tablespaces_on_local_ssd del server per la durata della migrazione. Ripristinare il parametro allo stato originale dopo la migrazione.

Configurare la configurazione 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.

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

Abilitare le estensioni

Per garantire una corretta migrazione mediante il servizio migrazione in Database di Azure per PostgreSQL, potrebbe essere necessario verificare le estensioni per l'istanza di PostgreSQL di origine. Le estensioni offrono caratteristiche 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 dei server 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 all'istanza di Database di Azure per PostgreSQL. Nella portale di Azure passare a Parametri del server e aggiornare manualmente i valori.

• Salvare le modifiche del parametro e riavviare l'istanza di 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 associati devono essere migrati manualmente all'istanza di Database di Azure per PostgreSQL. Per facilitare questo processo, è possibile usare l'utilità pg_dumpall con il flag --globals-only per esportare oggetti globali, ad esempio ruoli e account utente.

  Eseguire il comando seguente. Sostituire <username> con il nome utente effettivo e sostituire <filename> con il nome che si vuole usare per il file di output.

  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. Le autorizzazioni con privilegi avanzati devono essere rimosse prima della migrazione. Assicurarsi di modificare le autorizzazioni e i ruoli di conseguenza.

Completare 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

È fondamentale disabilitare la disponibilità elevata (affidabilità) e le repliche di lettura nell'ambiente di destinazione prima di avviare la migrazione. Queste funzionalità devono essere abilitate solo dopo il completamento della migrazione.

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 Amazon Aurora 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 basata su procedura guidata per eseguire una migrazione a un server flessibile da una macchina virtuale locale o di Azure.

   Note

   La prima volta che si usa il servizio di migrazione, viene visualizzata una griglia vuota con una richiesta 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 un trattino (-). Il nome non può iniziare con un trattino e deve essere univoco per un 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 server locale.

• Opzione di migrazione : consente di eseguire le 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.
  • 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, lo cambieremo in Online.

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, può includere voci come production-flexible-server.example.com, 198.1.0.2 o un FQDN PostgreSQL come 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 nome di dominio completo 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.

Summary

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. Per annullare il flusso di lavoro, è necessario che il flusso di lavoro sia in corso . 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 elimina né esegue il rollback delle modifiche nel server di destinazione. Assicurarsi di eliminare i database nel server di destinazione 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 un'interfaccia della riga di comando 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": "OnPremises",
        "sslMode": "Prefer"
    }
}

Note

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 "sourceType":"AzureVM" proprietà . Questo 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 <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 Failed.

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

Stato della migrazione

Stato	Descrizione
In elaborazione	È in corso la configurazione dell'infrastruttura di migrazione oppure è in corso la migrazione effettiva dei dati.
Canceled	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.
In attesa dell'azione dell'utente	In attesa dell'azione di cutover da parte dell'utente.

Dettagli della migrazione

Stato secondario	Descrizione
Esecuzione dei passaggi preliminari	La configurazione dell'infrastruttura è in corso per la migrazione dei dati.
Convalida in corso	La convalida è in esecuzione.
Eliminazione del database nella destinazione	Eliminazione di un database già esistente nel server di destinazione.
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	Descrizione
Non riuscito	Convalida non riuscita.
Completato	La convalida ha avuto esito positivo.
Warning	La convalida è nello stato di avviso.

Avvia il cutover

È possibile avviare il cutover usando il portale di Azure o l'interfaccia della riga di comando di Azure.

Portal

Per l'opzione Convalida e migrazione , il completamento della migrazione online richiede all'utente di completare un passaggio aggiuntivo, che consiste nell'attivare l'azione di cutover. Al termine della copia o della clonazione dei dati di base, la migrazione passa allo stato Waiting for user action e allo stato secondario Waiting for cutover trigger. In questo stato, l'utente può avviare il cutover dal portale selezionando la procedura di migrazione.

Prima di avviare il cambio, è importante assicurarsi che:

• Le scritture nell'origine sono arrestate: il valore latency è 0 o vicino allo 0. Le latency informazioni possono essere ottenute dalla schermata dei dettagli della migrazione, come illustrato di seguito:
• latency il valore diminuisce a 0 o vicino a 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 dal server di origine al server di destinazione e completa la migrazione. Se si attiva un cutover, anche con un valore diverso da zero latency, la replica si arresta fino a quel punto nel tempo. Tutti i dati dell'origine fino al punto di cutover vengono quindi applicati alla destinazione. Se si verifica una latenza di 15 minuti al punto di cutover, tutte le modifiche apportate ai dati negli ultimi 15 minuti vengono applicate alla destinazione.

Il tempo dipende dal backlog delle modifiche apportate negli ultimi 15 minuti. È quindi consigliabile che la latenza vada a zero o quasi zero prima di attivare il cutover.

• Quando lo stato secondario Migrating data o il cutover (nella migrazione online) termina correttamente, la migrazione passa allo stato Succeeded. Se c'è un problema nello stato secondario Migrating data, la migrazione passa a uno stato Failed.

CLI

Per l'opzione Convalida e migrazione , il completamento della migrazione online richiede all'utente di completare un passaggio aggiuntivo, che consiste nell'attivare l'azione di cutover. Al termine della copia o della clonazione dei dati di base, la migrazione passa allo stato Waiting for user action e allo stato secondario Waiting for cutover trigger. In questo stato, l'utente può avviare il cutover tramite la CLI usando il comando seguente. Il cutover può anche essere attivato dal portale selezionando il nome della migrazione nella griglia di migrazione.

Prima di avviare il cutover, è importante assicurarsi che:

• Le operazioni di scrittura sull'origine vengono fermate: latency il valore è 0 o prossimo a 0. Le latency informazioni possono essere ottenute dalla schermata dei dettagli della migrazione, come illustrato di seguito:
• latency il valore diminuisce a 0 o vicino a 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 dal server di origine al server di destinazione e completa la migrazione. Se si attiva un cutover, anche con un valore latency diverso da zero, la replica si arresta a quel punto nel tempo. 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, tutte le modifiche apportate ai dati negli ultimi 15 minuti vengono applicate alla destinazione.

Il tempo dipende dal backlog delle modifiche apportate negli ultimi 15 minuti. È quindi consigliabile che la latenza vada a zero o quasi zero prima di attivare il cutover.

• Quando lo stato secondario Migrating data o il cutover (nella migrazione online) termina correttamente, la migrazione passa allo stato Succeeded. Se si verifica un problema nello Migrating data stato secondario, la migrazione passa a un altro Failed stato.

Per attivare il cutover, usare il comando seguente:

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

Controllare la migrazione al termine

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

Contenuti correlati

• Servizio di migrazione
• Procedure consigliate
• Limitazioni e problemi noti
• Configurazione della rete
• Convalide premigrazione