PostgreSQL – Accéder aux données d’une base de données d’une autre instance


Quel que soit le moteur de bases de données, il est utile de pouvoir accéder directement aux données stockées sur un autre serveur.

Nous prendrons ici un exemple simple pour illustrer le propos.

Une base de données contient par exemple des données cadastrales modifiables uniquement dans cette base de données.

Une autre base de données sur un autre serveurs peut avoir besoin de ces données cadastrales en consultation afin de présenter des services associés. Elle a besoin d’aller chercher les données présentes dans la base de données cadastrale de l’autre serveur.

L’exemple qui suit va considérer une table très simple des noms de villes qui seraient stockées dans cette base de données cadastrale.

Architecture

L’architecture qui va être construite est la suivante :

  • Serveur Linux postgresql1101 (serveur du cadastre)
    • Instance PostgreSQL écoutant sur le port 5432
      • Utilisateur cadastre
      • Base de données cadastredb appartenant à cadastre
        • Table villes
  • Serveur Linux postgresql1102 (serveur de services s’appuyant sur les données cadastrales)
    • Instance PostgreSQL écoutant sur le port 5432
      • Utilisateur cadastre
      • Base de données cadastredb appartenant à cadastre
        • pseudo-table en lien avec la table villes distante sur le serveur postgresql1101

Construction de l’architecture

Serveurs

Nous considérons que les serveurs Linux nommés postgresql1101 et postgresql1102 ont été installés et accueillent des instance de bases de données PostgreSQL en version 11.x.

Les instances sont déployées et accessibles par le réseau avec chacune leur fichier pg_hba.conf correctement configuré pour accepter des connexions entrantes sur leurs adresses de services respectives.

Création des bases de données et des utilisateurs sur les serveurs postgresql1101 et postgresql1102

Dans un premier temps il faut créer la base de données cadastredb et l’utilisateur cadastre dans chacune des deux instances :

Création du « Foreign Data Wrapper » sur postgresql1102

La création d’un lien entre deux instances se résout par l’utilisation d’un « foreign data wrapper » (que l’on pourrait traduire par « accès à des données externe) spécifique PostgreSQL (il existe de multiples foreign data wrappers selon l’accès à des données externes à l’instance que l’on souhaite réaliser). La création de l’extension ainsi que du serveur se font dans la base de données cadastredb :

Une fois le serveur créé pour le foreign data wrapper PostgreSQL, nous définissons l’utilisateur cadastre propriétaire de celui-ci. Il est impératif que le serveur appartienne à l’utilisateur cadastre afin que celui-ci puisse passer des requêtes au travers de ce serveur.

Création du lien entre utilisateur local à postgresql1102 et utilisateur distant de postgresql1101

Une fois le serveur de foreign data wrapper créé dans l’instance du serveur postgresql1102, il faut établir le lien entre l’utilisateur cadastre local à postgresql1102 et l’utilisateur distant du serveur postgresql1101. Cette opération est à réaliser dans la base de données cadastredb  :

Création et peuplement de la table des villes dans l’instance du serveur postgresql1101

Pour les besoins de l’exemple, nous créons la table des villes avec l’utilisateur cadastre dans la base de données cadastredb du serveur postgresql1101 que nous peuplons de quelques villes :

Création de la pseudo-table cadastredb_villes dans la base de données cadastredb du serveur postgresql1102

Il ne reste plus qu’à créer la pseudo-table cadastredb_villes dans la base de données cadastredb avec l’utilisateur cadastre du serveur postgresql1102 et interroger la pseudo-table afin de voir que l’on récupère bien les données provenant du serveur postgresql1101 :

!!! ATTENTION !!!, la table est mise en mode « updatable ‘false' » afin de ne pas pouvoir insérer ou modifier des données à la source.

A ce stade je n’ai pas mis en place de trigger sur la table source pour la gestion propre des séquences. Une insertion à partir du serveur postgresql1102 avec un « id » n’est pas contrôlé, d’où le mode « updatable ‘false' » choisi dans le cas présent.