Discussion :

[pdelorme]

bonjour,

J'ai une base de donnée qui est accédé de plusieurs endroits dans le monde. certain de ces endroits bénéficie d'une bande passante très faible, ce qui rend l'accès directe à la base impraticable.

Pour résoudre se problème de temps de réponse, j'imagine de répliquer ma base sur les différents lieux d'accès. Les accès seraient alors locaux et rapide.

La base doit être modifiable depuis toutes ses réplications et les changements doivent être synchronisés de sorte a ce que mes bases soient (a peut près) toujours les même à un temps t.

Je cherche donc un mécanisme de réplication postgres qui :
- supporte plusieurs bases maitre (2 pour l'instant).
- synchronise les données d'une base à l'autre.
- ne bloque pas les accès durant la synchronisation.
- ne soit pas nécessairement temps reél.
- ne "gache" pas la bande passante.

j'ai jeté un oeuil à pgCluster mais j'ai c'est pas très clair

des idées, du vécu?

merci

Patrice.

[scheu]

Je ne pense pas que Postgresql, dans les versions actuelles, propose des outils pour faire ce genre d'architecture évoluée
Tu as éventuellement les dblinks mais ça voudrait dire que pour chaque insert/update/delete sur 1 maître, il faudrait un trigger qui le réplique via dblink ... Ca deviendrait vite une usine à gaz ...

C'est à mon avis en tout très difficile de faire du synchrone avec Postgresql

[SQLpro]

Ce que vous recherchez c'est faire une réplication de fusion. Ce n'est peut être pas implémenté sous PG. Mais vous pouvez le faire à la main. Ceci dit cela représente beaucoup de travail pour réaliser une telle chose alors que certains SGBDR proposent cela en standard (MS SQL Server).
En effet il faut entre autre :
1) ajouter une colonne avec un GUID dans toutes les tables répliquées
2) prévoir 3 triggers (INSERT + UPDATE + DELETE) dans chacune des tables répliquées
3) centraliser les mises à jours distribuées dans une base (qui servira aussi pour la gestion des conflits)
4) prévoir que les clefs auto incrémentée ne se recoupent pas (gérer les auto incrément par plage ou modulo)
5) introduire une gestion des conflits de réplication (qui gagne en cas de MAJ des deux côtés).

Bref, quelques mois de développement au minimum pour réaliser tout cela et un bon DBA pour gérer les conflits et surveiller la charge.

A +

[pdelorme]

SQLPro, savez vous ou je peux trouver de la documentation sur le sujet?
cette approche m'intéresse.

quelles sont les solutions pour la résolution des conflits?
je pense notamment aux contraintes d'unicités et aux intégrités référentielles mises à mal par une suppression d'un coté et un ajout de l'autre.

merci,

P.

[SQLpro]

SQLPro, savez vous ou je peux trouver de la documentation sur le sujet?

Fouillez le net avec les mots clef MERGE REPLICATION.

quelles sont les solutions pour la résolution des conflits?

Il s'agit de régles métiers à implanter dans le SGBDR. malgré cela il faut un outil de gestion des conflits.

Exemple : règle métier = données la plus récente. Si data1.datatimeRefresh = data2.datatimeRefresh alors, faire tomber les tuples dans une base de gestion de conflit et demander au DBA comment il arbitre.

Compter 3 à 6 mois de développement pour un spécialiste SQL... Bon courage !

PS : ceci existe en standard dans SQL Server....

A +

[pdelorme]

Compter 3 à 6 mois de développement pour un spécialiste SQL... Bon courage !

Oups, merci pour l'encouragement....

P.

[SQLpro]

J'ai oublié de vous dire, pour les règles métier, c'est à mettre dans un déclencheur.

A +

[scheu]

Franchement si j'étais toi je prendrais le problème à la base
Ca reviendrait sûrement moins cher d'investir dans une bande passante plus rapide que de passer 6 mois à développer une usine à gaz ...

Si réellement ton réseau ne peut pas être plus rapide il te faut trouver des compromis :
- les utilisateurs de tes différents sites peuvent-ils modifier les mêmes données ? si non, chaque site pourrait avoir son schéma de données principal de travail
- peux-tu envisager un rafraichissement asynchrone via export/import entre tes sites ? dans ce cas tu ne transfèrerais que le dump compressé par le réseau ...

[SQLpro]

Ou encore changer de SGBDR !!! J'ai déjà vu des rigolos prendre MySQL et développer pendant 6 mois des outils qui existent en standard dans la concurrence et sont mille fois plus stable... Mais le mythe du free qui coute pas cher....

