Procedure consigliate per la migrazione senza problemi in Database di Azure per PostgreSQL
SI APPLICA A:
Database di Azure per PostgreSQL - Server flessibile
Questo articolo illustra le insidie comuni rilevate e le procedure consigliate per garantire una migrazione uniforme e corretta alle Database di Azure per PostgreSQL.
Convalida della pre-migrazione
Come primo passaggio della migrazione, eseguire la convalida della premigration prima di eseguire una migrazione. È possibile usare le opzioni Convalida e Convalida e Migrazione nella pagina di configurazione della migrazione. La convalida della premigration 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 premigration fino a quando non viene restituito lo stato Succeeded . Selezionare le convalide di premigration per altre informazioni.
Configurazione del server flessibile di destinazione
Durante la copia di base iniziale dei dati, vengono eseguite più istruzioni insert nella destinazione, che genera WALs (Write Ahead Logs). Fino a quando questi WALs 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 superiore 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 dello spettro di configurazione di archiviazione raddoppia in base alle dimensioni, quindi la stima dello spazio di archiviazione richiesto in anticipo è prudente.
La guida introduttiva per creare un server flessibile Database di Azure per PostgreSQL usando il portale è un ottimo punto di partenza. Le opzioni di calcolo e archiviazione in Database di Azure per PostgreSQL - Server flessibile offrono anche informazioni dettagliate su ogni configurazione del server.
Sequenza temporale della migrazione
Ogni migrazione ha una durata massima di sette giorni (168 ore) una volta avviata e si verifica il timeout dopo sette giorni. È possibile completare la migrazione e il cutover dell'applicazione al termine della 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 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 maggior parte dei server non prod (dev, UAT, test, staging) viene eseguita tramite migrazioni offline. Poiché questi server hanno meno dati rispetto ai server di produzione, la migrazione viene completata rapidamente. 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. Dato il numero di fattori che possono influire sul tempo di migrazione, è difficile stimare il tempo totale per il completamento della migrazione. L'approccio migliore consiste nell'eseguire una migrazione di test con il carico di lavoro.
Le fasi seguenti vengono considerate per calcolare il tempo di inattività totale per eseguire la migrazione del server di produzione.
Migrazione del ripristino temporizzato : il modo migliore per ottenere una stima corretta sul tempo impiegato 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 appena ripristinato.
Migrazione del buffer : dopo aver completato il passaggio precedente, è possibile pianificare la migrazione effettiva di produzione durante un periodo di tempo in cui il traffico dell'applicazione è basso. Questa migrazione può essere pianificata nello stesso giorno o probabilmente una settimana. In questo momento, 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, è possibile provare a eseguire un altro test usando il server PITR. Ma per la maggior parte dei server l'aumento delle dimensioni non deve essere abbastanza significativo.
Convalida dei dati: una volta completata la migrazione per il server di produzione, è necessario verificare se i dati nel server flessibile sono una copia esatta dell'istanza di origine. I clienti possono usare strumenti open source o di terze parti o 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 corrispondenti per tutti gli oggetti di database (tabelle, sequenze, estensioni, procedure, indici)
Confronto di ID massimi o min di colonne chiave correlate all'applicazione
Nota
Le dimensioni dei database devono essere la metrica corretta per la convalida. L'istanza di origine potrebbe avere tuple bloats/dead, che possono aumentare le dimensioni dell'istanza di origine. È normale avere differenze di dimensioni tra le istanze di origine e i server di destinazione. Se si verifica un problema nei primi tre passaggi della convalida, indica un problema con la migrazione.
Migrazione delle impostazioni del server: tutti i parametri del server personalizzati, le regole del firewall (se applicabile), i tag e gli avvisi devono essere copiati manualmente dall'istanza di origine alla destinazione.
Modifica delle stringa di connessione: l'applicazione deve modificare i stringa di connessione in un server flessibile dopo la convalida. Questa attività è coordinata con il team dell'applicazione per modificare tutti i riferimenti di stringa di connessione che puntano all'istanza di origine. Nel server flessibile, il parametro utente può essere usato nel formato user=username nel stringa di connessione.
Ad esempio: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1
Sebbene una migrazione venga eseguita spesso senza un hitch, è consigliabile pianificare contingenze se è 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 i 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, 128 GB di disco e 500 operazioni di i/o al secondo)
| 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 |
Nota
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
Selezionare uno SKU superiore per il server flessibile per eseguire migrazioni più veloci. Database di Azure per PostgreSQL server flessibile supporta il ridimensionamento delle operazioni di calcolo e I/O al secondo quasi zero, 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 delle 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 nel caso in cui la distribuzione dei dati tra le tabelle debba essere più bilanciata e/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, il calcolo allocato per la migrazione deve essere completamente utilizzato e crea un collo di bottiglia. Di conseguenza, le tabelle di grandi dimensioni vengono suddivise in blocchi più piccoli, che vengono quindi migrati in parallelo. Questa funzionalità si applica alle tabelle con più di 10000000 tuple (10 m). 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 un valore int significativo.
Nota
Nel caso di approcci n. 2 o 3, l'utente deve 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 se l'utente procede con le modifiche.
Se la tabella non ha una chiave primaria semplice o un indice univoco di tipo int o significativo, 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 int/big int semplice o un indice univoco o una colonna che soddisfa i criteri del tipo di dati, è possibile aggiungere una colonna di questo tipo usando ALTER e eliminarla 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, che dovrebbe fornire un aumento marcato della velocità di migrazione.
Funzionamento
- Il servizio di migrazione cerca il valore intero massimo e minimo dell'indice chiave primaria/univoco della tabella che deve essere suddiviso ed eseguito la migrazione in parallelo.
- Se la differenza tra il valore minimo e quello massimo è maggiore di 10000000 (10 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 100000000 (10 m) righe in modo che la differenza tra il valore minimo e massimo della chiave primaria sia maggiore di 100000000 (10 m).
- Lo SKU usato include core inattive, che possono essere usati per la migrazione della tabella in parallelo.
Vuoto bloat nel database PostgreSQL
Nel corso del tempo, man mano che i dati vengono aggiunti, aggiornati ed eliminati, PostgreSQL potrebbe accumulare righe non attive e spazio di archiviazione sprecato. Questo bloat può causare un aumento dei requisiti di archiviazione e una riduzione delle prestazioni delle query. Il vuoto è un'attività di manutenzione fondamentale che consente di recuperare questo spazio sprecato e garantisce che il database funzioni in modo efficiente. L'aspirapolvere risolve problemi quali righe non recapitabili e bloat di tabella, garantendo un uso efficiente dello spazio di archiviazione. Più importante, garantisce una migrazione più rapida perché il tempo di migrazione impiegato è una funzione delle dimensioni del database.
PostgreSQL fornisce il comando VACUUM per recuperare l'archiviazione occupata da righe non recapitabili. L'opzione ANALYZE raccoglie anche le statistiche, ottimizzando ulteriormente la pianificazione delle query. Per le tabelle con attività di scrittura intensa, il VACUUM processo può essere più aggressivo usando VACUUM FULL, ma richiede più tempo per l'esecuzione.
- Vuoto standard
VACUUM your_table;
- Vacuum con Analizza
VACUUM ANALYZE your_table;
- Vacuum aggressivo per tabelle di scrittura pesanti
VACUUM FULL your_table;
In questo esempio sostituire your_table con il nome effettivo della tabella. Il VACUUM comando senza FULL recupera spazio in modo efficiente, ottimizzando la VACUUM ANALYZE pianificazione delle query. L'opzione VACUUM FULL deve essere usata in modo succoso a causa del suo impatto più pesante sulle prestazioni.
Alcuni database archivia oggetti di grandi dimensioni, ad esempio immagini o documenti, che possono contribuire al blob del database nel tempo. Il VACUUMLO comando è progettato per oggetti di grandi dimensioni in PostgreSQL.
- Oggetti grandi vacuum
VACUUMLO;
L'incorporamento regolare di queste strategie di vuoto garantisce un database PostgreSQL ben gestito.
Considerazioni speciali
Esistono condizioni speciali che in genere fanno riferimento a circostanze, configurazioni o prerequisiti univoci di cui gli studenti devono essere a conoscenza prima di procedere con un'esercitazione o un modulo. Queste condizioni possono includere versioni software specifiche, requisiti hardware o strumenti aggiuntivi necessari per il completamento corretto del contenuto di apprendimento.
Migrazione online
La migrazione online usa pgcopydb e alcune delle restrizioni di decodifica logica si applicano. È inoltre consigliabile avere una chiave primaria in tutte le tabelle di un database in fase di migrazione online. Se la chiave primaria è assente, la carenza può comportare solo operazioni di inserimento riflesse durante la migrazione, esclusi gli aggiornamenti o le eliminazioni. Aggiungere una chiave primaria temporanea alle tabelle pertinenti prima di procedere con la migrazione online.
Un'alternativa consiste nell'usare il ALTER TABLE comando in cui l'azione è REPLICA IDENTIY con l'opzione FULL . L'opzione FULL registra i valori precedenti 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.
- Rimuovere temporaneamente (scollegare) wrapper di dati stranieri nell'istanza di origine.
- Eseguire la migrazione dei dati inattivi usando il servizio migrazione.
- Ripristinare i ruoli wrapper dei dati esterni, l'utente e i collegamenti alla destinazione dopo la migrazione.
Database con estensione postGIS
L'estensione Postgis presenta problemi di modifiche/compatta 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 devono essere apportate. Le note sulla versione e le notizie postGIS sono un buon punto di partenza per comprendere le modifiche di rilievo tra le versioni.
Pulizia della connessione al database
In alcuni casi, è possibile che si verifichi questo errore durante l'avvio di 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 caso, è possibile concedere l'autorizzazione migration user per chiudere tutte le connessioni attive al database o chiudere manualmente le connessioni prima di ritentare la migrazione.