Esercitazione: eseguire la migrazione online da Google Cloud SQL per PostgreSQL a Database di Azure per PostgreSQL con la versione di anteprima del servizio di migrazione

Questo articolo illustra come eseguire la migrazione online del database PostgreSQL da Google Cloud SQL per PostgreSQL al 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
• Cutover
• 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 Database di Azure per PostgreSQL, è importante soddisfare i prerequisiti seguenti, progettati appositamente per gli scenari di migrazione online.

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

Verificare la versione di origine

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

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

Nota

Il servizio di migrazione in Database di Azure per PostgreSQL supporta le connessioni usando l'indirizzo IP per l'origine di Google Cloud SQL per PostgreSQL. Il formato myproject:myregion:myinstance non è supportato.

Installare test_decoding - setup dell'origine

• test_decoding riceve il log write-ahead (WAL) tramite il meccanismo di decodifica logica e lo decodifica in rappresentazioni testuali delle operazioni eseguite.
• In Google Cloud SQL per PostgreSQL il plug-in test_decoding è preinstallato e pronto per la replica logica. Questo consente di configurare facilmente slot di replica logica e trasmettere modifiche del log write-ahead, semplificando i casi d'uso quali CDC (Change Data Capture) o la replica in sistemi esterni.
• Per altre informazioni sul plug-in test-decoding, vedere la documentazione di PostgreSQL

Configurare il setup della destinazione

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

Abilitare Change Data Capture come origine

• Il plug-in di decodifica logica test_decoding acquisisce i record modificati dall'origine.
• Per assicurarsi che l'utente di migrazione disponga dei privilegi di replica necessari, eseguire il comando SQL seguente:

Alter user <<username>> with REPLICATION;

• Passare all'istanza di Google Cloud SQL PostgreSQL in Google Cloud Console, selezionare il nome dell'istanza per aprire la relativa pagina dei dettagli, selezionare il pulsante Modifica e nella sezione Flag modificare i flag seguenti:

  • Impostare il flag cloudsql.logical_decoding = on
  • Impostare il flag max_replication_slots su un valore maggiore di uno. Il valore deve essere maggiore del numero di database selezionati per la migrazione.
  • Impostare il flag max_wal_senders su un valore maggiore di uno. Deve essere almeno uguale a max_replication_slots, più il numero di mittenti già usati nell'istanza.
  • Il flag wal_sender_timeout termina le connessioni di replica inattive più lunghe del numero specificato di millisecondi. 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 uno spazio tabella sufficiente usando un disco gestito con provisioning. Per raggiungere questo obiettivo, disabilitare il parametro server azure.enable_temp_tablespaces_on_local_ssd per la durata della migrazione e ripristinarlo allo stato originale dopo la migrazione.

Configurare il setup di rete

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

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

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.

Portale

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. Ecco come iniziare:

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

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

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

   

4. Selezionare il pulsante Crea per eseguire la migrazione da Google Cloud SQL al Database di Azure per PostgreSQL - Server flessibile. Se si usa il servizio di migrazione per la prima volta, viene visualizzata una griglia vuota con un prompt per iniziare la prima migrazione.

   

   Se sono già state create migrazioni alla destinazione Database di Azure per PostgreSQL, la griglia contiene informazioni sulle migrazioni tentate.

5. Selezionare il pulsante Crea. Verrà visualizzata una serie di schede basate su procedura guidata per creare una migrazione in questa destinazione Database di Azure per PostgreSQL dall'istanza di origine PostgreSQL.

Attrezzaggio

La prima scheda è Configurazione, in cui l'utente deve fornire i dettagli sulla migrazione, ad esempio il nome delle migrazione e il tipo di server di origine, per avviare le migrazioni.

• 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 il tipo di origine corrispondente, ad esempio un servizio PostgreSQL basato sul cloud, un'installazione locale o una macchina virtuale.

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

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

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

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

Selezionare il pulsante Avanti: Connetti all'origine.

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.

Connetti all'origine

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

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

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

Selezionare la destinazione di migrazione

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

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

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

Selezionare i database per la migrazione

In questa scheda, un elenco di database utente si trova all'interno del server di origine selezionato nella scheda di configurazione. È possibile selezionare fino a otto database ed eseguirne la migrazione in un unico tentativo di migrazione. Se sono presenti più di otto database utente, il processo di migrazione viene ripetuto tra i server di origine e di destinazione per il set di database successivo.

Dopo aver scelto i database, selezionare Avanti: Riepilogo

Riepilogo

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

Monitorare la migrazione

Dopo aver selezionato il pulsante di avvio, entro pochi secondi viene visualizzata una notifica per indicare che la convalida o la creazione della migrazione è stata eseguita correttamente. Si verrà quindi reindirizzati automaticamente alla pagina Migrazione del server flessibile, che include una nuova voce per la convalida o la migrazione creata di recente.

La griglia che mostra le migrazioni include queste colonne: Nome, Stato, Modalità di migrazione, Tipo di migrazione, Server di origine, Tipo del server di origine, Database, Durata e Ora inizio. Le voci vengono visualizzate nell'ordine decrescente dell'ora di inizio con la voce più recente in alto. È possibile usare il pulsante di aggiornamento per aggiornare lo stato della convalida o della migrazione. Selezionare il nome della migrazione nella griglia per visualizzare i dettagli associati.

