Procedure consigliate per una migrazione fluida in Database di Azure per PostgreSQL

Questo articolo illustra i problemi comuni riscontrati e le procedure consigliate per garantire una migrazione fluida ed efficace a Database di Azure per PostgreSQL.

Convalide pre-migrazione

Innanzitutto, prima di eseguire una migrazione, eseguire la convalida pre-migrazione. È possibile usare le opzioni Convalidare e convalidare ed eseguire la migrazione nella pagina di installazione della migrazione. Nella convalida pre-migrazione vengono eseguiti controlli approfonditi rispetto a un set di regole predefinito. L'obiettivo è identificare potenziali problemi e fornire informazioni dettagliate utili per le azioni correttive. Continuare a eseguire la convalida pre-migrazione fino a quando non viene restituito uno stato di esito positivo. Per altre informazioni, vedere Convalide pre-migrazione.

Configurazione del server flessibile di destinazione

Durante la copia di base iniziale dei dati, vengono eseguite più istruzioni insert sulla destinazione, che genera log write-ahead (WAL). Finché questi log WAL non vengono archiviati, consumano spazio di archiviazione nella destinazione e spazio di archiviazione richiesto dal database.

Per calcolare il numero, accedere all'istanza di origine ed eseguire questo comando per la migrazione di tutti i database:

SELECT pg_size_pretty( pg_database_size('dbname') );

È consigliabile allocare spazio di archiviazione sufficiente nel server flessibile, equivalente a 1,25 volte o al 25% di spazio di archiviazione in più rispetto a quello usato per ogni output del comando precedente. È anche possibile usare l'aumento automatico dell'archiviazione.

La guida introduttiva per creare un server flessibile di Database di Azure per PostgreSQL è un ottimo punto di partenza. Per altre informazioni su ogni configurazione del server, vedere Opzioni di calcolo e archiviazione nel server flessibile di Database di Azure per PostgreSQL.

Sequenza temporale della migrazione

Ogni migrazione ha una durata massima di sette giorni (168 ore) dopo l'avvio, dopodiché se ne verifica il timeout. È possibile completare la migrazione e il cutover dell'applicazione una volta completati la convalida dei dati e tutti i controlli per evitare il timeout della migrazione. Nelle migrazioni online, dopo il completamento della copia di base iniziale, la finestra di cutover prima del timeout è di tre giorni (72 ore). Nelle migrazioni offline, le applicazioni devono interrompere la scrittura nel database per evitare la perdita di dati. Analogamente, per la migrazione online, mantenere basso il traffico durante la migrazione.

La migrazione della maggior parte dei server non di produzione (dev, UAT, test e staging) viene eseguita tramite migrazioni offline. Poiché questi server contengono meno dati rispetto ai server di produzione, la migrazione è veloce. Per la migrazione di server di produzione, occorre conoscere il tempo necessario per completarla e poterla pianificare in anticipo.

Il tempo impiegato per il completamento di una migrazione dipende da diversi fattori. Include il numero di database, le dimensioni, il numero di tabelle all'interno di ogni database, il numero di indici e la distribuzione dei dati tra tabelle. Dipende anche dallo SKU del server di destinazione e dalle operazioni di I/O al secondo disponibili nell'istanza di origine e nel server di destinazione. Stimarne il tempo totale necessario per il completamento della migrazione è difficile, dati i molti fattori da cui dipende. L'approccio è eseguire una migrazione di test con il proprio carico di lavoro.

Per il calcolo del tempo di inattività totale necessario per eseguire la migrazione del server di produzione, vengono considerate le fasi seguenti:

• Migrazione del ripristino temporizzato: il modo migliore per ottenere una stima corretta del tempo richiesto per eseguire la migrazione del server di database di produzione consiste nell'eseguire un ripristino temporizzato del server di produzione ed eseguire la migrazione offline in questo server ripristinato.

• Migrazione del buffer: dopo aver completato il passaggio precedente, è possibile pianificare la migrazione di produzione effettiva in un periodo in cui il traffico dell'applicazione è basso. Questa migrazione può essere pianificata per lo stesso giorno oppure una settimana dopo. In questo intervallo, le dimensioni del server di origine possono aumentare. Aggiornare il tempo di migrazione stimato per il server di produzione in base a questo aumento di dimensioni. Se l'aumento è significativo, provare a eseguire un altro test usando il server di ripristino temporizzato. Tuttavia, per la maggior parte dei server l'aumento di dimensioni non è particolarmente ingente.

