Condividi tramite

Procedure consigliate per la migrazione senza problemi in Database di Azure per PostgreSQL

  • Articolo

SI APPLICA A: Server flessibile di Database di Azure per PostgreSQL

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

Convalida della pre-migrazione

Come primo passaggio della migrazione, eseguire la convalida della migrazione preventiva prima di eseguire una migrazione. È possibile usare le opzioni Convalida e Convalida ed esegui la migrazione nella pagina Configurazione della migrazione. La convalida della migrazione preventiva esegue 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 della migrazione preventiva fino a quando non viene restituito uno stato Operazione completata. Per altre informazioni, vedere Convalide delle premigrazioni.

Configurazione del server flessibile di destinazione

Durante la copia di base iniziale dei dati, vengono eseguite più istruzioni insert nella destinazione, che genera log write-ahead (WAL). Fino a quando questi WAL non vengono archiviati, i log usano l'archiviazione nella destinazione e lo spazio di archiviazione richiesto dal database.

Per calcolare il numero, accedere all’istanza di origine ed eseguire questo comando per eseguire 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.

Importante

Le dimensioni di archiviazione non possono essere ridotte nella configurazione manuale o nell'aumento automatico dell'archiviazione. Ogni passaggio nello spettro di configurazione dell’archiviazione raddoppia in termini di dimensioni, quindi stimare in anticipo lo spazio di archiviazione richiesto è una scelta prudente.

L’avvio rapido per creare un’istanza di Database di Azure per PostgreSQL - server flessibile usando il portale è un ottimo punto di partenza. Per altre informazioni su ogni configurazione del server, vedere Opzioni di calcolo e archiviazione in Database di Azure per PostgreSQL - server flessibile.

Importante

Dopo aver creato il server flessibile, assicurarsi di modificare il parametro del server password_encryption nel server flessibile da SCRAM-SHA-256 a MD5 prima di attivare la migrazione. Questa operazione è essenziale per il funzionamento delle credenziali esistenti in un singolo server nel server flessibile

Sequenza temporale della migrazione

Ogni migrazione ha una durata massima di sette giorni (168 ore) dopo l’avvio e si verifica il timeout dopo sette giorni. È possibile completare la migrazione e il cutover dell’applicazione dopo la convalida dei dati e tutti i controlli vengono completati per evitare il timeout della migrazione. Nelle migrazioni online, dopo il completamento della copia di base iniziale, la finestra di cutover dura tre giorni (72 ore) prima del timeout. 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 del server di produzione, è necessario conoscere il tempo necessario per completare la migrazione per pianificarla in anticipo.

Il tempo impiegato per il completamento di una migrazione dipende da diversi fattori. Include il numero di database, dimensioni, numero di tabelle all'interno di ogni database, numero di indici e 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. Con così tanti fattori che possono influire sul tempo di migrazione, è difficile stimare il tempo totale per il completamento di una migrazione. L’approccio migliore consiste nell’eseguire una migrazione di test con il carico di lavoro personale.

Le fasi seguenti vengono considerate per calcolare il tempo di inattività totale per eseguire la migrazione del server di produzione:

  • Migrazione del ripristino temporizzato (PITR): il modo migliore per ottenere una stima corretta del tempo impiegato per eseguire la migrazione del server del database di produzione consiste nell’eseguire un ripristino temporizzato del server di produzione ed eseguire la migrazione offline in questo server appena ripristinato.

  • Migrazione del buffer: dopo aver completato il passaggio precedente, è possibile pianificare la migrazione di produzione effettiva durante un periodo di tempo in cui il traffico dell’applicazione è basso. Questa migrazione può essere pianificata nello stesso giorno o probabilmente dopo una settimana. In questo intervallo, le dimensioni del server di origine potrebbero essere aumentate. Aggiornare il tempo di migrazione stimato per il server di produzione in base alla quantità di questo aumento. Se l’aumento è significativo, provare a eseguire un altro test usando il server di ripristino temporizzato. Ma per la maggior parte dei server, l’aumento delle dimensioni non dovrebbe essere piuttosto significativo.

  • Convalida dei dati: al termine della migrazione per il 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 coinvolte nella migrazione.

    • Conteggi di corrispondenza per tutti gli oggetti del database (tabelle, sequenze, estensioni, procedure e indici).

    • Confronto tra ID massimi o minimi delle colonne chiave correlate all’applicazione.

      Nota

      La dimensione comparativa dei database non è la metrica corretta per la convalida. L’istanza di origine potrebbe evidenziare bloat o tuple morte, che possono aumentare le dimensioni dell’istanza di origine. È 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 con la migrazione.

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

  • Modifica delle stringhe di connessione: l’applicazione deve modificare le stringhe di connessione in un server flessibile dopo la convalida corretta. Questa attività è coordinata con il team dell'applicazione per 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 user=username nella stringa di connessione.

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

Anche se una migrazione viene spesso eseguita senza problemi, è consigliabile pianificare le contingenze in caso sia necessario più tempo per il debug o se è necessario riavviare una migrazione.

Benchmarking della velocità di migrazione

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

Dimensione database Tempo approssimativo impiegato (HH:MM)
1 GB 00:01
5 GB 00:03
10 GB 00:08
50 GB 00:35
100 GB 01:00
500 GB 04:00
1.000 GB 07:00

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

Importante

Anche se lo SKU con burst non è una limitazione, è consigliabile scegliere uno SKU superiore per il server flessibile per eseguire migrazioni più veloci. Database di Azure per PostgreSQL - server flessibile supporta il calcolo dei tempi di inattività pari quasi a zero e il ridimensionamento delle operazioni di I/O al secondo, in modo che lo SKU possa essere aggiornato con tempi di inattività minimi. È sempre possibile modificare lo SKU in modo che corrisponda alle esigenze dell'applicazione dopo la migrazione.

