Procedure consigliate per pg_dump e pg_restore per Database di Azure per PostgreSQL - Server flessibile
SI APPLICA A:
Database di Azure per PostgreSQL - Server flessibile
Questo articolo esamina le opzioni e le procedure consigliate per velocizzare pg_dump e pg_restore. Vengono inoltre illustrate le configurazioni server migliori per l'esecuzione di pg_restore.
Procedure consigliate per pg_dump
È possibile usare l'utilità pg_dump per estrarre un database server flessibile Database di Azure per PostgreSQL in un file di script o in un file di archivio. Alcune delle opzioni della riga di comando che è possibile usare per ridurre il tempo di dump complessivo usando pg_dump sono elencate nelle sezioni seguenti.
Formato directory (-Fd)
Questa opzione restituisce un archivio in formato directory che è possibile immettere per pg_restore. Per impostazione predefinita, l'output viene compresso.
Processi paralleli (-j)
Con pg_dump è possibile eseguire i processi di dump contemporaneamente usando l'opzione processi paralleli. Questa opzione riduce il tempo totale di dump, ma aumenta il carico nel server di database. È consigliabile arrivare a un valore di processo parallelo dopo aver monitorato attentamente le metriche del server di origine, ad esempio CPU, memoria e operazioni di I/O al secondo (operazioni di input/output al secondo).
Quando si imposta un valore per l'opzione processi paralleli, pg_dump richiede quanto segue:
- Il numero di connessioni deve corrispondere al numero di processi paralleli +1, quindi assicurarsi di impostare il
max_connectionsvalore di conseguenza. - Il numero di processi paralleli deve essere minore o uguale al numero di vCPU allocati per il server di database.
Compression(-Z0)
Questa opzione specifica il livello di compressione da utilizzare. Zero indica che non è disponibile alcuna compressione. La compressione zero durante il processo di pg_dump potrebbe contribuire a migliorare le prestazioni.
Bloats e vacuuming delle tabelle
Prima di iniziare il processo di pg_dump, valutare se è necessario eseguire il vacuuming delle tabelle. Bloat sulle tabelle aumenta significativamente pg_dump volte. Eseguire la query seguente per identificare i bloats della tabella:
select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;
La dead_pct colonna in questa query è la percentuale di tuple inattivi rispetto alle tuple attive. Un valore elevato dead_pct per una tabella potrebbe indicare che la tabella non è sottoposta a vuoto correttamente. Per altre informazioni, vedere Ottimizzazione automatica in Database di Azure per PostgreSQL - Server flessibile.
Per ogni tabella identificata, è possibile eseguire un'analisi manuale del vuoto eseguendo le operazioni seguenti:
vacuum(analyze, verbose) <table_name>
Usare un server PITR
È possibile eseguire un pg_dump in un server online o live. Rende coerenti i backup anche se il database viene usato. Non impedisce ad altri utenti di usare il database. Prendere in considerazione le dimensioni del database e altre esigenze aziendali o dei clienti prima di avviare il processo di pg_dump. I database di piccole dimensioni possono essere candidati validi per l'esecuzione di un pg_dump nel server di produzione.
Per i database di grandi dimensioni, è possibile creare un server di ripristino temporizzato (PITR) dal server di produzione ed eseguire il processo di pg_dump nel server PITR. L'esecuzione di pg_dump in un ripristino temporizzato sarebbe un processo di esecuzione a freddo. Il compromesso per questo approccio è che non ci si preoccupa dell'utilizzo di CPU, memoria e I/O aggiuntivo fornito con un processo di pg_dump eseguito in un server di produzione effettivo. È possibile eseguire pg_dump in un server PITR e quindi eliminare il server PITR al termine del processo di pg_dump.
Sintassi per pg_dump
Usare la sintassi seguente per pg_dump:
pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format
Procedure consigliate per pg_restore
È possibile usare l'utilità pg_restore per ripristinare un database server flessibile Database di Azure per PostgreSQL da un archivio creato da pg_dump. Alcune opzioni della riga di comando per ridurre il tempo di ripristino complessivo sono elencate nelle sezioni seguenti.
Ripristino parallelo
Usando più processi simultanei, è possibile ridurre il tempo necessario per ripristinare un database di grandi dimensioni in un server di destinazione multi-vCore. Il numero di processi può essere uguale o minore del numero di vCPU allocati per il server di destinazione.
Parametri del server
Se si ripristinano i dati in un nuovo server o in un server non di produzione, è possibile ottimizzare i parametri server seguenti prima di eseguire pg_restore:
work_mem = 32 MB
max_wal_size = 65536 (64 GB)
checkpoint_timeout = 3600 #60min
maintenance_work_mem = 2097151 (2 GB)
autovacuum = off
wal_compression = su
Al termine del ripristino, assicurarsi che tutti questi parametri vengano aggiornati in modo appropriato in base ai requisiti del carico di lavoro.
Nota
Seguire le indicazioni precedenti solo se è disponibile memoria e spazio su disco sufficiente. Se si dispone di un server di piccole dimensioni con 2, 4 o 8 vCore, impostare i parametri di conseguenza.
Altre considerazioni
- Disabilitare la disponibilità elevata prima di eseguire pg_restore.
- Analizzare tutte le tabelle di cui viene eseguita la migrazione al termine del ripristino.
Sintassi per pg_restore
Usare la sintassi seguente per pg_restore:
pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>
-Fd: formato della directory.-j: numero di processi.-C: iniziare l'output con un comando per creare il database stesso e quindi riconnettersi.
Ecco un esempio di come può apparire questa sintassi:
pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format
Considerazioni sulle macchine virtuali
Creare una macchina virtuale nella stessa area e nella stessa zona di disponibilità, preferibilmente in cui sono presenti sia i server di destinazione che i server di origine. In alternativa, creare almeno la macchina virtuale più vicina al server di origine o a un server di destinazione. È consigliabile usare Azure Macchine virtuali con un'unità SSD locale a prestazioni elevate.
Per altre informazioni sugli SKU, vedere: