PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 15.8 » Administration du serveur » Configuration du serveur et mise en place » Lancer le serveur de bases de données

19.3. Lancer le serveur de bases de données

Avant qu'une personne ait accès à la base de données, vous devez démarrer le serveur de bases de données. Le programme serveur est appelé postgres.

Si vous utilisez une version pré-packagé de PostgreSQL, il inclut pratiquement à coup sûr de quoi exécuter le serveur en tâche de fond suivant les conventions de votre système d'exploitation. Utiliser l'infrastructure du paquet pour démarrer le serveur demande beaucoup moins d'efforts qu'essayer de le faire soi-même. Consultez la documentation du paquet pour les détails.

La façon brute pour démarrer le serveur manuellement est d'invoquer postgres directement, en précisant l'emplacement du répertoire des données avec l'option -D, par exemple :

$ postgres -D /usr/local/pgsql/data

qui laissera le serveur s'exécuter en avant plan. Pour cela, vous devez être connecté en utilisant le compte de l'utilisateur PostgreSQL. Sans l'option -d, le serveur essaiera d'utiliser le répertoire de données nommé par la variable d'environnement pgdata. Si cette variable ne le fournit pas non plus, le lancement échouera.

Habituellement, il est préférable de lancer postgres en tâche de fond. Pour cela, utilisez la syntaxe shell Unix habituelle :

$ postgres -D /usr/local/pgsql/data >journaux_trace 2>&1 &

Il est important de sauvegarder les sorties stdout et stderr du serveur quelque part, comme montré ci-dessus. Cela vous aidera dans des buts d'audits ou pour diagnostiquer des problèmes (voir la Section 25.3 pour une discussion plus détaillée de la gestion de journaux de trace).

Le programme postgres prend aussi un certain nombre d'autres options en ligne de commande. Pour plus d'informations, voir la page de référence postmaster ainsi que le Chapitre 20 ci-dessous.

Cette syntaxe shell peut rapidement devenir ennuyante. Donc, le programme d'emballage pg_ctl est fourni pour simplifier certaines tâches. Par exemple :

pg_ctl start -l journaux_trace

lancera le serveur en tâche de fond et placera les sorties dans le journal de trace indiqué. L'option -d a la même signification ici que pour postgres. pg_ctl est aussi capable d'arrêter le serveur.

Normalement, vous lancerez le serveur de bases de données lors du démarrage de l'ordinateur . Les scripts de lancement automatique sont spécifiques au système d'exploitation. Quelques scripts d'exemple sont distribués avec PostgreSQL dans le répertoire contrib/start-scripts. En installer un nécessitera les droits de root.

Différents systèmes ont différentes conventions pour lancer les démons au démarrage. La plupart des systèmes ont un fichier /etc/rc.local ou /etc/rc.d/rc.local. D'autres utilisent les répertoires init.d ou rc.d. Quoi que vous fassiez, le serveur doit être exécuté par le compte utilisateur PostgreSQL et non pas par root ou tout autre utilisateur. Donc, vous devriez probablement former vos commandes en utilisant su postgres -c '...' . Par exemple :

su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'