Migliorare la velocità di migrazione: migrazione parallela di tabelle

È consigliabile usare uno SKU potente per la destinazione perché il servizio di migrazione PostgreSQL esce 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 per migliorare la velocità di migrazione se la distribuzione dei dati tra le tabelle deve essere più bilanciata o uno SKU più potente non influisce significativamente sulla velocità di migrazione.

Se la distribuzione dei dati nell’origine è altamente asimmetrica, con la maggior parte dei dati presenti in una tabella, è necessario usare completamente il calcolo allocato per la migrazione, creando un collo di bottiglia. Suddividere quindi tabelle di grandi dimensioni in blocchi più piccoli che vengono poi migrati in parallelo. Questa funzionalità si applica alle tabelle con più di 1.000.000 (1 M) di tuple. La suddivisione della tabella in blocchi più piccoli è possibile se viene soddisfatta una delle condizioni seguenti:

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

    Nota

    Nel caso degli approcci primo o secondo, è necessario valutare attentamente le implicazioni dell’aggiunta di una colonna di indice univoca allo schema di origine. Solo dopo la conferma che l’aggiunta di una colonna di indice univoca non influisce sull’applicazione, è consigliabile procedere con le modifiche.

  • Se la tabella non ha una chiave primaria semplice o un indice univoco di tipo int o significant int, ma ha 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 ha una chiave primaria simple int/big int, un indice univoco o una colonna che soddisfa i criteri del tipo di dati, è possibile aggiungere tale colonna usando ALTER e rimuoverla dopo la migrazione. L’esecuzione del comando ALTER richiede un blocco nella tabella.

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

Se una delle condizioni precedenti viene soddisfatta, la tabella viene migrata in più partizioni in parallelo, con un aumento della velocità di migrazione.

Funzionamento

  • Il servizio di migrazione cerca il valore intero massimo e minimo dell’indice univoco/chiave primaria della tabella che deve essere suddiviso di cui deve essere eseguita la migrazione in parallelo.
  • Se la differenza tra il valore minimo e quello massimo è maggiore di 1.000.000 (1 M), la tabella viene suddivisa in più parti e ogni parte viene migrata in parallelo.

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 int o un valore int significativo.
  • La tabella contiene almeno 1.000.000 (1 M) di righe, in modo che la differenza tra il valore minimo e massimo della chiave primaria sia maggiore di 1.000.000 (1 M).
  • Lo SKU usato include core inattivi, che possono essere usati per la migrazione della tabella in parallelo.

Vacuum bloat nel database PostgreSQL

Nel corso del tempo, man mano che i dati vengono aggiunti, aggiornati ed eliminati, PostgreSQL potrebbe accumulare righe non recapitabili e spazio di archiviazione sprecato. Questo 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 vacuuming risolve problemi quali righe morte e bloat di tabelle per garantire un uso efficiente dello spazio di archiviazione. Consente inoltre di garantire una migrazione più rapida perché il tempo di migrazione è una funzione delle dimensioni del database.

PostgreSQL fornisce il comando VACUUM per recuperare l’archiviazione occupata da righe morte. L’opzione ANALYZE raccoglie anche le 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 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 giudiziosamente a causa del suo impatto più pesante sulle prestazioni.

Alcuni database archiviano oggetti di grandi dimensioni, ad esempio immagini o documenti, che possono contribuire al 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 database PostgreSQL ben gestito.

Considerazioni speciali

Esistono condizioni speciali che in genere fanno riferimento a circostanze, configurazioni o prerequisiti univoci 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 il comando pgcopydb follow e vengono applicate alcune delle restrizioni di decodifica logica. È anche consigliabile disporre di una chiave primaria in tutte le tabelle di un database in fase di migrazione online. Se una chiave primaria è assente, la mancanza comporta la riflessione delle sole operazioni insert durante la migrazione, escludendo gli aggiornamenti o le eliminazioni. Aggiungere una chiave primaria temporanea alle tabelle pertinenti prima di procedere con la migrazione online.

Nota

Nel caso della migrazione online di tabelle senza una chiave primaria, solo le operazioni insert verranno riprodotte nella destinazione. Ciò può potenzialmente introdurre incoerenza nel database se i record aggiornati o eliminati nell’origine non si riflettono nella destinazione.

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 sulla destinazione durante la migrazione online. Se nessuna di queste opzioni funziona, eseguire una migrazione offline come alternativa.

Database con estensione postgres_fdw

Il modulo postgres_fdw fornisce il wrapper di dati esterni postgres_fdw, che può essere usato per accedere ai dati archiviati in server PostgreSQL esterni. Se il database usa questa estensione, è necessario eseguire i passaggi seguenti per garantire una corretta migrazione.

  1. Rimuovere temporaneamente (scollegare) il wrapper di dati esterni nell’istanza di origine.
  2. Eseguire la migrazione dei dati del resto usando il servizio di migrazione.
  3. Ripristinare i ruoli del wrapper di dati esterni, l’utente e i collegamenti alla destinazione dopo la migrazione.

Database con estensione postGIS

L’estensione postGIS presenta problemi di modifiche/compattazione di rilievo tra versioni diverse. Se si esegue la migrazione a un server flessibile, l’applicazione deve essere verificata rispetto alla versione postGIS più recente per assicurarsi che l’applicazione non sia interessata o che le modifiche necessarie vengano apportate. Le Novità PostGIS e le note sulla versione sono un buon punto di partenza per comprendere le modifiche di rilievo tra le versioni.

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 a migration user l’autorizzazione per chiudere tutte le connessioni attive al database o chiudere manualmente le connessioni prima di ripetere la migrazione.

Contenuto correlato