blocage pg_dump et pg_dump_all

mich30 · 27/05/2011 09:34:07

Quand je lances des pg_dump, et surtout pg_dump_all, ça bloque toutes modifications des tables tant que l'opération n'est pas terminée.
merci de confirmer est ce normal ?

Marc Cousin · 27/05/2011 09:40:05

Ce n'est ni vrai, ni normal.

mich30 · 30/05/2011 09:45:48

ca bloque sur les create table
genre create table ma table as select ...
Si ce n'est pas normal existe t'il un parametre de
configuration
merci!

Marc Cousin · 30/05/2011 11:37:53

Ah, ok.
Oui, effectivement, pg_dump bloque les modifications de structure des tables pendant son exécution. Comme n'importe quel SELECT d'ailleurs. Ce n'est pas désactivable.

mich30 · 30/05/2011 11:55:29

comment puis je contourner ???
existe t'il une commande qui annule toutes les transactions
(requete en cours des utilisateurs )
de tous le utilisateurs afin que le pg_dump puisse se lancer automatiquement ?

Comment font les autres utilisateurs qui sauvegarde a 3 heures du matin mais
un utilisateur a lancer une une grosse requete qui est en train de tourner ?
merci

Dernière modification par mich30 (30/05/2011 11:56:43)

Marc Cousin · 30/05/2011 15:01:37

Si la grosse requête ne fait que lire des données ou en écrire, ils n'ont pas de problème.

Si ils lancent des scripts de réorganisation de base en même temps que le dump, ils sont coincés. Ce n'est pas le dump le problème, c'est les modifications de schéma (alter table, vacuum full, reindex…)

mich30 · 30/05/2011 15:57:21

1)

donc il vaut mieux faire

create table t1

puis faire des inserts de la grosse table vers t1

plutot
que
create table matablet1 as select * from grossetable

2)
j'ai le autovacum a on ce n'est pas genant ?

merci

Marc Cousin · 30/05/2011 16:05:58

1) si c'est en deux transactions séparées oui, vous tiendrez des verrous moins longtemps (seulement pendant la durée du create table)
2) Non, l'autovacuum libère ses verrous et arrête ses traitements si il se rend compte qu'il gêne.

mich30 · 30/05/2011 16:08:12

ok merci

SQLpro · 31/05/2011 15:30:22

mich30 a écrit :

Comment font les autres utilisateurs qui sauvegarde a 3 heures du matin mais
un utilisateur a lancer une une grosse requete qui est en train de tourner ?

La sauvegarde à chaud est quelque chose de complexe. Par exemple elle n'est toujours pas implémentée sous MySQL.
Pour vous donner un exemple de ce que fais SQL Server qui possède un des algo les plus avancés sur le sujet, il procède de cette manière :
1) avant de démarrer la sauvegarde il met une marque dans le journal de transaction.
2) il sauvegarde les pages de données de manière binaire, sans aucun verrouillage en commençant par les pages les moins modifiées depuis les fichiers et en finissant par les pages les plus modifiées depuis la mémoire (pour calculer cela il conserve des statistiques en mémoire pendant toute la durée de vie du serveur, stats qui sont remise à zéro à chaque sauvegarde)
Les pages vides ou supprimées sont ignorées.
3) il sauvegarde le journal des transactions, depuis la marque qu'il a fait et jusqu'à la fin du journal.

Ainsi, aucun verrouillage ne ralentis la production. Seule les ressources utilisées par le processus de sauvegarde ralentissent globalement le serveur, et notamment les écritures disques des fichiers de sauvegardes.
Comme dans SQL Serveer les CREATE TABLE, ALTER et DROP sont journalisés, aucune transaction n'est perturbée !

Lors de la restaurations, le processus est le suivant :
1) recréation des fichiers originaux vide.
2) lecture des pages et replacement des pages dans les fichiers
3) lecture du journal de transaction et application des transactions validées.

Hélas, PG a encore du boulot pour arriver à ce niveau... Mais comparer à MySQL, y'a pas photo....

A +

Dernière modification par SQLpro (31/05/2011 15:38:40)

gilles · 31/05/2011 16:03:26

Wouah ! SQL serveur est vraiment impressionnant, c'est vrai que PostgreSQL c'est un peu limite des fois, hein. Moi je sais pas ce que t'en pense SQLPro mais le mieux se serait d'aller sur un forum dédié à SQL Serveur, parce que là y a plus rien a dire, moi je suis convaincu. En plus ici ils comprennent rien.

Aller à bientôt sur http://forum.sqlserver.fr !

Sérieux ca commence à être gonflant.

Dernière modification par gilles (31/05/2011 16:05:16)

SQLpro · 31/05/2011 17:07:28

