2 data-bases identiques sur même serveur, déversement entre tables

Bonjour,

Comme énoncé dans le titre, le serveur contient 2 databases identique(disons DB_1 et DB_2 crée par la requête CREATE DATABASE DB_2 WITH TEMPLATE DB_1;)
Les DB contiennent chacune 5 tables dont une table message.
La seule base reliée à l'appli est la DB_1.
Je dois faire en sorte qu'a chaque fois qu'un nouveau message arrive dans la DB_1 il soit automatiquement intégré à la table message de la DB_2.
J'ai essayé de mettre une subscription en place mais sans succès, et je n'ai pas trouvé le moyen de copier d'une table à l'autre en inter DB, le seul moyen que j'ai trouvé c'est de dump la DB_1 pour la DEPLOY sur le DB_2, mais cela nécessite une action manuelle, et surtout ça n'est pas immédiat.

PostgreSQL 10.2

(J’espère respecter les bonnes pratique il s'agit de mon 1er post sur un forum)

Merci pour l'intérêt porté à mon problème!!

Bonjour,

Pour votre problème, j'aurais dit qu'il y a plusieurs solutions.

Il y a celle où vous avez besoin d'avoir la donnée en temps réelle dans la DB2 et dans ce cas, dans la DB1 vous faites un trigger avec, dedans, un insert dans la DB2 (Je vous invite, pour voir la syntaxe, à regarder le post du forum juste en dessous du votre)

Mais un trigger, en fonction de l'importance de la table et de ces interactions, cela peut être lourd.


Soit vous n'avez pas besoin d'un temps réel à la secondes près et dans ce cas, vous faites un script externe (perl....) qui tourne toutes les 5 minutes, interroge DB1 et insères les nouveaux résultats dans DB2 (Mais un champs date serait potentiellement nécessaire)

Bisous

La solution du trigger serait effectivement la meilleure, si je comprends bien je dois intégrer ce code:

Code:

---

1 2 3 4 5

SELECT * FROM DB1.INFORMATION_SCHEMA.TABLES UNION SELECT * FROM DB2.INFORMATION_SCHEMA.TABLES

---

à mon trigger, mais je tombe sur l'erreur:
cross-database reference are not implemented

Alors que d’apres les recherches les version au dessus de 9.2 l'intègre

Si il vous faut un trigger, il faut déjà procéder aux manipulations présentent dans ce lien :

https://dba.stackexchange.com/questi...es-in-psycopg2

Ensuite, pour ce qui est du contenu du trigger la requête serait plutôt du style :
https://stackoverflow.com/questions/...select/6083444

Par contre, je reste novice en postgresql et je ne saurais malheureusement pas dire si on peut faire une insertion dans une base distante depuis la base A ou si la base distante doit interroger la base A à distance puis faire une insertion...

Les déclencheurs inter-base sont totalement merdiques dans PG car il faut passer par un DB LINK... ce qui pose des problèmes de performances, car le code du déclencheur est joué dans la transaction, ce qui rallonge la durée du blocage...

La question est : pourquoi avoir 2 fois le même base dans la même instance de PostGreSQL ??? Ceci est généralement une mauvaise pratique !

A +

J'ai pu lire que c'était effectivement une mauvaise pratique,

D'après ce que j'ai compris on extrait des données de salesforce vers notre BD, l'idée est d'extraire les données sur une base et de les répliquer sur l'autre plutot que d'extraire les meme données en double. Car les appels à salesforce sont payant selon volume.
Il s'agit d'une mauvaise pratique mais temporaire c'est juste une phase de test nécessaire et on supprime en sortie (tout ça pour ça!)

Le mieux est alors de faire une sauvegarde restauration régulière....

A +

J'ai proposé un dump, restau tous les jours l'idée a été refusée il faut du flux tendu

Alors changez de SGBDR... Pour MS SQL Server qui permet de répliquer au fil de l'eau par différents modes (7 en tout) pour ce genre de cas de figure....
En particulier la réplication transactionnelle permet de sélectionner les tables que l'on veut en les filtrant horizontalement ou verticalement et utilise pour cela le journal de transaction (pas de déclencheur) en mode asynchrone et avec le possibilité de mettre le flux en mode "fil de l'eau" (quelques ms en tout).
MS SQL Server est ce qu'utilise la plupart des sites web commerciaux comme Fnac.com, cdisount ou ventre privées et utilisent ce genre de réplication pour assurer une surface d'attaque des données plus large de manière à absorber plus de charge (autrefois fnac.com c'était plus de 50 000 connexions simultanées...)

A +

Bonjour,

Depuis PostgreSQL v10, vous avez la réplication logique qui est faite pour ça...

@+

C'est hélas encore un peu limité.

Mais c'est sur la bonne voie et s'inspire de MS SQL Server pour ce qui est de la réplication transactionnelle dans son architecture, sauf pour la répartition des données....

A +

Mais dans le cas présent, c'est très certainement suffisant...
Sauf que j'ai un doute sur la possibilité d'installer une réplication logique d'une instance sur elle-même... Habituellement, on fait ça entre deux instances différentes.

Autrement, plutôt que de se prendre la tête avec db_link, on peut facilement mettre en place un foreign data wrapper entre deux bases PostgreSQL. C'est simple à mettre en œuvre (carrément moins usine à gaz que db_link) et les performances s'améliorent de version en version...

Bref, il y a plusieurs pistes.