Réplication de données sur MySQL
Bonjour,
Voila j'essaie de faire de la réplication de données entre deux base de données. C'est-à-dire avoir les mêmes données sur les deux bases en temps réel(enfin presque ;)
Ce que je fais
Pour explication, j'ai une application avec une version en locale et une autre en ligne. L'idée c'est de ne pas avoir d'interruption d'utilisation lorsqu'il n'y a pas d'accès internet. Chaque modification sur la base de données en ligne(maître) doit être répliquée sur le serveur en local(esclave) et inversement. Après des recherches, j'ai trouvé comment faire cela sur Mysql. Le seul hic, c'est qu'en ligne, je suis sur un serveur mutualisé et j'ai donc pas la main pour configurer cela.
Ce que je veux
Quelqu'un aurait il une idée à me proposer pour régler mon problème? Merci d'avance.
3 réponses
Malheuresement c'est içi que les offres mutualisés posent leurs limites , à ma connaisance aucun ne propose ce service , par contre tu peut créer un scrit qui calcul les différences entre ta base de données local et la distante qui les ajustes en conséquence , ce qui pourras te compenser ce manque de flexibilité en attendant un changement d'hébergeur futur ?
Bonjour.
Je pense que ta façon de faire/penser n'est pas la bonne, tu devrais plutôt faire en sorte que ton site distant (en ligne) puisse se comporter en tant qu'API, de cette manière, au lieu de faire des intéractions avec deux bases de données différentes, seul le site distant fera des intéractions avec la base de données (distante également) et ton site en local ne ferait que des appels auprès de ton site distant pour que celui-ci fasse les requête SQL (SELECT, INSERT, UPDATE et DELETE).
Car avec une seule base de donnée, tu peux faire un système de versionning pour les enregistrements de celle-ci, mais tu ne peux pas faire la comparaison entre deux bases de données différentes, même si elles ont les mêmes tables et mêmes champs.
Donc pour faire simple, lorsqu'avec ton site local tu veux faire des requêtes en base de données, quelque soit le type de requête, tu fais appel à ton site distant qui se chargera de faire les requêtes SQL, tel qu'une API.
Concernant le cas où tu peux te retrouver sans connexion internet, tu peux par exemple faire une tâche cron du côté de ton site distant, de manière à ce qu'il fasse une fois par jour un dump de la base de données et le transfère sur un système de stockage de fichier auquel tu as une synchronisation en local (Dropbox par exemple), de cette manière si un moment donné ton site local n'arrive pas à joindre ton site distant, tu récupères le dernier dump auquel tu as accès en local, tu alimentes ta base données locale et tu pourras au moins faire de la consultation auprès de la base de données avec des données les plus récentes.
Les noeuds sql ne peuvent pas fonctionner comme ca.
pour qu'ils soient parfaitement synchro, ils echangent en permanences les données, (maitre - maitre) Mais si coupure il y a, les bdd vont etre down le temps de la resynchro. Tu veux faire tomber ton site en prod parce que vous n'avez plus internet au bureau ? ... t'es sur de toi ? ...
d'ailleur, un cluster SQL c'est minimum 3 noeuds.
Tout simplement parce que quand t'as une coupure sur un noeud d'un cluster de 2 machine. donc plus de communication et que les 2 se synchronizent... qui détient la vérité sur l'etat de la bdd ? plantage ! site down.
Alors que si t'en met un nombre impair, se probleme se pose pas.
(bon au cas ou les 3 noeuds plantent, tu redémarres les noeuds 1 par 1 en specifiant qui synchro qui etc...)
Au pire dans ton cas, l'idée de lartak est la meilleur je pense. tous les soirs, un dump de la base de prod et tu la montes sur ton serveur local
parce que meme en maitre / esclave, t'as une coupure au bureau, t'arrive a switch sur ta bdd locale. ok super. tu bosse sans internet pendant 2h... Ah j'ai de nouveau internet. cool. donc synchro des bdd, il se passe quoi ? ca efface ton travail au bureau ? ca efface des données en prod car ta bdd a "déjà" 2h... tout ca pour rien ? 2h... -_-
Et si vous avez plus internet au bureau... bah... on le vit tous ca....... faut plutot faire en sorte que ca n'arrive pas pour bosser sur la prod autant que possible...