Vous n'êtes pas identifié(e).
Bonjour à tous, j'ai été confronté à une base de données qui journalisait énormément (plus de 100 Go de log par jours) et pour rien, car l'application pouvait très bien se contenter d'une restauration à j-1.
Nous étions contraint d'activer la journalisation uniquement pour faire des sauvegardes à chaud, la base ne pouvant pas être arrêtée.
J'ai donc réfléchi à comment activer la journalisation uniquement pendant la phase de pg_start_backup et pg_stop_backup mais comme vous le savez déjà, il faut redémarrer l'instance pour pouvoir prendre en compte le paramètre "archive_mode".
J'ai donc crée un fichier tag "backup_in_progress" avant chaque backup, ce qui me permet d'archiver les journaux qui seront strictement nécessaire à la restauration de l'instance. Une fois le backup des datas terminé, je supprime le fichier tag et je sauvegarde mes logs.
Ca se traduit par ça dans ma ligne de commande d'archivage :
archive_command = 'test -f /var/lib/pgsql/var/log/backup_in_progress && gzip < %p > /var/lib/pgsql/var/journaux/%f || cp %p /dev/null '
J'ai fait des tests de sauvegardes restaurations, ça fonctionne très bien pour une restauration "à la date du dernier backup".
J'aimerais généraliser cette solution pour les mêmes cas de figures (base avec des besoins de haute dispo mais sans besoin de journalisation). On retrouverait ainsi le mode de fonctionnement de SQL Server qui permet de faire de la sauvegarde à chaud sans journaliser les logs.
Est ce que vous voyez des effets de bords potentielles auquel je n'aurais pas pensé ?
Hors ligne
Il n'est en effet pas possible de modifier archive_mode sans redémarrer le serveur. Par contre, il est possible de le faire pour archive_command. Si vous remplacez l'archive_command par 'true' par exemple, PostgreSQL pensera avoir archivé le journal de transactions alors que non.
Ceci étant dit, pourquoi ne pas utiliser pg_dump dans ce cas ? ce serait plus simple.
Guillaume.
Hors ligne
Ah oui, effectivement, si l'on peut changer archive command à chaud ... c'est encore plus simple !! Ca ne m'était même pas venu à l'esprit ! Je vais tester ça.
Quand au pg_dump, l'idée est d’avoir un seul mode de sauvegarde (et de restauration) pour toutes nos bases, surtout celle avec une grosse volumétrie. Mais si il n'en tenait qu'à moi ...
Hors ligne
Ça paraît logique de n'avoir qu'une seule méthode de sauvegarde. Beaucoup plus simple et moins stressant quand une base doit être restaurée en urgence.
Une autre solution à votre problème serait d'utiliser pg_basebackup avec l'option -x.
Guillaume.
Hors ligne
En fait, nous passons par un logiciel de sauvegarde (Simpana de Comvault) et c'est lui qui doit sauvegarder les données pour pouvoir bénéficier des avantages de la déduplication. Donc nous devons passer par pg_start_backup et pg_stop_backup.
Pour les modes de sauvegardes et restaurations, je suis d'accord mais il nous manquait la possibilité de faire des sauvegardes à chaud sans journalisation.
Dernière modification par philwood (25/09/2017 11:23:06)
Hors ligne
