Discussion :

[Thotem]

Bonjour à tous.

Je suis en stage, et je dois développer tout un système d'information, de sa conception à son déploiement. Donc, instaurer une stratégie de sauvegarde. Et c'est là-dessus que j'aurais besoin de conseils, car n'ayant aucune expérience professionnelle, j'avoue ne pas trop savoir que faire.

En gros, mon employeur souhaiterait une BDD centralisée, utilisable à Paris comme à Nantes. Mais comme tout le travail de l'entreprise repose sur cette BDD (analyse : modification et consultation), il ne veut pas non plus risquer une improductivité (à juste titre), dans le cas où l'hébergeur connaîtrait des problèmes, ou encore une connexion Internet défectueuse, que ce soit ponctuel (une journée) ou long (une semaine).
Donc, dans l'idée, ce serait une BDD stockée en ligne, mais récupérée sur un serveur local à Paris comme à Nantes. On travaille en local, et régulièrement, la BDD locale est ré-enregistrée en ligne et/ou récupérée (dès qu'elle est modifiée d'un côté ou de l'autre).

Sur le fond, à la rigueur, pas de problèmes (Si ?). Encore que, je vois comment réaliser ce dump par PHP, mais je ne sais pas comment automatiser la récupération et le déploiement de ce dump sur le serveur local (ou sur le serveur Web dans l'autre sens ).

C'est là que ça se complique. La BDD peut être modifiée à Paris ou à Nantes. Les utilisateurs peuvent être amenés à travailler sur les mêmes tables, mais en aucun cas sur une les mêmes tuples.
Donc je ne sais pas comment réaliser ce système de sauvegarde, pour que l'on puisse travailler en local d'un côté comme de l'autre, et que les modifications effectuées à Paris, soit régulièrement updatées en ligne, récupérées par Nantes quelques minutes après, sans perdre les modifications effectuées sur Nantes entre-temps (et vice-versa, de Nantes vers Paris). Je ne sais pas si je suis clair, mais pour moi, on se situerait pas loin du miracle informatique.

Dans le cas où ce ne serait pas possible, ce que je pense, comment puis-je rassurer mon employeur sur le bon fonctionnement des BDD exlusivement en ligne (avec du coup, seulement une stratégie de sauvegarde simple par mysqldump, pour restauration manuelle en cas de crash d'hébergement) ? Puis-je lui garantir un hébergeur pro (mutualisé ? Dédié ? je ne sais pas non plus...) extrêmement fiable (et, si vous en connaissez un qui propose des services exceptionnels pour un prix valable ) ?

Je sais que je commence mal, premier post (mais pas premier passage ! Dev.c est une aide déjà précieuse depuis trop longtemps), et déjà si chiant...
Merci d'avance !

[Thotem]

Bon, après réflexion, je me demande si ce n'est pas plus simple de mettre en place un serveur local dans les murs.
Ce serveur stockera la BDD et un intranet (stocké sur la même machine) permettant de l'utiliser via le réseau local. En parallèle, ceux de l'extérieur auront accès, par le portail internet (stocké chez un hébergeur pour le coup, pas sur le serveur interne), à une duplication de cet intranet, toujours en intervenant directement sur la BDD du serveur local, via un nom de domaine et du DynDNS (en externe) et du DNS en interne.
Comme ça, je peux gérer simplement le problème de l'accès internet en garantissant un accès permanent à une bonne partie des utilisateurs (dans la maison mère) ; le problème de la sauvegarde est également simplifié...

J'voudrais juste des avis éclairés sur ce système...Merci

PS : Je sais, ça dérive un peu du sujet initial, qui était le problème de la stratégie de sauvegarde. Sauf que la solution énoncée ne le résout pas forcément, car masquant peut-être d'autres problèmes. Les commentaires des pros/expérimentés sont attendus

[erol972]

Ton problème peut trouver une solution avec la réplication de bases
http://dev.mysql.com/doc/refman/5.0/fr/replication.html
Erol

[Sivrît]

Le plus simple est clairement que toutes les applications fassent leur modifications sur la même BDD, et sur ce point la réplication n'aide pas car elle est à sens unique et les modifications doivent être faites sur le serveur maître.

A moins que l'application ne soit assez simple pour pouvoir synchroniser deux bases facilement (on peut rêver), ce qui permettrait peut-être (si le trafic est raisonnable) d'avoir un maitre en ligne et des répliques locales. Mais si le maître tombe il faudra à sa restauration synchroniser les deux esclaves locaux qui auront évolués séparément. A moins que chacun ne travaille sur des données bien identifiées... et encore ce sera pénible (et pas du ressort de mysqldump).

Même avec un serveur sur intranet, la réplication peut quand même servir pour éviter une indisponibilité en cas de panne (si la base est vitale à l'entreprise, ça compte). Par contre une réplique ne dispense pas de faire des dumps de temps à autre (il peuvent être faits sur la réplique pour ne pas charger le maître) car un bug ou une action malveillante va aussi pourrir la réplique.

[overider]

tu peux envisager de faire une replication circulaire



SERVEUR1 => SERVEUR2 => SERVEUR3 => SERVEUR1

C ce qu'on a chez nous et une fois en palce ça marche bien.

Et si tu es sur que tes utilisateur ne travaille jamais sur le meme tuple, alors la tu as tout gagné car tu peux mettre à jour n'importe lequel de tes serveur.