Voici quelques suggestions supplémentaires par système d'exploitation (dans chaque cas, assurez-vous d'utiliser le bon répertoire d'installation et le bon nom de l'utilisateur où nous montrons des valeurs génériques).

  • Pour freebsd, regardez le fichier contrib/start-scripts/freebsd du répertoire des sources de PostgreSQL.

  • Sur openbsd, ajoutez les lignes suivantes à votre fichier /etc/rc.local :

    if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
        su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data'
        echo -n ' PostgreSQL'
    fi

  • Sur les systèmes linux, soit vous ajoutez

    /usr/local/pgsql/bin/pg_ctl start -l journaux_trace -D /usr/local/pgsql/data

    à /etc/rc.d/rc.local ou /etc/rc.local soit vous jetez un œil à contrib/start-scripts/linux dans le répertoire des sources de PostgreSQL.

    Si vous utilisez systemd, vous pouvez utiliser le fichier de service (par exemple dans /etc/systemd/system/postgresql.service) :

    [Unit]
    Description=PostgreSQL database server
    Documentation=man:postgres(1)
    After=network-online.target
    Wants=network-online.target
    
    [Service]
    Type=notify
    User=postgres
    ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
    ExecReload=/bin/kill -HUP $MAINPID
    KillMode=mixed
    KillSignal=SIGINT
    TimeoutSec=infinity
    
    [Install]
    WantedBy=multi-user.target
       

    Utiliser Type=notify nécessite que le binaire du serveur soit construit avec configure --with-systemd.

    Faites bien attention au paramètre de délai. systemd a un délai par défaut de 90 secondes (au moment de l'écriture de cette documentation) et tuera un processus qui n'indique pas sa disponibilité après ce délai. Cependant, un serveur PostgreSQL qui aurait à réaliser une restauration suite à un crash pourrait prendre beaucoup plus de temps à démarrer. La valeur suggérée, infinity, désactive ce comportement.

  • Sur netbsd, vous pouvez utiliser les scripts de lancement de freebsd ou de linux suivant vos préférences.

  • Sur solaris, créez un fichier appelé /etc/init.d/PostgreSQL et contenant la ligne suivante :

    su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l journaux_trace -D /usr/local/pgsql/data"

    Puis, créez un lien symbolique vers lui dans /etc/rc3.d de nom s99PostgreSQL.

Tant que le serveur est lancé, son pid est stocké dans le fichier postmaster.pid du répertoire de données. C'est utilisé pour empêcher plusieurs instances du serveur d'être exécutées dans le même répertoire de données et peut aussi être utilisé pour arrêter le processus le serveur.

19.3.1. Échecs de lancement

Il existe de nombreuses raisons habituelles pour lesquelles le serveur échouerait au lancement. Vérifiez le journal des traces du serveur ou lancez-le manuellement (sans redirection des sorties standard et d'erreur) et regardez les messages d'erreurs qui apparaissent. Nous en expliquons certains ci-dessous parmi les messages d'erreurs les plus communs.

LOG:  could not bind IPv4 address "127.0.0.1": Address already in use
HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

Ceci signifie seulement ce que cela suggère : vous avez essayé de lancer un autre serveur sur le même port où un autre est en cours d'exécution. Néanmoins, si le message d'erreur du noyau n'est pas address already in use ou une quelconque variante, il pourrait y avoir un autre problème. Par exemple, essayer de lancer un serveur sur un numéro de port réservé pourrait avoir ce résultat :

$ postgres -p 666
LOG:  could not bind IPv4 address "127.0.0.1": Permission denied
HINT:  Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

Un message du type

FATAL:  could not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=5440001, size=4011376640, 03600).

signifie probablement que les limites de votre noyau sur la taille de la mémoire partagée est plus petite que l'aire de fonctionnement que PostgreSQL essaie de créer (4011376640 octets dans cet exemple). Ceci n'est susceptible de se produire uniquement si shared_memory_type a été affecté à sysv. Dans ce cas, vous pouvez essayer de lancer le serveur avec un nombre de tampons plus petit que la normale (shared_buffers) ou vous pouvez reconfigurer votre noyau pour accroître la taille de mémoire partagée autorisée. Vous pourriez voir aussi ce message en essayant d'exécuter plusieurs serveurs sur la même machine si le total de l'espace qu'ils requièrent dépasse la limite du noyau.

Une erreur du type

FATAL:  could not create semaphores: No space left on device
DETAIL:  Failed system call was semget(5440126, 17, 03600).

ne signifie pas qu'il vous manque de l'espace disque. Elle signifie que la limite de votre noyau sur le nombre de sémaphores system v est inférieure au nombre que PostgreSQL veut créer. Comme ci-dessus, vous pouvez contourner le problème en lançant le serveur avec un nombre réduit de connexions autorisées (max_connections) mais vous voudrez éventuellement augmenter la limite du noyau.

Des détails sur la configuration des capacités IPC System V sont donnés dans la Section 19.4.1.

19.3.2. Problèmes de connexion du client

Bien que les conditions d'erreurs possibles du côté client sont assez variées et dépendantes de l'application, certaines pourraient être en relation direct avec la façon dont le serveur a été lancé. Les conditions autres que celles montrées ici devraient être documentées avec l'application client respective.

psql: error: connection to server at "server.joe.com" (123.123.123.123), port 5432 failed: Connection refused
        Is the server running on that host and accepting TCP/IP connections?

Ceci est l'échec générique « je n'ai pas trouvé de serveur à qui parler ». Cela ressemble au message ci-dessus lorsqu'une connexion TCP/IP est tentée. Une erreur commune est d'oublier de configurer le serveur pour qu'il autorise les connexions TCP/IP.

Autrement, vous obtiendrez ceci en essayant une communication de type socket de domaine Unix vers un serveur local :

psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?

Si le serveur est vraiment en cours d'exécution, vérifiez que le chemin du socket pour le client (ici /tmp) est en accord avec le paramètre unix_socket_directories du serveur.

Un message d'échec de connexion affiche toujours l'adresse du serveur ou le chemin de la socket, ce qui est utile pour vérifier que le client est en train de se connecter au bon endroit. Si aucun serveur n'est en écoute ici, le message d'erreur du noyau sera typiquement soit connection refused soit no such file or directory, comme ce qui est illustré (il est important de réaliser que connection refused, dans ce contexte, ne signifie pas que le serveur a obtenu une demande de connexion et l'a refusé. Ce cas produira un message différent comme indiqué dans la Section 21.15). D'autres messages d'erreurs tel que connection timed out pourraient indiquer des problèmes plus fondamentaux comme un manque de connexion réseau, ou un pare-feu bloquant la connexion.