Discussion :

[randriano]

Bonjour,

Est-il bon d'avoir procéder comme ceci?
On a créé une application pour une société à plusieurs agences
Cette société ne possède pas le moyen des grandes firmes comme les banques qui peuvent avoir un seul serveur puissant à l'agence centrale et que les agences sont interconnectées par des matos hauts de gamme
Pour cette société, on va relier les agences par VPN (Internet) de plus faible débit que les réseaux locaux des agences, chaque agence est donc muni d'un serveur et AU DEPART, tous les serveurs ont donc les même données dans leurs BD

On a pensé à une REPLICATION pour les transferts des données entre agences
Est-ce que c'est correct?

[overider]

oui c'est correct.

On utilise ce procédé en réplication circulaire dans la boite ou je travaille. Attention toutefois si chaque serveur d'agence peut insérer des données au mêmes moments il faut appliquer des techniques avancés de réplication.

en activant ces variables de démarage
# auto_increment_increment
# auto_increment_offset



Je te renvoie a un des mes posts:
http://www.developpez.net/forums/d81...maitre-maitre/

[randriano]

Réplication! Synchronisation de base de données entre des endroits géographiquement distants!

Je n'ai jamais fait cela mais je dois y passer
Il faut synchroniser les BD de plus de 19 agences d'une organisation. De plus, vu qu'ils sont interconnectés par Internet, le transfert n'est pas sûr de réussir!
De plus cette réplication ou synchronisation, je ne sais plus, doit se faire assez fréquemment = toutes les heures au mieux ou à la fin de la journée au pire

Qu'en pensez-vous? Est-ce que je suis dans la merde?

[overider]

Cela veut 'il dire que chaque agence peut faire des insertions dans les bases et que ces modifications sont a reporté sur tous les serveurs.

Si c'est le cas oui. T'es plutot dans la merde.

La réplication circulaire c'est bien mais il faut pas trop mettre de serveur dans la boucle.

la réplication est un système d'iuntégration des donnés semi synchrone.

la synchronisation c'est à toi de l'implementer (mysqldump)

quelques questions :
est ce que ta base doit être 100% joignable tous le temps ?



tel que je vois ton réseau, si tu veux faire de la réplication (circulaire)

il faut que tu definnisses quelques serveurs d'intégration (pas plus de 9 d'apres les spec de la doc de Mysql). C'est sur eux que tu dois faire tes DML insert/update/delete/. Ton serveur d'agence ne te servira que pour les select.


Hesites pas à me contacter par mp

[randriano]

En fait, il y a une vraie dilemme sur le choix même du SGBD à utiliser
Le problème à la réplication c'est au niveau de la clé primaire car cela doit être unique or la réplication risque de changer les valeurs des clés étrangères des tables
Dommage MySql n'a pas le type "uniqueidentifier" comme sous SQL Server

Est-ce que ça s'utilise du MyIsam pour une BD avec beaucoup de tables de liaison: nécessité de CASCADE DELETE, de transactions et de déclencheurs

[CinePhil]

Je ne connais pas les techniques de réplication mais sur ça :

Est-ce que ça s'utilise du MyIsam pour une BD avec beaucoup de tables de liaison: nécessité de CASCADE DELETE, de transactions et de déclencheurs

Pas de clés étrangères et encore moins de contraintes ON DELETE CASCADE avec le moteur MyISAM. Il faut passer au moteur InnoDB... ou changer de SGBD... Postgresql par exemple mais c'est peut-être galère aussi au niveau réplication.

J'imagine que des SGBDR plus pro mais aussi (potentiellement beaucoup) plus chers tels que Oracle, DB2 ou MS SQL Server seront mieux à même de gérer ce genre de chose.

Le volume de données est-il si important que ça pour justifier une BDD répartie sur les 19 agences ? Le serveur centralisé est quand même une solution plus simple.