Come rendere pg_dump less risorse avidi

Ho configurato cron per invocare pg_dump su base giornaliera utilizzando la seguente regola:

# xyz database backups: 00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz 

Fondamentalmente, funziona. Il database cresce relativamente veloce ed esponenziale (tuttavia l'esponente non è molto grande). Attualmente il dump di gzipping dura circa 160 MB. Quando il database viene scaricato, il sistema inizia a eseguire la scansione. La media di carico che ho visto usando il command top era di circa 200, 200, 180 . Fondamentalmente il server è difficilmente reattivo.

  • Il calcolo di IOPS per ZFS RAIDZ è diverso da quello che calcola IOPS per RAID5 e RAID6?
  • Errore vuoto per l'avvio quasi-default di PostgreSQL
  • Problema di performance del file server di Cluster di failover con Windows Server 2016
  • Dimensionamento dei dischi di journal con volume di parità di Microsoft Storage Spaces
  • Quale router scegliere tra un 3620 e un 3640 per funzionare con gli switch di serie 3500?
  • Prestazioni del filesystem per i volumi crittografati LUKS?
  • La prima domanda è come determinare where si trova il collo di bottiglia. È la scarsa prestazione causata da operazioni di I / O pesanti? È causato da problemi di block del tavolo? Forse è un problema di memory? L'output del command pg_dump viene inviato al command gzip . È sequenziale, cioè l'integer dump viene inserito nella memory (problema di scambio?) E poi compresso o concorrente (cioè gzip comprime ciò che ottiene e attende di più)? Può essere causato da un altro fattore?

    La seconda domanda è come rendere l'operazione di dumping less invadente per le principali funzioni del sistema. Per quanto riguarda le cose, il deposito non può richiedere troppo tempo a causa dell'integrità del database. Ci sono blocchi di scrittura a table, ecc. Cosa posso fare per limitare i problemi (o ritardarlo, considerando la crescita del database).

    La terza domanda : è già giunto il momento di conoscere configurazioni di database più avanzate? Il sistema funziona bene quando i backup del database non vengono eseguiti, ma forse il problema di dumping è un primo sintomo di problemi in arrivo?

  • Questa è una valida strategia di backup per MongoDB?
  • Un backup completo non riuscito invalidare i backup del log delle transactions future?
  • pg_restore che richiede molto più tempo di pg_dump
  • Criterio di conservazione del backup di SQL Server
  • Opzioni di backup del cloudserver Rackspace
  • Come faccio a creare un utente MySQL di sola lettura per scopi di backup con mysqldump?
  • 2 Solutions collect form web for “Come rendere pg_dump less risorse avidi”

    Wow. Sorprendente numero di domande. Cercherò di affrontare alcuni, ma questa risposta non è ancora completa.

    come determinare where si trova il collo di bottiglia.

    Utilizza prima la parte top per vedere cosa succede durante il dump. Controllare l'utilizzo della CPU, lo stato del process. D significa "in attesa di I / O".

    È la scarsa prestazione causata da operazioni di I / O pesanti?

    Sì, molto probabilmente.

    È causato da problemi di block del tavolo?

    Può essere. è ansible utilizzare la vista del sistema pg_stat_activity per vedere cosa sta succedendo in postgres durante il dump.

    Forse è un problema di memory?

    Molto spiacevole.

    L'output del command pg_dump viene inviato al command gzip. È sequenziale, ossia l'integer dump viene inserito nella memory (problema di scambio?)

    No. gzip è un compressore di blocchi che funziona in modalità stream, non tiene tutti gli input in memory.

    e quindi compresso o concorrente (cioè gzip comprime ciò che ottiene e attende di più)?

    Sì, blocca block per block, uscisce e attende di più.

    Può essere causato da un altro fattore?

    Sì.

    Per quanto riguarda le cose, il deposito non può richiedere troppo tempo a causa dell'integrità del database. Ci sono blocchi di scrittura a table, ecc. Cosa posso fare per limitare i problemi (o ritardarlo, considerando la crescita del database).

    La durata della discarica non ha alcun effetto sull'integrità dump. L'integrità è assicurata usando una transazione con livello di isolamento di lettura ripetibile da tutti i processi pg_dump. Non ci sono serrature per la scrittura del tavolo.

    È già giunto il momento di conoscere configurazioni di database più avanzate? Il sistema funziona bene quando i backup del database non vengono eseguiti, ma forse il problema di dumping è un primo sintomo di problemi in arrivo?

    Mai troppo tardi. Inizia con http://wiki.postgresql.org/wiki/Performance_Optimization .

    Vi consiglio di esaminare l' archiviazione continua di postgresql. Ecco i vantaggi rispetto all'utilizzo di pg_dump:

    1. Non c'è bisogno di fare un backup completo each volta. Un primo backup è abbastanza all'inizio, ma è consigliabile avere un backup completo, ad esempio, each giorno.
    2. Molto più veloce da ripristinare quando il DB cresce in size.
    3. La capacità di ripristinare in un altro punto (ripristino in tempo reale).
    4. Verrà eseguito il backup incrementale each ora (30 minuti circa). Questo può essere configurato e dipende anche dall'attività di aggiornamento.

    Tuttavia, ci sono alcuni inconvenienti (che in molti casi potrebbero non essere un problema):

    1. Di solito è necessario più spazio perché questi sono backup binari. La cartella DB può essere compressa.
    2. Non è ansible ripristinarli su un'architettura diversa (dati binari).
    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.