Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je débute sous Postgres et je me pose des questions sur le backup de bases de prod.
J'ai noté que Postgres propose 2 utilitaires pour réaliser des sauvegardes : pg_dump et pg_dumpall
Existe-t-il un moyen de réaliser avec ces outils des backups cohérents sans interrompre les alimentations ?
Merci.
Hors ligne
Bonjour,
Cohérence : oui sans problème pour les deux.
pg_dump => backup d'une base d'un cluster
pg_dumpall => backup de toutes les bases d'un cluster
Hors ligne
Que font ces utilitaires pour assurer cette cohérence, notamment lors de backup de gros volumes.
Je m'explique par exemple avec 2 tables de données, T1 table de métadonnées, T2 table de données, très volumineuse et qui possède une contrainte étrangère sur T1.
Je lance pg_dump, qui commence par sauvegarder T2.
Presque en fin de backup de T2, une ligne de T1 référencée par des données de T2 est supprimée.
Que se passe-t-il au niveau du fichier résultat et de la cohérence des données ?
Postgres assure-t-il la cohérence en bloquant temporairement les transactions ?
Merci
Hors ligne
PostgreSQL utilise MVCC, comme de nombreux autres SGBD. L'implémentation est un peu différente de celles des autres SGBD mais cela ne change pas le but de MVCC, à savoir permette aux écrivains et aux lecteurs de travailler en même temps, sans se gêner. En fait, PostgreSQL peut avoir deux versions simultanées de la même ligne, ce qui fait que la transaction qui a fait une modification voit la ligne modifiée alors que les autres voient l'ancienne ligne tant que la transaction n'a pas été commitée.
Donc pour résumer :
* pg_dump et pg_dumpall font des sauvegardes cohérentes à chaud ;
* sans bloquer les utilisateurs ;
* sauf si ces derniers cherchent à supprimer les tables (DROP TABLE) ou à les redéfinir (style ALTER TABLE pour ajouter une colonne).
Si la sauvegarde dure 5 heures, le fichier résultant contiendra le contenu de la base 5h avant.
Guillaume.
Hors ligne
Juste pour enfoncer le clou.
Donc pg_dump se base en gros sur un numéro de transaction en début d'exécution et s'y tient pour la lecture et donc la sauvegarde des lignes.
Ceci implique qu' il vaut mieux utiliser ces outils plutôt qu'une succession de select basiques redirigés dans un fichier texte (ou programme maison) qui ne tiendraient pas compte de cette information cruciale.
Merci Guillaume.
Hors ligne
Plus précisément, pg_dump déclenche un snapshot de la base, tout simplement en commençant son travail par un ordre «begin transaction isolation level repeatable read» (je crois que c'était serializable qu'il utilisait dans les versions précédentes». On a donc des données cohérentes sur l'ensemble du dump. On peut même pousser le vice dans les versions récentes (9.1 et +) à lui passer l'option «--serializable-deferrable», afin qu'il réalise le dump en «serializable», ce qui permet d'avoir non seulement un export cohérent au sens auquel vous l'entendez, mais aussi avec la notion de transactions sérialisables. http://wiki.postgresql.org/wiki/SSI/fr
Marc.
Hors ligne
En gros, oui, il vaut mieux utiliser pg_dump.
Mais ce que fait pg_dump est facilement imitable. Il suffit d'ouvrir une transaction en mode "repeatable read", de placer un verrou sur chaque table (style access share), et re faire des COPY TO. Ceci que pour les données. Reste évidemment ensuite les déclarations d'objets. Donc faisable, mais pas simple. Beaucoup plus facile (et sûr) de passer par pg_dump 
Guillaume.
Hors ligne
Super clair.
Merci à tous, je cours faire des backups !
Hors ligne
Pages : 1
