Infrastructure at your Service

Open source Team

PostgreSQL : Qu’ai-je installé, Où sont mes données ?

Dans mon dernier article sur PostgreSQL, j’ai présenté l’installation du logiciel en explorant les 2 solutions suivantes, l’installation Debian et l’installation EntrepriseDB. Ces deux installations créent immédiatement un cluster de base de données, Debian nous imposant le point de stockage et EntrepriseDB nous proposant de saisir une destination. Je vous propose maintenant d’explorer ce qui a été installé sur votre disque à la mise en route de ce cluster de base et d’analyser les différences entre les deux installations.

Qu’installe-t-on ?

Avant d’examiner comment et où sont installés les binaires, je vais revenir sur l’installation à partir des sources. Cette installation, si elle est faite dans sa version courte décrite dans le fichier INSTALL des sources, met les binaires dans le répertoire /usr/local/pgsql ainsi que les librairies et documentation. Cette installation courte nous propose même de positionner les données dans un répertoire data sous /usr/local/pgsql, ceci n’est pas recommandé pour une base de données de production.

Une lecture plus approfondie montre que tout est paramétrable à l’installation avec des paramètres permettant de préciser où installer chaque éléments (binaires, librairie ..), par l’utilisation d’une ou plusieurs des options décrites ci-dessous sur la ligne de commande configure

  • –prefix=PREFIX ,
  •  –exec-prefix=EXEC-PREFIX ,
  •  –bindir=DIRECTORY etc …. ( voir le fichier INSTALL )

Exemple :

$SOURCEDIR/configure –prefix=/u00/app/postgresql/product/9.1.3 --with-perl --with-python

Du coté des binaires

On peut constater que les “packageurs” ont fait des choix cohérents avec l’organisation des binaires dans leur distribution.
La distribution SuSE installe tous les binaires dans /usr/bin/ et les librairies dans /usr/lib64/postgresql.
La distribution Debian installe tout dans /usr/lib/postgresql/version.
Nous ne pouvons pas modifier les points d’installation dans une distribution, donc pour cela nous devons installer depuis les sources ou utiliser l’installation d’EntrepriseDB.
Celle-ci nous permet de choisir le point d’installation où on retrouvera l’ensemble des binaires, librairies et scripts de gestion.

Du coté des données

Concernant les données, il y a peu de différences, Suse et Debian s’appuient sur la commande initdb. Les différences se trouvent essentiellement dans la manière de gérer l’emplacement des fichiers de configuration et des versions.
Debian et ses variantes créent le cluster en utilisant la commande pg_createcluster qui pose les fichiers de configuration dans une arborescence liée à la version et au nom du cluster dans /etc (et non pas dans le répertoire de données PGDATA), qui est par défaut dans le répertoire /usr/lib/postgresql/version/nomcluster.
EntrepriseDB installe un cluster de base de données en gardant dans le répertoire des données, les fichiers de configuration.

Du coté startup

Le script Debian de démarrage gére deux paramètres : la version et le nom du cluster. Le script de SuSE ne prévoit pas une installation multiple. EntrepriseDB crée à l’installation un script de démarrage, mais un seul par version de binaire.

La structure physique des données PostgreSQL

La structure de l’arborescence constituant le cluster est la même pour toutes les installations, on trouve une différence dans le positionnement des log applicatifs, EntrepriseDB a introduit dans l’arborescence un répertoire pg_log ou sont stockés les fichiers de log applicatif ( trace ).

drwx------ 12 postgres postgres  4096 2012-05-04 06:09 .
drwxr-xr-x  4 root     root      4096 2012-05-02 05:39 ..
drwx------  7 postgres postgres  4096 2012-05-02 10:07 base
drwx------  2 postgres postgres  4096 2012-05-04 06:09 global
drwx------  2 postgres postgres  4096 2012-05-02 05:29 pg_clog
-rw-------  1 postgres postgres  3465 2012-05-02 06:38 pg_hba.conf
-rw-------  1 postgres postgres  1631 2012-05-02 05:29 pg_ident.conf
drwxr-xr-x  2 postgres postgres  4096 2012-05-04 06:09 pg_log
drwx------  4 postgres postgres  4096 2012-05-02 05:29 pg_multixact
drwx------  2 postgres postgres  4096 2012-05-04 06:14 pg_stat_tmp
drwx------  2 postgres postgres  4096 2012-05-02 05:29 pg_subtrans
drwx------  2 postgres postgres  4096 2012-05-02 05:29 pg_tblspc
drwx------  2 postgres postgres  4096 2012-05-02 05:29 pg_twophase
-rw-------  1 postgres postgres     4 2012-05-02 05:29 PG_VERSION
drwx------  3 postgres postgres  4096 2012-05-02 10:13 pg_xlog
-rw-rw-r--  1 postgres postgres 16897 2012-05-02 05:29 postgresql.conf
-rw-------  1 postgres postgres    80 2012-05-04 06:09 postmaster.opts
-rw-------  1 postgres postgres    49 2012-05-04 06:09 postmaster.pid

 

 

