Condividi tramite

Procedure consigliate per pg_dump e pg_restore per Database di Azure per PostgreSQL - Server flessibile

  • Articolo

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_connections valore 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 al 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:

Condividere i suggerimenti e i bug con il team del prodotto Database di Azure per PostgreSQL.

Contenuto correlato