Quando viene creata la convalida o la migrazione, questa passa allo stato InProgress e allo stato secondario PerformingPreRequisiteSteps. Il flusso di lavoro richiede 2-3 minuti per configurare l'infrastruttura di migrazione e le connessioni di rete.

Dettagli della migrazione

Nella scheda Configurazione è stata selezionata l'opzione di migrazione Convalida ed esegui migrazione. In questo scenario, le convalide vengono eseguite prima dell'avvio della migrazione. Quando lo stato secondario PerformingPreRequisiteSteps viene completato, il flusso di lavoro passa allo stato secondario Validation in Progress.

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

È possibile visualizzare i risultati della convalida e della migrazione a livello di istanza e di database.

I possibili stati della migrazione includono:

Stati della migrazione

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

Stati secondari della migrazione

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

Stati secondari della convalida

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

Cutover

Se sono presenti sia Esegui migrazione che Convalida ed esegui migrazione, il completamento della migrazione online richiede un altro passaggio: l'utente deve eseguire un'azione di cutover. Al termine della copia/clonazione dei dati di base, la migrazione passa allo WaitingForUserAction stato e allo WaitingForCutoverTrigger stato secondario. In questo stato, l'utente può attivare il cutover dal portale selezionando la migrazione.

Prima di avviare il cutover, è importante assicurarsi che:

• Le scritture nell'origine sono arrestate: il parametro Latency è 0 o vicino a 0. Le informazioni relative a Latency possono essere ottenute dalla schermata dei dettagli della migrazione, come illustrato di seguito:

  

• Il valore latency diminuisce a 0 o vicino a 0

• Il valore latency indica quando è avvenuta l'ultima sincronizzazione della destinazione con l'origine. A questo punto, le scritture nell'origine possono essere arrestate e il cutover può essere avviato. Se l'origine presenta traffico elevato, è consigliabile arrestare prima le scritture in modo che Latency possa avvicinarsi a 0 e successivamente avviare il cutover. L'operazione di cutover applica tutte le modifiche in sospeso dall'origine alla destinazione e completa la migrazione. Se si attiva un "Cutover" anche con il valore Latency, diverso da zero, la replica si arresta fino a quel momento. Tutti i dati rimangono nell'origine fino a quando il punto di cutover non viene applicato alla destinazione. Si supponga che la latenza fosse di 15 minuti nel punto di cutover; tutti i dati delle modifiche degli ultimi 15 minuti vengono quindi applicati alla destinazione. Il tempo dipende dal backlog delle modifiche apportate negli ultimi 15 minuti. Di conseguenza, è consigliabile che la latenza passi a zero o si avvicini a zero prima di attivare il cutover.

  

• La migrazione passa allo stato Succeeded non appena lo stato secondario Migrating Data o il cutover (nella migrazione online) viene completato correttamente. Se si verifica un problema nello stato secondario Migrating Data, la migrazione passa a uno stato Failed.

  

CLI

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

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

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

az login

Configurare l'attività di migrazione

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

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

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

• 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 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --filter All
  

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

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

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

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

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

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

• È possibile annullare eventuali tentativi di migrazione in corso mediante il comando cancel. Questo comando arresta il tentativo di migrazione specifico ed esegue il rollback di tutte le modifiche nel server di destinazione. Ecco il comando dell'interfaccia della riga di comando per eliminare una migrazione:

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

Cutover

• Nelle migrazioni online, al termine della migrazione dei dati di base l'attività di migrazione passa allo stato secondario WaitingForCutoverTrigger. In questo stato, l'utente può attivare il cutover tramite l'interfaccia della riga di comando mediante il comando seguente. Il cutover può anche essere attivato dal portale selezionando il nome della migrazione nella griglia di migrazione.

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

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

Controllare la migrazione al termine dell'operazione

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

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

• Verificare i dati nel server flessibile e assicurarsi che si tratti di una copia esatta dell'istanza di origine.
• Dopo la verifica, abilitare l'opzione di disponibilità elevata nel server flessibile in base alle esigenze.
• Modificare lo SKU del server flessibile in modo che corrisponda alle esigenze dell'applicazione. Questa modifica richiede un riavvio del server di database.
• Se si modificano i parametri del server dai relativi valori predefiniti nell'istanza di origine, copiare questi valori nel server flessibile.
• Copiare le altre impostazioni del server dall'istanza di origine al server flessibile, ad esempio tag, avvisi e regole del firewall (se applicabile).
• Apportare modifiche all'applicazione per puntare le stringhe di connessione a un server flessibile.
• Monitorare attentamente le prestazioni del database per assicurarsi che non sia necessaria l'ottimizzazione delle prestazioni.

Contenuto correlato

• Eseguire la migrazione offline da Google Cloud SQL per PostgreSQL
• Servizio di migrazione
• Eseguire la migrazione dall'ambiente locale e da macchine virtuali di Azure
• Problemi noti e limitazioni