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)
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.
postgres@ubuntu:/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.
postgres@ubuntu:/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.
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 postgres@ubuntu:~$ 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:postgres@ubuntu:/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/