Vue graphique (Debian)

Screenshot_3_1

 

Nous constatons que les distributions proposent une organisation des binaires mais pas vraiment une organisation de déploiement utilisable en production.

Il est possible de proposer une organisation proche de celle que nous proposons pour les instances Oracle et MySQL quant au positionnement des tablespaces, archives et fichiers d’administration.

Organistion du répertoire PGDATA

Comment s’organise l’instance / cluster dans ce repertoire? Un cluster est composé de répertoires et de fichiers :

  • Répertoire de données
  • Fichiers de configuration,versions et fichiers PID
  • Répertoire des Tablespaces
  • Répertoire statistiques
  • Répertoire de trace
  • Répertoire de log (wal files)

Descriptions des répertoires

Le répertoire base contient les fichiers de données (tables, index, séquences). Il contient un sous-répertoire par base de données. Dans ces répertoires, on trouve un à N fichiers par objet à stocker.
Par exemple, une table sera constituée de plusieurs fichiers :

  • Si le nom est postfixé par un ‘.1’, ‘.2’, cela montre qu’il s’agit d’un fichier d’extension Chunk de 1GB.
  • Si le nom est postfixé par _fsm, il s’agit du fichier stockant la Free Space Map
  • Si le nom est postfixé par _vm, il s’agit du fichier stockant la Visibility Map

Le répertoire “global” contient les objets qui sont “globaux” à tout le cluster, comme la table des bases de données, la table des rôles et des tablespaces. C’est en quelque sorte un micro tablespace SYSTEM au sens ORACLE.

Le répertoire pg_log contient les traces de la base de données. Il est présent ou absent en fonction du paramétrage du cluster. Les fichiers traces sont des fichiers textes contenant des alertes, des requetes sql.

Plusieurs paramètres (plus de 15 ) permettent de définir ou quoi et à quel niveau tracer.

Exemple de trace :

2012-05-02 05:39:59 PDT LOG:  autovacuum launcher started
2012-05-02 05:39:59 PDT LOG:  database system is ready to accept connections
2012-05-02 09:22:08 PDT LOG:  received SIGHUP, reloading configuration files
2012-05-02 09:38:13 PDT ERROR:  language "plpgsql" already exists
2012-05-02 09:38:13 PDT STATEMENT:  CREATE PROCEDURAL LANGUAGE plpgsql;
 
2012-05-02 09:38:17 PDT WARNING:  no privileges could be revoked for "public"
2012-05-02 09:38:18 PDT WARNING:  no privileges could be revoked for "public"
2012-05-02 09:38:18 PDT WARNING:  no privileges were granted for "public"
2012-05-02 09:38:18 PDT WARNING:  no privileges were granted for "public"
2012-05-02 10:13:21 PDT LOG:  received fast shutdown request
2012-05-02 10:13:21 PDT LOG:  aborting any active transactions
2012-05-02 10:13:21 PDT LOG:  autovacuum launcher shutting down

Les répertoires “pg_clog”, “pg_multixact”, “pg_serial”, “pg_subtrans” et “pg_twophase” contiennent des fichiers de gestion des transactions.

Le répertoire pg_tblspc

Il y est stocké uniquement des liens symboliques vers les répertoires où sont écrites réellement les données. Un cluster / instance à deux tablespaces par défaut dont les noms sont dans pg_tablespace.

postgres=# select * from pg_tablespace;
 spcname   | spcowner | spclocation | spcacl | spcoptions 
------------+----------+-------------+--------+------------
 pg_default |       10 |             |        | 
 pg_global  |       10 |             |        | 

 

 

Définir une tablespace

La creation d’un tablespace se fait par la commande suivante :

CREATE TABLESPACE CAVE location '/u02/postgresql/data/prod913/cave' ;
 CREATE TABLESPACE tp location '/u02/postgresql/data/prod913/tp' ;
 
postgres=# select * from pg_tablespace;
 spcname   | spcowner |            spclocation            | spcacl | spcoptions 
------------+----------+-----------------------------------+--------+------------
 pg_default |       10 |                                   |        | 
 pg_global  |       10 |                                   |        | 
 cave       |       10 | /u02/postgresql/data/prod913/cave |        | 
 tp         |       10 | /u02/postgresql/data/prod913/tp   |        | 


