B3. Utilisation du SGBD PostgreSQL

Généralités

PostgreSQL est un SGBD objet-relationnel. C’est une alternative aux SGBD commercialisés (tels que Oracle Database, Microsoft SQL Server etc.). Dans les grands réseaux, le SGBD PostgreSQL peut être utilisé en tant que BD externe pour Dr.Web Enterprise Security Suite.

Pour utiliser PostgreSQL en tant que BD externe, il est nécessaire d’effectuer les opérations suivantes :

1.Installer le Serveur PostgreSQL.

2.Configurer le Serveur Dr.Web conformément à l’utilisation de la base externe. Ceci peut être effectué dans le fichier de configuration ou via le Centre de gestion : dans le menu Configuration du Serveur Dr.Web, dans l’onglet Base de données.

Pour vous connecter à la BD PostgreSQL vous pouvez utiliser uniquement une authentification trust, password et MD5.

Installation et versions supportées

1.Téléchargez la dernière version du produit gratuit PostgreSQL (serveur PostgreSQL et le pilote ODBC correspondant) et surtout n’utilisez pas une version plus ancienne que 8.4.

2.Créez la base de données PostgreSQL d’une des façons suivantes :

a)Avec l’interface graphique pgAdmin.

b)Avec la commande SQL CREATE DATABASE.

La base doit être créée dans le codage UTF8.

Pour migrer vers la BD externe, consultez le paragraphe Changement de type de SGBD Dr.Web Enterprise Security Suite.

Notez également les pré-requis système pour le Serveur Dr.Web lors du travail avec la base de données externe PostgreSQL (voir le Manuel d’installation, p. Pré-requis système).

Paramètres

Lors de la configuration de la connexion à la BD PostgreSQL, les paramètres décrits dans le tableau ci-dessous sont utilisés.

PostgreSQL

Nom

Valeur par défaut

Description

host

<Socket local UNIX>

Hôte du Serveur PostgreSQL

port

 

Port du Serveur PostgreSQL ou extension du nom de fichier du socket

dbname

drwcs

Nom de la base de données

user

drwcs

Nom d’utilisateur

password

drwcs

Mot de passe

options

 

Options de débogage/traçage à envoyer au Serveur

requiressl

 

1 pour la demande de connexion SSL

0 pour ne pas demander

temp_tablespaces

 

Nom de l’espace pour les tableaux temporaires

default_transaction_isolation

 

Mode d’isolation de la transaction (voir la documentation PostgreSQL)

Pour plus d’information technique, visitez le lien http://www.postgresql.org/docs/manuals/.

Interaction entre le Serveur Dr.Web et la BD PostgreSQL via UDS

Lors de l’installation du Serveur Dr.Web et de la BD PostgreSQL sur la même machine, leur interaction peut être configurée via UDS (socket du domaine UNIX).

Pour configurer l’interaction via UDS, procédez comme suit :

1.Dans le fichier de configuration de la BD PostgreSQL postgresql.conf, indiquez le dossier suivant pour UDS :

unix_socket_directory = ’/var/run/postgresql'

2.Redémarrez PostgreSQL.

Configuration de la base de données PostgreSQL

Pour augmenter les performances lors de la gestion de la base de données, il est recommandé d’effectuer la configuration basée sur les informations reçues des manuels officiels sur la base de données.

En cas d’utilisation d’une base de données de grande taille et en cas de disponibilité des ressources de calculs correspondants, il est recommandé de configurer les paramètres suivants dans le fichier de configuration postgresql.conf :

Configuration minimale :

shared_buffers = 256Mo

temp_buffers = 64Mo

work_mem = 16Mo

Configuration avancée :

shared_buffers = 1Go

temp_buffers = 128Mo

work_mem = 32Mo

fsync = off

synchronous_commit = off

wal_sync_method = fdatasync

commit_delay = 1000

max_locks_per_transaction = 256

max_pred_locks_per_transaction = 256

Le paramètre fsync = off augmente considérablement les performances, pourtant cela peut amener à la perte complète des données en cas de coupure de courant ou d’échec du système. Il est recommandé de désactiver le paramètre fsync uniquement s’il y a une copie de sauvegarde de la base de données pour pouvoir la restaurer complètement.

 

La configuration du paramètre max_locks_per_transaction peut être utile pour l’assurance de travail continu en cas d’appel de masse aux tables de la base de données, notamment en cas de la mise à niveau de la base de données.