A +

[kedare]

Ou encore changer de SGBDR !!! J'ai déjà vu des rigolos prendre MySQL et développer pendant 6 mois des outils qui existent en standard dans la concurrence et sont mille fois plus stable... Mais le mythe du free qui coute pas cher....

A +

Le problème c'est que tout le monde n'a pas les moyens ou l'envie d'aller sur MS-SQL et Windows Server (dont moi)

[SQLpro]

Les envies des uns ne sont pas toujours compatible avec la réalité économique des autres !

A +

[kedare]

Les envies des uns ne sont pas toujours compatible avec la réalité économique des autres !

A +

Je doute qu'une solution sous Windows Server + MS SQL Server soit plus économique qu'une solution sous Linux (Debian ou Fedora) ou BSD et Postgresql,
surtout qu'après il faut payer les grosses mises a jours si l'on veut beneficier des dernières nouveautés (WS2003->WS2008, SQLSERVER2005->SQLSERVER2008),
Personnellement j'ai déjà essayé SQLSERVER2008... Plus jamais je re-installe ce truc, c'est pire que mysql niveau respect du SQL (genre les GO, sp_truc, [table]....)
Enfin bon après c'est pas un sujet Postgresql vs Mssql, chacun ses gouts

[SQLpro]

Je doute qu'une solution sous Windows Server + MS SQL Server soit plus économique qu'une solution sous Linux (Debian ou Fedora) ou BSD et Postgresql

Ce n'est pas ce que disent les études....
Voici un exemple :
http://www.sco.com/products/unixware...p_Analysis.pdf

A +

[kedare]

Ce n'est pas ce que disent les études....
Voici un exemple :
http://www.sco.com/products/unixware...p_Analysis.pdf

A +

Ah oui... Red Hat Linux, le linux proprio payant que personne utilise...
Je pensais plutôt a des technologies open source en disant linux (genre debian)

[scheu]

Ah oui... Red Hat Linux, le linux proprio payant que personne utilise...
Je pensais plutôt a des technologies open source en disant linux (genre debian)

Red Hat Linux est un bon compromis pour une entreprise souhaitant passer à l'open source, ce n'est pas du tout un système fermé et proprio ou chaque évolution ou mise à jour nécessite de payer ...

[kedare]

Red Hat Linux est un bon compromis pour une entreprise souhaitant passer à l'open source, ce n'est pas du tout un système fermé et proprio ou chaque évolution ou mise à jour nécessite de payer ...

Je vois pas trop les avantages de RedHat par apport a Debian, Centos, Archlinux ou autres distributions open-source.. A par le "c'est payant donc ca fait bien"

[pdelorme]

Merci pour ce débat open source/propriétaire passionnant.
mais pour en revenir au sujet initial :

- peux-tu envisager un rafraichissement asynchrone via export/import entre tes sites ? dans ce cas tu ne transfèrerais que le dump compressé par le réseau ...

dans ce cas comment merge t'on les données? existe t'il des algos connus?

merci

P.

[lelutin]

Bonjour,

désolé de m'immiscer dans la discussion mais comme le rappel pdelorme, il n'y pas besoin de réplication/propagation en temps réel.
Je pense que de simples scripts basés sur les entrées de log pour charger une base tampon de chaque coté et un autre en cron pour transformer la BD cible serait peut-être suffisant (on peut aussi faire un script basé sur les logs sans BD). Des outils d'ETL comme Talend (version gratuite biensur(désolé pour la pub, c'est pas le but)) peuvent être étudiés comme solution, ne pensez vous pas?


ps: Parallèlement, j'aurais aimé que SQLPro nous explique pourquoi un tel dev devrait mettre 3à6 mois/H pour arriver en prod?
(Ayant à faire à peu près la même chose (en un peu plus compliqué et sur de multiples systèmes hétérogènes), cela me semble, personnellement un peu disproportionné en terme de délais; mais je peux me tromper (à ce moment-là, je suis vraiment dans la **** (j'en ai + de 10 à réaliser sur la même période))

[SQLpro]

dans ce cas comment merge t'on les données? existe t'il des algos connus?

Le problème est toujours le même : c'est spécifique à votre organisation. A vous de le développer.
Par exemple cela peut être le dernier à toujours raison. Mais il faut prévoir le cas ou les modif auront été faites exactement au même moment à chaque bout de la chaîne (gestion des conflits). Or les données continuent à arriver de part et d'autre !

A +