Re: Connecteur mysql_fdw : problème de "cache"

Bonjour,

Je vous remercie pour votre réponse mais le soucis n'est pas seulement la conversion de structure / la réinsertion des données mais bien la réécriture des requêtes de nos applicatifs.
Je ne rentrerai pas plus dans les détails mais il n'est pas concevable pour nous de nous arrêter X jours / semaines / mois pour ne faire QUE la migration PostGreSQL : pendant que ce projet va vivre, notre business continue.
D'ailleurs, si mon soucis était la conversion de la structure des tables, je n'envisagerai pas les connecteurs FDW puisqu'il faut créer des FOREIGN TABLE.

Du coup, mes questions sur les FDW restent pertinentes.
Est-ce que vous les avez déjà utilisés et si oui est-ce que vous avez été confrontés à mes difficultés ?

Cordialement,
Bertrand ROBERT

De: "bernard schoenacker" <bernard(dot)schoenacker(at)free(dot)fr>
À: "b robert" <b(dot)robert(at)kifaisa(dot)com>
Cc: "pgsql-fr-generale" <pgsql-fr-generale(at)postgresql(dot)org>
Envoyé: Mercredi 14 Décembre 2016 16:20:31
Objet: Re: [pgsql-fr-generale] Connecteur mysql_fdw : problème de "cache"

On Wed, 14 Dec 2016 15:20:23 +0100 (CET)
Bertrand ROBERT <b(dot)robert(at)kifaisa(dot)com> wrote:

> Bonjour,
>
> Je travaille sur une potentielle migration de MySQL à PostGreSQL.
> Dans les solutions envisagées, nous regardons du côté du connecteur
> mysql_fdw pour nous aider à migrer en douceur.
>
> Voici mon jeu de test :
> - côté MySQL, j'ai une table "matable" qui contient deux colonnes
> (monid, mavaleur) et des données toutes simples : '1', '2.129'
> '2', '2.129'
> '3', '2.129'
> etc
>
> - côté PostGreSQL, j'ai créé une foreign table de "matable" et
> j'arrive bien à interagir dessus (select, insert, update, delete)
> depuis PostGreSQL
>
> Si je réalise les opérations suivantes :
> - je me connecte à PostGreSQL avec psql
>
> - je lance un "select * from matable;" depuis PostGreSQL :
> => la connexion s’établit sur MySQL et j'ai bien la liste des lignes
> qui se trouvent dans "matable" de MySQL => je maintiens cette
> connexion PostGreSQL ouverte '1', '2.129'
> '2', '2.129'
> '3', '2.129'
> etc
>
> - je lance un "update matable set mavaleur = '3.229';" depuis MySQL
> et je vérifie les valeurs côtés MySQL : '1', '3.129'
> '2', '3.129'
> '3', '3.129'
> etc
>
> - je relance la lecture depuis PostGreSQL avec la même connexion
> qu'au début : '1', '2.129'
> '2', '2.129'
> '3', '2.129'
> etc
>
> => PostGreSQL ne voit pas les nouvelles valeurs
>
> Après analyse, j'ai découvert :
> - que la connexion établit de PostGreSQL vers MySQL ressemble à du
> persistent : elle reste ouverte tant que la console psql est ouverte
> ou pendant X secondes
> - que le même update lancé depuis PostGreSQL sur la table MySQL
> permettait à PostGreSQL de voir les bonnes valeurs avec un select
> (3.129)
> - quelque soit le moyen utilisé, si la connexion de PostGreSQL à
> MySQL est une nouvelle connexion, les données affichées seront les
> bonnes (3.129)
>
> Pour forcer la connexion de PostGreSQL à MySQL, plusieurs moyens :
> - rouvrir une connexion à PostGreSQL en parallèle ou en fermant la
> connexion d'origine
> - redémarrant MySQL
> - redémarrant PostGreSQL
> - attendant X secondes que la connexion de PostGreSQL vers MySQL
> tombe en timeout
>
> J'ai cherché dans le peu de documentation du connecteur et je n'ai
> pas l'impression qu'il soit possible de désactiver le côté
> "persistant" de la connexion PostGreSQL -> MySQL mais j'ai peut être
> loupé quelque chose.
>
> J'ai donc plusieurs questions :
> - est-ce que quelqu'un sait s'il est possible de désactiver ce côté
> persistant / faire tomber le timeout à 0 ?
> - quelle est la valeur de ce timeout ?
> - est-ce qu'il est possible de demander à PostGreSQL à ne pas
> utiliser ce qui ressemble à du "cache" ?
>
> J'en profite pour poser une autre question.
> J'ai remarqué qu'une transaction côté PostGreSQL n'était pas gérée
> côté MySQL. Si je démarre une transaction sur PostGreSQL, que je fais
> deux updates (un dans une foreign table MySQL, un dans une table
> native PostGreSQL) et que je rollback :
> - l'update est annulé sur la table native PostGreSQL
> - l'update est commité sur la table MySQL
>
> J'ai essayé de jouer avec autocommit des deux côtés mais rien y fait
> et il semble que la gestion des transactions ne soient pas intégrée
> aux connecteurs FDW. La question est donc : est-ce que quelqu'un sait
> s'il est prévu de gérer les transactions dans une future version de
> PostGreSQL et, si oui, dans laquelle ?
>
> Je vous remercie d'avance et vous souhaite une bonne journée.
>
> Cordialement,
> Bertrand ROBERT
>
bonjour,

il existe plusieures manières de migrer les tables de MySQL vers
PostgreSQL :

https://en.wikibooks.org/wiki/Converting_MySQL_to_PostgreSQL

https://wiki.postgresql.org/wiki/Converting_from_other_Databases_to_PostgreSQL#MySQL

en passant par ruby :

https://t37.net/comment-convertir-une-base-de-donnees-mysql-vers-postgresql-pour-les-manchots.html

petit topo linuxfr :

https://linuxfr.org/forums/programmation-sql/posts/migrer-de-mysql-vers-prostgre

liste des paquets nécessaires :

cl-pgloader - extract, transform and load data into PostgreSQL
pgloader - extract, transform and load data into PostgreSQL

slt
bernard

--
bernard schoenacker <bernard(dot)schoenacker(at)free(dot)fr>

__________ Information from ESET Mail Security, version of virus signature database 14604 (20161214) __________

The message was checked by ESET Mail Security.
http://www.eset.com

__________ Information from ESET Mail Security, version of virus signature database 14604 (20161214) __________

The message was checked by ESET Mail Security.
http://www.eset.com