Je ne voit pas ce qu'il y a de gonflant à comparer des techniques mise en œuvre. Chacune à ses limites, ses avantages et inconvénients.
Il s'agit juste de replacer l'outil à son usage et comprendre ce que font les autres permet de choisir ce qu'il y a de mieux.
Par exemple si la base de données doit en permanence subir des ordres DDL la sauvegarde PG sera un point bloquant.
Il faut donc, soit déporter ses commandes DDL à un moment hors sauvegarde, soit changer de SGBDR.
La plupart des SGBDR, y compris PG et SQL Server s'inspirent de réalisation déjà existantes pour s'améliorer...
Il n'y a donc aucune honte à montrer cela. Ce n'est pas du dénigrement, comme certains intégristes voudrait le faire croire.

PG a fait de grand progrès depuis que je le connais (c'est à dire depuis 1997 - à l'époque PostGres95)...
Et aujourd'hui, depuis la V9, c'est un SGBDR que je recommande pour un grande partie des applications de gestion non critique (c'est à dire la majeure partie)...

Par exemple dans ce post, j'ai commis le crime de défendre PG... http://www.developpez.net/forums/d10844 … se-donnee/

A +

orgrim · 31/05/2011 17:34:49

Salut,

Je pense que l'objet initial du thread n'est pas de comparer PostgreSQL avec d'autres sur la sauvegarde, mais plutot d'aider mich30 à faire réussir sa sauvegarde. Ce qui me fait dire que vos réponses sont un peu hors sujet, comme souvent, et je comprends la fatigue de gilles.

Si vous tenez vraiment à convertir des utilisateurs à SQL Server, bon courage, la plupart des membres actives ici sont de fervent(e)s défenseur(e)s du Logiciel Libre et de l'Open Source. Dans ce cas, ouvrez des threads séparés plutôt que de perturber les fils existants.

Merci d'avance.

PS: tiens, la sauvegarde que vous décrivez ressemble beaucoup à la sauvegarde PITR de PostgreSQL (http://docs.postgresql.fr/9.0/continuous-archiving.html), si vous voulez continuer sur ce sujet, lancez un fil à côté

gilles · 31/05/2011 18:01:03

Petite précision historique; en 1997 il s'agissait déjà de PostgreSQL 6.0, enfin ca n'a pas été trop dur vu qu'on est passé directement de la version 1.x a la version 6.x :-) C'est vrai qu'à l'époque on était pas nombreux.

SQLpro · 01/06/2011 19:32:13

orgrim a écrit :

PS: tiens, la sauvegarde que vous décrivez ressemble beaucoup à la sauvegarde PITR de PostgreSQL (http://docs.postgresql.fr/9.0/continuous-archiving.html), si vous voulez continuer sur ce sujet, lancez un fil à côté

C'est normal, les mécanismes des journalisation des transactions des SGBDR sont tous basés sur le même algo de base : ARIES (sauf MySQL), suite aux travaux de Gray et Bernstein sur le sujet, vers la fin des années 70...
A lire :
http://portal.acm.org/citation.cfm?id=128770
http://www.cs.uwaterloo.ca/~david/cs448/aries-mohan.pdf

A +

orgrim · 03/06/2011 09:53:18

*BLONG* Raté... Un autre fil, c'est pourtant pas dur ! De mon coté je m'arrete là sur ce fil, vu votre mauvaise volonté et votre attitude.

#1 27/05/2011 09:34:07

blocage pg_dump et pg_dump_all

#2 27/05/2011 09:40:05

Re : blocage pg_dump et pg_dump_all

#3 30/05/2011 09:45:48

Re : blocage pg_dump et pg_dump_all

#4 30/05/2011 11:37:53

Re : blocage pg_dump et pg_dump_all

#5 30/05/2011 11:55:29

Re : blocage pg_dump et pg_dump_all

#6 30/05/2011 15:01:37

Re : blocage pg_dump et pg_dump_all

#7 30/05/2011 15:57:21

Re : blocage pg_dump et pg_dump_all

#8 30/05/2011 16:05:58

Re : blocage pg_dump et pg_dump_all

#9 30/05/2011 16:08:12

Re : blocage pg_dump et pg_dump_all

#10 31/05/2011 15:30:22

Re : blocage pg_dump et pg_dump_all

#11 31/05/2011 16:03:26

Re : blocage pg_dump et pg_dump_all

#12 31/05/2011 17:07:28

Re : blocage pg_dump et pg_dump_all

#13 31/05/2011 17:34:49

Re : blocage pg_dump et pg_dump_all

#14 31/05/2011 18:01:03

Re : blocage pg_dump et pg_dump_all

#15 01/06/2011 19:32:13

Re : blocage pg_dump et pg_dump_all

#16 03/06/2011 09:53:18

Re : blocage pg_dump et pg_dump_all

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux