Eseguire la migrazione online da un server Amazon RDS per 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
• Avviare il cutover
• Controllare la migrazione al termine

Prerequisiti

Per iniziare 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 gli scenari di migrazione online.

• Verificare la versione di origine
• Installare test_decoding - Configurazione della sorgente
• Configurare la configurazione di destinazione
• Abilitare CDC come origine
• Configurare la configurazione di rete
• Abilitare le estensioni
• Controllare i parametri del server
• Controllare utenti e 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 è inferiore alla 9.5, aggiornarla alla versione 9.5 o successiva prima di avviare la migrazione.

Installare test_decoding - Configurazione dell'origine

• test_decoding riceve WAL tramite il meccanismo di decodifica logica e lo decodifica in rappresentazioni testuali delle operazioni eseguite.
• In Amazon RDS per PostgreSQL il plug-in test_decoding è preinstallato e pronto per la replica logica. In questo modo è possibile configurare facilmente slot di replica logica e trasmettere modifiche WAL, semplificando i casi d'uso, ad esempio Change Data Capture (CDC) o la replica in sistemi esterni.
• Per altre informazioni sul plug-in di decodifica di test, vedere la documentazione di PostgreSQL

Configurare l'impostazione di destinazione

• Prima della migrazione, è necessario creare il server flessibile di Database di Azure per PostgreSQL.
• 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 server flessibile di Database di Azure per PostgreSQL

Abilitare CDC come sorgente

• test_decoding Il plug-in di decodifica logica acquisisce i record modificati dall'origine.
• Per consentire all'utente di migrazione di accedere ai privilegi di replica, eseguire il comando seguente:

GRANT rds_replication TO <<username>>;

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

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

• Nel server flessibile di destinazione, per evitare che la migrazione online non disponga di spazio sufficiente per memorizzare i log, assicurarsi di disporre di uno spazio tabella sufficiente usando un disco gestito con provisioning. A tale scopo, disabilitare il parametro azure.enable_temp_tablespaces_on_local_ssd del server per la durata della migrazione e ripristinarlo nello stato originale dopo la migrazione.

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.

Abilitare le estensioni

Per garantire una corretta migrazione 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 sezione "Parametri 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 utenti e ruoli

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

• Migrazione manuale di utenti e ruoli: gli utenti e i ruoli associati 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 account utente. 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 senza problemi senza le variabili aggiunte introdotte dalla disponibilità elevata e dalle repliche in lettura. Una volta completata la migrazione e il database è stabile, è possibile abilitare queste funzionalità per migliorare la disponibilità e la scalabilità dell'ambiente di database in Azure.

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

   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 un trattino (-). Il nome non può iniziare con un trattino e deve essere univoco per un 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 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.

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

Annotazioni

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.

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

Stato della migrazione

Stato	Description
In elaborazione	La configurazione dell'infrastruttura di migrazione è in corso 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.
In attesa dell'azione dell'utente	In attesa dell'azione di cutover da parte dell'utente.

Dettagli della 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.
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	Description
Non riuscito	Convalida non riuscita.
Riuscito	La convalida ha avuto esito positivo.
Avvertenza	La convalida è nello stato di avviso.

Avviare 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 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 latency valore indica quando l'ultima destinazione è sincronizzata 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.

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

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 latency valore indica quando l'ultima destinazione è sincronizzata 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.

• La migrazione passa allo stato Succeeded quando lo stato secondario Migrating data o il cutover (nella migrazione online) termina correttamente. 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 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

• Servizio di migrazione
• Procedure consigliate
• Problemi noti e limitazioni
• Configurazione della rete
• Convalide premigrazione