• Convalida dei dati: al termine della migrazione del server di produzione, è necessario verificare se i dati nel server flessibile sono una copia esatta dell'istanza di origine. È possibile usare strumenti open source o di terze parti, oppure eseguire manualmente la convalida. Preparare i passaggi di convalida da eseguire prima della migrazione effettiva. La convalida può includere:

  • Corrispondenza del numero di righe per tutte le tabelle incluse nella migrazione.

  • Corrispondenza del numero per tutti gli oggetti del database (tabelle, sequenze, estensioni, procedure e indici).

  • Confronto degli ID massimi o minimi delle colonne chiave correlate all'applicazione.

    Note

    Le dimensioni comparative dei database non rappresentano la metrica corretta per la convalida. L'istanza di origine potrebbe includere software bloat o tuple inattive che ne possono aumentare le dimensioni. È normale che ci siano differenze di dimensione tra le istanze di origine e i server di destinazione. Un problema nei tre passaggi di convalida precedenti indica un problema della migrazione.

• Migrazione delle impostazioni del server: tutti i parametri del server personalizzati, le regole del firewall (se applicabili), i tag e gli avvisi devono essere copiati manualmente dall'istanza di origine alla destinazione.

• Modifica delle stringhe di connessione: dopo la convalida, l'applicazione deve modificare le proprie stringhe di connessione in modo che puntino a un server flessibile. Questa attività è coordinata con il team dell'applicazione al fine di modificare tutti i riferimenti delle stringhe di connessione che puntano all'istanza di origine. Nel server flessibile, il parametro utente può essere usato nel formato utente=nomeutente nella stringa di connessione.

ad esempio psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

Anche se spesso la migrazione viene eseguita senza problemi, è consigliabile prevedere eventuali emergenze in caso sia necessario più tempo per il debug o sia richiesto il riavvio della migrazione.

Benchmarking della velocità di migrazione

La tabella seguente mostra il tempo necessario per eseguire le migrazioni di database di varie dimensioni usando il servizio di migrazione. La migrazione è stata eseguita usando un server flessibile con lo SKU Standard_D4ds_v4 (4 core, 16 GB di memoria).

I numeri precedenti forniscono un'approssimazione del tempo impiegato per completare la migrazione. È consigliabile eseguire una migrazione di test con il proprio carico di lavoro per ottenere un valore preciso per la migrazione del server.

Migliorare la velocità di migrazione: migrazione parallela delle tabelle

È consigliabile usare uno SKU potente per la destinazione perché il servizio di migrazione PostgreSQL viene eseguito da un contenitore nel server flessibile. Uno SKU potente consente di eseguire la migrazione di più tabelle in parallelo. È possibile ridimensionare lo SKU alla configurazione preferita dopo la migrazione. Questa sezione contiene i passaggi necessari per aumentare la velocità di migrazione se la distribuzione dei dati tra le tabelle deve essere più bilanciata o uno SKU più potente non incide significativamente sulla velocità.

Se la distribuzione dei dati nell'origine è altamente asimmetrica e la maggior parte dei dati è contenuta in una sola tabella, è necessario utilizzare completamente l'ambiente di calcolo allocato per la migrazione e ciò crea un collo di bottiglia. In questo caso, suddividere le tabelle di grandi dimensioni in blocchi più piccoli di cui verrà eseguita la migrazione parallelo. Questa funzionalità si applica alle tabelle di dimensioni superiori a 20 GB. La suddivisione della tabella in blocchi più piccoli è possibile in presenza di una delle condizioni seguenti:

• La tabella deve avere una colonna con una chiave primaria semplice (non composita) o un indice univoco di tipo smallint, integer o big int.

  Note

  Per il primo o il secondo approccio, è necessario valutare attentamente le implicazioni dell'aggiunta di una colonna di indice univoca allo schema di origine. È consigliabile procedere con le modifiche solo dopo aver verificato che l'aggiunta di una colonna di indice univoca non influisce sull'applicazione.

• Se la tabella non dispone di una chiave primaria semplice o di un indice univoco di tipo smallint, integer o big int ma include una colonna che soddisfa i criteri del tipo di dati, la colonna può essere convertita in un indice univoco usando il comando seguente. Questo comando non richiede un blocco sulla tabella.

      create unique index concurrently partkey_idx on <table name> (column name);
  

• Se la tabella non dispone di una chiave primaria o di un indice univoco smallint, integer o big int, né di alcuna colonna che soddisfa i criteri del tipo di dati, è possibile aggiungere tale colonna usando ALTER ed eliminarla dopo la migrazione. L’esecuzione del comando ALTER richiede un blocco sulla tabella.

      alter table <table name> add column <column name> big serial unique;
  

Se si soddisfa qualsiasi delle condizioni precedenti, viene eseguita la migrazione della tabella in più partizioni in parallelo e ciò dovrebbero offrire un aumento della velocità.

