synchros de bdd - Page 1

Salut les enfants,
J'ai deux bases de données identiques, l'une étant sur un serveur maître distant et l'autre sur un cache local.
Historiquement, les clés primaires sont des entiers auto incrémentés (le cache local est une nouveauté).
Comment s'en sortir proprement pour la gestion des clés primaires ? Tout ce que je vois, à priori, c'est de piloter la création via le serveur maître distant, qui sera seul apte à donner des clés primaires, et de synchroniser le serveur cache local en fonction. Mais du coup, ça implique de rendre la clé primaire de la version locale éditable arbitrairement via le code de l'appli, non ? (avec une contrainte d'unicité, évidemment)
Avez vous une idée de pattern qui serait plus transparent pour les BDD locales ?
Merci d'avance

Suivant le type de bases de données, tu dois pouvoir disposer de mécanismes de réplication externes, non ? (donc sans passer par du SQL, mais par des fichiers de logs transactionnels, comme ce qui se fait avec BDB). C'est quoi comme BDD ?

Nil (./2) :
Suivant le type de bases de données, tu dois pouvoir disposer de mécanismes de réplication externes, non ?

Je ne connais pas bien le domaine, mais je ne pense pas : on doit pouvoir contrôler finement le moment de la synchro, qui doit se faire presque à la demande et par projet, en fonction des étapes du workflow. En fait on reste sur le serveur local tant qu'on peut, puis le serveur local doit passer la main au serveur distant distant en particulier lors du déclenchement d'un calcul. Le serveur distant doit alors recevoir les infos à jour, puis faire le calcul, puis renvoyer les infos au serveur local.

Nil (./2) :
C'est quoi comme BDD ?

mysql

(mmm, j'ai toujours cru que le numéro était auto incrémenté, mais en fait apparemment non )

Hm, tu as une autre solution... un trigger sur le maître, qui fait ça :
- Récupération de la valeur donnée pour l'auto incrément de la dernière requête en écriture du Maître (je ne sais pas comment l'avoir, mais vu qu'on peut la récupérer en PHP, il n'y a aucune raison que l'API de base MySQL ne permette pas de la récupérer
- un début de transaction
- ALTER TABLE <tablename> AUTO_INCREMENT=<value> sur l'esclave
- La requête SQL sur l'esclave
- une fin de transaction

Pas possible ?

Edit : ah, je n'avais pas compris que tu ne voulais pas une réplication instantanée... du coup, ça devient plus compliqué...

./3 : mysql a des mécanismes de réplication, par contre, avec les mécanismes standards, c'est du master <=> slave, l'esclave étant alors dédié à faire du readonly : si tu fais un update ou quoi que ce soit dessus, tu prends le risque de casser ta réplication.

Pen^2 (./3) :
on doit pouvoir contrôler finement le moment de la synchro

tu peux le faire : en gros, ton master génère des binlogs... L'esclave est mis en pause. Et quand tu le souhaites, tu le démarres, et il synchronise. Par contre, même impératif qu'avant : tu ne dois faire aucun update sur l'esclave.


Après, tu peux faire des choses un peu fun : master <=> master. ça marche si on fait bien gaffe et si l'application en amont est bien gaulée (pas trivial).
en gros, tu fais comme un master slave, mais dans les deux sens. Tu as un mécanisme pour empêcher les update cycliques. Et pour les auto incrément, tu peux modifier le comportement par défaut, pour que chaque serveur génère un auto incrément différent : l'un en 2*n, l'autre en 2*n+1.
=> dans ton cas :

SRV1, SRV2
SRV1 == master, génère des binlogs. slave de SRV2, stoppé.
SRV2 == slave synchronisé, puis stoppé.

quand tu souhaites faire la bascule SRV1 => SRV2 :
SRV2 synchronise sur SRV1 (start slave; show slave status => dès que OK, stop slave
le traitement bascule sur SRV2, il bidouille... Et SRV2 génère du coup des binlogs.
quand traitement fini :
SRV1 : start slave; show master status => dès que fini, pouf pouf, tu peux rebasculer.
SRV2 : stop slave;

par contre :
* ne jamais purger les binlogs qui n'ont pas été consommés par le serveur distant
* chaque serveur doit générer des auto incrément différents.
* chaque serveur ne doit pas générer de binlog pour ce qu'il reçoit de son master
* ton appli doit être aware de tout ça

note : je raccourcis, mais en gros, l'idée devrait fonctionner, faut bien le gauler

Pour éviter ces problèmes, il devrait être possible d'utiliser des ensembles de clés primaires disjoints. Par exemple, le serveur ne crée que des clés paires et l'esclave que des impaires (ou des clés Nk + i pour le i-ème serveur parmi N).

y'a pas une option de load balancing dans l'install serveur de MySQL ? et sionn, quid de l'utilisation d'un moniteur transactionnel (genre Tuxedo, mais j'imagine qu'il est hors budget)

./7 : c'est un peu ce que j'expliquais plus haut, pour les auto incrément
./8 : mysql sait faire du transactionnel (innodb)

Je sais mais l'avantage d'un moniteur transactionnel, c'est qu'il est souvent capable de gérer le load balancing entre les serveurs de BDD

kim (./9) :
./7 : c'est un peu ce que j'expliquais plus haut, pour les auto incrément

En effet, c'est exactement ça. On va dire que c'est un cross (oui de deux heures )