Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration PostgreSQL Discussion :

Optimisation d'une commande pg_dump


Sujet :

Administration PostgreSQL

  1. #1
    Membre régulier
    Optimisation d'une commande pg_dump
    bonjour a tous

    Qui peut m'aider svp sur comment je peut optimiser mes plan des sauvegarde

    En fait le backup il prend plus que 10 heures et parfois il ne se termine pas le matin

    j'utilise la command pg_dump pour sauvegarder mes bases et je suis sous un environnement linux

    merci pour vos conseil

  2. #2
    Rédacteur

    Il n'y a pas 36000 choses à faire, car PostGreSQL est très limité en cette matière.
    1) vous pouvez tenter une sauvegarde en mode compressé, cela diminue parfois le temps de sauvegarde.
    2) vous pouvez agir au niveau du hardware. Un dump consiste à lire des pages de données sur le disque et les écrire sur un autre. Si vos disques sont en RAID 5, passez en RAID 10 (pour les fichiers de la base, comme pour la destination de la sauvegarde) avec beaucoup de disque en parallèle. Par exemple en passant d'un RAID 5 à 3 disques de part et d'autre (côté base, comme côté sauvegarde) à un RAID 10 à 4 disques, vous allez gagner 2 à 3h sur votre sauvegarde de 10 heures... Même chose en mettant du disque SSD à condition que ce soient des SSD professionnels de type "write intensive".

    Maintenant si cela ne suffit pas changez de SGBDR !
    En effet, le free coute pas cher, mais on en as pour son argent... Car c'est souvent très limité !

    Par exemple dans SQL Server les sauvegarde sont toujours multithreadées ce que ne sait pas faire PG et vous pouvez faire des sauvegardes multi destination (par exemple, envoyez la sauvegarde sur 8 disques distinct en parallèle) afin de minimiser le temps d'écriture (souvent le plus long) et enfin, vous pouvez faire des sauvegardes partielles consistantes par "storage"....
    Évidemment c'est pas le même prix.

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  3. #3
    Rédacteur/Modérateur

    Bonjour,

    Pour pouvoir vous aider plus efficacement (sans vous faire changer de SGBD ), il nous faudrait un peu plus d'informations...
    Quelle est la volumétrie de vos bases de données sur votre instance ?
    Dans quelle version de PostgreSQL est cette instance ?
    À partir de la version 9.2, il est possible de paralléliser les opérations de pg_dump avec l'option -j nb_jobs (ou --jobs=nb_jobs).

    Sinon, vous pouvez aussi envisager de passer à une sauvegarde de type PITR...
    Et je passe sur les solutions plus bas niveau, qui sont fonction de la configuration matérielle de votre serveur (snapshot en ZFS par exemple).
    Tout cela est documenté dans la doc de PostgreSQL.
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  4. #4
    Rédacteur/Modérateur

    Citation Envoyé par SQLpro Voir le message
    Par exemple dans SQL Server les sauvegarde sont toujours multithreadées ce que ne sait pas faire PG
    Raté ! Depuis la version 9.2 de PostgreSQL, avec pg_dump, c'est possible...
    Ça date quand même de 2012...
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  5. #5
    Rédacteur

    Citation Envoyé par ced Voir le message
    Raté ! Depuis la version 9.2 de PostgreSQL, avec pg_dump, c'est possible...
    Ça date quand même de 2012...
    C'est un multithread de job pas de la sauvegarde de chaque base.
    Autrement dit si vous avez 10 bases à sauvegarder, ce paramètre permet d'envoyer 10 threads pour exécuter les 10 sauvegardes distincte simultanément.
    mais la sauvegarde d'une base reste toujours mono thread alors que dans oracle ou SQL Server elle est multithreadé pour une même base (dans Oracle il n'y avait d'ailleurs qu'une seule base par instance jusaqu'à la version 12c.) en fonction des "storages" existants et des destinations en face.
    Pour vous votre information personelle au sujet des sauvegardes de SQL Server :
    https://www.sqlbackuprestore.com/bac...sandwrites.htm
    https://www.brentozar.com/archive/20...ce-of-backups/

    Au lieu de systématiquement défendre bêtement PostGreSQL sans regardez ce que font les autres SGBDR, vous devriez vous cultiver et lire ce que fait la concurrence.

    Pour info ce multithreadage des sauvegardes existe depuis la version 7 de SQL Server (1998) soit 20ans... Conclusion PostGreSQL à plus de 20 ans de retard sur ce sujet qui n'est toujours pas à l'horizon de la R&D de PG...

    Et comme je le dis souvent PG n'est pas fait pour gérer de grosses bases....

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  6. #6
    Rédacteur/Modérateur

    Citation Envoyé par SQLpro Voir le message
    C'est un multithread de job pas de la sauvegarde de chaque base.
    Et donc, ça reste de la parallélisation de tâches. Donc, nous sommes bien d'accord...
    Ensuite, tout dépend de définition qu'on donne au terme "multithread".

    Citation Envoyé par SQLpro Voir le message
    Autrement dit si vous avez 10 bases à sauvegarder, ce paramètre permet d'envoyer 10 threads pour exécuter les 10 sauvegardes distincte simultanément.
    Ça, c'est plus lié à l'architecture de l'OS... La notion de thread est plus propre à Windows. Sous Linux, ce sont des process, et plusieurs process de sauvegarde peuvent très bien être lancés en parallèle... Un même process peut faire l'objet de plusieurs "jobs", ce qui tend à en réduire le temps d'exécution (problème rencontré dans le cas de la présente discussion).

    Citation Envoyé par SQLpro Voir le message
    mais la sauvegarde d'une base reste toujours mono thread
    Encore une fois, tout dépend de la définition d'un thread et de l'OS dans lequel on se trouve.

    Citation Envoyé par SQLpro Voir le message
    Au lieu de systématiquement défendre bêtement PostGreSQL sans regardez ce que font les autres SGBDR, vous devriez vous cultiver et lire ce que fait la concurrence.
    Pure conjecture et procès d'intention... Je ne défends pas PostgreSQL, je tente de rétablir un raccourci rapide de votre part.

    Citation Envoyé par SQLpro Voir le message
    Et comme je le dis souvent PG n'est pas fait pour gérer de grosses bases...
    Encore une fois, on est là dans le jugement de valeurs... Qu'est-ce qu'on entend par "grosses bases" ? On ne connait pas la volumétrie de la base qui pose problème dans le cas présent.

    Quoi qu'il en soit, l'objet de la discussion est bien d'aider un membre à résoudre un problème qu'il rencontre avec les outils dont il dispose.

    A +
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  7. #7
    Membre régulier
    quoteBonjour,

    Pour pouvoir vous aider plus efficacement (sans vous faire changer de SGBD ), il nous faudrait un peu plus d'informations...
    Quelle est la volumétrie de vos bases de données sur votre instance ?
    Dans quelle version de PostgreSQL est cette instance ?
    À partir de la version 9.2, il est possible de paralléliser les opérations de pg_dump avec l'option -j nb_jobs (ou --jobs=nb_jobs).

    Sinon, vous pouvez aussi envisager de passer à une sauvegarde de type PITR...
    Et je passe sur les solutions plus bas niveau, qui sont fonction de la configuration matérielle de votre serveur (snapshot en ZFS par exemple).
    Tout cela est documenté dans la doc de PostgreSQL

    oui je suis avec la version 9.1 avec des bases de données de 1.55 Tera

    le problème avec le sauvegarde PITR si demain tu as une besoin de restauration d'une telle base vous été obliger de restaurer Toutes les bases

  8. #8
    Rédacteur/Modérateur

    Il va falloir songer à monter de version. La version 9.1 n'est plus supportée depuis bientôt deux ans.
    Et du coup, en montant de version, vous pourrez paralléliser les dumps.

    Pour l'instant, c'est difficile d'améliorer les choses. Est-ce que vos sauvegardes sont compressées ? Si oui, de quelle façon ? Avec pg_dump ou avec un outil externe de compression (type gzip) ?
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  9. #9
    Membre régulier
    Citation Envoyé par ced Voir le message
    Il va falloir songer à monter de version. La version 9.1 n'est plus supportée depuis bientôt deux ans.
    Et du coup, en montant de version, vous pourrez paralléliser les dumps.

    Pour l'instant, c'est difficile d'améliorer les choses. Est-ce que vos sauvegardes sont compressées ? Si oui, de quelle façon ? Avec pg_dump ou avec un outil externe de compression (type gzip) ?

    Mois j'utilise perssonellement l'option
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    pg_dump -Fc
    qui me permez d'avoir le format compressé par défaut

    Si je procéde a une modification vers
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    pg_dump dbname | gzip > filename.gz
    y 'aura til de gain par rapprt a la formta -Fc

    merci

  10. #10
    Rédacteur/Modérateur

    C'est possible, il faut tester, cela dépend des configurations.
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça