Ca ne règle en rien les problèmes de réconciliation.

Une autre solution c'est de le gérer au niveau de l'appli : tu loggues systématiquement toutes les modif (insert / update / delete suffisent dans ton cas, au cas où tu modifies la structure des tables, on suppose que tu fais une procédure de migration ) et tu rejoues chaque modif en appelant un webservice sur l'autre serveur par exemple.

gizmo> de fait.
Tiens je l'avais raté cet howto là...mais de fait c'est pas du nat à mysql, donc on est encore un peu trop dans du brcolage à mon gout...

vais finir par tout foutre sur un seul serveur je le sens...

Ce n'est pas du tout la meme utilisation. Dans le cluster de MySQL, l'info n'est pas dupliquee mais repartie sur plusieurs serveurs pour alleger la charge de chacun.

Ce que blietaer demande, c'est plus une architecture du type master-master, dont un tutoriel est explique ici: http://www.howtoforge.com/mysql_master_master_replication

Maintenant, il faut aussi savoir que si c'est possible, c'est quelque chose qui est assez mal supporte par MySQL et qui ne fonctionnera proprement que pour un trafic leger a moyen avec des risques de colisions faibles.

Attention le cluster mysql est limité à un LAN si je ne m'abuse ? Je ne sais pas dans quelle mesure on peut le leurrer via un VPN (sûrement possible si la plage d'ip est la même)...

mysql supporte le cluster depuis la version 4.1 si je ne m'abuse

dans ce cas, pas de maitre ni escale, mais une grappe

Autre solution : mettre ton serveur MySQL sur une ligne qui a bon upload. Du coup, tu n'as le bottle-neck qu'a l'envoie depuis les deux ADSL. Tu décentralises ton serveur, mais au mois, tu gagnes en réactivité et en simplicité.
C'est une application critique au point de devoir être dispo en cas de plantage d'ADSL (qui n'arrive pas si souvent, soyons honnêtes)?

Ce n'est pas du tout hors sujet: cette solution est toujours en lice.
La seule chose c'est que toutes les transactions doivent alors emprunter ce double bottle-neck, j'ai un peu peur de la réactivité du bazard, alors que si une des deux ADSL vient à se péter la gueule, le truc reste fonctionnel en local...jusqu'à la prochaine synchro (en espérant que l'on ne dépasse pas les 10min de downtime... :chut:)

Et pourquoi ne pas tout rapatrier sur un seul serveur?
(oui, je sais, je suis hors sujet, mais c'est pour mieux comprendre...)

Bonjour,

Je crois que je pose ici un problème vieux comme le byte: maintenir des tables/DBs synchro entre plusieurs serveurs séparés par ce qu'on pourrait comparer à deux connections ADSL de base (3.6M/384k)

Le résultat de mes googlages m'entraîne principalement vers des solutions où reigne un maître sur un esclave (avec l'écrasement à sens-unique qui en découle)

Mes critères sont les suivants:
- les deux serveurs doivent fournir la même information (*)
- les deux serveurs doivent être capables de subir des inputations
- les deux serveurs doivent être aware des inputations effectuées sur l'autre (et vice-versa)
- Il ne s'agit probablement pas de toute une grosse DB grasse, mais de quelques tables ponctuelles, ou, pour être exact: quelques lignes de ces tables (abah forcément... )

(*) un délai de +/-10min est tout à fait tolérable pour la synchronisation, dans le sens où c'est exactement le temps que mettrait une personne pour aller consulter/modifier ses infos sur un serveur et puis l'autre (et vice-versa)


Est-il possible de s'en sortir sans ajouter un gros timestamp sur chaque ligne et de faire une moulinette crasse qui les compare à tour de bras?

J'ai du mal à croire que c'est un truc extraterrestre ou un défaut de design qui me pousse à vouloir cela, mais je me rends bien compte que mon handicap ici est la rapidité des deux ADSL...

Bien le merci!