Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous.
Nous avons réalisé hier un import sur une nouvelle base de données (Version : 9.2 sur x64).
Celle-ci est supervisée en partie avec l'outil "check_postgres".
C'est d'ailleurs au travers de ce module (je pense qu'il s'appuie sur les fonctions postgresql) que nous sommes aperçus que la taille de la base était largement surestimée (certainement le double).
Le taux d'occupation sur disque donné par la commande 'df' est par ailleurs inférieur conformément aux volumes prévus.
L'utilisation de check_postgres est nouvelle pour nous mais je n'avais jamais remarqué ce phénomène auparavant. Nous surveillons les volumes table/table avec un script basé sur la lecture de pg_class.
Je précise que le problème est reproductible sur deux versions antérieures de cette base sur 2 autres plateformes - 8.4.
-bash-4.1$ check_postgres.pl -H xyo-int -p 5433 -dbname bdcp --action=database_size --warning=10M --critical=100M
POSTGRES_DATABASE_SIZE CRITICAL: DB "bdcp" (host:xyo-int) (port=5433) bdcp: 756220651760 (704 GB) postgres: 6698104 (6541 kB) template1: 6665336 (6509 kB) template0: 6513156 (6361 kB) | time=0.03s bdcp=756220651760;10485760;104857600 postgres=6698104;10485760;104857600 template1=6665336;10485760;104857600 template0=6513156;10485760;104857600
Ici, on note une occupation disque de 355Go sur 1To:
Sys. de fichiers Taille Uti. Disp. Uti% Monté sur
...
...
/dev/mapper/vg_bdcp-lv_bdcp_base
1008G 355G 603G 38% /bdcp_base
Par contre, via la fonction postgresql ...
bdcp=# SELECT pg_size_pretty(pg_database_size('bdcp'));
pg_size_pretty
----------------
704 GB
(1 ligne)
J'ai eu, durant un moment, un doute sur la location du tablespace qui héberge la base, donc vérification:
postgres=# \db
List of tablespaces
Name | Owner | Location
------------+----------+--------------------------------
bdcp | postgres | /bdcp_base/data/pg_tblspc/bdcp
pg_default | postgres |
pg_global | postgres |
(3 rows)
Le tablespace est bien sous le même FS que la base, dont contenu dans les 355Go.
[postgres@xyo-int pg_tblspc]$ ll
total 4
lrwxrwxrwx 1 postgres postgres 30 Dec 6 2012 16437 -> /bdcp_base/data/pg_tblspc/bdcp
drwx------ 3 postgres postgres 4096 Dec 5 2012 bdcp
Si vous pouviez m'éclairer, je ne vois pas où est le lézard ....
David
Dernière modification par David (28/06/2013 10:37:04)
Hors ligne
Bonjour,
il ne faut absolument pas positionner le répertoire de destination d'un tablespace dans le répertoire $PGDATA. Le lien symbolique créé dans le répertoire pg_tblspc sert justement à faire le lien entre le répertoire externe et $PGDATA.
Il vous suffit de déplacer ce répertoire, mettre à jour le lien symbolique (base arrêtée bien entendu) et tout rentrera dans l'ordre.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour.
Quand vous dites "il ne faut pas", il s'agit juste d'éviter ce problème de comptabilité n'est ce pas ? Car je ne vois pas plus de risque à être dans cette configuration qu'avec une configuration sans TS.
D'ailleurs dans notre cas, il s'agit d'un choix de départ pour nous permettre, si jamais le volume de la base venait à s'accroitre au delà de nos estimations, de déplacer ceci sur un autre FS (que nous n'avons pas aujourd'hui).
David
Hors ligne
Disons qu'actuellement, le serveur PostgreSQL ne risque pas d'avoir une action malheureuse sur le répertoire de ce tablespace. Il n'est pas garanti que cela reste ainsi dans les versions futures.
Mais bon, de toute façon, c'est une très mauvaise pratique de mettre des fichiers dans le répertoire de données de PostgreSQL. C'est son répertoire, c'est lui qui le gère, personne d'autre ne doit y stocker des fichiers ou des répertoires.
Maintenant, à vous de savoir si vous prenez le risque ou pas. Moi, je ne le ferais pas.
Guillaume.
Hors ligne
Par exemple une version corrective de PG pourrait mettre un fichier portant le même nom qu'un fichier d'une de vos table, ce qui écraserait ce fichier et ferait perdre des information de votre base en sus de la rendre incohérente !
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Pages : 1