Funzionamento

• Il servizio di migrazione cerca le dimensioni di una tabella per verificare se sono maggiori di 20 GB.
• Se le dimensioni sono maggiori di 20 GB ed è presente una chiave primaria o un indice univoco smallint, integer o big int, la tabella viene suddivisa in più parti e viene eseguita la migrazione in parallelo di ognuna di esse.

In sintesi, il servizio di migrazione PostgreSQL esegue la migrazione di una tabella in thread paralleli e riduce il tempo di migrazione se:

• La tabella include una colonna con una chiave primaria semplice o un indice univoco di tipo smallint, integer o big int.
• Le dimensioni della tabella sono maggiori di 20 GB.
• Lo SKU usato include core inattivi, che possono essere usati per la migrazione in parallelo della tabella.

Software bloat da vacuum nel database PostgreSQL

Nel corso del tempo, con l'aggiunta, l'aggiornamento e l'eliminazione di dati, PostgreSQL potrebbe accumulare righe non inattive e spazio di archiviazione sprecato. Questo software bloat può causare un aumento dei requisiti di archiviazione e una riduzione delle prestazioni delle query. Il vacuum è un'attività di manutenzione fondamentale che consente di recuperare questo spazio sprecato e garantisce che il database funzioni in modo efficiente. Il vacuum risolve problemi quali righe inattive e software bloat di tabelle per garantire un uso efficiente dello spazio di archiviazione. Permette inoltre una migrazione più rapida poiché il tempo di migrazione dipende dalle dimensioni del database.

PostgreSQL fornisce il comando VACUUM per il recupero dello spazio di archiviazione occupata da righe inattive. L'opzione ANALYZE raccoglie anche statistiche per ottimizzare ulteriormente la pianificazione delle query. Per le tabelle con attività di scrittura intensa, il processo VACUUM può essere più aggressivo usando VACUUM FULL, ma ciò richiede più tempo per l'esecuzione.

• Vacuum standard

  VACUUM your_table;
  

• Vacuum con analisi

  VACUUM ANALYZE your_table;
  

• Vacuum aggressivo per tabelle con attività di scrittura intensa

  VACUUM FULL your_table;
  

In questo esempio sostituire your_table con il nome effettivo della tabella. Il comando VACUUM senza FULL recupera spazio in modo efficiente, mentre VACUUM ANALYZE ottimizza la pianificazione delle query. L’opzione VACUUM FULL deve essere usata con cautela a causa del suo impatto maggiore sulle prestazioni.

Alcuni database archiviano oggetti di grandi dimensioni, ad esempio immagini o documenti, che possono contribuire al software bloat del database con il passare del tempo. Il comando VACUUMLO è progettato per oggetti di grandi dimensioni in PostgreSQL.

• Vacuum di oggetti di grandi dimensioni

  VACUUMLO;
  

L'incorporamento regolare di queste strategie di vacuum garantisce un mantenimento adeguato di PostgreSQL.

Considerazione speciale

Vi sono condizioni speciali relative a circostanze, configurazioni o prerequisiti specifici di cui è necessario essere a conoscenza prima di procedere con un'esercitazione o un modulo. Queste condizioni possono includere versioni software specifiche, requisiti hardware o altri strumenti necessari per il completamento corretto del contenuto di apprendimento.

Migrazione online

La migrazione online usa pgcopydb follow e vengono applicate alcune delle restrizioni di decodifica logica. Si consiglia inoltre di avere una chiave primaria in tutte le tabelle di un database sottoposto a migrazione online. Se non è presente una chiave primaria, tale assenza fa sì che la migrazione rifletta solo le operazioni insert, escludendo gli aggiornamenti o le eliminazioni. Aggiungere una chiave primaria temporanea alle tabelle interessate prima di procedere con la migrazione online.

Un'alternativa consiste nell'usare il comando ALTER TABLE in cui l'azione è REPLICA IDENTIY con l'opzione FULL. L’opzione FULL registra i valori meno recenti di tutte le colonne nella riga in modo che, anche in assenza di una chiave primaria, tutte le operazioni CRUD vengano riflesse nella destinazione durante la migrazione online. Se nessuna di queste opzioni funziona, eseguire una migrazione offline come alternativa.

Pulizia della connessione di database

In alcuni casi, è possibile che si verifichi questo errore quando si avvia una migrazione:

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

In questo scenario è possibile concedere al migration user l'autorizzazione a chiudere tutte le connessioni attive al database o a chiudere manualmente le connessioni prima di ripetere la migrazione.

Contenuti correlati

• Servizio di migrazione
• Problemi noti e limitazioni