Que voyons nous au niveau du systéme de fichier ?

Dans pg_tblsp

Des liens vers les localisations que nous avons spécifiés à la création du tablespace.

[email protected]:/u01/postgresql/data/prod913/pg_tblspc$ ls -la
total 8
drwx------  2 postgres postgres 4096 2012-05-04 07:50 .
drwx------ 14 postgres postgres 4096 2012-05-04 06:09 ..
lrwxrwxrwx  1 postgres postgres   33 2012-05-04 07:49 16514 -> /u02/postgresql/data/prod913/cave
lrwxrwxrwx  1 postgres postgres   31 2012-05-04 07:50 16515 -> /u02/postgresql/data/prod913/tp

 

Et dans le répertoire de destination un répertoire ne contenant aucun objet car nous n’avons pas encore créé de table dans ce tablespace.

[email protected]:/u01/postgresql/data/prod913/pg_tblspc$ ls -la /u02/postgresql/data/prod913/cave
total 12
drwx------ 3 postgres postgres 4096 2012-05-04 07:49 .
drwxr-xr-x 4 postgres postgres 4096 2012-05-04 07:40 ..
drwx------ 2 postgres postgres 4096 2012-05-04 07:49 PG_9.1_201105231

 

Les Tablespaces dans PgAdmin3

PgAdmin nous permets de visualiser plus facilement la structure.
Screenshot_3_2

Pour comprendre ce que contiendra le répertoire de destination du tablespace nous allons créer une table.

Création d’une table dans un tablespace

Pour cela connectons nous à la base cave avec le role caviste.c cave
You are now connected to database “cave” as user “postgres”.

cave=# set role caviste ;
SET
cave=> create table reg tablespace CAVE as select * from region;
ERROR:  permission denied for tablespace cave

Il nous faut d’abord autoriser caviste à utiliser ce tablespace.

cave=> q
[email protected]:~$ psql 
psql.bin (9.1.3)
Type "help" for help.

postgres=# grant all on tablespace cave to caviste ;
GRANT
postgres=# c cave
You are now connected to database "cave" as user "postgres".
cave=# set role caviste;
SET
cave=> create table reg tablespace CAVE as select * from region;

 

Nous trouvons maintenant dans le filesystem plusieurs objets:[email protected]:/u01/postgresql/data/prod913/pg_tblspc$ ls -la /u02/postgresql/data/prod913/cave/PG_9.1_201105231/16394/

total 24
drwx------ 2 postgres postgres 4096 2012-05-04 08:05 .
drwx------ 3 postgres postgres 4096 2012-05-04 08:05 ..
-rw------- 1 postgres postgres 8192 2012-05-04 08:05 16516
-rw------- 1 postgres postgres    0 2012-05-04 08:05 16519
-rw------- 1 postgres postgres 8192 2012-05-04 08:05 16521

Ces trois objets (fichiers) correspondent à la table reg créée précèdement.

cave=# select relname, relfilenode from pg_class where relfilenode > 16515;
 relname        | relfilenode 
----------------------+-------------
 pg_toast_16516       |       16519
 pg_toast_16516_index |       16521
 reg                  |       16516

 

Du fait de sa définition, celle-ci est composée de trois fichiers dont deux liés à un stockage externe nommé “toast” Acronyme pour The Oversized-Attribute Storage Technique, utilisé pour le stockage des champs de type texte.

cave=# d reg
 Table "public.reg"
 Column  |  Type   | Modifiers 
---------+---------+-----------
 id      | integer | 
 libelle | text    | 
Tablespace: "cave"

Comme nous pouvons le voir les tablespaces sont un moyen sous postgresql de répartir les données sur des espaces disques différents.

Le répertoire pg_xlog

Il contient les journaux de transactions. Ces journaux garantissent la durabilité des données dans la base, en traçant toutes les modifications devant être effectuées AVANT les écritures en base de bgwriter. Ce sont ces fichiers que l’on garde en archive pour assurer les restore PITR ( Point In Time Restore).

Attention, ils ne sont pas particulièrement sécurisés, ce répertoire est trés important, les fichiers sont accédés séquentielement en écriture et en lecture.

Un article abordera l’importance de ces fichiers dans le processus de fiabilisation de la base.

Références documentaires

http://docs.postgresql.fr/
http://www.thegeekstuff.com/2009/04/linux-postgresql-install-and-configure-from-source/
http://www.cyberciti.biz/faq/howto-fedora-linux-install-postgresql-server/

One Comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Open source Team
Open source Team